[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [CI,1/3] drm/i915: Suspend submission tasklets around wedging

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Suspend submission tasklets 
around wedging
URL   : https://patchwork.freedesktop.org/series/39312/
State : warning

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-2p-primscrn-pri-indfb-draw-pwrite:
pass   -> SKIP   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +1
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
incomplete -> PASS   (shard-hsw) fdo#105087
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#105087 https://bugs.freedesktop.org/show_bug.cgi?id=105087
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-apltotal:3463 pass:1822 dwarn:1   dfail:0   fail:7   skip:1632 
time:12480s
shard-hswtotal:3463 pass:1770 dwarn:1   dfail:0   fail:0   skip:1691 
time:12160s
shard-snbtotal:3463 pass:1361 dwarn:2   dfail:0   fail:1   skip:2099 
time:7015s
Blacklisted hosts:
shard-kbltotal:3442 pass:1932 dwarn:3   dfail:0   fail:8   skip:1498 
time:9566s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8224/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

[Rodrigo Vivi]

On Fri, Mar 02, 2018 at 11:20:42PM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Thu, 2018-03-01 at 12:53 +0200, Ville Syrjälä wrote:
> > On Wed, Feb 28, 2018 at 11:55:39PM +, Souza, Jose wrote:
> > > On Wed, 2018-02-28 at 13:09 +0200, Ville Syrjälä wrote:
> > > > On Wed, Feb 28, 2018 at 12:57:07AM +, Souza, Jose wrote:
> > > > > On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> > > > > > On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza
> > > > > > wrote:
> > > > > > > When PSR/PSR2/GTC is enabled hardware can do AUX transactions
> > > > > > > by it
> > > > > > > self, so lets use the mutex register that is available in gen9+
> > > > > > > to
> > > > > > > avoid concurrent access by hardware and driver.
> > > > > > > Older gen handling will be done separated.
> > > > > > > 
> > > > > > > Reference: https://01.org/sites/default/files/documentation/int
> > > > > > > el-g
> > > > > > > fx-prm-osrc-skl-vol12-display.pdf
> > > > > > > Page 198 - AUX programming sequence
> > > > > > > 
> > > > > > > Reviewed-by: Dhinakaran Pandiyan  > > > > > > >
> > > > > > > Reviewed-by: Rodrigo Vivi 
> > > > > > > Cc: Jani Nikula 
> > > > > > > Cc: Ville Syrjälä 
> > > > > > > Signed-off-by: José Roberto de Souza 
> > > > > > > ---
> > > > > > > 
> > > > > > > Changelog:
> > > > > > > v2
> > > > > > > - removed the PSR dependency, now getting lock all the times
> > > > > > > when
> > > > > > > available
> > > > > > > - renamed functions to avoid nested calls
> > > > > > > - moved register bits right after the DP_AUX_CH_MUTEX()
> > > > > > > - removed 'drm/i915: keep AUX powered while PSR is enabled'
> > > > > > > Dhinakaran Pandiyan will sent a better and final version
> > > > > > > v3
> > > > > > > - rebased on top of Ville's AUX series
> > > > > > > - moved port registers to above DP_AUX_CH_MUTEX()
> > > > > > > - using intel_wait_for_register() instead of the internal
> > > > > > > version
> > > > > > > v4
> > > > > > > - removed virtual function to get mutex register address
> > > > > > > - enabling the mutex back only on aux channel init
> > > > > > > - added the aux channel name to the timeout debug message
> > > > > > > v5
> > > > > > > - renamed DP_AUX_CH_MUTEX() parameter to aux_ch
> > > > > > > - renamed goto label when intel_dp_aux_ch_trylock() fails
> > > > > > > 
> > > > > > >  drivers/gpu/drm/i915/i915_reg.h |  9 
> > > > > > >  drivers/gpu/drm/i915/intel_dp.c | 47
> > > > > > > +
> > > > > > >  2 files changed, 56 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > > > > index eea5b2c537d4..bce2e6dad4c4 100644
> > > > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > > > > @@ -5385,6 +5385,15 @@ enum {
> > > > > > >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> > > > > > >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> > > > > > >  
> > > > > > > +#define _DPA_AUX_CH_MUTEX(dev_priv-
> > > > > > > > info.display_mmio_offset + 0x6402C)
> > > > > > > 
> > > > > > > +#define _DPB_AUX_CH_MUTEX(dev_priv-
> > > > > > > > info.display_mmio_offset + 0x6412C)
> > > > > > > 
> > > > > > > +#define _DPC_AUX_CH_MUTEX(dev_priv-
> > > > > > > > info.display_mmio_offset + 0x6422C)
> > > > > > > 
> > > > > > > +#define _DPD_AUX_CH_MUTEX(dev_priv-
> > > > > > > > info.display_mmio_offset + 0x6432C)
> > > > > > > 
> > > > > > > +#define _DPF_AUX_CH_MUTEX(dev_priv-
> > > > > > > > info.display_mmio_offset + 0x6452C)
> > > > > > > 
> > > > > > > +#define DP_AUX_CH_MUTEX(aux_ch)  _MMIO_PORT(aux_ch,
> > > > > > > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
> > > > > > > +#define   DP_AUX_CH_MUTEX_ENABLE (1 << 31)
> > > > > > > +#define   DP_AUX_CH_MUTEX_STATUS (1 << 30)
> > > > > > > +
> > > > > > >  /*
> > > > > > >   * Computing GMCH M and N values for the Display Port link
> > > > > > >   *
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > index 2a3b3ae4e3da..7f4bf77227cd 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > @@ -1081,6 +1081,42 @@ static uint32_t
> > > > > > > intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> > > > > > >   aux_clock_divi
> > > > > > > der)
> > > > > > > ;
> > > > > > >  }
> > > > > > >  
> > > > > > > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > > > > > > +{
> > > > > > > + struct intel_digital_port *intel_dig_port =
> > > > > > > dp_to_dig_port(intel_dp);
> > > > > > > + struct drm_i915_private *dev_priv =
> > > > > > > + 

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

[Rodrigo Vivi]

Ville Syrjälä  writes:

> On Wed, Feb 28, 2018 at 11:55:39PM +, Souza, Jose wrote:
>> On Wed, 2018-02-28 at 13:09 +0200, Ville Syrjälä wrote:
>> > On Wed, Feb 28, 2018 at 12:57:07AM +, Souza, Jose wrote:
>> > > On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
>> > > > On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza
>> > > > wrote:
>> > > > > When PSR/PSR2/GTC is enabled hardware can do AUX transactions
>> > > > > by it
>> > > > > self, so lets use the mutex register that is available in gen9+
>> > > > > to
>> > > > > avoid concurrent access by hardware and driver.
>> > > > > Older gen handling will be done separated.
>> > > > > 
>> > > > > Reference: https://01.org/sites/default/files/documentation/int
>> > > > > el-g
>> > > > > fx-prm-osrc-skl-vol12-display.pdf
>> > > > > Page 198 - AUX programming sequence
>> > > > > 
>> > > > > Reviewed-by: Dhinakaran Pandiyan > > > > > >
>> > > > > Reviewed-by: Rodrigo Vivi 
>> > > > > Cc: Jani Nikula 
>> > > > > Cc: Ville Syrjälä 
>> > > > > Signed-off-by: José Roberto de Souza 
>> > > > > ---
>> > > > > 
>> > > > > Changelog:
>> > > > > v2
>> > > > > - removed the PSR dependency, now getting lock all the times
>> > > > > when
>> > > > > available
>> > > > > - renamed functions to avoid nested calls
>> > > > > - moved register bits right after the DP_AUX_CH_MUTEX()
>> > > > > - removed 'drm/i915: keep AUX powered while PSR is enabled'
>> > > > > Dhinakaran Pandiyan will sent a better and final version
>> > > > > v3
>> > > > > - rebased on top of Ville's AUX series
>> > > > > - moved port registers to above DP_AUX_CH_MUTEX()
>> > > > > - using intel_wait_for_register() instead of the internal
>> > > > > version
>> > > > > v4
>> > > > > - removed virtual function to get mutex register address
>> > > > > - enabling the mutex back only on aux channel init
>> > > > > - added the aux channel name to the timeout debug message
>> > > > > v5
>> > > > > - renamed DP_AUX_CH_MUTEX() parameter to aux_ch
>> > > > > - renamed goto label when intel_dp_aux_ch_trylock() fails
>> > > > > 
>> > > > >  drivers/gpu/drm/i915/i915_reg.h |  9 
>> > > > >  drivers/gpu/drm/i915/intel_dp.c | 47
>> > > > > +
>> > > > >  2 files changed, 56 insertions(+)
>> > > > > 
>> > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > > > > b/drivers/gpu/drm/i915/i915_reg.h
>> > > > > index eea5b2c537d4..bce2e6dad4c4 100644
>> > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > > > @@ -5385,6 +5385,15 @@ enum {
>> > > > >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
>> > > > >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
>> > > > >  
>> > > > > +#define _DPA_AUX_CH_MUTEX   (dev_priv-
>> > > > > > info.display_mmio_offset + 0x6402C)
>> > > > > 
>> > > > > +#define _DPB_AUX_CH_MUTEX   (dev_priv-
>> > > > > > info.display_mmio_offset + 0x6412C)
>> > > > > 
>> > > > > +#define _DPC_AUX_CH_MUTEX   (dev_priv-
>> > > > > > info.display_mmio_offset + 0x6422C)
>> > > > > 
>> > > > > +#define _DPD_AUX_CH_MUTEX   (dev_priv-
>> > > > > > info.display_mmio_offset + 0x6432C)
>> > > > > 
>> > > > > +#define _DPF_AUX_CH_MUTEX   (dev_priv-
>> > > > > > info.display_mmio_offset + 0x6452C)
>> > > > > 
>> > > > > +#define DP_AUX_CH_MUTEX(aux_ch) _MMIO_PORT(aux_ch,
>> > > > > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
>> > > > > +#define   DP_AUX_CH_MUTEX_ENABLE(1 << 31)
>> > > > > +#define   DP_AUX_CH_MUTEX_STATUS(1 << 30)
>> > > > > +
>> > > > >  /*
>> > > > >   * Computing GMCH M and N values for the Display Port link
>> > > > >   *
>> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> > > > > b/drivers/gpu/drm/i915/intel_dp.c
>> > > > > index 2a3b3ae4e3da..7f4bf77227cd 100644
>> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > > > > @@ -1081,6 +1081,42 @@ static uint32_t
>> > > > > intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
>> > > > >  aux_clock_divi
>> > > > > der)
>> > > > > ;
>> > > > >  }
>> > > > >  
>> > > > > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
>> > > > > +{
>> > > > > +struct intel_digital_port *intel_dig_port =
>> > > > > dp_to_dig_port(intel_dp);
>> > > > > +struct drm_i915_private *dev_priv =
>> > > > > +to_i915(intel_dig_port-
>> > > > > >base.base.dev);
>> > > > > +
>> > > > > +if (INTEL_GEN(dev_priv) < 9)
>> > > > > +return true;
>> > > > > +
>> > > > > +/* Spec says that mutex is acquired when status bit is
>> > > > > read as unset,
>> > > > > + * here waiting for 2msec(+-4 aux transactions) before
>> > > > > give up.
>> > > > > + */
>> > > > > +if 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Suspend submission tasklets around wedging

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Suspend submission tasklets 
around wedging
URL   : https://patchwork.freedesktop.org/series/39312/
State : success

== Summary ==

Series 39312v1 series starting with [CI,1/3] drm/i915: Suspend submission 
tasklets around wedging
https://patchwork.freedesktop.org/api/1.0/series/39312/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:472s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:462s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:395s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:490s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s

4f4e4dd52a3054b01591c3444ab1a91889c46172 drm-tip: 2018y-03m-02d-16h-28m-21s UTC 
integration manifest
32004c94d9c1 drm/i915/execlists: Split spinlock from its irq disabling 
side-effect
ec97b63aecc8 drm/i915/execlists: Move irq state manipulation inside irq 
disabled region
d503d1b6e99e drm/i915: Suspend submission tasklets around wedging

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8224/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

[Pandiyan, Dhinakaran]

On Thu, 2018-03-01 at 12:53 +0200, Ville Syrjälä wrote:
> On Wed, Feb 28, 2018 at 11:55:39PM +, Souza, Jose wrote:
> > On Wed, 2018-02-28 at 13:09 +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 28, 2018 at 12:57:07AM +, Souza, Jose wrote:
> > > > On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> > > > > On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza
> > > > > wrote:
> > > > > > When PSR/PSR2/GTC is enabled hardware can do AUX transactions
> > > > > > by it
> > > > > > self, so lets use the mutex register that is available in gen9+
> > > > > > to
> > > > > > avoid concurrent access by hardware and driver.
> > > > > > Older gen handling will be done separated.
> > > > > > 
> > > > > > Reference: https://01.org/sites/default/files/documentation/int
> > > > > > el-g
> > > > > > fx-prm-osrc-skl-vol12-display.pdf
> > > > > > Page 198 - AUX programming sequence
> > > > > > 
> > > > > > Reviewed-by: Dhinakaran Pandiyan  > > > > > >
> > > > > > Reviewed-by: Rodrigo Vivi 
> > > > > > Cc: Jani Nikula 
> > > > > > Cc: Ville Syrjälä 
> > > > > > Signed-off-by: José Roberto de Souza 
> > > > > > ---
> > > > > > 
> > > > > > Changelog:
> > > > > > v2
> > > > > > - removed the PSR dependency, now getting lock all the times
> > > > > > when
> > > > > > available
> > > > > > - renamed functions to avoid nested calls
> > > > > > - moved register bits right after the DP_AUX_CH_MUTEX()
> > > > > > - removed 'drm/i915: keep AUX powered while PSR is enabled'
> > > > > > Dhinakaran Pandiyan will sent a better and final version
> > > > > > v3
> > > > > > - rebased on top of Ville's AUX series
> > > > > > - moved port registers to above DP_AUX_CH_MUTEX()
> > > > > > - using intel_wait_for_register() instead of the internal
> > > > > > version
> > > > > > v4
> > > > > > - removed virtual function to get mutex register address
> > > > > > - enabling the mutex back only on aux channel init
> > > > > > - added the aux channel name to the timeout debug message
> > > > > > v5
> > > > > > - renamed DP_AUX_CH_MUTEX() parameter to aux_ch
> > > > > > - renamed goto label when intel_dp_aux_ch_trylock() fails
> > > > > > 
> > > > > >  drivers/gpu/drm/i915/i915_reg.h |  9 
> > > > > >  drivers/gpu/drm/i915/intel_dp.c | 47
> > > > > > +
> > > > > >  2 files changed, 56 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > > > index eea5b2c537d4..bce2e6dad4c4 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > > > @@ -5385,6 +5385,15 @@ enum {
> > > > > >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> > > > > >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> > > > > >  
> > > > > > +#define _DPA_AUX_CH_MUTEX  (dev_priv-
> > > > > > > info.display_mmio_offset + 0x6402C)
> > > > > > 
> > > > > > +#define _DPB_AUX_CH_MUTEX  (dev_priv-
> > > > > > > info.display_mmio_offset + 0x6412C)
> > > > > > 
> > > > > > +#define _DPC_AUX_CH_MUTEX  (dev_priv-
> > > > > > > info.display_mmio_offset + 0x6422C)
> > > > > > 
> > > > > > +#define _DPD_AUX_CH_MUTEX  (dev_priv-
> > > > > > > info.display_mmio_offset + 0x6432C)
> > > > > > 
> > > > > > +#define _DPF_AUX_CH_MUTEX  (dev_priv-
> > > > > > > info.display_mmio_offset + 0x6452C)
> > > > > > 
> > > > > > +#define DP_AUX_CH_MUTEX(aux_ch)_MMIO_PORT(aux_ch,
> > > > > > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
> > > > > > +#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
> > > > > > +#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
> > > > > > +
> > > > > >  /*
> > > > > >   * Computing GMCH M and N values for the Display Port link
> > > > > >   *
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > index 2a3b3ae4e3da..7f4bf77227cd 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > @@ -1081,6 +1081,42 @@ static uint32_t
> > > > > > intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> > > > > > aux_clock_divi
> > > > > > der)
> > > > > > ;
> > > > > >  }
> > > > > >  
> > > > > > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > > > > > +{
> > > > > > +   struct intel_digital_port *intel_dig_port =
> > > > > > dp_to_dig_port(intel_dp);
> > > > > > +   struct drm_i915_private *dev_priv =
> > > > > > +   to_i915(intel_dig_port-
> > > > > > >base.base.dev);
> > > > > > +
> > > > > > +   if (INTEL_GEN(dev_priv) < 9)
> > > > > > +   return true;
> > > > > > +
> > > > > > +   /* Spec says that mutex is acquired when status bit is
> > > > > > read as unset,
> > > > > > +* here waiting for 2msec(+-4 aux 

[Intel-gfx] [CI 2/3] drm/i915/execlists: Move irq state manipulation inside irq disabled region

[Chris Wilson]

Although this state (execlists->active and engine->irq_posted) itself is
not protected by the engine->timeline spinlock, it does conveniently
ensure that irqs are disabled. We can use this to protect our
manipulation of the state and so ensure that the next IRQ to arrive sees
consistent state and (hopefully) ignores the reset engine.

Suggested-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Reviewed-by: Mika Kuoppala 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180302131246.22036-1-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_lrc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c1a3636e94fc..0482e54c94f0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
GEM_TRACE("%s seqno=%x\n",
  engine->name, request ? request->global_seqno : 0);
 
-   reset_irq(engine);
-
spin_lock_irqsave(>timeline->lock, flags);
 
+   reset_irq(engine);
+
/*
 * Catch up with any missed context-switch interrupts.
 *
@@ -1636,11 +1636,11 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
/* Push back any incomplete requests for replay after the reset. */
__unwind_incomplete_requests(engine);
 
-   spin_unlock_irqrestore(>timeline->lock, flags);
-
/* Mark all CS interrupts as complete */
execlists->active = 0;
 
+   spin_unlock_irqrestore(>timeline->lock, flags);
+
/* If the request was innocent, we leave the request in the ELSP
 * and will try to replay it on restarting. The context image may
 * have been corrupted by the reset, in which case we may have
-- 
2.16.2

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

[Intel-gfx] [CI 1/3] drm/i915: Suspend submission tasklets around wedging

[Chris Wilson]

After staring hard at sequences like

[   28.199013]  systemd-1   2..s. 26062228us : 
execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
[   28.199095]  systemd-1   2..s. 26062229us : 
execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x, 
active=0x1
[   28.199177]  systemd-1   2..s. 26062230us : 
execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
[   28.199258]  systemd-1   2..s. 26062231us : 
execlists_submission_tasklet: rcs0 completed ctx=0
[   28.199340]  gem_eio-829 1..s1 26066853us : 
execlists_submission_tasklet: rcs0 in[0]:  ctx=1.1, seqno=1, prio=0
[   28.199421]   -0   2..s. 26066863us : 
execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
[   28.199503]   -0   2..s. 26066865us : 
execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x, 
active=0x1
[   28.199585]  gem_eio-829 1..s1 26067077us : 
execlists_submission_tasklet: rcs0 in[1]:  ctx=3.1, seqno=2, prio=0
[   28.199667]  gem_eio-829 1..s1 26067078us : 
execlists_submission_tasklet: rcs0 in[0]:  ctx=1.2, seqno=1, prio=0
[   28.199749]   -0   2..s. 26067084us : 
execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
[   28.199830]   -0   2..s. 26067085us : 
execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001, 
active=0x1
[   28.199912]   -0   2..s. 26067086us : 
execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
[   28.14]  gem_eio-829 2..s. 28246084us : 
execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
[   28.200096]  gem_eio-829 2..s. 28246088us : 
execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001, 
active=0x5
[   28.200178]  gem_eio-829 2..s. 28246089us : 
execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
[   28.200260]  gem_eio-829 2..s. 28246127us : 
execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 
* head + 1] != port->context_id)

the conclusion is that the only place where the ports are reset to zero,
is from engine->cancel_requests called during i915_gem_set_wedged().

The race is horrible as it results from calling set-wedged on active HW
(the GPU reset failed) and as such we need to be careful as the HW state
changes beneath us. Fortunately, it's the same scary conditions as
affect normal reset, so we can reuse the same machinery to disable state
tracking as we clobber it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in set_wedged")
Reviewed-by: Mika Kuoppala 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem.c  | 6 +-
 drivers/gpu/drm/i915/intel_lrc.c | 5 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c29b1a1cbe96..dcdcc09240b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3212,8 +3212,10 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
 * rolling the global seqno forward (since this would complete requests
 * for which we haven't set the fence error to EIO yet).
 */
-   for_each_engine(engine, i915, id)
+   for_each_engine(engine, i915, id) {
+   i915_gem_reset_prepare_engine(engine);
engine->submit_request = nop_submit_request;
+   }
 
/*
 * Make sure no one is running the old callback before we proceed with
@@ -3255,6 +3257,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_init_global_seqno(engine,
   
intel_engine_last_submit(engine));
spin_unlock_irqrestore(>timeline->lock, flags);
+
+   i915_gem_reset_finish_engine(engine);
}
 
wake_up_all(>gpu_error.reset_queue);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 14288743909f..c1a3636e94fc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -687,6 +687,8 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
struct rb_node *rb;
unsigned long flags;
 
+   GEM_TRACE("%s\n", engine->name);
+
spin_lock_irqsave(>timeline->lock, flags);
 
/* Cancel the requests on the HW and clear the ELSP tracker. */
@@ -733,6 +735,9 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
 */
clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
 
+   /* Mark all CS interrupts as complete */
+   execlists->active = 0;
+

[Intel-gfx] [CI 3/3] drm/i915/execlists: Split spinlock from its irq disabling side-effect

[Chris Wilson]

During reset/wedging, we have to clean up the requests on the timeline
and flush the pending interrupt state. Currently, we are abusing the irq
disabling of the timeline spinlock to protect the irq state in
conjunction to the engine's timeline requests, but this is accidental
and conflates the spinlock with the irq state. A baffling state of
affairs for the reader.

Instead, explicitly disable irqs over the critical section, and separate
modifying the irq state from the timeline's requests.

Suggested-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180302143246.2579-4-ch...@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0482e54c94f0..36b376e4b105 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -689,11 +689,27 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
 
GEM_TRACE("%s\n", engine->name);
 
-   spin_lock_irqsave(>timeline->lock, flags);
+   /*
+* Before we call engine->cancel_requests(), we should have exclusive
+* access to the submission state. This is arranged for us by the
+* caller disabling the interrupt generation, the tasklet and other
+* threads that may then access the same state, giving us a free hand
+* to reset state. However, we still need to let lockdep be aware that
+* we know this state may be accessed in hardirq context, so we
+* disable the irq around this manipulation and we want to keep
+* the spinlock focused on its duties and not accidentally conflate
+* coverage to the submission's irq state. (Similarly, although we
+* shouldn't need to disable irq around the manipulation of the
+* submission's irq state, we also wish to remind ourselves that
+* it is irq state.)
+*/
+   local_irq_save(flags);
 
/* Cancel the requests on the HW and clear the ELSP tracker. */
execlists_cancel_port_requests(execlists);
 
+   spin_lock(>timeline->lock);
+
/* Mark all executing requests as skipped. */
list_for_each_entry(rq, >timeline->requests, link) {
GEM_BUG_ON(!rq->global_seqno);
@@ -727,6 +743,8 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
execlists->first = NULL;
GEM_BUG_ON(port_isset(execlists->port));
 
+   spin_unlock(>timeline->lock);
+
/*
 * The port is checked prior to scheduling a tasklet, but
 * just in case we have suspended the tasklet to do the
@@ -738,7 +756,7 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
/* Mark all CS interrupts as complete */
execlists->active = 0;
 
-   spin_unlock_irqrestore(>timeline->lock, flags);
+   local_irq_restore(flags);
 }
 
 /*
@@ -1618,7 +1636,8 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
GEM_TRACE("%s seqno=%x\n",
  engine->name, request ? request->global_seqno : 0);
 
-   spin_lock_irqsave(>timeline->lock, flags);
+   /* See execlists_cancel_requests() for the irq/spinlock split. */
+   local_irq_save(flags);
 
reset_irq(engine);
 
@@ -1634,14 +1653,17 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
execlists_cancel_port_requests(execlists);
 
/* Push back any incomplete requests for replay after the reset. */
+   spin_lock(>timeline->lock);
__unwind_incomplete_requests(engine);
+   spin_unlock(>timeline->lock);
 
/* Mark all CS interrupts as complete */
execlists->active = 0;
 
-   spin_unlock_irqrestore(>timeline->lock, flags);
+   local_irq_restore(flags);
 
-   /* If the request was innocent, we leave the request in the ELSP
+   /*
+* If the request was innocent, we leave the request in the ELSP
 * and will try to replay it on restarting. The context image may
 * have been corrupted by the reset, in which case we may have
 * to service a new GPU hang, but more likely we can continue on
@@ -1654,7 +1676,8 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
if (!request || request->fence.error != -EIO)
return;
 
-   /* We want a simple context + ring to execute the breadcrumb update.
+   /*
+* We want a simple context + ring to execute the breadcrumb update.
 * We cannot rely on the context being intact across the GPU hang,
 * so clear it and rebuild just what we need for the breadcrumb.
   

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/3] drm/i915/error: remove unused gen8_engine_sync_index

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915/error: remove unused 
gen8_engine_sync_index
URL   : https://patchwork.freedesktop.org/series/39305/
State : warning

== Summary ==

 Possible new issues:

Test gem_pwrite:
Subgroup big-gtt-forwards:
pass   -> SKIP   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#104945 +1
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +3
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
incomplete -> PASS   (shard-hsw) fdo#105087
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
pass   -> SKIP   (shard-snb) fdo#102365
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-apl) fdo#99912
Test kms_vblank:
Subgroup pipe-a-accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#105087 https://bugs.freedesktop.org/show_bug.cgi?id=105087
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583

shard-apltotal:3442 pass:1809 dwarn:1   dfail:0   fail:6   skip:1624 
time:12116s
shard-hswtotal:3370 pass:1724 dwarn:1   dfail:0   fail:2   skip:1641 
time:11655s
shard-snbtotal:3463 pass:1358 dwarn:4   dfail:0   fail:1   skip:2100 
time:7002s
Blacklisted hosts:
shard-kbltotal:3442 pass:1931 dwarn:1   dfail:0   fail:8   skip:1501 
time:9518s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8222/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] drm-misc-next

[Sean Paul]

On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul  wrote:
>
> Hi Dave,
> Here's this weeks pull, relatively small when you pull out the trivial fixes.
>
> drm-misc-next-2018-02-28:
> drm-misc-next for 4.17:
>
> UAPI Changes:
>  Fix drm_color_ctm matrix docs to match usage and change the type to
>  __u64 make it obvious (Ville)

Hi Dave,
Could you please hold off on pulling this? I'd like to sort out this
change a bit more. We're already using the __s64 in chrome, and not
explicitly sign-magnitude. I think it would be prudent to hash this
out a little more.

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?l=161

Sean

>
> Core Changes:
>  Check modifier with format when checking if a plane state is supported 
> (Ville)
>
> Driver Changes:
>  sun4i: Improve hw plane utilization (Maxime)
>  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>  virtio: Whitespace + checkpatch changes (Rodrigo)
>
> Cc: Maxime Ripard 
> Cc: Oleksandr Andrushchenko 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Siqueira 
>
> Cheers, Sean
>
>
> The following changes since commit 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:
>
>   drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-28
>
> for you to fetch changes up to 7628166d5e2883e4cdd142b99863d29d411a81b2:
>
>   tinydrm: add backlight dependency (2018-02-28 15:08:56 -0500)
>
> 
> drm-misc-next for 4.17:
>
> UAPI Changes:
>  Fix drm_color_ctm matrix docs to match usage and change the type to
>  __u64 make it obvious (Ville)
>
> Core Changes:
>  Check modifier with format when checking if a plane state is supported 
> (Ville)
>
> Driver Changes:
>  sun4i: Improve hw plane utilization (Maxime)
>  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>  virtio: Whitespace + checkpatch changes (Rodrigo)
>
> Cc: Maxime Ripard 
> Cc: Oleksandr Andrushchenko 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Siqueira 
>
> 
> Arnd Bergmann (2):
>   drm: fix drm_get_max_iomem type mismatch
>   tinydrm: add backlight dependency
>
> Benjamin Gaignard (1):
>   drm/stm: check pitch and size calculations even if !CONFIG_MMU
>
> Chris Wilson (1):
>   drm/mm: Fix caching of leftmost node in the interval tree
>
> Linus Walleij (1):
>   drm/panel: Fix ARM Versatile panel clocks
>
> Maxime Ripard (4):
>   drm/sun4i: backend: Assign the pipes automatically
>   drm/sun4i: Remove the plane description structure
>   drm/sun4i: backend: Make zpos configurable
>   drm/sun4i: backend: Remove ARGB spoofing
>
> Oleksandr Andrushchenko (5):
>   drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC
>   drm/simple_kms_helper: Add {enable|disable}_vblank callback support
>   drm/mxsfb: Do not use deprecated drm_driver.{enable|disable)_vblank
>   drm/tve200: Do not use deprecated drm_driver.{enable|disable)_vblank
>   drm/pl111: Do not use deprecated drm_driver.{enable|disable)_vblank
>
> Rodrigo Siqueira (7):
>   drm/virtio: Add tabs at the start of a line
>   drm/virtio: Add blank line after variable declarations
>   drm/virtio: Add */ in block comments to separate line
>   drm/virtio: Remove return from void function
>   drm/virtio: Replace 'unsigned' for 'unsigned int'
>   drm/virtio: Remove multiple blank lines
>   drm/virtio: Add spaces around operators
>
> Thierry Reding (1):
>   drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC
>
> Ville Syrjälä (4):
>   drm: Check that the plane supports the request format+modifier combo
>   drm/i915: Remove the pipe/plane ID checks from 
> skl_check_ccs_aux_surface()
>   drm: Include the header with the prototype for 
> drm_get_panel_orientation_quirk()
>   drm/uapi: The ctm matrix uses sign-magnitude representation
>
>  drivers/gpu/drm/drm_atomic.c   | 10 +++--
>  drivers/gpu/drm/drm_crtc.c | 10 +++--
>  drivers/gpu/drm/drm_crtc_internal.h|  4 +-
>  drivers/gpu/drm/drm_memory.c   |  2 +-
>  drivers/gpu/drm/drm_mm.c   |  9 +++--
>  drivers/gpu/drm/drm_panel_orientation_quirks.c |  1 +
>  drivers/gpu/drm/drm_plane.c| 33 
>  drivers/gpu/drm/drm_simple_kms_helper.c| 34 
>  drivers/gpu/drm/i915/intel_display.c   |  8 
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 54 +
>  drivers/gpu/drm/panel/panel-arm-versatile.c|  

Re: [Intel-gfx] [PATCH 2/3] drm/i915/error: standardize function style in error capture

[Michal Wajdeczko]

On Fri, 02 Mar 2018 20:19:29 +0100, Daniele Ceraolo Spurio  
 wrote:



some of the static functions used from capture() have the "i915_"
prefix while other don't; most of them take i915 as a parameter, but one
of them derives it internally from error->i915. Let's be consistent by
avoiding prefix for static functions and always providing i915 as a
parameter.


Maybe this one static function that derived i915 from error->i915 is the
one that did it correctly? I see no point in passing dev_priv directly
as extra param as it is already attached to passed gpu error state.

/Michal



Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 47  
++-

 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c  
b/drivers/gpu/drm/i915/i915_gpu_error.c

index ef29fb48d6d9..d1f96e6a723a 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1084,8 +1084,8 @@ static uint32_t i915_error_generate_code(struct  
drm_i915_private *dev_priv,

return error_code;
 }
-static void i915_gem_record_fences(struct drm_i915_private *dev_priv,
-  struct i915_gpu_state *error)
+static void gem_record_fences(struct drm_i915_private *dev_priv,
+ struct i915_gpu_state *error)
 {
int i;
@@ -1424,8 +1424,8 @@ capture_object(struct drm_i915_private *dev_priv,
}
 }
-static void i915_gem_record_rings(struct drm_i915_private *dev_priv,
- struct i915_gpu_state *error)
+static void gem_record_rings(struct drm_i915_private *dev_priv,
+struct i915_gpu_state *error)
 {
struct i915_ggtt *ggtt = _priv->ggtt;
int i;
@@ -1527,8 +1527,8 @@ static void i915_gem_capture_vm(struct  
drm_i915_private *dev_priv,

error->active_bo_count[idx] = count;
 }
-static void i915_capture_active_buffers(struct drm_i915_private  
*dev_priv,

-   struct i915_gpu_state *error)
+static void capture_active_buffers(struct drm_i915_private *dev_priv,
+  struct i915_gpu_state *error)
 {
int cnt = 0, i, j;
@@ -1552,8 +1552,8 @@ static void i915_capture_active_buffers(struct  
drm_i915_private *dev_priv,

}
 }
-static void i915_capture_pinned_buffers(struct drm_i915_private  
*dev_priv,

-   struct i915_gpu_state *error)
+static void capture_pinned_buffers(struct drm_i915_private *dev_priv,
+  struct i915_gpu_state *error)
 {
struct i915_address_space *vm = _priv->ggtt.base;
struct drm_i915_error_buffer *bo;
@@ -1583,9 +1583,9 @@ static void i915_capture_pinned_buffers(struct  
drm_i915_private *dev_priv,

error->pinned_bo = bo;
 }
-static void capture_uc_state(struct i915_gpu_state *error)
+static void capture_uc_state(struct drm_i915_private *i915,
+struct i915_gpu_state *error)
 {
-   struct drm_i915_private *i915 = error->i915;
struct i915_error_uc *error_uc = >uc;
/* Capturing uC state won't be useful if there is no GuC */
@@ -1605,8 +1605,8 @@ static void capture_uc_state(struct i915_gpu_state  
*error)

 }
/* Capture all registers which don't fit into another category. */
-static void i915_capture_reg_state(struct drm_i915_private *dev_priv,
-  struct i915_gpu_state *error)
+static void capture_reg_state(struct drm_i915_private *dev_priv,
+ struct i915_gpu_state *error)
 {
int i;
@@ -1704,8 +1704,8 @@ static void i915_error_capture_msg(struct  
drm_i915_private *dev_priv,

  engine_mask ? "reset" : "continue");
 }
-static void i915_capture_gen_state(struct drm_i915_private *dev_priv,
-  struct i915_gpu_state *error)
+static void capture_gen_state(struct drm_i915_private *dev_priv,
+ struct i915_gpu_state *error)
 {
error->awake = dev_priv->gt.awake;
error->wakelock = atomic_read(_priv->runtime_pm.wakeref_count);
@@ -1741,6 +1741,7 @@ static void capture_params(struct i915_gpu_state  
*error)

 static int capture(void *data)
 {
struct i915_gpu_state *error = data;
+   struct drm_i915_private *i915 = error->i915;
error->time = ktime_get_real();
error->boottime = ktime_get_boottime();
@@ -1748,17 +1749,17 @@ static int capture(void *data)
  error->i915->gt.last_init_time);
capture_params(error);
-   capture_uc_state(error);
+   capture_uc_state(i915, error);
-   i915_capture_gen_state(error->i915, error);
-   i915_capture_reg_state(error->i915, error);
-   i915_gem_record_fences(error->i915, error);
-   

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Check for I915_MODE_FLAG_INHERITED before drm_atomic_helper_check_modeset

[Patchwork]

== Series Details ==

Series: drm/i915: Check for I915_MODE_FLAG_INHERITED before 
drm_atomic_helper_check_modeset
URL   : https://patchwork.freedesktop.org/series/38678/
State : failure

== Summary ==

Applying: drm/i915: Check for I915_MODE_FLAG_INHERITED before 
drm_atomic_helper_check_modeset
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_display.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915: Check for I915_MODE_FLAG_INHERITED before 
drm_atomic_helper_check_modeset
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".

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8102/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] drm/i915/icl: Ringbuffer interrupt handling

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915/icl: Ringbuffer interrupt handling
URL   : https://patchwork.freedesktop.org/series/39293/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-left-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +1
Test kms_plane:
Subgroup plane-panning-top-left-pipe-c-planes:
pass   -> FAIL   (shard-apl) fdo#103166
Test kms_vblank:
Subgroup pipe-a-ts-continuation-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540

shard-apltotal:3463 pass:1821 dwarn:1   dfail:0   fail:8   skip:1632 
time:12504s
shard-hswtotal:3389 pass:1721 dwarn:1   dfail:0   fail:1   skip:1664 
time:11624s
shard-snbtotal:3463 pass:1361 dwarn:2   dfail:0   fail:1   skip:2099 
time:6968s
Blacklisted hosts:
shard-kbltotal:3463 pass:1947 dwarn:1   dfail:0   fail:7   skip:1508 
time:9901s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8220/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/error: remove unused gen8_engine_sync_index

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915/error: remove unused 
gen8_engine_sync_index
URL   : https://patchwork.freedesktop.org/series/39305/
State : success

== Summary ==

Series 39305v1 series starting with [1/3] drm/i915/error: remove unused 
gen8_engine_sync_index
https://patchwork.freedesktop.org/api/1.0/series/39305/revisions/1/mbox/

 Known issues:

Test kms_chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#103841

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:428s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:493s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:122  pass:110  dwarn:0   dfail:0   fail:0   skip:12 
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:389s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:494s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:0   fail:1   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:487s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:423s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:522s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:527s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s

4f4e4dd52a3054b01591c3444ab1a91889c46172 drm-tip: 2018y-03m-02d-16h-28m-21s UTC 
integration manifest
3289fd0589fe drm/i915/error: capture uc_state after gen_state
dea3ce1d56b9 drm/i915/error: standardize function style in error capture
50b3e64be377 drm/i915/error: remove unused gen8_engine_sync_index

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8222/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915/error: remove unused gen8_engine_sync_index

[Daniele Ceraolo Spurio]

Leftover from Gen8 ringbuffer support removal

Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a7933c9b5562..ef29fb48d6d9 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1102,27 +1102,6 @@ static void i915_gem_record_fences(struct 
drm_i915_private *dev_priv,
error->nfence = i;
 }
 
-static inline u32
-gen8_engine_sync_index(struct intel_engine_cs *engine,
-  struct intel_engine_cs *other)
-{
-   int idx;
-
-   /*
-* rcs -> 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
-* vcs -> 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
-* bcs -> 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
-* vecs -> 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
-* vcs2 -> 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
-*/
-
-   idx = (other - engine) - 1;
-   if (idx < 0)
-   idx += I915_NUM_ENGINES;
-
-   return idx;
-}
-
 static void gen6_record_semaphore_state(struct intel_engine_cs *engine,
struct drm_i915_error_engine *ee)
 {
-- 
2.16.2

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

[Intel-gfx] [PATCH 2/3] drm/i915/error: standardize function style in error capture

[Daniele Ceraolo Spurio]

some of the static functions used from capture() have the "i915_"
prefix while other don't; most of them take i915 as a parameter, but one
of them derives it internally from error->i915. Let's be consistent by
avoiding prefix for static functions and always providing i915 as a
parameter.

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 47 ++-
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index ef29fb48d6d9..d1f96e6a723a 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1084,8 +1084,8 @@ static uint32_t i915_error_generate_code(struct 
drm_i915_private *dev_priv,
return error_code;
 }
 
-static void i915_gem_record_fences(struct drm_i915_private *dev_priv,
-  struct i915_gpu_state *error)
+static void gem_record_fences(struct drm_i915_private *dev_priv,
+ struct i915_gpu_state *error)
 {
int i;
 
@@ -1424,8 +1424,8 @@ capture_object(struct drm_i915_private *dev_priv,
}
 }
 
-static void i915_gem_record_rings(struct drm_i915_private *dev_priv,
- struct i915_gpu_state *error)
+static void gem_record_rings(struct drm_i915_private *dev_priv,
+struct i915_gpu_state *error)
 {
struct i915_ggtt *ggtt = _priv->ggtt;
int i;
@@ -1527,8 +1527,8 @@ static void i915_gem_capture_vm(struct drm_i915_private 
*dev_priv,
error->active_bo_count[idx] = count;
 }
 
-static void i915_capture_active_buffers(struct drm_i915_private *dev_priv,
-   struct i915_gpu_state *error)
+static void capture_active_buffers(struct drm_i915_private *dev_priv,
+  struct i915_gpu_state *error)
 {
int cnt = 0, i, j;
 
@@ -1552,8 +1552,8 @@ static void i915_capture_active_buffers(struct 
drm_i915_private *dev_priv,
}
 }
 
-static void i915_capture_pinned_buffers(struct drm_i915_private *dev_priv,
-   struct i915_gpu_state *error)
+static void capture_pinned_buffers(struct drm_i915_private *dev_priv,
+  struct i915_gpu_state *error)
 {
struct i915_address_space *vm = _priv->ggtt.base;
struct drm_i915_error_buffer *bo;
@@ -1583,9 +1583,9 @@ static void i915_capture_pinned_buffers(struct 
drm_i915_private *dev_priv,
error->pinned_bo = bo;
 }
 
-static void capture_uc_state(struct i915_gpu_state *error)
+static void capture_uc_state(struct drm_i915_private *i915,
+struct i915_gpu_state *error)
 {
-   struct drm_i915_private *i915 = error->i915;
struct i915_error_uc *error_uc = >uc;
 
/* Capturing uC state won't be useful if there is no GuC */
@@ -1605,8 +1605,8 @@ static void capture_uc_state(struct i915_gpu_state *error)
 }
 
 /* Capture all registers which don't fit into another category. */
-static void i915_capture_reg_state(struct drm_i915_private *dev_priv,
-  struct i915_gpu_state *error)
+static void capture_reg_state(struct drm_i915_private *dev_priv,
+ struct i915_gpu_state *error)
 {
int i;
 
@@ -1704,8 +1704,8 @@ static void i915_error_capture_msg(struct 
drm_i915_private *dev_priv,
  engine_mask ? "reset" : "continue");
 }
 
-static void i915_capture_gen_state(struct drm_i915_private *dev_priv,
-  struct i915_gpu_state *error)
+static void capture_gen_state(struct drm_i915_private *dev_priv,
+ struct i915_gpu_state *error)
 {
error->awake = dev_priv->gt.awake;
error->wakelock = atomic_read(_priv->runtime_pm.wakeref_count);
@@ -1741,6 +1741,7 @@ static void capture_params(struct i915_gpu_state *error)
 static int capture(void *data)
 {
struct i915_gpu_state *error = data;
+   struct drm_i915_private *i915 = error->i915;
 
error->time = ktime_get_real();
error->boottime = ktime_get_boottime();
@@ -1748,17 +1749,17 @@ static int capture(void *data)
  error->i915->gt.last_init_time);
 
capture_params(error);
-   capture_uc_state(error);
+   capture_uc_state(i915, error);
 
-   i915_capture_gen_state(error->i915, error);
-   i915_capture_reg_state(error->i915, error);
-   i915_gem_record_fences(error->i915, error);
-   i915_gem_record_rings(error->i915, error);
-   i915_capture_active_buffers(error->i915, error);
-   i915_capture_pinned_buffers(error->i915, error);
+   capture_gen_state(i915, error);
+   capture_reg_state(i915, error);
+   gem_record_fences(i915, error);
+   gem_record_rings(i915, error);
+   capture_active_buffers(i915, 

[Intel-gfx] [PATCH 3/3] drm/i915/error: capture uc_state after gen_state

[Daniele Ceraolo Spurio]

error->device_info.has_guc, which we check in capture_uc_state, is set
in capture_gen_state, so the latter needs to be performed first.

Reported-by: Vinay Belgaumkar 
Cc: Vinay Belgaumkar 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index d1f96e6a723a..e39f2bd4c2ab 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1749,9 +1749,9 @@ static int capture(void *data)
  error->i915->gt.last_init_time);
 
capture_params(error);
-   capture_uc_state(i915, error);
 
capture_gen_state(i915, error);
+   capture_uc_state(i915, error);
capture_reg_state(i915, error);
gem_record_fences(i915, error);
gem_record_rings(i915, error);
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH igt] lib: Fix MI_BATCH_BUFFER_START for hang injection

[Chris Wilson]

Quoting Ville Syrjälä (2018-03-02 17:09:29)
> On Fri, Mar 02, 2018 at 04:13:46PM +, Chris Wilson wrote:
> > A couple of bugs inside the hang injector, the worst being that the
> > presumed_offset of the reloc didn't match the batch; so if the reloc was
> > skipped (as the presumed_offset matched the reloc offset), the batch
> > wasn't updated and so we may not have generated a hanging batch at all!
> > Secondly, the MI_BATCH_BUFFER_START was not correct for all gen.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  lib/igt_gt.c | 28 +---
> >  1 file changed, 21 insertions(+), 7 deletions(-)
> > 
> > diff --git a/lib/igt_gt.c b/lib/igt_gt.c
> > index e630550b..799ca1ae 100644
> > --- a/lib/igt_gt.c
> > +++ b/lib/igt_gt.c
> > @@ -276,6 +276,7 @@ igt_hang_t igt_hang_ctx(int fd,
> >   uint32_t b[16];
> >   unsigned ban;
> >   unsigned len;
> > + int gen;
> >  
> >   igt_require_hang_ring(fd, ring);
> >  
> > @@ -310,12 +311,26 @@ igt_hang_t igt_hang_ctx(int fd,
> >  
> >   memset(b, 0xc5, sizeof(b));
> >  
> > - len = 2;
> > - if (intel_gen(intel_get_drm_devid(fd)) >= 8)
> > + len = 0;
> > + gen = intel_gen(intel_get_drm_devid(fd));
> > + if (gen >= 8) {
> > + b[len++] = MI_BATCH_BUFFER_START | 1 << 8 | 1;
> > + b[len++] = 0;
> > + b[len++] = 0;
> > + } else if (gen >= 6) {
> > + b[len++] = MI_BATCH_BUFFER_START | 1 << 8;
> > + b[len++] = 0;
> 
> ppgtt for gen6+
> 
> > + } else {
> > + b[len++] = MI_BATCH_BUFFER_START | 2 << 6;
> > + b[len] = 0;
> > + if (gen < 4) {
> > + b[len] |= 1;
> > + reloc.delta = 1;
> > + }
> >   len++;
> 
> gtt secure for gen4/5
> gtt non-secure for gen2/3
> 
> How does the security thing work on ctg/ilk for chained batches? The spec
> is a wee bit unclear. It says the security bit for chained batches is
> ignored, but then it also says non-secure batches can't access the gtt.
> That was the case for MI_STORE_DWORD if I recall your earlier patch
> correctly. So if we don't execute the first batch as secure the chained
> MI_BB_START gets nopped out maybe?

Yes, as soon as we lose the privilege bit (usually when the kernel does
the first MI_BB to us), we can regain privilege in this batch chain. How
this works with the ppgtt is a mystery, but it also functions
differently if it's not enabled.
 
> Hmm. Now I wonder how the earlier MI_STORE_DWORD thing worked on pre-ctg
> with a non-secure batch? Wasn't the hardware supposed to nop those out
> entirely? /me confused

Aiui, before ctg/ilk they remained unprivileged ops.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: clean up leftover references to CHV HBR2 support

[Patchwork]

== Series Details ==

Series: drm/i915/dp: clean up leftover references to CHV HBR2 support
URL   : https://patchwork.freedesktop.org/series/39285/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-right-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +2
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
pass   -> SKIP   (shard-snb) fdo#102365
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3442 pass:1809 dwarn:1   dfail:0   fail:7   skip:1623 
time:12139s
shard-hswtotal:3463 pass:1769 dwarn:1   dfail:0   fail:2   skip:1690 
time:12058s
shard-snbtotal:3463 pass:1359 dwarn:3   dfail:0   fail:1   skip:2100 
time:6970s
Blacklisted hosts:
shard-kbltotal:3463 pass:1945 dwarn:1   dfail:0   fail:7   skip:1510 
time:9866s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8219/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Register definitions for DP Phy compiance

[Clint Taylor]

On 03/02/2018 10:10 AM, Rodrigo Vivi wrote:

On Thu, Mar 01, 2018 at 11:36:12AM -0800, clinton.a.tay...@intel.com wrote:

From: Clint Taylor 

DisplayPort Phy compliance test patterns register definitions.

Hi Clint,

what's the current plan to add the actual use of these registers and bits?


Supporting DP phy compliance has been mentioned by an interested 
third-party. They needed the register definitions to be made available 
to start development.


Clint



thanks,
Rodrigo.


Signed-off-by: Clint Taylor 
---
  drivers/gpu/drm/i915/i915_reg.h | 18 ++
  1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 95a2e51..91152c9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8702,6 +8702,24 @@ enum skl_power_gate {
  #define  DDI_BUF_BALANCE_LEG_ENABLE   (1 << 31)
  #define DDI_BUF_TRANS_HI(port, i) _MMIO(_PORT(port, _DDI_BUF_TRANS_A, 
_DDI_BUF_TRANS_B) + (i) * 8 + 4)
  
+/* DDI DP Compliance Control */

+#define DDI_DP_COMP_CTL_A  0x640F0
+#define DDI_DP_COMP_CTL_B  0x641F0
+#define DDI_DP_COMP_CTL(port) _MMIO_PORT(port, DDI_DP_COMP_CTL_A, 
DDI_DP_COMP_CTL_B)
+#define  DDI_DP_COMP_CTL_ENABLE(1 << 31)
+#define  DDI_DP_COMP_CTL_D10_2 (0 << 28)
+#define  DDI_DP_COMP_CTL_SCRAMBLED_0   (1 << 28)
+#define  DDI_DP_COMP_CTL_PRBS7 (2 << 28)
+#define  DDI_DP_COMP_CTL_CUSTOM80  (3 << 28)
+#define  DDI_DP_COMP_CTL_HBR2  (4 << 28)
+#define  DDI_DP_COMP_CTL_SCRAMBLED_1   (5 << 28)
+#define  DDI_DP_COMP_CTL_HBR2_RESET(0xFC << 0)
+
+/* DDI DP Compliance Pattern */
+#define DDI_DP_COMP_PAT_A  0x640f4
+#define DDI_DP_COMP_PAT_B  0x641f4
+#define DDI_DP_COMP_PAT(port, i) _MMIO(_PORT(port, DDI_DP_COMP_PAT_A, 
DDI_DP_COMP_PAT_B) + (i) * 4) /* 3 dwords */
+
  /* Sideband Interface (SBI) is programmed indirectly, via
   * SBI_ADDR, which contains the register offset; and SBI_DATA,
   * which contains the payload */
--
1.9.1

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


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up the port pipe select bits (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Clean up the port pipe select bits (rev2)
URL   : https://patchwork.freedesktop.org/series/39259/
State : failure

== Summary ==

Series 39259v2 drm/i915: Clean up the port pipe select bits
https://patchwork.freedesktop.org/api/1.0/series/39259/revisions/2/mbox/

 Possible new issues:

Test core_auth:
Subgroup basic-auth:
pass   -> INCOMPLETE (fi-ivb-3520m)
pass   -> INCOMPLETE (fi-snb-2520m)
Test drv_module_reload:
Subgroup basic-reload:
pass   -> INCOMPLETE (fi-skl-6700k2)
Test kms_chamelium:
Subgroup common-hpd-after-suspend:
pass   -> DMESG-WARN (fi-skl-6700k2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> FAIL   (fi-skl-6700k2)
Subgroup basic-rte:
pass   -> FAIL   (fi-skl-6700k2)

 Known issues:

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6700k2) fdo#104108

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:472s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:459s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:496s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:292s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:449s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-skl-6700k2total:285  pass:257  dwarn:2   dfail:0   fail:2   skip:23 
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s

4f4e4dd52a3054b01591c3444ab1a91889c46172 drm-tip: 2018y-03m-02d-16h-28m-21s UTC 
integration manifest
9541206e7d05 drm/i915: Implement the missing bits of assert_panel_unlocked()
06e6449c17cb drm/i915: Allow eDP on port C in theory
2d0716ba5ea1 drm/i915: Clean up DP pipe select bits
cd255a42ae79 drm/i915: Nuke intel_trans_dp_port_sel()
4009bd6467a8 drm/i915: Parametrize TRANS_DP_PORT_SEL
7747b69cd6fd drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi code
88ab721b4937 drm/i915: Check for IVB instead of gen7 when we think about IVB 
CPU eDP
4566679f9e68 drm/i915: Use the same vswing->max_preemph mapping on HSW/BDW as 
on SKL+
690beefecf42 drm/i915: Use intel_ddi_dp_voltage_max() for HSW/BDW too
e4f2dca9a68c drm/i915: Clean up DVO pipe select bits
446caedf8adc drm/i915: Clean up TV pipe select bits
3eb206142cb5 drm/i915: Clean up SDVO pipe select bits
84ec7de4ae0c drm/i915: Clean up LVDS pipe select bits
4a222a76addc drm/i915: Clean 

Re: [Intel-gfx] [PATCH v12 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation

[Yaodong Li]

On 03/02/2018 12:04 AM, Sagar Arun Kamble wrote:

 (GUC_WOPCM_RESERVED + GEN9_GUC_FW_RESERVED)

+
+/**
+ * intel_wopcm_init_early() - Early initialization of the WOPCM.
+ * @wopcm: pointer to intel_wopcm.
+ *
+ * Setup the size of WOPCM which will be used by later on WOPCM 
partitioning.

+ */
+void intel_wopcm_init_early(struct intel_wopcm *wopcm)
+{
+    wopcm->size = GEN9_WOPCM_SIZE;
I am not sure if you plan to do this later but initializing it with 
value from gem_init_stolen now seems more appropriate.
I've been asked this for several times already. Yes. I have a plan, but 
just cannot switch to that plan right now.;-)


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

Re: [Intel-gfx] [PATCH] drm/i915: Register definitions for DP Phy compiance

[Rodrigo Vivi]

On Thu, Mar 01, 2018 at 11:36:12AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor 
> 
> DisplayPort Phy compliance test patterns register definitions.

Hi Clint,

what's the current plan to add the actual use of these registers and bits?

thanks,
Rodrigo.

> 
> Signed-off-by: Clint Taylor 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 95a2e51..91152c9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8702,6 +8702,24 @@ enum skl_power_gate {
>  #define  DDI_BUF_BALANCE_LEG_ENABLE  (1 << 31)
>  #define DDI_BUF_TRANS_HI(port, i)_MMIO(_PORT(port, _DDI_BUF_TRANS_A, 
> _DDI_BUF_TRANS_B) + (i) * 8 + 4)
>  
> +/* DDI DP Compliance Control */
> +#define DDI_DP_COMP_CTL_A0x640F0
> +#define DDI_DP_COMP_CTL_B0x641F0
> +#define DDI_DP_COMP_CTL(port) _MMIO_PORT(port, DDI_DP_COMP_CTL_A, 
> DDI_DP_COMP_CTL_B)
> +#define  DDI_DP_COMP_CTL_ENABLE  (1 << 31)
> +#define  DDI_DP_COMP_CTL_D10_2   (0 << 28)
> +#define  DDI_DP_COMP_CTL_SCRAMBLED_0 (1 << 28)
> +#define  DDI_DP_COMP_CTL_PRBS7   (2 << 28)
> +#define  DDI_DP_COMP_CTL_CUSTOM80(3 << 28)
> +#define  DDI_DP_COMP_CTL_HBR2(4 << 28)
> +#define  DDI_DP_COMP_CTL_SCRAMBLED_1 (5 << 28)
> +#define  DDI_DP_COMP_CTL_HBR2_RESET  (0xFC << 0)
> +
> +/* DDI DP Compliance Pattern */
> +#define DDI_DP_COMP_PAT_A0x640f4
> +#define DDI_DP_COMP_PAT_B0x641f4
> +#define DDI_DP_COMP_PAT(port, i) _MMIO(_PORT(port, DDI_DP_COMP_PAT_A, 
> DDI_DP_COMP_PAT_B) + (i) * 4) /* 3 dwords */
> +
>  /* Sideband Interface (SBI) is programmed indirectly, via
>   * SBI_ADDR, which contains the register offset; and SBI_DATA,
>   * which contains the payload */
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm/i915: Stop engines around GPU reset preparations

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: Stop engines around GPU reset 
preparations
URL   : https://patchwork.freedesktop.org/series/39284/
State : failure

== Summary ==

 Possible new issues:

Test drv_selftest:
Subgroup live_hangcheck:
pass   -> INCOMPLETE (shard-apl)
Test kms_cursor_legacy:
Subgroup short-flip-before-cursor-atomic-transitions-varying-size:
pass   -> FAIL   (shard-hsw)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-left-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> SKIP   (shard-snb) fdo#103375
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test perf:
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3445 pass:1803 dwarn:1   dfail:0   fail:7   skip:1632 
time:12245s
shard-hswtotal:3463 pass:1768 dwarn:1   dfail:0   fail:3   skip:1690 
time:12090s
shard-snbtotal:3463 pass:1361 dwarn:1   dfail:0   fail:1   skip:2100 
time:6913s
Blacklisted hosts:
shard-kbltotal:3445 pass:1926 dwarn:1   dfail:0   fail:7   skip:1510 
time:9778s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8218/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 12/14] drm/i915: Clean up DP pipe select bits

[Ville Syrjala]

From: Ville Syrjälä 

Clean up the DP pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state(),
the port state asserts, and the VLV power sequencer code.

v2: Return PIPE_A for cpt/ppt when the port isn't selected by
any transcoder. Returning INVALID_PIPE explodes *somewhere*
on some machines (can't immediately see where though). This
now matches the old behaviour.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  24 +++-
 drivers/gpu/drm/i915/intel_display.c |  46 +--
 drivers/gpu/drm/i915/intel_dp.c  | 110 ---
 drivers/gpu/drm/i915/intel_drv.h |   3 +
 4 files changed, 90 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc9fc6220509..9548e0bee7db 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5248,10 +5248,15 @@ enum {
 #define CHV_DP_D   _MMIO(VLV_DISPLAY_BASE + 0x64300)
 
 #define   DP_PORT_EN   (1 << 31)
-#define   DP_PIPEB_SELECT  (1 << 30)
-#define   DP_PIPE_MASK (1 << 30)
-#define   DP_PIPE_SELECT_CHV(pipe) ((pipe) << 16)
-#define   DP_PIPE_MASK_CHV (3 << 16)
+#define   DP_PIPE_SEL(pipe)((pipe) << 30)
+#define   DP_PIPE_SEL_MASK (1 << 30)
+#define   DP_PIPE_SEL_SHIFT30
+#define   DP_PIPE_SEL_IVB(pipe)((pipe) << 29)
+#define   DP_PIPE_SEL_MASK_IVB (3 << 29)
+#define   DP_PIPE_SEL_SHIFT_IVB29
+#define   DP_PIPE_SEL_CHV(pipe)((pipe) << 16)
+#define   DP_PIPE_SEL_MASK_CHV (3 << 16)
+#define   DP_PIPE_SEL_SHIFT_CHV16
 
 /* Link training mode - select a suitable mode for each stage */
 #define   DP_LINK_TRAIN_PAT_1  (0 << 28)
@@ -7921,16 +7926,6 @@ enum {
 #define PCH_DP_AUX_CH_DATA(aux_ch, i)  _MMIO(_PORT((aux_ch) - AUX_CH_B, 
_PCH_DPB_AUX_CH_DATA1, _PCH_DPC_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
 
 /* CPT */
-#define  PORT_TRANS_A_SEL_CPT  0
-#define  PORT_TRANS_B_SEL_CPT  (1<<29)
-#define  PORT_TRANS_C_SEL_CPT  (2<<29)
-#define  PORT_TRANS_SEL_MASK   (3<<29)
-#define  PORT_TRANS_SEL_CPT(pipe)  ((pipe) << 29)
-#define  PORT_TO_PIPE(val) (((val) & (1<<30)) >> 30)
-#define  PORT_TO_PIPE_CPT(val) (((val) & PORT_TRANS_SEL_MASK) >> 29)
-#define  SDVO_PORT_TO_PIPE_CHV(val)(((val) & (3<<24)) >> 24)
-#define  DP_PORT_TO_PIPE_CHV(val)  (((val) & (3<<16)) >> 16)
-
 #define _TRANS_DP_CTL_A0xe0300
 #define _TRANS_DP_CTL_B0xe1300
 #define _TRANS_DP_CTL_C0xe2300
@@ -7939,7 +7934,6 @@ enum {
 #define  TRANS_DP_PORT_SEL(port)   (((port) - PORT_B) << 29)
 #define  TRANS_DP_PORT_SEL_NONE(3 << 29)
 #define  TRANS_DP_PORT_SEL_MASK(3 << 29)
-#define  TRANS_DP_PIPE_TO_PORT(val)val) & TRANS_DP_PORT_SEL_MASK) >> 
29) + PORT_B)
 #define  TRANS_DP_AUDIO_ONLY   (1<<26)
 #define  TRANS_DP_ENH_FRAMING  (1<<18)
 #define  TRANS_DP_8BPC (0<<9)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 43b589dfe71f..dfe3a17b86d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1261,38 +1261,22 @@ void assert_pch_transcoder_disabled(struct 
drm_i915_private *dev_priv,
 pipe_name(pipe));
 }
 
-static bool dp_pipe_enabled(struct drm_i915_private *dev_priv,
-   enum pipe pipe, u32 port_sel, u32 val)
+static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
+  enum pipe pipe, enum port port,
+  i915_reg_t dp_reg)
 {
-   if ((val & DP_PORT_EN) == 0)
-   return false;
+   enum pipe port_pipe;
+   bool state;
 
-   if (HAS_PCH_CPT(dev_priv)) {
-   u32 trans_dp_ctl = I915_READ(TRANS_DP_CTL(pipe));
-   if ((trans_dp_ctl & TRANS_DP_PORT_SEL_MASK) != port_sel)
-   return false;
-   } else if (IS_CHERRYVIEW(dev_priv)) {
-   if ((val & DP_PIPE_MASK_CHV) != DP_PIPE_SELECT_CHV(pipe))
-   return false;
-   } else {
-   if ((val & DP_PIPE_MASK) != (pipe << 30))
-   return false;
-   }
-   return true;
-}
+   state = intel_dp_port_enabled(dev_priv, dp_reg, port, _pipe);
 
-static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
-  enum pipe pipe, i915_reg_t reg,
-  u32 port_sel)
-{
-   u32 val = I915_READ(reg);
-   I915_STATE_WARN(dp_pipe_enabled(dev_priv, pipe, port_sel, val),
-"PCH DP (0x%08x) enabled on transcoder %c, should be disabled\n",
-

[Intel-gfx] [PATCH libdrm 1/1] intel: allocate buffer with the requested size when reuse is disabled

[James Xiong]

From: "Xiong, James" 

Previously a bucket size was used for buffer allocation whether
bo_reuse is false or true. This patch returns NULL in function
drm_intel_gem_bo_bucket_for_size() when bo_reuse is false, the
original requested size is used instead.

Signed-off-by: Xiong, James 
---
 intel/intel_bufmgr_gem.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 386da30..43a3f38 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -402,6 +402,9 @@ drm_intel_gem_bo_bucket_for_size(drm_intel_bufmgr_gem 
*bufmgr_gem,
 {
int i;
 
+   if (!bufmgr_gem->bo_reuse)
+   return NULL;
+
for (i = 0; i < bufmgr_gem->num_buckets; i++) {
struct drm_intel_gem_bo_bucket *bucket =
_gem->cache_bucket[i];
@@ -1382,7 +1385,7 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, 
time_t time)
 
bucket = drm_intel_gem_bo_bucket_for_size(bufmgr_gem, bo->size);
/* Put the buffer into our internal cache for reuse if we can. */
-   if (bufmgr_gem->bo_reuse && bo_gem->reusable && bucket != NULL &&
+   if (bo_gem->reusable && bucket != NULL &&
drm_intel_gem_bo_madvise_internal(bufmgr_gem, bo_gem,
  I915_MADV_DONTNEED)) {
bo_gem->free_time = time;
@@ -3806,6 +3809,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
drm_intel_gem_get_pipe_from_crtc_id;
bufmgr_gem->bufmgr.bo_references = drm_intel_gem_bo_references;
 
+   bufmgr_gem->bo_reuse = false; /* explicitly set to false */
init_cache_buckets(bufmgr_gem);
 
DRMINITLISTHEAD(_gem->vma_cache);
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/1] intel: align reuse buffer's size on page size instead

[James Xiong]

From: "Xiong, James" 

With gem_reuse enabled, when a buffer size is different than
the sizes of buckets, it is aligned to the next bucket's size,
which means about 25% more memory than the requested is allocated
in the worst senario. For example:

Orignal sizeActual
32KB+1Byte  40KB
.
.
.
8MB+1Byte   10MB
.
.
.
96MB+1Byte  112MB

This is very memory expensive and make the reuse feature less
favorable than it deserves to be.

This commit aligns the reuse buffer size on page size instead,
the buffer whose size falls between bucket[n] and bucket[n+1] is
put in bucket[n] when it's done; And when searching for a cached
buffer for reuse, it goes through the cached buffers list in the
bucket until a cached buffer, whose size is larger than or equal
to the requested size, is found.

Performed gfxbench tests, the performances and reuse ratioes
(reuse count/allocation count) were same as before, saved memory
usage by 1% ~ 7%(gl_manhattan: peak allocated memory size was
reduced from 448401408 to 419078144).

Signed-off-by: Xiong, James 
---
 intel/intel_bufmgr_gem.c | 180 +--
 libdrm_lists.h   |   6 ++
 2 files changed, 101 insertions(+), 85 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 386da30..5b2d0d0 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -402,11 +402,10 @@ drm_intel_gem_bo_bucket_for_size(drm_intel_bufmgr_gem 
*bufmgr_gem,
 {
int i;
 
-   for (i = 0; i < bufmgr_gem->num_buckets; i++) {
-   struct drm_intel_gem_bo_bucket *bucket =
-   _gem->cache_bucket[i];
-   if (bucket->size >= size) {
-   return bucket;
+   for (i = 0; i < bufmgr_gem->num_buckets - 1; i++) {
+   if (size >= bufmgr_gem->cache_bucket[i].size &&
+   size < bufmgr_gem->cache_bucket[i+1].size) {
+   return _gem->cache_bucket[i];
}
}
 
@@ -685,25 +684,95 @@ drm_intel_gem_bo_madvise(drm_intel_bo *bo, int madv)
 madv);
 }
 
-/* drop the oldest entries that have been purged by the kernel */
+/* drop the entries that are older than the given time */
 static void
 drm_intel_gem_bo_cache_purge_bucket(drm_intel_bufmgr_gem *bufmgr_gem,
-   struct drm_intel_gem_bo_bucket *bucket)
+   struct drm_intel_gem_bo_bucket *bucket,
+   time_t time)
 {
-   while (!DRMLISTEMPTY(>head)) {
-   drm_intel_bo_gem *bo_gem;
-
-   bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
- bucket->head.next, head);
-   if (drm_intel_gem_bo_madvise_internal
-   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED))
-   break;
-
-   DRMLISTDEL(_gem->head);
-   drm_intel_gem_bo_free(_gem->bo);
+   drm_intel_bo_gem *bo_gem, *temp;
+   DRMLISTFOREACHENTRYSAFE(bo_gem, temp, >head, head) {
+   if (bo_gem->free_time >= time) {
+   drm_intel_gem_bo_madvise_internal
+   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED);
+   DRMLISTDEL(_gem->head);
+   drm_intel_gem_bo_free(_gem->bo);
+   }
}
 }
 
+static drm_intel_bo_gem *
+drm_intel_gem_bo_cached_for_size(drm_intel_bufmgr_gem *bufmgr_gem,
+ unsigned long size,
+ uint32_t tiling_mode,
+ unsigned long stride,
+ unsigned long alignment,
+ bool for_render)
+{
+   struct drm_intel_gem_bo_bucket *bucket =
+   drm_intel_gem_bo_bucket_for_size(bufmgr_gem, size);
+
+   if(bucket != NULL) {
+   drm_intel_bo_gem *bo_gem, *temp_bo_gem;
+retry:
+   bo_gem = NULL;
+   if (for_render) {
+   /* Allocate new render-target BOs from the tail (MRU)
+* of the list, as it will likely be hot in the GPU
+* cache and in the aperture for us.
+*/
+   DRMLISTFOREACHENTRYREVERSE(temp_bo_gem, >head, 
head) {
+   if (temp_bo_gem->bo.size >= size) {
+   bo_gem = temp_bo_gem;
+   DRMLISTDEL(_gem->head);
+   bo_gem->bo.align = alignment;
+   break;
+   }
+   }
+   } else {
+   assert(alignment == 0);
+   /* For non-render-target BOs (where we're probably
+* going to map it first thing in order to 

[Intel-gfx] ✗ Fi.CI.IGT: warning for Documentation patch for batchbuffer submission (rev2)

[Patchwork]

== Series Details ==

Series: Documentation patch for batchbuffer submission (rev2)
URL   : https://patchwork.freedesktop.org/series/38433/
State : warning

== Summary ==

 Possible new issues:

Test gem_pwrite:
Subgroup big-gtt-forwards:
pass   -> SKIP   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945 +1
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-left-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3401 pass:1781 dwarn:1   dfail:0   fail:7   skip:1609 
time:11464s
shard-hswtotal:3463 pass:1770 dwarn:1   dfail:0   fail:1   skip:1690 
time:12060s
shard-snbtotal:3463 pass:1362 dwarn:1   dfail:0   fail:1   skip:2099 
time:6969s
Blacklisted hosts:
shard-kbltotal:3463 pass:1948 dwarn:1   dfail:0   fail:7   skip:1507 
time:9885s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8217/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] lib: Fix MI_BATCH_BUFFER_START for hang injection

[Ville Syrjälä]

On Fri, Mar 02, 2018 at 04:13:46PM +, Chris Wilson wrote:
> A couple of bugs inside the hang injector, the worst being that the
> presumed_offset of the reloc didn't match the batch; so if the reloc was
> skipped (as the presumed_offset matched the reloc offset), the batch
> wasn't updated and so we may not have generated a hanging batch at all!
> Secondly, the MI_BATCH_BUFFER_START was not correct for all gen.
> 
> Signed-off-by: Chris Wilson 
> ---
>  lib/igt_gt.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/igt_gt.c b/lib/igt_gt.c
> index e630550b..799ca1ae 100644
> --- a/lib/igt_gt.c
> +++ b/lib/igt_gt.c
> @@ -276,6 +276,7 @@ igt_hang_t igt_hang_ctx(int fd,
>   uint32_t b[16];
>   unsigned ban;
>   unsigned len;
> + int gen;
>  
>   igt_require_hang_ring(fd, ring);
>  
> @@ -310,12 +311,26 @@ igt_hang_t igt_hang_ctx(int fd,
>  
>   memset(b, 0xc5, sizeof(b));
>  
> - len = 2;
> - if (intel_gen(intel_get_drm_devid(fd)) >= 8)
> + len = 0;
> + gen = intel_gen(intel_get_drm_devid(fd));
> + if (gen >= 8) {
> + b[len++] = MI_BATCH_BUFFER_START | 1 << 8 | 1;
> + b[len++] = 0;
> + b[len++] = 0;
> + } else if (gen >= 6) {
> + b[len++] = MI_BATCH_BUFFER_START | 1 << 8;
> + b[len++] = 0;

ppgtt for gen6+

> + } else {
> + b[len++] = MI_BATCH_BUFFER_START | 2 << 6;
> + b[len] = 0;
> + if (gen < 4) {
> + b[len] |= 1;
> + reloc.delta = 1;
> + }
>   len++;

gtt secure for gen4/5
gtt non-secure for gen2/3

How does the security thing work on ctg/ilk for chained batches? The spec
is a wee bit unclear. It says the security bit for chained batches is
ignored, but then it also says non-secure batches can't access the gtt.
That was the case for MI_STORE_DWORD if I recall your earlier patch
correctly. So if we don't execute the first batch as secure the chained
MI_BB_START gets nopped out maybe?

Hmm. Now I wonder how the earlier MI_STORE_DWORD thing worked on pre-ctg
with a non-secure batch? Wasn't the hardware supposed to nop those out
entirely? /me confused

Anyways the new code looks at least more correct than the old one so
Reviewed-by: Ville Syrjälä 

> - b[0] = MI_BATCH_BUFFER_START | (len - 2);
> - b[len] = MI_BATCH_BUFFER_END;
> - b[len+1] = MI_NOOP;
> + }
> + b[len++] = MI_BATCH_BUFFER_END;
> + b[len] = MI_NOOP;
>   gem_write(fd, exec.handle, 0, b, sizeof(b));
>  
>   reloc.offset = sizeof(uint32_t);
> @@ -364,8 +379,7 @@ void igt_post_hang_ring(int fd, igt_hang_t arg)
>   if (arg.handle == 0)
>   return;
>  
> - gem_set_domain(fd, arg.handle,
> -I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
> + gem_sync(fd, arg.handle);
>   gem_close(fd, arg.handle);
>  
>   context_set_ban(fd, arg.ctx, arg.ban);
> -- 
> 2.16.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm: Don't create properties without names (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm: Don't create properties without names 
(rev2)
URL   : https://patchwork.freedesktop.org/series/39277/
State : success

== Summary ==

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-bottom-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +2
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-apltotal:3463 pass:1823 dwarn:1   dfail:0   fail:7   skip:1632 
time:12511s
shard-hswtotal:3463 pass:1768 dwarn:1   dfail:0   fail:3   skip:1690 
time:12054s
shard-snbtotal:3463 pass:1360 dwarn:3   dfail:0   fail:1   skip:2099 
time:6997s
Blacklisted hosts:
shard-kbltotal:3401 pass:1906 dwarn:1   dfail:0   fail:7   skip:1485 
time:9036s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8216/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/icl: Ringbuffer interrupt handling

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915/icl: Ringbuffer interrupt handling
URL   : https://patchwork.freedesktop.org/series/39293/
State : success

== Summary ==

Series 39293v1 series starting with [1/6] drm/i915/icl: Ringbuffer interrupt 
handling
https://patchwork.freedesktop.org/api/1.0/series/39293/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ivb-3770) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:475s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:472s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:459s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:493s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:574s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:504s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:494s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:521s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s

75cc49c0195a217db94582fd59e7264709b0 drm-tip: 2018y-03m-02d-15h-49m-26s UTC 
integration manifest
93c06d88e6cd drm/i915/icl: Gen11 forcewake support
6454d9eddb6f drm/i915/icl: Add Indirect Context Offset for Gen11
fbda88d78285 drm/i915/icl: Enhanced execution list support
eccd00f6e1ec drm/i915/icl: new context descriptor support
30be6ea2de55 drm/i915/icl: Correctly initialize the Gen11 engines
bf0e69425895 drm/i915/icl: Ringbuffer interrupt handling

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8220/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915: Keep the AKSV details in intel_dp_hdcp_write_an_aksv()

[Ville Syrjälä]

On Fri, Feb 23, 2018 at 08:14:53PM +0530, Ramalingam C wrote:
> 
> 
> On Friday 23 February 2018 07:16 PM, Ville Syrjälä wrote:
> > On Fri, Feb 23, 2018 at 04:40:42PM +0530, Ramalingam C wrote:
> >> This is really making it cleaner.
> >>
> >> Reviewed-by: Ramalingam C 
> >>
> >>
> >>
> >> On Friday 23 February 2018 02:57 AM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä 
> >>>
> >>> Let's try to keep the details on the AKSV stuff concentrated
> >>> in one place. So move the control bit and +5 data size handling
> >>> there.
> >>>
> >>> v2: Increase txbuf[] to include the payload which intel_dp_aux_xfer()
> >>>   will still load into the registers even though the hardware
> >>>   will ignore it
> >>>
> >>> Cc: Sean Paul 
> >>> Cc: Ramalingam C 
> >>> Signed-off-by: Ville Syrjälä 
> >>> ---
> >>>drivers/gpu/drm/i915/intel_dp.c | 42 
> >>> +
> >>>1 file changed, 13 insertions(+), 29 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >>> b/drivers/gpu/drm/i915/intel_dp.c
> >>> index 217cc6aee477..0d699d230b77 100644
> >>> --- a/drivers/gpu/drm/i915/intel_dp.c
> >>> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >>> @@ -1059,29 +1059,11 @@ static uint32_t skl_get_aux_send_ctl(struct 
> >>> intel_dp *intel_dp,
> >>>  DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> >>>}
> >>>
> >>> -static uint32_t intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> >>> -   bool has_aux_irq,
> >>> -   int send_bytes,
> >>> -   uint32_t aux_clock_divider,
> >>> -   bool aksv_write)
> >>> -{
> >>> - uint32_t val = 0;
> >>> -
> >>> - if (aksv_write) {
> >>> - send_bytes += 5;
> >>> - val |= DP_AUX_CH_CTL_AUX_AKSV_SELECT;
> >>> - }
> >>> -
> >>> - return val | intel_dp->get_aux_send_ctl(intel_dp,
> >>> - has_aux_irq,
> >>> - send_bytes,
> >>> - aux_clock_divider);
> >>> -}
> >>> -
> >>>static int
> >>>intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >>> const uint8_t *send, int send_bytes,
> >>> -   uint8_t *recv, int recv_size, bool aksv_write)
> >>> +   uint8_t *recv, int recv_size,
> >>> +   u32 aux_send_ctl_flags)
> >>>{
> >>>   struct intel_digital_port *intel_dig_port = 
> >>> dp_to_dig_port(intel_dp);
> >>>   struct drm_i915_private *dev_priv =
> >>> @@ -1145,11 +1127,12 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >>>   }
> >>>
> >>>   while ((aux_clock_divider = 
> >>> intel_dp->get_aux_clock_divider(intel_dp, clock++))) {
> >>> - u32 send_ctl = intel_dp_get_aux_send_ctl(intel_dp,
> >>> -  has_aux_irq,
> >>> -  send_bytes,
> >>> -  aux_clock_divider,
> >>> -  aksv_write);
> >>> + u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
> >>> +   has_aux_irq,
> >>> +   send_bytes,
> >>> +   aux_clock_divider);
> >>> +
> >>> + send_ctl |= aux_send_ctl_flags;
> >>>
> >>>   /* Must try at least 3 times according to DP spec */
> >>>   for (try = 0; try < 5; try++) {
> >>> @@ -1287,7 +1270,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, 
> >>> struct drm_dp_aux_msg *msg)
> >>>   memcpy(txbuf + HEADER_SIZE, msg->buffer, 
> >>> msg->size);
> >>>
> >>>   ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
> >>> - rxbuf, rxsize, false);
> >>> + rxbuf, rxsize, 0);
> >>>   if (ret > 0) {
> >>>   msg->reply = rxbuf[0] >> 4;
> >>>
> >>> @@ -1310,7 +1293,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, 
> >>> struct drm_dp_aux_msg *msg)
> >>>   return -E2BIG;
> >>>
> >>>   ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
> >>> - rxbuf, rxsize, false);
> >>> + rxbuf, rxsize, 0);
> >>>   if (ret > 0) {
> >>>   msg->reply = rxbuf[0] >> 4;
> >>>   /*
> >>> @@ -5085,7 +5068,7 @@ int intel_dp_hdcp_write_an_aksv(struct 
> >>> intel_digital_port *intel_dig_port,
> >>>   u8 *an)
> >>>{
> >>>   struct intel_dp *intel_dp = 
> >>> 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/huc: Mark firmware as failed on auth failure

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/huc: Mark firmware as failed on 
auth failure
URL   : https://patchwork.freedesktop.org/series/39280/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass   -> SKIP   (shard-snb)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-right-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +1
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> SKIP   (shard-snb) fdo#103375

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:3442 pass:1802 dwarn:2   dfail:0   fail:13  skip:1624 
time:12396s
shard-hswtotal:3463 pass:1770 dwarn:1   dfail:0   fail:1   skip:1690 
time:12247s
shard-snbtotal:3463 pass:1359 dwarn:2   dfail:0   fail:1   skip:2101 
time:6918s
Blacklisted hosts:
shard-kbltotal:3297 pass:1821 dwarn:2   dfail:1   fail:11  skip:1460 
time:9388s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8215/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915/execlists: Split spinlock from its irq disabling side-effect

[Mika Kuoppala]

Chris Wilson  writes:

> Quoting Mika Kuoppala (2018-03-02 15:50:53)
>> Chris Wilson  writes:
>> 
>> > During reset/wedging, we have to clean up the requests on the timeline
>> > and flush the pending interrupt state. Currently, we are abusing the irq
>> > disabling of the timeline spinlock to protect the irq state in
>> > conjunction to the engine's timeline requests, but this is accidental
>> > and conflates the spinlock with the irq state. A baffling state of
>> > affairs for the reader.
>> >
>> > Instead, explicitly disable irqs over the critical section, and separate
>> > modifying the irq state from the timeline's requests.
>> >
>> > Suggested-by: Mika Kuoppala 
>> > Signed-off-by: Chris Wilson 
>> > Cc: Mika Kuoppala 
>> > Cc: Michel Thierry 
>> > ---
>> >  drivers/gpu/drm/i915/intel_lrc.c | 21 +++--
>> >  1 file changed, 15 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
>> > b/drivers/gpu/drm/i915/intel_lrc.c
>> > index 0482e54c94f0..7d1109aceabb 100644
>> > --- a/drivers/gpu/drm/i915/intel_lrc.c
>> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> > @@ -689,11 +689,13 @@ static void execlists_cancel_requests(struct 
>> > intel_engine_cs *engine)
>> >  
>> >   GEM_TRACE("%s\n", engine->name);
>> >  
>> > - spin_lock_irqsave(>timeline->lock, flags);
>> > + local_irq_save(flags);
>> 
>> Chris explained in irc that this is for lockdep only. It was a bit
>> confusing as we already are guaranteed exclusive access to
>> state by tasklet being killed and dead at this point.
>> 
>> I think this warrants a comment that this is to soothe lockdep.
>
> /*
>  * Before we call engine->cancel_requests(), we should have exclusive
>  * access to the submission state. This is arranged for us by the caller
>  * disabling the interrupt generation, the tasklet and other threads
>  * that may then access the same state, giving us a free hand to
>  * reset state. However, we still need to let lockdep be aware that
>  * we know this state may be accessed in hardirq context, so we
>  * disable the irq around this manipulation and we want to keep
>  * the spinlock focused on its duties and not accidentally conflate
>  * coverage to the submission's irq state. (Similarly, although we
>  * shouldn't need to disable irq around the manipulation of the
>  * submission's irq state, we also wish to remind ourselves that
>  * it is irq state.)
>  */
>
>> >  
>> >   /* Cancel the requests on the HW and clear the ELSP tracker. */
>> >   execlists_cancel_port_requests(execlists);
>> >  
>> > + spin_lock(>timeline->lock);
>> > @@ -1618,10 +1622,11 @@ static void reset_common_ring(struct 
>> > intel_engine_cs *engine,
>> >   GEM_TRACE("%s seqno=%x\n",
>> > engine->name, request ? request->global_seqno : 0);
>> >  
>> > - spin_lock_irqsave(>timeline->lock, flags);
>
>   /* See execlists_cancel_requests() for the irq/spinlock split. */
>> > + local_irq_save(flags);
>
> Good?

Much more than I bargained for. Excellent!
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/6] drm/i915/icl: Enhanced execution list support

[Mika Kuoppala]

From: Thomas Daniel 

Enhanced Execlists is an upgraded version of execlists which supports
up to 8 ports. The lrcs to be submitted are written to a submit queue
(the ExecLists Submission Queue - ELSQ), which is then loaded on the
HW. When writing to the ELSP register, the lrcs are written cyclically
in the queue from position 0 to position 7. Alternatively, it is
possible to write directly in the individual positions of the queue
using the ELSQC registers. To be able to re-use all the existing code
we're using the latter method and we're currently limiting ourself to
only using 2 elements.

v2: Rebase.
v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
v5: Reword commit, rename regs to be closer to specs, turn off
preemption (Daniele), reuse engine->execlists.elsp (Chris)
v6: use has_logical_ring_elsq to differentiate the new paths
v7: add preemption support, rename els to submit_reg (Chris)
v8: save the ctrl register inside the execlists struct, drop CSB
handling updates (superseded by preempt_complete_status) (Chris)
v9: s/drm_i915_gem_request/i915_request (Mika)
v10: resolved conflict in inject_preempt_context (Mika)

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Thomas Daniel 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson  (v8)
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_pci.c  |  3 +-
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 drivers/gpu/drm/i915/intel_lrc.c | 58 
 drivers/gpu/drm/i915/intel_lrc.h |  3 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h  | 12 +--
 6 files changed, 62 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8e2e6585549d..2b52592b193e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2772,6 +2772,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 
 #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
((dev_priv)->info.has_logical_ring_contexts)
+#define HAS_LOGICAL_RING_ELSQ(dev_priv) \
+   ((dev_priv)->info.has_logical_ring_elsq)
 #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 26e8f5c13231..062e91b39085 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -594,7 +594,8 @@ static const struct intel_device_info intel_cannonlake_info 
= {
GEN10_FEATURES, \
GEN(11), \
.ddb_size = 2048, \
-   .has_csr = 0
+   .has_csr = 0, \
+   .has_logical_ring_elsq = 1
 
 static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index ab5bfd305477..7cc5a8e649b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -96,6 +96,7 @@ enum intel_platform {
func(has_l3_dpf); \
func(has_llc); \
func(has_logical_ring_contexts); \
+   func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
func(has_overlay); \
func(has_pooled_eu); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e50d86af1345..ea88e74ba8ac 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -417,18 +417,30 @@ static u64 execlists_update_context(struct i915_request 
*rq)
return ce->lrc_desc;
 }
 
-static inline void elsp_write(u64 desc, u32 __iomem *elsp)
+static inline void write_desc(struct intel_engine_execlists *execlists, u64 
desc, u32 port)
 {
-   writel(upper_32_bits(desc), elsp);
-   writel(lower_32_bits(desc), elsp);
+   if (execlists->ctrl_reg) {
+   writel(lower_32_bits(desc), execlists->submit_reg + port * 2);
+   writel(upper_32_bits(desc), execlists->submit_reg + port * 2 + 
1);
+   } else {
+   writel(upper_32_bits(desc), execlists->submit_reg);
+   writel(lower_32_bits(desc), execlists->submit_reg);
+   }
 }
 
 static void execlists_submit_ports(struct intel_engine_cs *engine)
 {
-   struct execlist_port *port = engine->execlists.port;
+   struct intel_engine_execlists *execlists = >execlists;
+   struct execlist_port *port = execlists->port;
unsigned int n;
 
-   for (n = execlists_num_ports(>execlists); n--; ) {
+   /*
+* ELSQ note: the submit queue is not cleared after 

[Intel-gfx] [PATCH 3/6] drm/i915/icl: new context descriptor support

[Mika Kuoppala]

From: Daniele Ceraolo Spurio 

Starting from Gen11 the context descriptor format has been updated in
the HW. The hw_id field has been considerably reduced in size and engine
class and instance fields have been added.

There is a slight name clashing issue because the field that we call
hw_id is actually called SW Context ID in the specs for Gen11+.

With the current size of the hw_id field we can have a maximum of 2k
contexts at any time, but we could use the sw_counter field (which is sw
defined) to increase that because the HW requirement is that
engine_id + sw id + sw_counter is a unique number.
GuC uses a similar method to support more contexts but does its tracking
at lrc level. To avoid doing an implementation that will need to be
reworked once GuC support lands, defer it for now and mark it as TODO.

v2: rebased, add documentation, fix GEN11_ENGINE_INSTANCE_SHIFT
v3: rebased, bring back lost code from i915_gem_context.c
v4: make TODO comment more generic
v5: be consistent with bit ordering, add extra checks (Chris)

Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 11 --
 drivers/gpu/drm/i915/i915_reg.h |  6 ++
 drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
 drivers/gpu/drm/i915/intel_lrc.c| 36 +++--
 5 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10c9e5e619ab..8e2e6585549d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2103,6 +2103,7 @@ struct drm_i915_private {
 */
struct ida hw_ida;
 #define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
} contexts;
 
u32 fdi_rx_config;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index a73340ae9419..f2cbea7cf940 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -211,9 +211,15 @@ static void context_close(struct i915_gem_context *ctx)
 static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out)
 {
int ret;
+   unsigned int max;
+
+   if (INTEL_GEN(dev_priv) >= 11)
+   max = GEN11_MAX_CONTEXT_HW_ID;
+   else
+   max = MAX_CONTEXT_HW_ID;
 
ret = ida_simple_get(_priv->contexts.hw_ida,
-0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
+0, max, GFP_KERNEL);
if (ret < 0) {
/* Contexts are only released when no longer active.
 * Flush any pending retires to hopefully release some
@@ -221,7 +227,7 @@ static int assign_hw_id(struct drm_i915_private *dev_priv, 
unsigned *out)
 */
i915_retire_requests(dev_priv);
ret = ida_simple_get(_priv->contexts.hw_ida,
-0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
+0, max, GFP_KERNEL);
if (ret < 0)
return ret;
}
@@ -463,6 +469,7 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
 
/* Using the simple ida interface, the max is limited by sizeof(int) */
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
+   BUILD_BUG_ON(GEN11_MAX_CONTEXT_HW_ID > INT_MAX);
ida_init(_priv->contexts.hw_ida);
 
/* lowest priority; idle task */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 45ae05d0fe78..9a62d20bea8e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3912,6 +3912,12 @@ enum {
 
 #define GEN8_CTX_ID_SHIFT 32
 #define GEN8_CTX_ID_WIDTH 21
+#define GEN11_SW_CTX_ID_SHIFT 37
+#define GEN11_SW_CTX_ID_WIDTH 11
+#define GEN11_ENGINE_CLASS_SHIFT 61
+#define GEN11_ENGINE_CLASS_WIDTH 3
+#define GEN11_ENGINE_INSTANCE_SHIFT 48
+#define GEN11_ENGINE_INSTANCE_WIDTH 6
 
 #define CHV_CLK_CTL1   _MMIO(0x101100)
 #define VLV_CLK_CTL2   _MMIO(0x101104)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 911fc08658c5..4ba139c27fba 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -234,6 +234,9 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
GEM_BUG_ON(info->class >= ARRAY_SIZE(intel_engine_classes));
class_info = _engine_classes[info->class];
 
+   BUILD_BUG_ON(MAX_ENGINE_CLASS >= BIT(GEN11_ENGINE_CLASS_WIDTH));
+   BUILD_BUG_ON(MAX_ENGINE_INSTANCE >= BIT(GEN11_ENGINE_INSTANCE_WIDTH));
+
if (GEM_WARN_ON(info->class > 

[Intel-gfx] [PATCH 6/6] drm/i915/icl: Gen11 forcewake support

[Mika Kuoppala]

From: Daniele Ceraolo Spurio 

The main difference with previous GENs is that starting from Gen11
each VCS and VECS engine has its own power well, which only exist
if the related engine exists in the HW.
The fallback forcewake request workaround is only needed on gen9
according to the HSDES WA entry (1604254524), so we can go back to using
the simpler fw_domains_get/put functions.

BSpec: 18331

v2: fix fwtable, use array to test shadow tables, create new
accessors to avoid check on every access (Tvrtko)
v3 (from Paulo): Rebase.
v4:
  - Range 09400-097FF should be FORCEWAKE_ALL (Daniele)
  - Use the BIT macro for forcewake domains (Daniele)
  - Add a comment about the range ordering (Oscar)
  - Updated commit message (Oscar)
v5: Rebased
v6: Use I915_MAX_VCS/VECS (Michal)
v7: translate FORCEWAKE_ALL to available domains
v8: rebase, add clarification on fallback ack in commit message.
v9: fix rebase issue, change check in fw_domains_init from IS_GEN11
to GEN >= 11
v10: Generate is_genX_shadowed with a macro (Daniele)
 Include gen11_fw_ranges in the selftest (Michel)
v11: Simplify FORCEWAKE_ALL, new line between NEEDS_FORCEWAKEs (Tvrtko)

Cc: Michal Wajdeczko 
Cc: Tvrtko Ursulin 
Cc: Paulo Zanoni 
Acked-by: Michel Thierry 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
Signed-off-by: Michel Thierry 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_reg.h   |   4 +
 drivers/gpu/drm/i915/intel_uncore.c   | 157 --
 drivers/gpu/drm/i915/intel_uncore.h   |  23 +++-
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  31 +++--
 4 files changed, 189 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9a62d20bea8e..4787d9bf58b9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8020,9 +8020,13 @@ enum {
 #define   VLV_GTLC_PW_RENDER_STATUS_MASK   (1 << 7)
 #define  FORCEWAKE_MT  _MMIO(0xa188) /* multi-threaded 
*/
 #define  FORCEWAKE_MEDIA_GEN9  _MMIO(0xa270)
+#define  FORCEWAKE_MEDIA_VDBOX_GEN11(n)_MMIO(0xa540 + (n) * 4)
+#define  FORCEWAKE_MEDIA_VEBOX_GEN11(n)_MMIO(0xa560 + (n) * 4)
 #define  FORCEWAKE_RENDER_GEN9 _MMIO(0xa278)
 #define  FORCEWAKE_BLITTER_GEN9_MMIO(0xa188)
 #define  FORCEWAKE_ACK_MEDIA_GEN9  _MMIO(0x0D88)
+#define  FORCEWAKE_ACK_MEDIA_VDBOX_GEN11(n)_MMIO(0x0D50 + (n) * 4)
+#define  FORCEWAKE_ACK_MEDIA_VEBOX_GEN11(n)_MMIO(0x0D70 + (n) * 4)
 #define  FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0x0D84)
 #define  FORCEWAKE_ACK_BLITTER_GEN9_MMIO(0x130044)
 #define   FORCEWAKE_KERNEL BIT(0)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 5ae9a62712ca..4df7c2ef8576 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -37,6 +37,12 @@ static const char * const forcewake_domain_names[] = {
"render",
"blitter",
"media",
+   "vdbox0",
+   "vdbox1",
+   "vdbox2",
+   "vdbox3",
+   "vebox0",
+   "vebox1",
 };
 
 const char *
@@ -774,6 +780,9 @@ void assert_forcewakes_active(struct drm_i915_private 
*dev_priv,
 /* We give fast paths for the really cool registers */
 #define NEEDS_FORCE_WAKE(reg) ((reg) < 0x4)
 
+#define GEN11_NEEDS_FORCE_WAKE(reg) \
+   ((reg) < 0x4 || ((reg) >= 0x1c && (reg) < 0x1dc000))
+
 #define __gen6_reg_read_fw_domains(offset) \
 ({ \
enum forcewake_domains __fwd; \
@@ -826,6 +835,14 @@ find_fw_domain(struct drm_i915_private *dev_priv, u32 
offset)
if (!entry)
return 0;
 
+   /*
+* The list of FW domains depends on the SKU in gen11+ so we
+* can't determine it statically. We use FORCEWAKE_ALL and
+* translate it here to the list of available domains.
+*/
+   if (entry->domains == FORCEWAKE_ALL)
+   return dev_priv->uncore.fw_domains;
+
WARN(entry->domains & ~dev_priv->uncore.fw_domains,
 "Uninitialized forcewake domain(s) 0x%x accessed at 0x%x\n",
 entry->domains & ~dev_priv->uncore.fw_domains, offset);
@@ -860,6 +877,14 @@ static const struct intel_forcewake_range 
__vlv_fw_ranges[] = {
__fwd; \
 })
 
+#define __gen11_fwtable_reg_read_fw_domains(offset) \
+({ \
+   enum forcewake_domains __fwd = 0; \
+   if (GEN11_NEEDS_FORCE_WAKE((offset))) \
+   __fwd = find_fw_domain(dev_priv, offset); \
+   __fwd; \
+})
+
 /* *Must* be sorted by offset! See intel_shadow_table_check(). */
 static const i915_reg_t 

[Intel-gfx] [PATCH 5/6] drm/i915/icl: Add Indirect Context Offset for Gen11

[Mika Kuoppala]

From: Michel Thierry 

v2: rebased to intel_lr_indirect_ctx_offset
v3: rebase, move define to intel_lrc_reg.h

BSpec: 11740
Signed-off-by: Michel Thierry 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Michal Wajdeczko 
Reviewed-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_lrc.c | 4 
 drivers/gpu/drm/i915/intel_lrc_reg.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ea88e74ba8ac..78ffa9ade608 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2244,6 +2244,10 @@ static u32 intel_lr_indirect_ctx_offset(struct 
intel_engine_cs *engine)
default:
MISSING_CASE(INTEL_GEN(engine->i915));
/* fall through */
+   case 11:
+   indirect_ctx_offset =
+   GEN11_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
+   break;
case 10:
indirect_ctx_offset =
GEN10_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h 
b/drivers/gpu/drm/i915/intel_lrc_reg.h
index a53336e2fc97..169a2239d6c7 100644
--- a/drivers/gpu/drm/i915/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
@@ -63,5 +63,6 @@
 #define GEN8_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x17
 #define GEN9_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x26
 #define GEN10_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0x19
+#define GEN11_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0x1A
 
 #endif /* _INTEL_LRC_REG_H_ */
-- 
2.14.1

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

[Intel-gfx] [PATCH 1/6] drm/i915/icl: Ringbuffer interrupt handling

[Mika Kuoppala]

From: Tvrtko Ursulin 

On Gen11 interrupt masks need to be clear to allow C6 entry.
We keep them all enabled knowing that we generate extra
interrupts.

v2: Rebase.
v3: Remove gen 11 extra check in logical_render_ring_init.
v4: Rebase fixes.
v5: Rebase/refactor.
v6: Rebase.
v7: Rebase.
v8: Update comment and commit message (Daniele)

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Daniele Ceraolo Spurio 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 16 ++--
 drivers/gpu/drm/i915/intel_lrc.c | 13 +++--
 2 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index a83690642aab..094f010908b8 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -168,17 +168,21 @@ static void irq_enable(struct intel_engine_cs *engine)
set_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted);
 
/* Caller disables interrupts */
-   spin_lock(>i915->irq_lock);
-   engine->irq_enable(engine);
-   spin_unlock(>i915->irq_lock);
+   if (engine->irq_enable) {
+   spin_lock(>i915->irq_lock);
+   engine->irq_enable(engine);
+   spin_unlock(>i915->irq_lock);
+   }
 }
 
 static void irq_disable(struct intel_engine_cs *engine)
 {
/* Caller disables interrupts */
-   spin_lock(>i915->irq_lock);
-   engine->irq_disable(engine);
-   spin_unlock(>i915->irq_lock);
+   if (engine->irq_disable) {
+   spin_lock(>i915->irq_lock);
+   engine->irq_disable(engine);
+   spin_unlock(>i915->irq_lock);
+   }
 }
 
 void __intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 14288743909f..a96288c85cb9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2009,8 +2009,17 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
*engine)
 
engine->set_default_submission = execlists_set_default_submission;
 
-   engine->irq_enable = gen8_logical_ring_enable_irq;
-   engine->irq_disable = gen8_logical_ring_disable_irq;
+   if (INTEL_GEN(engine->i915) < 11) {
+   engine->irq_enable = gen8_logical_ring_enable_irq;
+   engine->irq_disable = gen8_logical_ring_disable_irq;
+   } else {
+   /*
+* TODO: On Gen11 interrupt masks need to be clear
+* to allow C6 entry. Keep interrupts enabled at
+* and take the hit of generating extra interrupts
+* until a more refined solution exists.
+*/
+   }
engine->emit_bb_start = gen8_emit_bb_start;
 }
 
-- 
2.14.1

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

[Intel-gfx] [PATCH 2/6] drm/i915/icl: Correctly initialize the Gen11 engines

[Mika Kuoppala]

From: Oscar Mateo 

Gen11 has up to 4 VCS and up to 2 VECS engines, this patch adds mmio
base definitions for all of them.

Bspec: 20944
Bspec: 7021

v2: Set the correct mmio_base in intel_engines_init_mmio; updating the
base mmio values any later would cause incorrect reads in
i915_gem_sanitize (Michel).

Cc: Tvrtko Ursulin 
Cc: Ceraolo Spurio, Daniele 
Signed-off-by: Oscar Mateo 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_reg.h|  6 +
 drivers/gpu/drm/i915/intel_engine_cs.c | 44 +-
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 258e86eb37d5..45ae05d0fe78 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2345,7 +2345,13 @@ enum i915_power_well_id {
 #define BSD_RING_BASE  0x04000
 #define GEN6_BSD_RING_BASE 0x12000
 #define GEN8_BSD2_RING_BASE0x1c000
+#define GEN11_BSD_RING_BASE0x1c
+#define GEN11_BSD2_RING_BASE   0x1c4000
+#define GEN11_BSD3_RING_BASE   0x1d
+#define GEN11_BSD4_RING_BASE   0x1d4000
 #define VEBOX_RING_BASE0x1a000
+#define GEN11_VEBOX_RING_BASE  0x1c8000
+#define GEN11_VEBOX2_RING_BASE 0x1d8000
 #define BLT_RING_BASE  0x22000
 #define RING_TAIL(base)_MMIO((base)+0x30)
 #define RING_HEAD(base)_MMIO((base)+0x34)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3e1107ecb6ee..911fc08658c5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -123,6 +123,22 @@ static const struct engine_info intel_engines[] = {
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
},
+   [VCS3] = {
+   .hw_id = VCS3_HW,
+   .uabi_id = I915_EXEC_BSD,
+   .class = VIDEO_DECODE_CLASS,
+   .instance = 2,
+   .mmio_base = GEN11_BSD3_RING_BASE,
+   .irq_shift = 0, /* not used */
+   },
+   [VCS4] = {
+   .hw_id = VCS4_HW,
+   .uabi_id = I915_EXEC_BSD,
+   .class = VIDEO_DECODE_CLASS,
+   .instance = 3,
+   .mmio_base = GEN11_BSD4_RING_BASE,
+   .irq_shift = 0, /* not used */
+   },
[VECS] = {
.hw_id = VECS_HW,
.uabi_id = I915_EXEC_VEBOX,
@@ -131,6 +147,14 @@ static const struct engine_info intel_engines[] = {
.mmio_base = VEBOX_RING_BASE,
.irq_shift = GEN8_VECS_IRQ_SHIFT,
},
+   [VECS2] = {
+   .hw_id = VECS2_HW,
+   .uabi_id = I915_EXEC_VEBOX,
+   .class = VIDEO_ENHANCEMENT_CLASS,
+   .instance = 1,
+   .mmio_base = GEN11_VEBOX2_RING_BASE,
+   .irq_shift = 0, /* not used */
+   },
 };
 
 /**
@@ -230,7 +254,25 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
 class_info->name, info->instance) >=
sizeof(engine->name));
engine->hw_id = engine->guc_id = info->hw_id;
-   engine->mmio_base = info->mmio_base;
+   if (INTEL_GEN(dev_priv) >= 11) {
+   switch (engine->id) {
+   case VCS:
+   engine->mmio_base = GEN11_BSD_RING_BASE;
+   break;
+   case VCS2:
+   engine->mmio_base = GEN11_BSD2_RING_BASE;
+   break;
+   case VECS:
+   engine->mmio_base = GEN11_VEBOX_RING_BASE;
+   break;
+   default:
+   /* take the original value for all other engines  */
+   engine->mmio_base = info->mmio_base;
+   break;
+   }
+   } else {
+   engine->mmio_base = info->mmio_base;
+   }
engine->irq_shift = info->irq_shift;
engine->class = info->class;
engine->instance = info->instance;
-- 
2.14.1

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

[Intel-gfx] [PATCH igt] lib: Fix MI_BATCH_BUFFER_START for hang injection

[Chris Wilson]

A couple of bugs inside the hang injector, the worst being that the
presumed_offset of the reloc didn't match the batch; so if the reloc was
skipped (as the presumed_offset matched the reloc offset), the batch
wasn't updated and so we may not have generated a hanging batch at all!
Secondly, the MI_BATCH_BUFFER_START was not correct for all gen.

Signed-off-by: Chris Wilson 
---
 lib/igt_gt.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index e630550b..799ca1ae 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -276,6 +276,7 @@ igt_hang_t igt_hang_ctx(int fd,
uint32_t b[16];
unsigned ban;
unsigned len;
+   int gen;
 
igt_require_hang_ring(fd, ring);
 
@@ -310,12 +311,26 @@ igt_hang_t igt_hang_ctx(int fd,
 
memset(b, 0xc5, sizeof(b));
 
-   len = 2;
-   if (intel_gen(intel_get_drm_devid(fd)) >= 8)
+   len = 0;
+   gen = intel_gen(intel_get_drm_devid(fd));
+   if (gen >= 8) {
+   b[len++] = MI_BATCH_BUFFER_START | 1 << 8 | 1;
+   b[len++] = 0;
+   b[len++] = 0;
+   } else if (gen >= 6) {
+   b[len++] = MI_BATCH_BUFFER_START | 1 << 8;
+   b[len++] = 0;
+   } else {
+   b[len++] = MI_BATCH_BUFFER_START | 2 << 6;
+   b[len] = 0;
+   if (gen < 4) {
+   b[len] |= 1;
+   reloc.delta = 1;
+   }
len++;
-   b[0] = MI_BATCH_BUFFER_START | (len - 2);
-   b[len] = MI_BATCH_BUFFER_END;
-   b[len+1] = MI_NOOP;
+   }
+   b[len++] = MI_BATCH_BUFFER_END;
+   b[len] = MI_NOOP;
gem_write(fd, exec.handle, 0, b, sizeof(b));
 
reloc.offset = sizeof(uint32_t);
@@ -364,8 +379,7 @@ void igt_post_hang_ring(int fd, igt_hang_t arg)
if (arg.handle == 0)
return;
 
-   gem_set_domain(fd, arg.handle,
-  I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
+   gem_sync(fd, arg.handle);
gem_close(fd, arg.handle);
 
context_set_ban(fd, arg.ctx, arg.ban);
-- 
2.16.2

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

Re: [Intel-gfx] i915 vs checkpatch

[Jani Nikula]

On Thu, 01 Mar 2018, Jani Nikula  wrote:
> Does checkpatch support disabling checks or do you have to filter them
> out from the output?

Turns out it does. There's an --ignore option. For starters, I sent a
patch [1] to show the warning types in the output, so we can more
accurately discuss the ignores.

Alas it's probably not as simple as just slamming the ignores to dim:
I'll probably want to use the strictest set both when I'm developing and
applying patches (just to get an idea about the warnings, and I try to
keep my patches under 80 columns, etc.). Some other drivers and drm core
might have different sets of rules, and dim is no longer an Intel-only
tool. So we probably need to be able to specify different rule sets.

BR,
Jani.

PS. We need to get dim-tools and igt-dev etc. subscribed to the mail
archive and marc etc.


[1] id:20180302155800.6874-1-jani.nik...@intel.com



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

Re: [Intel-gfx] [PATCH 4/5] drm/i915/execlists: Split spinlock from its irq disabling side-effect

[Chris Wilson]

Quoting Mika Kuoppala (2018-03-02 15:50:53)
> Chris Wilson  writes:
> 
> > During reset/wedging, we have to clean up the requests on the timeline
> > and flush the pending interrupt state. Currently, we are abusing the irq
> > disabling of the timeline spinlock to protect the irq state in
> > conjunction to the engine's timeline requests, but this is accidental
> > and conflates the spinlock with the irq state. A baffling state of
> > affairs for the reader.
> >
> > Instead, explicitly disable irqs over the critical section, and separate
> > modifying the irq state from the timeline's requests.
> >
> > Suggested-by: Mika Kuoppala 
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Michel Thierry 
> > ---
> >  drivers/gpu/drm/i915/intel_lrc.c | 21 +++--
> >  1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 0482e54c94f0..7d1109aceabb 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -689,11 +689,13 @@ static void execlists_cancel_requests(struct 
> > intel_engine_cs *engine)
> >  
> >   GEM_TRACE("%s\n", engine->name);
> >  
> > - spin_lock_irqsave(>timeline->lock, flags);
> > + local_irq_save(flags);
> 
> Chris explained in irc that this is for lockdep only. It was a bit
> confusing as we already are guaranteed exclusive access to
> state by tasklet being killed and dead at this point.
> 
> I think this warrants a comment that this is to soothe lockdep.

/*
 * Before we call engine->cancel_requests(), we should have exclusive
 * access to the submission state. This is arranged for us by the caller
 * disabling the interrupt generation, the tasklet and other threads
 * that may then access the same state, giving us a free hand to
 * reset state. However, we still need to let lockdep be aware that
 * we know this state may be accessed in hardirq context, so we
 * disable the irq around this manipulation and we want to keep
 * the spinlock focused on its duties and not accidentally conflate
 * coverage to the submission's irq state. (Similarly, although we
 * shouldn't need to disable irq around the manipulation of the
 * submission's irq state, we also wish to remind ourselves that
 * it is irq state.)
 */

> >  
> >   /* Cancel the requests on the HW and clear the ELSP tracker. */
> >   execlists_cancel_port_requests(execlists);
> >  
> > + spin_lock(>timeline->lock);
> > @@ -1618,10 +1622,11 @@ static void reset_common_ring(struct 
> > intel_engine_cs *engine,
> >   GEM_TRACE("%s seqno=%x\n",
> > engine->name, request ? request->global_seqno : 0);
> >  
> > - spin_lock_irqsave(>timeline->lock, flags);

/* See execlists_cancel_requests() for the irq/spinlock split. */
> > + local_irq_save(flags);

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: clean up leftover references to CHV HBR2 support

[Patchwork]

== Series Details ==

Series: drm/i915/dp: clean up leftover references to CHV HBR2 support
URL   : https://patchwork.freedesktop.org/series/39285/
State : success

== Summary ==

Series 39285v1 drm/i915/dp: clean up leftover references to CHV HBR2 support
https://patchwork.freedesktop.org/api/1.0/series/39285/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:480s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:493s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:406s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:441s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:487s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:421s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s

7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC 
integration manifest
5222c26026ac drm/i915/dp: clean up leftover references to CHV HBR2 support

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8219/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Call prepare/finish around intel_gpu_reset() during GEM sanitize

[Mika Kuoppala]

Chris Wilson  writes:

> During GEM sanitization, we reset the GPU so that it's always in a
> default state whenever we take over or return the GPU back to the BIOS.
> We call the GPU reset directly, so that we don't get caught up in trying
> to handle GEM or KMS state that is isn't ready at that time, but now we
> have a couple of helpers to prepare and finish around the HW reset. Use
> them, so that we can extend them as required for updating HW state
> tracking around resets.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 
> Cc: Michal Wajdeczko 

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915/execlists: Split spinlock from its irq disabling side-effect

[Mika Kuoppala]

Chris Wilson  writes:

> During reset/wedging, we have to clean up the requests on the timeline
> and flush the pending interrupt state. Currently, we are abusing the irq
> disabling of the timeline spinlock to protect the irq state in
> conjunction to the engine's timeline requests, but this is accidental
> and conflates the spinlock with the irq state. A baffling state of
> affairs for the reader.
>
> Instead, explicitly disable irqs over the critical section, and separate
> modifying the irq state from the timeline's requests.
>
> Suggested-by: Mika Kuoppala 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0482e54c94f0..7d1109aceabb 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -689,11 +689,13 @@ static void execlists_cancel_requests(struct 
> intel_engine_cs *engine)
>  
>   GEM_TRACE("%s\n", engine->name);
>  
> - spin_lock_irqsave(>timeline->lock, flags);
> + local_irq_save(flags);

Chris explained in irc that this is for lockdep only. It was a bit
confusing as we already are guaranteed exclusive access to
state by tasklet being killed and dead at this point.

I think this warrants a comment that this is to soothe lockdep.
>  
>   /* Cancel the requests on the HW and clear the ELSP tracker. */
>   execlists_cancel_port_requests(execlists);
>  
> + spin_lock(>timeline->lock);
> +
>   /* Mark all executing requests as skipped. */
>   list_for_each_entry(rq, >timeline->requests, link) {
>   GEM_BUG_ON(!rq->global_seqno);
> @@ -727,6 +729,8 @@ static void execlists_cancel_requests(struct 
> intel_engine_cs *engine)
>   execlists->first = NULL;
>   GEM_BUG_ON(port_isset(execlists->port));
>  
> + spin_unlock(>timeline->lock);
> +
>   /*
>* The port is checked prior to scheduling a tasklet, but
>* just in case we have suspended the tasklet to do the
> @@ -738,7 +742,7 @@ static void execlists_cancel_requests(struct 
> intel_engine_cs *engine)
>   /* Mark all CS interrupts as complete */
>   execlists->active = 0;
>  
> - spin_unlock_irqrestore(>timeline->lock, flags);
> + local_irq_restore(flags);
>  }
>  
>  /*
> @@ -1618,10 +1622,11 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>   GEM_TRACE("%s seqno=%x\n",
> engine->name, request ? request->global_seqno : 0);
>  
> - spin_lock_irqsave(>timeline->lock, flags);
> + local_irq_save(flags);
>  
>   reset_irq(engine);
>  
> +

Unintentional extra line?

Reviewed-by: Mika Kuoppala 

>   /*
>* Catch up with any missed context-switch interrupts.
>*
> @@ -1634,14 +1639,17 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>   execlists_cancel_port_requests(execlists);
>  
>   /* Push back any incomplete requests for replay after the reset. */
> + spin_lock(>timeline->lock);
>   __unwind_incomplete_requests(engine);
> + spin_unlock(>timeline->lock);
>  
>   /* Mark all CS interrupts as complete */
>   execlists->active = 0;
>  
> - spin_unlock_irqrestore(>timeline->lock, flags);
> + local_irq_restore(flags);
>  
> - /* If the request was innocent, we leave the request in the ELSP
> + /*
> +  * If the request was innocent, we leave the request in the ELSP
>* and will try to replay it on restarting. The context image may
>* have been corrupted by the reset, in which case we may have
>* to service a new GPU hang, but more likely we can continue on
> @@ -1654,7 +1662,8 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>   if (!request || request->fence.error != -EIO)
>   return;
>  
> - /* We want a simple context + ring to execute the breadcrumb update.
> + /*
> +  * We want a simple context + ring to execute the breadcrumb update.
>* We cannot rely on the context being intact across the GPU hang,
>* so clear it and rebuild just what we need for the breadcrumb.
>* All pending requests for this context will be zapped, and any
> -- 
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset (rev2)

[Imre Deak]

On Thu, Mar 01, 2018 at 10:48:25PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset (rev2)
> URL   : https://patchwork.freedesktop.org/series/39129/
> State : success
> 
> == Summary ==

Thanks for the review, pushed it to -dinq.

> 
>  Possible new issues:
> 
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:
> dmesg-fail -> PASS   (shard-apl)
> 
>  Known issues:
> 
> Test drv_suspend:
> Subgroup debugfs-reader:
> pass   -> INCOMPLETE (shard-hsw) k.org#196691
> Test gem_eio:
> Subgroup in-flight-contexts:
> pass   -> INCOMPLETE (shard-apl) fdo#104945
> Test kms_chv_cursor_fail:
> Subgroup pipe-b-256x256-top-edge:
> dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
> Test kms_flip:
> Subgroup 2x-flip-vs-expired-vblank-interruptible:
> fail   -> PASS   (shard-hsw) fdo#102887
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-indfb-draw-render:
> fail   -> PASS   (shard-apl) fdo#103167 +1
> Test kms_sysfs_edid_timing:
> warn   -> PASS   (shard-apl) fdo#100047
> Test perf:
> Subgroup polling:
> fail   -> PASS   (shard-hsw) fdo#102252
> 
> k.org#196691 https://bugzilla.kernel.org/show_bug.cgi?id=196691
> fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
> fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
> fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
> fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
> fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
> fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
> 
> shard-apltotal:3459 pass:1819 dwarn:1   dfail:0   fail:7   skip:1631 
> time:11761s
> shard-hswtotal:3441 pass:1755 dwarn:1   dfail:0   fail:1   skip:1682 
> time:11665s
> shard-snbtotal:3461 pass:1360 dwarn:1   dfail:0   fail:1   skip:2099 
> time:6615s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8199/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Move irq state manipulation inside irq disabled region

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Move irq state manipulation inside irq disabled 
region
URL   : https://patchwork.freedesktop.org/series/39276/
State : success

== Summary ==

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-left-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-mmap-gtt:
pass   -> FAIL   (shard-apl) fdo#101623 +1
Test kms_plane_lowres:
Subgroup pipe-c-tiling-yf:
pass   -> FAIL   (shard-apl) fdo#103166
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3463 pass:1819 dwarn:1   dfail:0   fail:10  skip:1632 
time:12439s
shard-hswtotal:3463 pass:1770 dwarn:1   dfail:0   fail:1   skip:1690 
time:12146s
shard-snbtotal:3463 pass:1361 dwarn:2   dfail:0   fail:1   skip:2099 
time:6996s
Blacklisted hosts:
shard-kbltotal:3463 pass:1944 dwarn:3   dfail:0   fail:7   skip:1509 
time:9783s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8213/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Stop engines around GPU reset preparations

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: Stop engines around GPU reset 
preparations
URL   : https://patchwork.freedesktop.org/series/39284/
State : success

== Summary ==

Series 39284v1 series starting with [1/5] drm/i915: Stop engines around GPU 
reset preparations
https://patchwork.freedesktop.org/api/1.0/series/39284/revisions/1/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:478s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:467s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:465s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:395s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:555s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:491s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:404s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:450s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:408s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:447s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:488s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:496s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:403s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:519s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s
fi-cnl-y3 failed to collect. IGT log at Patchwork_8218/fi-cnl-y3/run0.log

7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC 
integration manifest
676919bfcffd drm/i915: Call prepare/finish around intel_gpu_reset() during GEM 
sanitize
93c1a7f6cb61 drm/i915/execlists: Split spinlock from its irq disabling 
side-effect
0a4ef58484b9 drm/i915/execlists: Move irq state manipulation inside irq 
disabled region
1fcd7b68df1b drm/i915: Suspend submission tasklets around wedging
63aeeb0f1728 drm/i915: Stop engines around GPU reset preparations

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8218/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH xf86-video-intel v2] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors

[Chris Wilson]

Quoting Chris Wilson (2018-03-02 12:14:07)
> Quoting Ville Syrjälä (2018-03-02 12:12:26)
> > On Fri, Mar 02, 2018 at 12:01:42PM +, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2018-03-02 11:59:18)
> > > > From: Ville Syrjälä 
> > > > 
> > > > Use the new "COLOR_ENCODING" plane property to implement the
> > > > XV_COLORSPACE port attribute for sprite Xv adaptors.
> > > > 
> > > > v2: assert(colorspace < ARRAY_SIZE) (Chris)
> > > > 
> > > > Cc: Jyri Sarha 
> > > > Cc: Chris Wilson 
> > > > Signed-off-by: Ville Syrjälä 
> > > 
> > > Is this (i.e. the kernel implementation is done) ready to land?
> > 
> > No one has complained about the proposed uapi and I have sufficient
> > r-bs, so I'm ready to push the kernel stuff as soon as there's a green
> > light from the user space side.
> 
> Reviewed-by: Chris Wilson 

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

Re: [Intel-gfx] [PATCH] sna: CustomEDID fix

[Chris Wilson]

Quoting dom.const...@free.fr (2018-02-06 18:57:05)
> 
> 
> > Quoting dom.const...@free.fr (2018-02-02 18:37:12)
> > > Hello,
> > > 
> > > For my HTPC setup, I'm using the option "CustomEDID".
> > > With this option, output attaching and destroying events leads to
> > > crashes.
> > > 
> > > The following sequence leads to a crash:
> > > - In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edid.bin"
> > > - Starting Xorg
> > > - Connect HDMI2
> > > - Disconnect HDMI2
> > > - Reconnect HDMI2
> > >   -> Crash
> > > 
> > > 
> > > The crash happens in xf86OutputSetEDID
> > > (xorg/xserver/hw/xfree86/modes/xf86Crtc.c)
> > > at "free(output->MonInfo)". MonInfo is assigned with
> > > sna_output->fake_edid_mon
> > > which is allocated by intel driver in sna_output_load_fake_edid
> > > (src/sna/sna_display.c).
> > > 
> > > 
> > > Sequence details:
> > > - Starting Xorg
> > >-> fake_edid_mon is initialized
> > > 
> > > - Connect HDMI2
> > >-> xf86OutputSetEDID is called:
> > >- MonInfo is NULL
> > >- MonInfo is assigned with fake_edid_mon pointer
> > >- MonInfo is read by Xorg
> > > 
> > > - Disconnect HDMI2
> > > 
> > > - Reconnect HDMI2
> > >-> xf86OutputSetEDID is called:
> > >- MonInfo is freed thus also fake_edid_mon
> > >- MonInfo is assigned with fake_edid_mon
> > >- MonInfo is read but it was freed -> CRASH
> > > 
> > > 
> > > The fix consists of a new instance of xf86MonPtr for each calls of
> > > xf86OutputSetEDID.
> > > This instance is initialized with fake_edid_raw which render
> > > fake_edid_mon useless.
> > > With this proposal, the behaviour of an EDID override is similar to
> > > a "real" EDID.
> > > 
> > > Regards,
> > > 
> > > 
> > > Signed-off-by: Dominique Constant 
> > > To: Chris Wilson 
> > 
> > Apologies if this is a resend, but could you send me this patch using
> > "git send-email" (or attach the output of "git format-patch"). git am
> > is not happy with it.
> > -Chris
> > 
> 
> 
> Hello,
> Thank you for taking into consideration this patch.

Finally, got around to picking up patches for -intel. Thank you very
much for the fix,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Documentation patch for batchbuffer submission (rev2)

[Patchwork]

== Series Details ==

Series: Documentation patch for batchbuffer submission (rev2)
URL   : https://patchwork.freedesktop.org/series/38433/
State : success

== Summary ==

Series 38433v2 Documentation patch for batchbuffer submission
https://patchwork.freedesktop.org/api/1.0/series/38433/revisions/2/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-guc) fdo#103191
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:475s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:478s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:394s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:492s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:504s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-skl-guc   total:288  pass:259  dwarn:0   dfail:0   fail:1   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:527s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s

7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC 
integration manifest
d41820ee9693 i915: additional GEM documentation

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8217/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/dp: clean up leftover references to CHV HBR2 support

[Jani Nikula]

No such thing as CHV HBR2. Clean up after commit ed63baaf849e
("drm/i915: Avoid TP3 on CHV").

Reported-by: Ville Syrjälä 
Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aba2f45819d8..33946f830641 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -92,8 +92,6 @@ static const struct dp_link_dpll chv_dpll[] = {
{ .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a } },
{ 27,   /* m2_int = 27, m2_fraction = 0 */
{ .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } },
-   { 54,   /* m2_int = 27, m2_fraction = 0 */
-   { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
 };
 
 /**
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Don't create properties without names (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm: Don't create properties without names 
(rev2)
URL   : https://patchwork.freedesktop.org/series/39277/
State : success

== Summary ==

Series 39277v2 series starting with [1/3] drm: Don't create properties without 
names
https://patchwork.freedesktop.org/api/1.0/series/39277/revisions/2/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700k2) fdo#104108
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:376s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:478s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:395s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:488s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:504s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:442s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:490s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:491s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:578s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:403s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:424s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:523s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s

7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC 
integration manifest
0170b5d10306 drm: Add BT.2020 constant luminance enum value for the 
COLOR_ENCODING property
e643d887905b [PATCH v2 2/3 drm: Check property/enum name length
7a28ad7d5e5c drm: Don't create properties without names

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8216/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Suspend submission tasklets around wedging

[Mika Kuoppala]

Chris Wilson  writes:

> After starting hard at sequences like

Perhaps you meant staring, but starting is fine too.
-Mika

>
> [   28.199013]  systemd-1   2..s. 26062228us : 
> execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
> [   28.199095]  systemd-1   2..s. 26062229us : 
> execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x, 
> active=0x1
> [   28.199177]  systemd-1   2..s. 26062230us : 
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
> [   28.199258]  systemd-1   2..s. 26062231us : 
> execlists_submission_tasklet: rcs0 completed ctx=0
> [   28.199340]  gem_eio-829 1..s1 26066853us : 
> execlists_submission_tasklet: rcs0 in[0]:  ctx=1.1, seqno=1, prio=0
> [   28.199421]   -0   2..s. 26066863us : 
> execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
> [   28.199503]   -0   2..s. 26066865us : 
> execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x, 
> active=0x1
> [   28.199585]  gem_eio-829 1..s1 26067077us : 
> execlists_submission_tasklet: rcs0 in[1]:  ctx=3.1, seqno=2, prio=0
> [   28.199667]  gem_eio-829 1..s1 26067078us : 
> execlists_submission_tasklet: rcs0 in[0]:  ctx=1.2, seqno=1, prio=0
> [   28.199749]   -0   2..s. 26067084us : 
> execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
> [   28.199830]   -0   2..s. 26067085us : 
> execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001, 
> active=0x1
> [   28.199912]   -0   2..s. 26067086us : 
> execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
> [   28.14]  gem_eio-829 2..s. 28246084us : 
> execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
> [   28.200096]  gem_eio-829 2..s. 28246088us : 
> execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001, 
> active=0x5
> [   28.200178]  gem_eio-829 2..s. 28246089us : 
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
> [   28.200260]  gem_eio-829 2..s. 28246127us : 
> execlists_submission_tasklet: execlists_submission_tasklet:886 
> GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
>
> the conclusion is that the only place where the ports are reset to zero,
> is from engine->cancel_requests called during i915_gem_set_wedged().
>
> The race is horrible as it results from calling set-wedged on active HW
> (the GPU reset failed) and as such we need to be careful as the HW state
> changes beneath us. Fortunately, it's the same scary conditions as
> affect normal reset, so we can reuse the same machinery to disable state
> tracking as we clobber it.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 
> Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in 
> set_wedged")
> Reviewed-by: Mika Kuoppala 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-ch...@chris-wilson.co.uk
> ---
>  drivers/gpu/drm/i915/i915_gem.c  | 6 +-
>  drivers/gpu/drm/i915/intel_lrc.c | 5 +
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c29b1a1cbe96..dcdcc09240b9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3212,8 +3212,10 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>* rolling the global seqno forward (since this would complete requests
>* for which we haven't set the fence error to EIO yet).
>*/
> - for_each_engine(engine, i915, id)
> + for_each_engine(engine, i915, id) {
> + i915_gem_reset_prepare_engine(engine);
>   engine->submit_request = nop_submit_request;
> + }
>  
>   /*
>* Make sure no one is running the old callback before we proceed with
> @@ -3255,6 +3257,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>   intel_engine_init_global_seqno(engine,
>  
> intel_engine_last_submit(engine));
>   spin_unlock_irqrestore(>timeline->lock, flags);
> +
> + i915_gem_reset_finish_engine(engine);
>   }
>  
>   wake_up_all(>gpu_error.reset_queue);
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 14288743909f..c1a3636e94fc 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -687,6 +687,8 @@ static void execlists_cancel_requests(struct 
> intel_engine_cs *engine)
>   struct rb_node *rb;
>   unsigned long flags;
>  
> + GEM_TRACE("%s\n", engine->name);
> +
>   spin_lock_irqsave(>timeline->lock, flags);
>  
>   /* Cancel the requests on the HW and clear the ELSP tracker. */

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/huc: Mark firmware as failed on auth failure

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/huc: Mark firmware as failed on 
auth failure
URL   : https://patchwork.freedesktop.org/series/39280/
State : success

== Summary ==

Series 39280v1 series starting with [v2,1/2] drm/i915/huc: Mark firmware as 
failed on auth failure
https://patchwork.freedesktop.org/api/1.0/series/39280/revisions/1/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:413s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:467s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:390s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:492s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:504s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:447s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:488s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:445s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:490s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s
fi-cnl-y3 failed to collect. IGT log at Patchwork_8215/fi-cnl-y3/run0.log

7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC 
integration manifest
7d0df29c1a92 HAX: Enable GuC for CI
ad2c01a37e79 drm/i915/huc: Mark firmware as failed on auth failure

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8215/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/uc: Introduce intel_uc_suspend|resume

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/uc: Introduce 
intel_uc_suspend|resume
URL   : https://patchwork.freedesktop.org/series/39272/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-right-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (shard-hsw) fdo#103928
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
fail   -> SKIP   (shard-snb) fdo#102365
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3422 pass:1787 dwarn:2   dfail:0   fail:13  skip:1618 
time:12108s
shard-hswtotal:3463 pass:1770 dwarn:1   dfail:0   fail:1   skip:1690 
time:12133s
shard-snbtotal:3463 pass:1360 dwarn:2   dfail:0   fail:1   skip:2100 
time:6939s
Blacklisted hosts:
shard-kbltotal:3324 pass:1814 dwarn:27  dfail:2   fail:14  skip:1463 
time:8844s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8211/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/5] drm/i915: Suspend submission tasklets around wedging

[Chris Wilson]

After starting hard at sequences like

[   28.199013]  systemd-1   2..s. 26062228us : 
execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
[   28.199095]  systemd-1   2..s. 26062229us : 
execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x, 
active=0x1
[   28.199177]  systemd-1   2..s. 26062230us : 
execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
[   28.199258]  systemd-1   2..s. 26062231us : 
execlists_submission_tasklet: rcs0 completed ctx=0
[   28.199340]  gem_eio-829 1..s1 26066853us : 
execlists_submission_tasklet: rcs0 in[0]:  ctx=1.1, seqno=1, prio=0
[   28.199421]   -0   2..s. 26066863us : 
execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
[   28.199503]   -0   2..s. 26066865us : 
execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x, 
active=0x1
[   28.199585]  gem_eio-829 1..s1 26067077us : 
execlists_submission_tasklet: rcs0 in[1]:  ctx=3.1, seqno=2, prio=0
[   28.199667]  gem_eio-829 1..s1 26067078us : 
execlists_submission_tasklet: rcs0 in[0]:  ctx=1.2, seqno=1, prio=0
[   28.199749]   -0   2..s. 26067084us : 
execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
[   28.199830]   -0   2..s. 26067085us : 
execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001, 
active=0x1
[   28.199912]   -0   2..s. 26067086us : 
execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
[   28.14]  gem_eio-829 2..s. 28246084us : 
execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
[   28.200096]  gem_eio-829 2..s. 28246088us : 
execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001, 
active=0x5
[   28.200178]  gem_eio-829 2..s. 28246089us : 
execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
[   28.200260]  gem_eio-829 2..s. 28246127us : 
execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 
* head + 1] != port->context_id)

the conclusion is that the only place where the ports are reset to zero,
is from engine->cancel_requests called during i915_gem_set_wedged().

The race is horrible as it results from calling set-wedged on active HW
(the GPU reset failed) and as such we need to be careful as the HW state
changes beneath us. Fortunately, it's the same scary conditions as
affect normal reset, so we can reuse the same machinery to disable state
tracking as we clobber it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in set_wedged")
Reviewed-by: Mika Kuoppala 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem.c  | 6 +-
 drivers/gpu/drm/i915/intel_lrc.c | 5 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c29b1a1cbe96..dcdcc09240b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3212,8 +3212,10 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
 * rolling the global seqno forward (since this would complete requests
 * for which we haven't set the fence error to EIO yet).
 */
-   for_each_engine(engine, i915, id)
+   for_each_engine(engine, i915, id) {
+   i915_gem_reset_prepare_engine(engine);
engine->submit_request = nop_submit_request;
+   }
 
/*
 * Make sure no one is running the old callback before we proceed with
@@ -3255,6 +3257,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_init_global_seqno(engine,
   
intel_engine_last_submit(engine));
spin_unlock_irqrestore(>timeline->lock, flags);
+
+   i915_gem_reset_finish_engine(engine);
}
 
wake_up_all(>gpu_error.reset_queue);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 14288743909f..c1a3636e94fc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -687,6 +687,8 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
struct rb_node *rb;
unsigned long flags;
 
+   GEM_TRACE("%s\n", engine->name);
+
spin_lock_irqsave(>timeline->lock, flags);
 
/* Cancel the requests on the HW and clear the ELSP tracker. */
@@ -733,6 +735,9 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
 */
clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
 
+   /* Mark all CS interrupts as complete */
+   execlists->active = 0;
+

[Intel-gfx] [PATCH 4/5] drm/i915/execlists: Split spinlock from its irq disabling side-effect

[Chris Wilson]

During reset/wedging, we have to clean up the requests on the timeline
and flush the pending interrupt state. Currently, we are abusing the irq
disabling of the timeline spinlock to protect the irq state in
conjunction to the engine's timeline requests, but this is accidental
and conflates the spinlock with the irq state. A baffling state of
affairs for the reader.

Instead, explicitly disable irqs over the critical section, and separate
modifying the irq state from the timeline's requests.

Suggested-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_lrc.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0482e54c94f0..7d1109aceabb 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -689,11 +689,13 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
 
GEM_TRACE("%s\n", engine->name);
 
-   spin_lock_irqsave(>timeline->lock, flags);
+   local_irq_save(flags);
 
/* Cancel the requests on the HW and clear the ELSP tracker. */
execlists_cancel_port_requests(execlists);
 
+   spin_lock(>timeline->lock);
+
/* Mark all executing requests as skipped. */
list_for_each_entry(rq, >timeline->requests, link) {
GEM_BUG_ON(!rq->global_seqno);
@@ -727,6 +729,8 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
execlists->first = NULL;
GEM_BUG_ON(port_isset(execlists->port));
 
+   spin_unlock(>timeline->lock);
+
/*
 * The port is checked prior to scheduling a tasklet, but
 * just in case we have suspended the tasklet to do the
@@ -738,7 +742,7 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
/* Mark all CS interrupts as complete */
execlists->active = 0;
 
-   spin_unlock_irqrestore(>timeline->lock, flags);
+   local_irq_restore(flags);
 }
 
 /*
@@ -1618,10 +1622,11 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
GEM_TRACE("%s seqno=%x\n",
  engine->name, request ? request->global_seqno : 0);
 
-   spin_lock_irqsave(>timeline->lock, flags);
+   local_irq_save(flags);
 
reset_irq(engine);
 
+
/*
 * Catch up with any missed context-switch interrupts.
 *
@@ -1634,14 +1639,17 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
execlists_cancel_port_requests(execlists);
 
/* Push back any incomplete requests for replay after the reset. */
+   spin_lock(>timeline->lock);
__unwind_incomplete_requests(engine);
+   spin_unlock(>timeline->lock);
 
/* Mark all CS interrupts as complete */
execlists->active = 0;
 
-   spin_unlock_irqrestore(>timeline->lock, flags);
+   local_irq_restore(flags);
 
-   /* If the request was innocent, we leave the request in the ELSP
+   /*
+* If the request was innocent, we leave the request in the ELSP
 * and will try to replay it on restarting. The context image may
 * have been corrupted by the reset, in which case we may have
 * to service a new GPU hang, but more likely we can continue on
@@ -1654,7 +1662,8 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
if (!request || request->fence.error != -EIO)
return;
 
-   /* We want a simple context + ring to execute the breadcrumb update.
+   /*
+* We want a simple context + ring to execute the breadcrumb update.
 * We cannot rely on the context being intact across the GPU hang,
 * so clear it and rebuild just what we need for the breadcrumb.
 * All pending requests for this context will be zapped, and any
-- 
2.16.2

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

[Intel-gfx] [PATCH 5/5] drm/i915: Call prepare/finish around intel_gpu_reset() during GEM sanitize

[Chris Wilson]

During GEM sanitization, we reset the GPU so that it's always in a
default state whenever we take over or return the GPU back to the BIOS.
We call the GPU reset directly, so that we don't get caught up in trying
to handle GEM or KMS state that is isn't ready at that time, but now we
have a couple of helpers to prepare and finish around the HW reset. Use
them, so that we can extend them as required for updating HW state
tracking around resets.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dcdcc09240b9..7ae9c877c1c6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4874,6 +4874,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
mutex_unlock(>drm.struct_mutex);
}
 
+   intel_gpu_reset_prepare(i915, ALL_ENGINES);
+
/*
 * If we inherit context state from the BIOS or earlier occupants
 * of the GPU, the GPU may be in an inconsistent state when we
@@ -4884,6 +4886,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
 */
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+
+   intel_gpu_reset_finish(i915, ALL_ENGINES);
 }
 
 int i915_gem_suspend(struct drm_i915_private *dev_priv)
-- 
2.16.2

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

[Intel-gfx] [PATCH 3/5] drm/i915/execlists: Move irq state manipulation inside irq disabled region

[Chris Wilson]

Although this state (execlists->active and engine->irq_posted) itself is
not protected by the engine->timeline spinlock, it does conveniently
ensure that irqs are disabled. We can use this to protect our
manipulation of the state and so ensure that the next IRQ to arrive sees
consistent state and (hopefully) ignores the reset engine.

Suggested-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Reviewed-by: Mika Kuoppala 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180302131246.22036-1-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_lrc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c1a3636e94fc..0482e54c94f0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
GEM_TRACE("%s seqno=%x\n",
  engine->name, request ? request->global_seqno : 0);
 
-   reset_irq(engine);
-
spin_lock_irqsave(>timeline->lock, flags);
 
+   reset_irq(engine);
+
/*
 * Catch up with any missed context-switch interrupts.
 *
@@ -1636,11 +1636,11 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
/* Push back any incomplete requests for replay after the reset. */
__unwind_incomplete_requests(engine);
 
-   spin_unlock_irqrestore(>timeline->lock, flags);
-
/* Mark all CS interrupts as complete */
execlists->active = 0;
 
+   spin_unlock_irqrestore(>timeline->lock, flags);
+
/* If the request was innocent, we leave the request in the ELSP
 * and will try to replay it on restarting. The context image may
 * have been corrupted by the reset, in which case we may have
-- 
2.16.2

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

[Intel-gfx] [PATCH 1/5] drm/i915: Stop engines around GPU reset preparations

[Chris Wilson]

As we make preparations to reset the GPU state, we assume that the GPU
is hung and will not advance. Make this assumption more explicit by
setting the STOP_RING bit on the engines as part of our early reset
preparations.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Reviewed-by: Mika Kuoppala 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-1-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_drv.c |  3 +++
 drivers/gpu/drm/i915/i915_drv.h | 11 +--
 drivers/gpu/drm/i915/intel_uncore.c | 36 +++-
 3 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aaa861b51024..925f5722d077 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1908,6 +1908,8 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
error->reset_count++;
 
disable_irq(i915->drm.irq);
+   intel_gpu_reset_prepare(i915, ALL_ENGINES);
+
ret = i915_gem_reset_prepare(i915);
if (ret) {
dev_err(i915->drm.dev, "GPU recovery failed\n");
@@ -1969,6 +1971,7 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
 
 finish:
i915_gem_reset_finish(i915);
+   intel_gpu_reset_finish(i915, ALL_ENGINES);
enable_irq(i915->drm.irq);
 
 wakeup:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10c9e5e619ab..0cb141f768ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2957,8 +2957,15 @@ extern const struct dev_pm_ops i915_pm_ops;
 extern int i915_driver_load(struct pci_dev *pdev,
const struct pci_device_id *ent);
 extern void i915_driver_unload(struct drm_device *dev);
-extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
-extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
+
+bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
+
+void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
+unsigned int engine_mask);
+int intel_gpu_reset(struct drm_i915_private *dev_priv,
+   unsigned int engine_mask);
+void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
+   unsigned int engine_mask);
 
 #define I915_RESET_QUIET BIT(0)
 extern void i915_reset(struct drm_i915_private *i915, unsigned int flags);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 5ae9a62712ca..e193af2feefb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1899,7 +1899,31 @@ static reset_func intel_get_gpu_reset(struct 
drm_i915_private *dev_priv)
return NULL;
 }
 
-int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)
+static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
+ unsigned int engine_mask,
+ u32 mode)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   if (INTEL_GEN(dev_priv) < 3)
+   return;
+
+   for_each_engine_masked(engine, dev_priv, engine_mask, id)
+   I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
+}
+
+void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
+unsigned int engine_mask)
+{
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+   i915_engines_set_mode(dev_priv, engine_mask,
+ _MASKED_BIT_ENABLE(STOP_RING));
+}
+
+int intel_gpu_reset(struct drm_i915_private *dev_priv,
+   unsigned int engine_mask)
 {
reset_func reset = intel_get_gpu_reset(dev_priv);
int retry;
@@ -1939,6 +1963,16 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, 
unsigned engine_mask)
return ret;
 }
 
+void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
+   unsigned int engine_mask)
+{
+   /* Clear the STOP_RING bit as the reset may not have occurred */
+   i915_engines_set_mode(dev_priv, engine_mask,
+ _MASKED_BIT_DISABLE(STOP_RING));
+
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+}
+
 bool intel_has_gpu_reset(struct drm_i915_private *dev_priv)
 {
return intel_get_gpu_reset(dev_priv) != NULL;
-- 
2.16.2

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

Re: [Intel-gfx] *cringe* at adding a parameter to workaround issues.

[Jani Nikula]

On Thu, 01 Mar 2018, Marc Herbert  wrote:
> Hi Jani,
>
>> *cringe* at adding a parameter to workaround issues.
>
> I understand that *each* parameter has the potential to *multiply* the total
> number of configurations and that the resulting combinatorial explosion is
> absolutely not scalable and sustainable from a validation perspective. No
> one should expect to get support here when options like this one are set to
> a non-default value.
>
> When something breaks on the other hand, transparent _test_ knobs like this
> one have proved invaluable countless times to help troubleshoot and isolate
> issues. It's at least 10 times more productive to ask a non-expert in some
> opposite timezone "please test again after rebooting with this parameter"
> compared to "test again after applying this patch, recompiling, etc." -
> assuming the latter has any chance of success at all.  I'm speaking from
> actual experience as we are routinely experiencing both type of situations.

Yes, I do understand, and that's why it's a "cringe", not a "nak".

The flip side are bug reports that we still get regardless of warnings
in dmesg and kernel taint when people try out parameters that they read
about in random forums, and expect support. And lack of bug reports when
people silently workaround their issues using module parameters.

> I hope the "unsafe" part of "i915_param_named_unsafe" provides a permanent
> solution to both problems by making a clear distinction between the only one
> single true supported configuration on one hand versus test datapoints
> on the other hand.  Same for "tainted", sysfs or else.

This is what I hoped too when I added support for the "unsafe"
parameters. :) Now I wish we could move this stuff to debugfs and flip
debugfs options as easily as module parameters. I think this is the
primary reason we have so many debugging module parameters: they are
more convenient than debugfs.

BR,
Jani.


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Don't create properties without names

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm: Don't create properties without names
URL   : https://patchwork.freedesktop.org/series/39277/
State : success

== Summary ==

Series 39277v1 series starting with [1/3] drm: Don't create properties without 
names
https://patchwork.freedesktop.org/api/1.0/series/39277/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:412s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:419s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:494s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:461s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:390s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:492s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:407s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:287s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:404s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:485s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:494s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:578s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s

7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC 
integration manifest
6b313f784de6 drm: Add BT.2020 constant luminance enum value for the 
COLOR_ENCODING property
c0ec45ad9801 drm: Check property/enum name length
7de598d791f9 drm: Don't create properties without names

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8214/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/1] i915: additional GEM documentation

[kevin . rogovin]

From: Kevin Rogovin 

This patch provides additional overview documentation to the
i915 kernel driver GEM. In addition, it presents already written
documentation to i915.rst as well.

Signed-off-by: Kevin Rogovin 
---
 Documentation/gpu/i915.rst | 194 +++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   3 +-
 drivers/gpu/drm/i915/i915_vma.h|  11 +-
 drivers/gpu/drm/i915/intel_lrc.c   |   3 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h|  64 ++
 5 files changed, 235 insertions(+), 40 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 41dc881b00dc..cd23da2793ec 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -13,6 +13,18 @@ Core Driver Infrastructure
 This section covers core driver infrastructure used by both the display
 and the GEM parts of the driver.
 
+Initialization
+--
+
+The real action of initialization for the i915 driver is handled by
+:c:func:`i915_driver_load`; from this function one can see the key
+data (in paritcular :c:struct:'drm_driver' for GEM) of the entry points
+to to the driver from user space.
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.c
+   :functions: i915_driver_load
+
+
 Runtime Power Management
 
 
@@ -243,32 +255,148 @@ Display PLLs
 .. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.h
:internal:
 
-Memory Management and Command Submission
-
+GEM: Memory Management and Command Submission
+=
 
 This sections covers all things related to the GEM implementation in the
 i915 driver.
 
-Batchbuffer Parsing

+Intel GPU Basics
+
 
-.. kernel-doc:: drivers/gpu/drm/i915/i915_cmd_parser.c
-   :doc: batch buffer command parser
+An Intel GPU has multiple engines. There are several engine types.
+The user-space value `I915_EXEC_DEFAULT` is an alias to the user
+space value `I915_EXEC_RENDER`.
+
+- RCS engine is for rendering 3D and performing compute, this is named 
`I915_EXEC_RENDER` in user space.
+- BCS is a blitting (copy) engine, this is named `I915_EXEC_BLT` in user space.
+- VCS is a video encode and decode engine, this is named `I915_EXEC_BSD` in 
user space
+- VECS is video enhancement engine, this is named `I915_EXEC_VEBOX` in user 
space.
+
+The Intel GPU family is a familiy of integrated GPU's using Unified Memory
+Access. For having the GPU "do work", user space will feed the GPU batch 
buffers
+via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2` or
+`DRM_IOCTL_I915_GEM_EXECBUFFER2_WR` (the ioctl `DRM_IOCTL_I915_GEM_EXECBUFFER`
+is deprecated). Most such batchbuffers will instruct the GPU to perform work
+(for example rendering) and that work needs memory from which to read and 
memory
+to which to write. All memory is encapsulated within GEM buffer objects 
(usually
+created with the ioctl `DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a 
batchbuffer
+for the GPU to create will also list all GEM buffer objects that the 
batchbuffer
+reads and/or writes. For implementation details of memory management see
+`GEM BO Management Implementation Details`_.
+
+A GPU pipeline (mostly strongly so for the RCS engine) has a great deal of 
state
+which is to be programmed by user space via the contents of a batchbuffer. 
Starting
+in Gen6 (SandyBridge), hardware contexts are supported. A hardware context
+encapsulates GPU pipeline state and other portions of GPU state and it is much 
more
+efficient for the GPU to load a hardware context instead of re-submitting 
commands
+in a batchbuffer to the GPU to restore state. In addition, using hardware 
contexts
+provides much better isolation between user space clients. The ioctl
+`DRM_IOCTL_I915_GEM_CONTEXT_CREATE` is used by user space to create a hardware 
context
+which is identified by a 32-bit integer. The non-deprecated ioctls to submit 
batchbuffer
+work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) to
+identify what HW context to use with the command. When the kernel submits the
+batchbuffer to be executed by the GPU it will also instruct the GPU to load 
the HW
+context prior to executing the contents of a batchbuffer.
+
+The GPU has its own memory management and address space. The kernel driver
+maintains the memory translation table for the GPU. For older GPUs (i.e. those
+before Gen8), there is a single global such translation table, a global
+Graphics Translation Table (GTT). For newer generation GPUs each hardware
+context has its own translation table, called Per-Process Graphics Translation
+Table (PPGTT). Of important note, is that although PPGTT is named per-process 
it
+is actually per hardware context. When user space submits a batchbuffer, the 
kernel
+walks the list of GEM buffer objects used by the batchbuffer and guarantees
+that not only is 

[Intel-gfx] [PATCH v2 0/1] Documentation patch for batchbuffer submission

[kevin . rogovin]

From: Kevin Rogovin 

v2:
   More documentation: intel_ringbuffer, sequence number.
   Expose to i915.rst existing documentation

   Call out GEM_EXECBUFFER as deprecated.
   Place code detailed documentation in source files.
   Call out INTEL_EXEC_RENDER.
   Reorder text to make it more readable.
   Refer to Command Buffer Parser instead of Batchbuffer Parser.
   (suggested by Joonas Lahtinen)





Kevin Rogovin (1):
  i915: additional documentation

 Documentation/gpu/i915.rst | 194 +++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   3 +-
 drivers/gpu/drm/i915/i915_vma.h|  11 +-
 drivers/gpu/drm/i915/intel_lrc.c   |   3 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h|  64 ++
 5 files changed, 235 insertions(+), 40 deletions(-)

-- 
2.16.2

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

[Intel-gfx] [PATCH v2 2/3 drm: Check property/enum name length

[Ville Syrjala]

From: Ville Syrjälä 

Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.

v2: drm_property_create() returns a pointer

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_property.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index fe8627fb7ae6..c37ac41125b5 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -78,6 +78,9 @@ struct drm_property *drm_property_create(struct drm_device 
*dev, int flags,
struct drm_property *property = NULL;
int ret;
 
+   if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+   return NULL;
+
property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
if (!property)
return NULL;
@@ -372,6 +375,9 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
 {
struct drm_property_enum *prop_enum;
 
+   if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+   return -EINVAL;
+
if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)))
return -EINVAL;
-- 
2.16.1

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm: Don't create properties without names

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm: Don't create properties without names
URL   : https://patchwork.freedesktop.org/series/39277/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm: Don't create properties without names
Okay!

Commit: drm: Check property/enum name length
-
+  ^
+drivers/gpu/drm/drm_property.c:82:10: warning: return makes pointer from 
integer without a cast [-Wint-conversion]
+drivers/gpu/drm/drm_property.c:82:24:expected struct drm_property *
+drivers/gpu/drm/drm_property.c:82:24:got int
+drivers/gpu/drm/drm_property.c:82:24: warning: incorrect type in return 
expression (different base types)
+drivers/gpu/drm/drm_property.c: In function ‘drm_property_create’:
+   return -EINVAL;

Commit: drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING 
property
Okay!

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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move irq state manipulation inside irq disabled region

[Chris Wilson]

Quoting Chris Wilson (2018-03-02 13:12:46)
> Although this state (execlists->active and engine->irq_posted) itself is
> not protected by the engine->timeline spinlock, it does conveniently
> ensure that irqs are disabled. We can use this to protect our
> manipulation of the state and so ensure that the next IRQ to arrive sees
> consistent state and (hopefully) ignores the reset engine.
> 
> Suggested-by: Mika Kuoppala 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index c1a3636e94fc..0482e54c94f0 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
> GEM_TRACE("%s seqno=%x\n",
>   engine->name, request ? request->global_seqno : 0);
>  
> -   reset_irq(engine);
> -
> spin_lock_irqsave(>timeline->lock, flags);
>  
> +   reset_irq(engine);

Alternatively, we split this up with

local_irq_save(flags);

reset_irq(engine);

spin_lock(>timline->lock);
...

Worth the exercise?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Move irq state manipulation inside irq disabled region

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Move irq state manipulation inside irq disabled 
region
URL   : https://patchwork.freedesktop.org/series/39276/
State : success

== Summary ==

Series 39276v1 drm/i915/execlists: Move irq state manipulation inside irq 
disabled region
https://patchwork.freedesktop.org/api/1.0/series/39276/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:420s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:477s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:475s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:475s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:494s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:582s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:448s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:495s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:423s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s

7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC 
integration manifest
fa87757ad944 drm/i915/execlists: Move irq state manipulation inside irq 
disabled region

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8213/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move irq state manipulation inside irq disabled region

[Mika Kuoppala]

Chris Wilson  writes:

> Although this state (execlists->active and engine->irq_posted) itself is
> not protected by the engine->timeline spinlock, it does conveniently
> ensure that irqs are disabled. We can use this to protect our
> manipulation of the state and so ensure that the next IRQ to arrive sees
> consistent state and (hopefully) ignores the reset engine.
>
> Suggested-by: Mika Kuoppala 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index c1a3636e94fc..0482e54c94f0 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>   GEM_TRACE("%s seqno=%x\n",
> engine->name, request ? request->global_seqno : 0);
>  
> - reset_irq(engine);
> -
>   spin_lock_irqsave(>timeline->lock, flags);
>  
> + reset_irq(engine);
> +
>   /*
>* Catch up with any missed context-switch interrupts.
>*
> @@ -1636,11 +1636,11 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>   /* Push back any incomplete requests for replay after the reset. */
>   __unwind_incomplete_requests(engine);
>  
> - spin_unlock_irqrestore(>timeline->lock, flags);
> -
>   /* Mark all CS interrupts as complete */
>   execlists->active = 0;
>  
> + spin_unlock_irqrestore(>timeline->lock, flags);
> +
>   /* If the request was innocent, we leave the request in the ELSP
>* and will try to replay it on restarting. The context image may
>* have been corrupted by the reset, in which case we may have
> -- 
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Suspend submission tasklets around wedging

[Mika Kuoppala]

Chris Wilson  writes:

> After starting hard at sequences like
>
> [   28.199013]  systemd-1   2..s. 26062228us : 
> execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
> [   28.199095]  systemd-1   2..s. 26062229us : 
> execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x, 
> active=0x1
> [   28.199177]  systemd-1   2..s. 26062230us : 
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
> [   28.199258]  systemd-1   2..s. 26062231us : 
> execlists_submission_tasklet: rcs0 completed ctx=0
> [   28.199340]  gem_eio-829 1..s1 26066853us : 
> execlists_submission_tasklet: rcs0 in[0]:  ctx=1.1, seqno=1, prio=0
> [   28.199421]   -0   2..s. 26066863us : 
> execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
> [   28.199503]   -0   2..s. 26066865us : 
> execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x, 
> active=0x1
> [   28.199585]  gem_eio-829 1..s1 26067077us : 
> execlists_submission_tasklet: rcs0 in[1]:  ctx=3.1, seqno=2, prio=0
> [   28.199667]  gem_eio-829 1..s1 26067078us : 
> execlists_submission_tasklet: rcs0 in[0]:  ctx=1.2, seqno=1, prio=0
> [   28.199749]   -0   2..s. 26067084us : 
> execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
> [   28.199830]   -0   2..s. 26067085us : 
> execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001, 
> active=0x1
> [   28.199912]   -0   2..s. 26067086us : 
> execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
> [   28.14]  gem_eio-829 2..s. 28246084us : 
> execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
> [   28.200096]  gem_eio-829 2..s. 28246088us : 
> execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001, 
> active=0x5
> [   28.200178]  gem_eio-829 2..s. 28246089us : 
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
> [   28.200260]  gem_eio-829 2..s. 28246127us : 
> execlists_submission_tasklet: execlists_submission_tasklet:886 
> GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
>
> the conclusion is that the only place where the ports are reset to zero,
> is from engine->cancel_requests called during i915_gem_set_wedged().
>
> The race is horrible as it results from calling set-wedged on active HW
> (the GPU reset failed) and as such we need to be careful as the HW state
> changes beneath us. Fortunately, it's the same scary conditions as
> affect normal reset, so we can reuse the same machinery to disable state
> tracking as we clobber it.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 
> ---
>  drivers/gpu/drm/i915/i915_gem.c  | 6 +-
>  drivers/gpu/drm/i915/intel_lrc.c | 5 +
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c29b1a1cbe96..dcdcc09240b9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3212,8 +3212,10 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>* rolling the global seqno forward (since this would complete requests
>* for which we haven't set the fence error to EIO yet).
>*/
> - for_each_engine(engine, i915, id)
> + for_each_engine(engine, i915, id) {
> + i915_gem_reset_prepare_engine(engine);
>   engine->submit_request = nop_submit_request;
> + }
>  
>   /*
>* Make sure no one is running the old callback before we proceed with
> @@ -3255,6 +3257,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>   intel_engine_init_global_seqno(engine,
>  
> intel_engine_last_submit(engine));
>   spin_unlock_irqrestore(>timeline->lock, flags);
> +
> + i915_gem_reset_finish_engine(engine);
>   }
>  
>   wake_up_all(>gpu_error.reset_queue);
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 14288743909f..c1a3636e94fc 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -687,6 +687,8 @@ static void execlists_cancel_requests(struct 
> intel_engine_cs *engine)
>   struct rb_node *rb;
>   unsigned long flags;
>  
> + GEM_TRACE("%s\n", engine->name);
> +
>   spin_lock_irqsave(>timeline->lock, flags);
>  
>   /* Cancel the requests on the HW and clear the ELSP tracker. */
> @@ -733,6 +735,9 @@ static void execlists_cancel_requests(struct 
> intel_engine_cs *engine)
>*/
>   clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
>  
> + /* Mark all CS interrupts as complete */
> + execlists->active = 0;

With the followup patch to handle the other irq state manipulation 

[Intel-gfx] [PATCH v2 1/2] drm/i915/huc: Mark firmware as failed on auth failure

[Michal Wajdeczko]

If we fail to authenticate HuC firmware, we should change
its load status to FAIL. While around, print HUC_STATUS
on firmware verification failure.

v2: keep the variables sorted by length (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Anusha Srivatsa 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_huc.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index e37f58e..65e2afb 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -48,6 +48,7 @@ int intel_huc_auth(struct intel_huc *huc)
struct drm_i915_private *i915 = huc_to_i915(huc);
struct intel_guc *guc = >guc;
struct i915_vma *vma;
+   u32 status;
int ret;
 
if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
@@ -58,28 +59,35 @@ int intel_huc_auth(struct intel_huc *huc)
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
DRM_ERROR("HuC: Failed to pin huc fw object %d\n", ret);
-   return ret;
+   goto fail;
}
 
ret = intel_guc_auth_huc(guc,
 guc_ggtt_offset(vma) + huc->fw.rsa_offset);
if (ret) {
DRM_ERROR("HuC: GuC did not ack Auth request %d\n", ret);
-   goto out;
+   goto fail_unpin;
}
 
/* Check authentication status, it should be done by now */
-   ret = intel_wait_for_register(i915,
- HUC_STATUS2,
- HUC_FW_VERIFIED,
- HUC_FW_VERIFIED,
- 50);
+   ret = __intel_wait_for_register(i915,
+   HUC_STATUS2,
+   HUC_FW_VERIFIED,
+   HUC_FW_VERIFIED,
+   2, 50, );
if (ret) {
-   DRM_ERROR("HuC: Authentication failed %d\n", ret);
-   goto out;
+   DRM_ERROR("HuC: Firmware not verified %#x\n", status);
+   goto fail_unpin;
}
 
-out:
i915_vma_unpin(vma);
+   return 0;
+
+fail_unpin:
+   i915_vma_unpin(vma);
+fail:
+   huc->fw.load_status = INTEL_UC_FIRMWARE_FAIL;
+
+   DRM_ERROR("HuC: Authentication failed %d\n", ret);
return ret;
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 2/2] HAX: Enable GuC for CI

[Michal Wajdeczko]

v2: except running with HYPERVISOR

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 8e25474..fb80e86 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;
 
return enable_guc;
 }
-- 
1.9.1

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Stop engines around GPU reset preparations

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Stop engines around GPU reset 
preparations
URL   : https://patchwork.freedesktop.org/series/39270/
State : failure

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite:
pass   -> FAIL   (shard-apl)

 Known issues:

Test drv_selftest:
Subgroup live_gtt:
pass   -> INCOMPLETE (shard-apl) fdo#103927
Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060

fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060

shard-apltotal:3441 pass:1798 dwarn:1   dfail:0   fail:8   skip:1632 
time:12107s
shard-hswtotal:3422 pass:1748 dwarn:1   dfail:0   fail:2   skip:1669 
time:11536s
shard-snbtotal:3463 pass:1360 dwarn:2   dfail:0   fail:1   skip:2100 
time:6926s
Blacklisted hosts:
shard-kbltotal:3445 pass:1926 dwarn:1   dfail:0   fail:8   skip:1509 
time:9796s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8210/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Stop engines around GPU reset preparations

[Patchwork]

== Series Details ==

Series: drm/i915: Stop engines around GPU reset preparations
URL   : https://patchwork.freedesktop.org/series/39261/
State : failure

== Summary ==

 Possible new issues:

Test drv_selftest:
Subgroup live_hangcheck:
pass   -> INCOMPLETE (shard-apl)
Test gem_eio:
Subgroup in-flight-internal:
pass   -> INCOMPLETE (shard-apl)
Test gem_exec_capture:
Subgroup capture-vebox:
pass   -> INCOMPLETE (shard-apl)
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip   -> PASS   (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-apl) fdo#104945 +1
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540

shard-apltotal:3190 pass:1654 dwarn:1   dfail:0   fail:7   skip:1522 
time:10062s
shard-hswtotal:3422 pass:1749 dwarn:1   dfail:0   fail:1   skip:1669 
time:11471s
shard-snbtotal:3463 pass:1361 dwarn:2   dfail:0   fail:1   skip:2099 
time:7009s
Blacklisted hosts:
shard-kbltotal:3190 pass:1765 dwarn:10  dfail:0   fail:6   skip:1403 
time:8063s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8209/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 3/3] drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property

[Ville Syrjala]

From: Ville Syrjälä 

BT.2020 specifies two YCbCr<->RGB conversion formulas. The more
traditional non-constant luminance and a more complicate constant
luminance one. Add an enum value for the constant luminance variant
as well in case someone has hardware supporting it.

v2: Reduce the enum name to fit within the 31 character uapi limit

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
CC: Uma Shankar 
Cc: Shashank Sharma 
Cc: Jyri Sarha 
Signed-off-by: Ville Syrjälä 
Acked-by: Harry Wentland  #v1
---
 drivers/gpu/drm/drm_color_mgmt.c | 1 +
 include/drm/drm_color_mgmt.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 4ff064623836..cc28c32399af 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -358,6 +358,7 @@ static const char * const color_encoding_name[] = {
[DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
[DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
[DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
+   [DRM_COLOR_YCBCR_BT2020_CONST] = "ITU-R BT.2020 YCbCr const",
 };
 
 static const char * const color_range_name[] = {
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index b3b6d302ca8c..175943c87d5b 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -41,7 +41,8 @@ int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
 enum drm_color_encoding {
DRM_COLOR_YCBCR_BT601,
DRM_COLOR_YCBCR_BT709,
-   DRM_COLOR_YCBCR_BT2020,
+   DRM_COLOR_YCBCR_BT2020, /* non-constant luminance */
+   DRM_COLOR_YCBCR_BT2020_CONST, /* constant luminance */
DRM_COLOR_ENCODING_MAX,
 };
 
-- 
2.13.6

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

[Intel-gfx] [PATCH 2/3] drm: Check property/enum name length

[Ville Syrjala]

From: Ville Syrjälä 

Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_property.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index fe8627fb7ae6..f062adf21b9c 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -78,6 +78,9 @@ struct drm_property *drm_property_create(struct drm_device 
*dev, int flags,
struct drm_property *property = NULL;
int ret;
 
+   if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+   return -EINVAL;
+
property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
if (!property)
return NULL;
@@ -372,6 +375,9 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
 {
struct drm_property_enum *prop_enum;
 
+   if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+   return -EINVAL;
+
if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)))
return -EINVAL;
-- 
2.13.6

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

[Intel-gfx] [PATCH 1/3] drm: Don't create properties without names

[Ville Syrjala]

From: Ville Syrjälä 

Creating a property that doesn't have a name makes no sense to me. Don't
allow it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_property.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index bae50e6b819d..fe8627fb7ae6 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -99,10 +99,8 @@ struct drm_property *drm_property_create(struct drm_device 
*dev, int flags,
property->num_values = num_values;
INIT_LIST_HEAD(>enum_list);
 
-   if (name) {
-   strncpy(property->name, name, DRM_PROP_NAME_LEN);
-   property->name[DRM_PROP_NAME_LEN-1] = '\0';
-   }
+   strncpy(property->name, name, DRM_PROP_NAME_LEN);
+   property->name[DRM_PROP_NAME_LEN-1] = '\0';
 
list_add_tail(>head, >mode_config.property_list);
 
-- 
2.13.6

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Kill the remaining CHV HBR2 leftovers

[Patchwork]

== Series Details ==

Series: drm/i915: Kill the remaining CHV HBR2 leftovers
URL   : https://patchwork.freedesktop.org/series/39260/
State : success

== Summary ==

 Possible new issues:

Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip   -> PASS   (shard-snb)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-right-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +4
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> DMESG-WARN (shard-snb) fdo#102365
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3442 pass:1810 dwarn:1   dfail:0   fail:7   skip:1623 
time:12114s
shard-hswtotal:3366 pass:1727 dwarn:1   dfail:0   fail:1   skip:1636 
time:11477s
shard-snbtotal:3463 pass:1358 dwarn:5   dfail:0   fail:1   skip:2099 
time:7024s
Blacklisted hosts:
shard-kbltotal:3445 pass:1927 dwarn:1   dfail:0   fail:7   skip:1509 
time:9675s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8208/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/execlists: Move irq state manipulation inside irq disabled region

[Chris Wilson]

Although this state (execlists->active and engine->irq_posted) itself is
not protected by the engine->timeline spinlock, it does conveniently
ensure that irqs are disabled. We can use this to protect our
manipulation of the state and so ensure that the next IRQ to arrive sees
consistent state and (hopefully) ignores the reset engine.

Suggested-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_lrc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c1a3636e94fc..0482e54c94f0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
GEM_TRACE("%s seqno=%x\n",
  engine->name, request ? request->global_seqno : 0);
 
-   reset_irq(engine);
-
spin_lock_irqsave(>timeline->lock, flags);
 
+   reset_irq(engine);
+
/*
 * Catch up with any missed context-switch interrupts.
 *
@@ -1636,11 +1636,11 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
/* Push back any incomplete requests for replay after the reset. */
__unwind_incomplete_requests(engine);
 
-   spin_unlock_irqrestore(>timeline->lock, flags);
-
/* Mark all CS interrupts as complete */
execlists->active = 0;
 
+   spin_unlock_irqrestore(>timeline->lock, flags);
+
/* If the request was innocent, we leave the request in the ELSP
 * and will try to replay it on restarting. The context image may
 * have been corrupted by the reset, in which case we may have
-- 
2.16.2

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up the port pipe select bits

[Patchwork]

== Series Details ==

Series: drm/i915: Clean up the port pipe select bits
URL   : https://patchwork.freedesktop.org/series/39259/
State : failure

== Summary ==

Series 39259v1 drm/i915: Clean up the port pipe select bits
https://patchwork.freedesktop.org/api/1.0/series/39259/revisions/1/mbox/

 Possible new issues:

Test core_auth:
Subgroup basic-auth:
pass   -> INCOMPLETE (fi-ivb-3520m)
pass   -> INCOMPLETE (fi-snb-2520m)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:475s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:478s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:397s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:491s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:408s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:406s
fi-ivb-3520m total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:491s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:422s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:497s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:387s

519e1b37fcc70054cc3064b811bdf68fbd4ff699 drm-tip: 2018y-03m-02d-11h-56m-58s UTC 
integration manifest
950164172c86 drm/i915: Implement the missing bits of assert_panel_unlocked()
314966553211 drm/i915: Allow eDP on port C in theory
34744df0f6ca drm/i915: Clean up DP pipe select bits
a760b515dcb8 drm/i915: Nuke intel_trans_dp_port_sel()
cf688310aae9 drm/i915: Parametrize TRANS_DP_PORT_SEL
4897c0985bc7 drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi code
1c0d7dc03383 drm/i915: Check for IVB instead of gen7 when we think about IVB 
CPU eDP
399bbd665a74 drm/i915: Use the same vswing->max_preemph mapping on HSW/BDW as 
on SKL+
d3e8f01d950c drm/i915: Use intel_ddi_dp_voltage_max() for HSW/BDW too
7ab6b990997e drm/i915: Clean up DVO pipe select bits
e3d61fda6189 drm/i915: Clean up TV pipe select bits
c93cce952eca drm/i915: Clean up SDVO pipe select bits
30893edbb0e6 drm/i915: Clean up LVDS pipe select bits
450b0ac22c5c drm/i915: Clean up ADPA pipe select bits

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8212/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/8] drm: Add COLOR_ENCODING and COLOR_RANGE plane properties

[Ville Syrjälä]

On Wed, Feb 14, 2018 at 09:23:19PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Here's a refresh of Jyri's COLOR_ENCODING and COLOR_RANGE properties,
> and the i915 implementation I did on top. I tossed in a few core
> updates as well: plane state dump, and the BT.2020 constant luminance
> variant.
> 
> Apparently nouveau is already exposing a "iturbt_709" bool property
> which allows one to choose between BT.601 and BT.709 encodings, but
> given that we want at least BT.2020 in addition I don't think that
> property is good enough. Trying to implement it, and somehow extend
> it beyond BT.601 vs. BT.709 seems like wasted effort. Hence I think
> we should just ignore it and move on.
> 
> My userspace implementation in the form of intel ddx
> XV_COLORSPACE attribute:
> https://patchwork.freedesktop.org/patch/204696/
> 
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Cc: Daniel Stone 
> Cc: Russell King - ARM Linux 
> Cc: Ilia Mirkin 
> Cc: Hans Verkuil 
> Cc: Uma Shankar 
> Cc: Shashank Sharma 
> 
> Jyri Sarha (1):
>   drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to
> drm_plane
> 
> Ville Syrjälä (7):
>   drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING
> property
>   drm/atomic: Include color encoding/range in plane state dump
>   drm/i915: Correctly handle limited range YCbCr data on VLV/CHV
>   drm/i915: Fix plane YCbCr->RGB conversion for GLK
>   drm/i915: Add support for the YCbCr COLOR_ENCODING property
>   drm/i915: Change the COLOR_ENCODING prop default value to BT.709
>   drm/i915: Add support for the YCbCr COLOR_RANGE property

Userspace for i915 was deemed ready [1] so I've pushed the series (apart
from the BT2020_CONST thing) to drm-misc-next. Thanks to everyone who
worked on this.

[1] https://lists.freedesktop.org/archives/intel-gfx/2018-March/157512.html

-- 
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 2/2] drm/i915: Suspend submission tasklets around wedging

[Chris Wilson]

Quoting Chris Wilson (2018-03-02 11:33:24)
> After starting hard at sequences like
> 
> [   28.199013]  systemd-1   2..s. 26062228us : 
> execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
> [   28.199095]  systemd-1   2..s. 26062229us : 
> execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x, 
> active=0x1
> [   28.199177]  systemd-1   2..s. 26062230us : 
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
> [   28.199258]  systemd-1   2..s. 26062231us : 
> execlists_submission_tasklet: rcs0 completed ctx=0
> [   28.199340]  gem_eio-829 1..s1 26066853us : 
> execlists_submission_tasklet: rcs0 in[0]:  ctx=1.1, seqno=1, prio=0
> [   28.199421]   -0   2..s. 26066863us : 
> execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
> [   28.199503]   -0   2..s. 26066865us : 
> execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x, 
> active=0x1
> [   28.199585]  gem_eio-829 1..s1 26067077us : 
> execlists_submission_tasklet: rcs0 in[1]:  ctx=3.1, seqno=2, prio=0
> [   28.199667]  gem_eio-829 1..s1 26067078us : 
> execlists_submission_tasklet: rcs0 in[0]:  ctx=1.2, seqno=1, prio=0
> [   28.199749]   -0   2..s. 26067084us : 
> execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
> [   28.199830]   -0   2..s. 26067085us : 
> execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001, 
> active=0x1
> [   28.199912]   -0   2..s. 26067086us : 
> execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
> [   28.14]  gem_eio-829 2..s. 28246084us : 
> execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
> [   28.200096]  gem_eio-829 2..s. 28246088us : 
> execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001, 
> active=0x5
> [   28.200178]  gem_eio-829 2..s. 28246089us : 
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
> [   28.200260]  gem_eio-829 2..s. 28246127us : 
> execlists_submission_tasklet: execlists_submission_tasklet:886 
> GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
> 
> the conclusion is that the only place where the ports are reset to zero,
> is from engine->cancel_requests called during i915_gem_set_wedged().
> 
> The race is horrible as it results from calling set-wedged on active HW
> (the GPU reset failed) and as such we need to be careful as the HW state
> changes beneath us. Fortunately, it's the same scary conditions as
> affect normal reset, so we can reuse the same machinery to disable state
> tracking as we clobber it.
> 

Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in set_wedged")

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/uc: Introduce intel_uc_suspend|resume

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/uc: Introduce 
intel_uc_suspend|resume
URL   : https://patchwork.freedesktop.org/series/39272/
State : success

== Summary ==

Series 39272v1 series starting with [v2,1/2] drm/i915/uc: Introduce 
intel_uc_suspend|resume
https://patchwork.freedesktop.org/api/1.0/series/39272/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:413s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:478s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:397s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:494s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:451s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:408s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:446s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:488s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:520s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:512s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
fi-cnl-y3 failed to collect. IGT log at Patchwork_8211/fi-cnl-y3/run0.log

519e1b37fcc70054cc3064b811bdf68fbd4ff699 drm-tip: 2018y-03m-02d-11h-56m-58s UTC 
integration manifest
b6ef3c59a5e0 HAX: Enable GuC for CI
7b7da3ba6479 drm/i915/uc: Introduce intel_uc_suspend|resume

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8211/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/8] drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property

[Ville Syrjälä]

On Wed, Feb 14, 2018 at 09:23:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> BT.2020 specifies two YCbCr<->RGB conversion formulas. The more
> traditional non-constant luminance and a more complicate one constant
> luminance one. Add an enum value for the constant luminance variant
> as well in case someone has hardware supporting it.
> 
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Cc: Daniel Stone 
> Cc: Russell King - ARM Linux 
> Cc: Ilia Mirkin 
> Cc: Hans Verkuil 
> CC: Uma Shankar 
> Cc: Shashank Sharma 
> Cc: Jyri Sarha 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_color_mgmt.c | 1 +
>  include/drm/drm_color_mgmt.h | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index a84fc861e406..061d342f9d96 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -357,6 +357,7 @@ static const char * const color_encoding_name[] = {
>   [DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
>   [DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
>   [DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
> + [DRM_COLOR_YCBCR_BT2020_CONST] = "ITU-R BT.2020 YCbCr constant 
> luminance",

I just realized that this exceeds the max prop enum name length
of 31 characters. I guess we'll just have to truncate it to something
like "ITU-R BT.2020 YCbCr const". Any better suggestions?

/me goes add some WARN_ON()s for invalid prop/enum names...

>  };
>  
>  static const char * const color_range_name[] = {
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index b3b6d302ca8c..175943c87d5b 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -41,7 +41,8 @@ int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>  enum drm_color_encoding {
>   DRM_COLOR_YCBCR_BT601,
>   DRM_COLOR_YCBCR_BT709,
> - DRM_COLOR_YCBCR_BT2020,
> + DRM_COLOR_YCBCR_BT2020, /* non-constant luminance */
> + DRM_COLOR_YCBCR_BT2020_CONST, /* constant luminance */
>   DRM_COLOR_ENCODING_MAX,
>  };
>  
> -- 
> 2.13.6

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop engines around GPU reset preparations

[Chris Wilson]

Quoting Mika Kuoppala (2018-03-02 12:17:19)
> Chris Wilson  writes:
> 
> > Quoting Mika Kuoppala (2018-03-02 11:50:32)
> >> Chris Wilson  writes:
> >> > +static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
> >> > +   unsigned engine_mask,
> >> > +   u32 mode)
> >> > +{
> >> > + struct intel_engine_cs *engine;
> >> > + enum intel_engine_id id;
> >> > +
> >> > + if (INTEL_GEN(dev_priv) < 3)
> >> > + return;
> >> > +
> >> > + for_each_engine_masked(engine, dev_priv, engine_mask, id)
> >> > + I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
> >> 
> >> Is there reason to not use gen3_stop_engine in this level?
> >
> > It clears HEAD/TAIL, so undoing it in the case of no reset is a bit more
> > tricky.
> 
> With this we now have 3 different flavours of stopping an engine.
> 
> I would like to see early on prepare reset to call engine->stop(),
> which would be unified way of bring engine to halt. And limit
> any further restoration of state if we can't really manage to reset it,
> leaving it as stopped and dormant as we possibly could get it.
> 
> Then only on successful reset and restoration of init state, we would
> have an engine->start().

Wire it up, and see how it looks. We do

engine->stop # reset(early) or suspend
engine->reset # reset or suspend
engine->cancel # reset or wedge
engine->init # reset or resume
engine->start # reset(late) or resume

I agree adopting that scheme should help, if we can nail the code into
individual steps without repetition. (If we find we repeat ourselves,
the above scheme doesn't fit :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2] lib/igt_pm: Restore runtime pm state on test exit

[Imre Deak]

On Fri, Mar 02, 2018 at 09:56:26AM +, Tvrtko Ursulin wrote:
> 
> On 02/03/2018 09:29, Imre Deak wrote:
> > On Wed, Feb 28, 2018 at 03:35:06PM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > Some tests (the ones which call igt_setup_runtime_pm and
> > > igt_pm_enable_audio_runtime_pm) change default system configuration and
> > > never restore it.
> > > 
> > > The configured runtime suspend is aggressive and may influence behaviour
> > > of subsequent tests, so it is better to restore to previous values on test
> > > exit.
> > > 
> > > This way system behaviour, with regards to a random sequence of executed
> > > tests, will be more consistent from one run to another.
> > > 
> > > v2: Read failure means no runtime pm support so don't assert on it.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Cc: Imre Deak 
> > > Reviewed-by: Chris Wilson  # v1
> > 
> > Agreed about having a consistent expected state for each test, not sure
> > why we didn't restore these settings :/ Btw, I feel somewhat the same
> > about test results being affected by previous tests, but not sure if
> > anything should/can be done about that.
> > 
> > Acked-by: Imre Deak 
> > 
> > Some nits below.
> > 
> > > ---
> > >   lib/igt_pm.c | 122 
> > > ---
> > >   1 file changed, 117 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> > > index 5bf5b2e23cdc..04e2b89cca95 100644
> > > --- a/lib/igt_pm.c
> > > +++ b/lib/igt_pm.c
> > > @@ -63,6 +63,46 @@ enum {
> > >   /* Remember to fix this if adding longer strings */
> > >   #define MAX_POLICY_STRLEN   strlen(MAX_PERFORMANCE_STR)
> > > +static char __igt_pm_audio_runtime_power_save[64];
> > > +static char __igt_pm_audio_runtime_control[64];
> > > +
> > > +static void __igt_pm_audio_runtime_exit_handler(int sig)
> > > +{
> > > + int fd;
> > > +
> > > + igt_debug("Restoring audio power management to '%s' and '%s'\n",
> > > +   __igt_pm_audio_runtime_power_save,
> > > +   __igt_pm_audio_runtime_control);
> > > +
> > > + fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
> > > + if (fd < 0)
> > > + return;
> > > + if (write(fd, __igt_pm_audio_runtime_power_save,
> > > +   strlen(__igt_pm_audio_runtime_power_save)) !=
> > > + strlen(__igt_pm_audio_runtime_power_save))
> > > + igt_warn("Failed to restore audio power_save to '%s'\n",
> > > +  __igt_pm_audio_runtime_power_save);
> > > + close(fd);
> > > +
> > > + fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
> > > + if (fd < 0)
> > > + return;
> > > + if (write(fd, __igt_pm_audio_runtime_control,
> > > +   strlen(__igt_pm_audio_runtime_control)) !=
> > > + strlen(__igt_pm_audio_runtime_control))
> > > + igt_warn("Failed to restore audio control to '%s'\n",
> > > +  __igt_pm_audio_runtime_control);
> > > + close(fd);
> > > +}
> > > +
> > > +static void strchomp(char *str)
> > > +{
> > > + int len = strlen(str);
> > > +
> > > + if (len && str[len - 1] == '\n')
> > > + str[len - 1] = 0;
> > > +}
> > > +
> > >   /**
> > >* igt_pm_enable_audio_runtime_pm:
> > >*
> > > @@ -78,16 +118,32 @@ void igt_pm_enable_audio_runtime_pm(void)
> > >   {
> > >   int fd;
> > > - fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
> > > + /* Check if already enabled. */
> > > + if (__igt_pm_audio_runtime_power_save[0])
> > > + return;
> > > +
> > > + fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
> > >   if (fd >= 0) {
> > > + igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
> > > + sizeof(__igt_pm_audio_runtime_power_save)) > 0);
> > > + strchomp(__igt_pm_audio_runtime_power_save);
> > >   igt_assert_eq(write(fd, "1\n", 2), 2);
> > > + igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
> > 
> > Read/install_handler/write would avoid a potential race with ^C. There's 
> > also
> 
> Well spotted, done in v3.

Ok, for that one:
Reviewed-by: Imre Deak 

> 
> > link_power_management_policy which is only restored during normal exit.
> 
> This one already has code to restore
> (igt_pm_restore_sata_link_power_management) so maybe best to decide where to
> put the responsibility of installing the exit handler in a follow up patch?
> Make igt_pm_enable_sata_link_power_management do it, or have the caller do
> it? Former would be inline with this patch, and then probably we can
> unexport igt_pm_restore_sata_link_power_management. Or does it already
> handle this for normal exit since it is calling it from igt_fixture?

Yes, it's handled for normal exit via igt_fixture, but I think it should
be restored the same 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop engines around GPU reset preparations

[Mika Kuoppala]

Chris Wilson  writes:

> Quoting Mika Kuoppala (2018-03-02 11:50:32)
>> Chris Wilson  writes:
>> > +static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
>> > +   unsigned engine_mask,
>> > +   u32 mode)
>> > +{
>> > + struct intel_engine_cs *engine;
>> > + enum intel_engine_id id;
>> > +
>> > + if (INTEL_GEN(dev_priv) < 3)
>> > + return;
>> > +
>> > + for_each_engine_masked(engine, dev_priv, engine_mask, id)
>> > + I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
>> 
>> Is there reason to not use gen3_stop_engine in this level?
>
> It clears HEAD/TAIL, so undoing it in the case of no reset is a bit more
> tricky.

With this we now have 3 different flavours of stopping an engine.

I would like to see early on prepare reset to call engine->stop(),
which would be unified way of bring engine to halt. And limit
any further restoration of state if we can't really manage to reset it,
leaving it as stopped and dormant as we possibly could get it.

Then only on successful reset and restoration of init state, we would
have an engine->start().

But as this does stop the engine early on it is an improvement,
Reviewed-by: Mika Kuoppala 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH xf86-video-intel v2] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors

[Chris Wilson]

Quoting Ville Syrjälä (2018-03-02 12:12:26)
> On Fri, Mar 02, 2018 at 12:01:42PM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2018-03-02 11:59:18)
> > > From: Ville Syrjälä 
> > > 
> > > Use the new "COLOR_ENCODING" plane property to implement the
> > > XV_COLORSPACE port attribute for sprite Xv adaptors.
> > > 
> > > v2: assert(colorspace < ARRAY_SIZE) (Chris)
> > > 
> > > Cc: Jyri Sarha 
> > > Cc: Chris Wilson 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > Is this (i.e. the kernel implementation is done) ready to land?
> 
> No one has complained about the proposed uapi and I have sufficient
> r-bs, so I'm ready to push the kernel stuff as soon as there's a green
> light from the user space side.

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

Re: [Intel-gfx] [PATCH xf86-video-intel v2] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors

[Ville Syrjälä]

On Fri, Mar 02, 2018 at 12:01:42PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-03-02 11:59:18)
> > From: Ville Syrjälä 
> > 
> > Use the new "COLOR_ENCODING" plane property to implement the
> > XV_COLORSPACE port attribute for sprite Xv adaptors.
> > 
> > v2: assert(colorspace < ARRAY_SIZE) (Chris)
> > 
> > Cc: Jyri Sarha 
> > Cc: Chris Wilson 
> > Signed-off-by: Ville Syrjälä 
> 
> Is this (i.e. the kernel implementation is done) ready to land?

No one has complained about the proposed uapi and I have sufficient
r-bs, so I'm ready to push the kernel stuff as soon as there's a green
light from the user space side.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Stop engines around GPU reset preparations

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Stop engines around GPU reset 
preparations
URL   : https://patchwork.freedesktop.org/series/39270/
State : success

== Summary ==

Series 39270v1 series starting with [1/2] drm/i915: Stop engines around GPU 
reset preparations
https://patchwork.freedesktop.org/api/1.0/series/39270/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-byt-n2820) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:411s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:479s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:476s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:393s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:494s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:449s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:491s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:491s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:403s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:512s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s
fi-cnl-y3 failed to collect. IGT log at Patchwork_8210/fi-cnl-y3/run0.log

b2e10fd5e8b2cd72b0e1eba46c1221dc3d4b70bc drm-tip: 2018y-03m-02d-09h-36m-59s UTC 
integration manifest
f2dac0f529e2 drm/i915: Suspend submission tasklets around wedging
1e1a9eccd43f drm/i915: Stop engines around GPU reset preparations

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8210/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wedged engine mask makes more sense in hex

[Tvrtko Ursulin]

On 28/02/2018 17:54, Patchwork wrote:

== Series Details ==

Series: drm/i915: Wedged engine mask makes more sense in hex
URL   : https://patchwork.freedesktop.org/series/39147/
State : success

== Summary ==

Series 39147v1 drm/i915: Wedged engine mask makes more sense in hex
https://patchwork.freedesktop.org/api/1.0/series/39147/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-b:
 pass   -> INCOMPLETE (fi-skl-guc) fdo#103191

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:376s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:464s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:396s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:590s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-skl-guc   total:245  pass:220  dwarn:0   dfail:0   fail:0   skip:24
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:529s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s

573e919160e546baa4268a213400f9f42f72ae97 drm-tip: 2018y-02m-28d-16h-17m-37s UTC 
integration manifest
a1a2ccdff789 drm/i915: Wedged engine mask makes more sense in hex


Pushed, thanks for the reviews!

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH xf86-video-intel v2] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors

[Chris Wilson]

Quoting Ville Syrjala (2018-03-02 11:59:18)
> From: Ville Syrjälä 
> 
> Use the new "COLOR_ENCODING" plane property to implement the
> XV_COLORSPACE port attribute for sprite Xv adaptors.
> 
> v2: assert(colorspace < ARRAY_SIZE) (Chris)
> 
> Cc: Jyri Sarha 
> Cc: Chris Wilson 
> Signed-off-by: Ville Syrjälä 

Is this (i.e. the kernel implementation is done) ready to land?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop engines around GPU reset preparations

[Chris Wilson]

Quoting Mika Kuoppala (2018-03-02 11:50:32)
> Chris Wilson  writes:
> > +static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
> > +   unsigned engine_mask,
> > +   u32 mode)
> > +{
> > + struct intel_engine_cs *engine;
> > + enum intel_engine_id id;
> > +
> > + if (INTEL_GEN(dev_priv) < 3)
> > + return;
> > +
> > + for_each_engine_masked(engine, dev_priv, engine_mask, id)
> > + I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
> 
> Is there reason to not use gen3_stop_engine in this level?

It clears HEAD/TAIL, so undoing it in the case of no reset is a bit more
tricky.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH xf86-video-intel v2] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors

[Ville Syrjala]

From: Ville Syrjälä 

Use the new "COLOR_ENCODING" plane property to implement the
XV_COLORSPACE port attribute for sprite Xv adaptors.

v2: assert(colorspace < ARRAY_SIZE) (Chris)

Cc: Jyri Sarha 
Cc: Chris Wilson 
Signed-off-by: Ville Syrjälä 
---
 src/sna/sna.h  |   1 +
 src/sna/sna_display.c  | 149 +++--
 src/sna/sna_video.h|   3 +
 src/sna/sna_video_sprite.c |  22 ++-
 4 files changed, 143 insertions(+), 32 deletions(-)

diff --git a/src/sna/sna.h b/src/sna/sna.h
index 5283ce436a3b..c9097d3db158 100644
--- a/src/sna/sna.h
+++ b/src/sna/sna.h
@@ -634,6 +634,7 @@ static inline void sna_present_cancel_flip(struct sna *sna) 
{ }
 
 extern unsigned sna_crtc_count_sprites(xf86CrtcPtr crtc);
 extern bool sna_crtc_set_sprite_rotation(xf86CrtcPtr crtc, unsigned idx, 
uint32_t rotation);
+extern void sna_crtc_set_sprite_colorspace(xf86CrtcPtr crtc, unsigned idx, int 
colorspace);
 extern uint32_t sna_crtc_to_sprite(xf86CrtcPtr crtc, unsigned idx);
 extern bool sna_crtc_is_transformed(xf86CrtcPtr crtc);
 
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index ea2f148d213c..091932f73971 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -222,6 +222,10 @@ struct sna_crtc {
uint32_t supported;
uint32_t current;
} rotation;
+   struct {
+   uint32_t prop;
+   uint64_t values[2];
+   } color_encoding;
struct list link;
} primary;
struct list sprites;
@@ -3293,17 +3297,125 @@ static const xf86CrtcFuncsRec sna_crtc_funcs = {
 #endif
 };
 
-inline static bool prop_is_rotation(struct drm_mode_get_property *prop)
+inline static bool prop_has_type_and_name(const struct drm_mode_get_property 
*prop,
+ unsigned int type, const char *name)
 {
-   if ((prop->flags & (1 << 5)) == 0)
+   if ((prop->flags & (1 << type)) == 0)
return false;
 
-   if (strcmp(prop->name, "rotation"))
+   if (strcmp(prop->name, name))
return false;
 
return true;
 }
 
+inline static bool prop_is_rotation(const struct drm_mode_get_property *prop)
+{
+   return prop_has_type_and_name(prop, 5, "rotation");
+}
+
+static void parse_rotation_prop(struct sna *sna, struct plane *p,
+   struct drm_mode_get_property *prop,
+   uint64_t value)
+{
+   struct drm_mode_property_enum *enums;
+   int j;
+
+   p->rotation.prop = prop->prop_id;
+   p->rotation.current = value;
+
+   DBG(("%s: found rotation property .id=%d, value=%ld, num_enums=%d\n",
+__FUNCTION__, prop->prop_id, value, prop->count_enum_blobs));
+
+   enums = malloc(prop->count_enum_blobs * sizeof(struct 
drm_mode_property_enum));
+   if (!enums)
+   return;
+
+   prop->count_values = 0;
+   prop->enum_blob_ptr = (uintptr_t)enums;
+
+   if (drmIoctl(sna->kgem.fd, DRM_IOCTL_MODE_GETPROPERTY, prop)) {
+   free(enums);
+   return;
+   }
+
+   /* XXX we assume that the mapping between kernel enum and
+* RandR remains fixed for our lifetimes.
+*/
+   VG(VALGRIND_MAKE_MEM_DEFINED(enums, 
sizeof(*enums)*prop->count_enum_blobs));
+   for (j = 0; j < prop->count_enum_blobs; j++) {
+   DBG(("%s: rotation[%d] = %s [%lx]\n", __FUNCTION__,
+j, enums[j].name, (long)enums[j].value));
+   p->rotation.supported |= 1 << enums[j].value;
+   }
+
+   free(enums);
+}
+
+inline static bool prop_is_color_encoding(const struct drm_mode_get_property 
*prop)
+{
+   return prop_has_type_and_name(prop, 3, "COLOR_ENCODING");
+}
+
+static void parse_color_encoding_prop(struct sna *sna, struct plane *p,
+ struct drm_mode_get_property *prop,
+ uint64_t value)
+{
+   struct drm_mode_property_enum *enums;
+   unsigned int supported = 0;
+   int j;
+
+   DBG(("%s: found color encoding property .id=%d, value=%ld, 
num_enums=%d\n",
+__FUNCTION__, prop->prop_id, (long)value, prop->count_enum_blobs));
+
+   enums = malloc(prop->count_enum_blobs * sizeof(struct 
drm_mode_property_enum));
+   if (!enums)
+   return;
+
+   prop->count_values = 0;
+   prop->enum_blob_ptr = (uintptr_t)enums;
+
+   if (drmIoctl(sna->kgem.fd, DRM_IOCTL_MODE_GETPROPERTY, prop)) {
+   free(enums);
+   return;
+   }
+
+   VG(VALGRIND_MAKE_MEM_DEFINED(enums, 
sizeof(*enums)*prop->count_enum_blobs));
+   for (j = 0; j < prop->count_enum_blobs; j++) {
+   if (!strcmp(enums[j].name, "ITU-R BT.601 YCbCr")) {
+  

[Intel-gfx] [PATCH i-g-t v5] tests/perf_pmu: Handle CPU hotplug failures better

[Tvrtko Ursulin]

From: Chris Wilson 

CPU hotplug, especially CPU0, can be flaky on commodity hardware.

To improve test reliability and reponse times when testing larger runs we
need to handle those cases better.

Handle failures to off-line a CPU by immediately skipping the test, and
failures to on-line a CPU by immediately rebooting the machine.

This patch includes igt_sysrq_reboot implementation from Chris Wilson.

v2: Halt by default, reboot if env variable IGT_REBOOT_ON_FATAL_ERROR is
set. (Petri Latvala)

v3: Add missign docs and update stale comment. (Petri Latvala)

v4: Use pause instead of sleep. (Chris Wilson)
v5: Newlines! (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Petri Latvala 
Cc: Tomi Sarvela 
Reviewed-by: Petri Latvala 
---
 lib/Makefile.sources |  2 ++
 lib/igt_core.c   | 23 +++
 lib/igt_core.h   |  1 +
 lib/igt_sysrq.c  | 27 +++
 lib/igt_sysrq.h  | 30 ++
 lib/meson.build  |  1 +
 tests/perf_pmu.c | 38 +++---
 7 files changed, 115 insertions(+), 7 deletions(-)
 create mode 100644 lib/igt_sysrq.c
 create mode 100644 lib/igt_sysrq.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 5b13ef8896c0..3d37ef1d1984 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -35,6 +35,8 @@ lib_source_list = \
igt_stats.h \
igt_sysfs.c \
igt_sysfs.h \
+   igt_sysrq.c \
+   igt_sysrq.h \
igt_x86.h   \
igt_x86.c   \
igt_vgem.c  \
diff --git a/lib/igt_core.c b/lib/igt_core.c
index c292343de09e..e52b806bdb01 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -70,6 +70,7 @@
 #include "igt_core.h"
 #include "igt_aux.h"
 #include "igt_sysfs.h"
+#include "igt_sysrq.h"
 #include "igt_rc.h"
 
 #define UNW_LOCAL_ONLY
@@ -1136,6 +1137,28 @@ void igt_fail(int exitcode)
}
 }
 
+/**
+ * igt_fatal_error: Stop test execution on fatal errors
+ *
+ * Stop test execution or optionally, if the IGT_REBOOT_ON_FATAL_ERROR
+ * environment variable is set, reboot the machine.
+ *
+ * Since out test runner (piglit) does support fatal test exit codes, we
+ * implement the default behaviour by waiting endlessly.
+ */
+void  __attribute__((noreturn)) igt_fatal_error(void)
+{
+   if (igt_check_boolean_env_var("IGT_REBOOT_ON_FATAL_ERROR", false)) {
+   igt_warn("FATAL ERROR - REBOOTING\n");
+   igt_sysrq_reboot();
+   } else {
+   igt_warn("FATAL ERROR\n");
+   for (;;)
+   pause();
+   }
+}
+
+
 /**
  * igt_can_fail:
  *
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 7af2b4c109fe..66523a208c31 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -311,6 +311,7 @@ void __igt_fail_assert(const char *domain, const char *file,
   const char *format, ...)
__attribute__((noreturn));
 void igt_exit(void) __attribute__((noreturn));
+void igt_fatal_error(void) __attribute__((noreturn));
 
 /**
  * igt_ignore_warn:
diff --git a/lib/igt_sysrq.c b/lib/igt_sysrq.c
new file mode 100644
index ..3bda321f7c5b
--- /dev/null
+++ b/lib/igt_sysrq.c
@@ -0,0 +1,27 @@
+#include 
+#include 
+#include 
+#include 
+
+#include "igt_core.h"
+
+#include "igt_sysrq.h"
+
+/**
+ * igt_sysrq_reboot: Reboots the machine
+ *
+ * Syncs filesystems and immediately reboots the machine.
+ */
+void igt_sysrq_reboot(void)
+{
+   sync();
+
+   /* Try to be nice at first, and if that fails pull the trigger */
+   if (reboot(RB_AUTOBOOT)) {
+   int fd = open("/proc/sysrq-trigger", O_WRONLY);
+   igt_ignore_warn(write(fd, "b", 2));
+   close(fd);
+   }
+
+   abort();
+}
diff --git a/lib/igt_sysrq.h b/lib/igt_sysrq.h
new file mode 100644
index ..422473d2a480
--- /dev/null
+++ b/lib/igt_sysrq.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop engines around GPU reset preparations

[Mika Kuoppala]

Chris Wilson  writes:

> As we make preparations to reset the GPU state, we assume that the GPU
> is hung and will not advance. Make this assumption more explicit by
> setting the STOP_RING bit on the engines as part of our early reset
> preparations.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 
> ---
> See 
> https://intel-gfx-ci.01.org/tree/drm-tip/kasan_15/fi-bdw-5557u/pstore22-1519879816_Panic_3.log
> for a bizarre error that kasan-farm keeps on trying over. Maybe related
> to this?
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  3 +++
>  drivers/gpu/drm/i915/i915_drv.h | 10 --
>  drivers/gpu/drm/i915/intel_uncore.c | 33 +
>  3 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index aaa861b51024..925f5722d077 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1908,6 +1908,8 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
> int flags)
>   error->reset_count++;
>  
>   disable_irq(i915->drm.irq);
> + intel_gpu_reset_prepare(i915, ALL_ENGINES);
> +
>   ret = i915_gem_reset_prepare(i915);
>   if (ret) {
>   dev_err(i915->drm.dev, "GPU recovery failed\n");
> @@ -1969,6 +1971,7 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
> int flags)
>  
>  finish:
>   i915_gem_reset_finish(i915);
> + intel_gpu_reset_finish(i915, ALL_ENGINES);
>   enable_irq(i915->drm.irq);
>  
>  wakeup:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 10c9e5e619ab..b95e675e0834 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2957,8 +2957,14 @@ extern const struct dev_pm_ops i915_pm_ops;
>  extern int i915_driver_load(struct pci_dev *pdev,
>   const struct pci_device_id *ent);
>  extern void i915_driver_unload(struct drm_device *dev);
> -extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 
> engine_mask);
> -extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
> +
> +bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
> +
> +void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
> +  unsigned engine_mask);
> +int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
> +void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
> + unsigned engine_mask);
>  
>  #define I915_RESET_QUIET BIT(0)
>  extern void i915_reset(struct drm_i915_private *i915, unsigned int flags);
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 5ae9a62712ca..7186fe4d2ba9 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1899,6 +1899,29 @@ static reset_func intel_get_gpu_reset(struct 
> drm_i915_private *dev_priv)
>   return NULL;
>  }
>  
> +static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
> +   unsigned engine_mask,
> +   u32 mode)
> +{
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> +
> + if (INTEL_GEN(dev_priv) < 3)
> + return;
> +
> + for_each_engine_masked(engine, dev_priv, engine_mask, id)
> + I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);

Is there reason to not use gen3_stop_engine in this level?

-Mika

> +}
> +
> +void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
> +  unsigned engine_mask)
> +{
> + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> +
> + i915_engines_set_mode(dev_priv, engine_mask,
> +   _MASKED_BIT_ENABLE(STOP_RING));
> +}
> +
>  int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)
>  {
>   reset_func reset = intel_get_gpu_reset(dev_priv);
> @@ -1939,6 +1962,16 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, 
> unsigned engine_mask)
>   return ret;
>  }
>  
> +void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
> + unsigned engine_mask)
> +{
> + /* Clear the STOP_RING bit as the reset may not have occurred */
> + i915_engines_set_mode(dev_priv, engine_mask,
> +   _MASKED_BIT_DISABLE(STOP_RING));
> +
> + intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> +}
> +
>  bool intel_has_gpu_reset(struct drm_i915_private *dev_priv)
>  {
>   return intel_get_gpu_reset(dev_priv) != NULL;
> -- 
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/15] drm/i915/guc: Tidy guc_log_control

[Michał Winiarski]

On Fri, Mar 02, 2018 at 04:39:38PM +0530, Sagar Arun Kamble wrote:
> 
> 
> On 2/27/2018 6:22 PM, Michał Winiarski wrote:
> > We plan to decouple log runtime (mapping + relay) from verbosity control.
> > Let's tidy the code now to reduce the churn in the following patches.
> > 
> > Signed-off-by: Michał Winiarski 
> > Cc: Chris Wilson 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Michal Wajdeczko 
> > Cc: Sagar Arun Kamble 
> > ---
> >   drivers/gpu/drm/i915/i915_debugfs.c  | 11 ++
> >   drivers/gpu/drm/i915/intel_guc_log.c | 75 
> > +++-
> >   drivers/gpu/drm/i915/intel_guc_log.h |  3 +-
> >   3 files changed, 46 insertions(+), 43 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 33fbf3965309..58983cafaece 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2500,13 +2500,10 @@ static int i915_guc_log_control_get(void *data, u64 
> > *val)
> Should we name this i915_guc_log_level_get instead? and other related
> functions too?

I chose symmetry here, note that the debugfs file is still named
i915_guc_log_control at this point. This changes later in the series though.

> >   {
> > struct drm_i915_private *dev_priv = data;
> > -   if (!HAS_GUC(dev_priv))
> > +   if (!USES_GUC(dev_priv))
> > return -ENODEV;
> > -   if (!dev_priv->guc.log.vma)
> > -   return -EINVAL;
> > -
> > -   *val = i915_modparams.guc_log_level;
> > +   *val = intel_guc_log_control_get(_priv->guc);
> > return 0;
> >   }
> > @@ -2515,10 +2512,10 @@ static int i915_guc_log_control_set(void *data, u64 
> > val)
> >   {
> > struct drm_i915_private *dev_priv = data;
> > -   if (!HAS_GUC(dev_priv))
> > +   if (!USES_GUC(dev_priv))
> > return -ENODEV;
> > -   return intel_guc_log_control(_priv->guc, val);
> > +   return intel_guc_log_control_set(_priv->guc, val);
> >   }
> >   DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
> > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
> > b/drivers/gpu/drm/i915/intel_guc_log.c
> > index 7b5074e2120c..22a05320817b 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_log.c
> > +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> > @@ -657,52 +657,55 @@ void intel_guc_log_destroy(struct intel_guc *guc)
> > i915_vma_unpin_and_release(>log.vma);
> >   }
> > -int intel_guc_log_control(struct intel_guc *guc, u64 control_val)
> > +int intel_guc_log_control_get(struct intel_guc *guc)
> Should we be passing guc_log as parameter and implement guc_log_to_guc()
> function.

This is the top-level interface exported for GuC users. In other words - callers
of this function shouldn't have to know about struct guc_log (and the fact that
it's located inside struct intel_guc).

> > +{
> > +   GEM_BUG_ON(!guc->log.vma);
> > +   GEM_BUG_ON(i915_modparams.guc_log_level < 0);
> > +
> > +   return i915_modparams.guc_log_level;
> > +}
> > +
> > +#define GUC_LOG_IS_ENABLED(x)  (x > 0)
> > +#define GUC_LOG_LEVEL_TO_VERBOSITY(x)  (GUC_LOG_IS_ENABLED(x) ? x - 1 
> > : 0)
> This is bit misleading, can we make this macro return -1 if logging is to be
> disabled. That way guc_log_control can be invoked with
> single signed 32bit parameter.

Note that guc_log_control is the function operating directly on GuC interface.
This Host2GuC action really takes 3 arguments (2 parameters here) - enable,
default_logging_enable, verbosity.
As a consequence, I'd like to avoid placing any logic there. The macros are
taking care of translation from guc_log_level modparam to values understood by
GuC (host2guc params).

I agree that the naming is confusing here.
I'll go with LOG_LEVEL_TO_ENABLED(x) and LOG_LEVEL_TO_VERBOSITY(x) in second
spin as suggested by Michał.

> > +int intel_guc_log_control_set(struct intel_guc *guc, u64 val)
> >   {
> > struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > -   bool enable_logging = control_val > 0;
> > -   u32 verbosity;
> > int ret;
> > -   if (!guc->log.vma)
> > -   return -ENODEV;
> > +   BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
> > +   GEM_BUG_ON(!guc->log.vma);
> > +   GEM_BUG_ON(i915_modparams.guc_log_level < 0);
> > -   BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);
> > -   if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
> > +   /*
> > +* GuC is recognizing log levels starting from 0 to max, we're using 0
> > +* as indication that logging should be disablded.
> > +*/
> > +   if (GUC_LOG_LEVEL_TO_VERBOSITY(val) < GUC_LOG_VERBOSITY_MIN ||
> This check seems unnecessary as we currently don't have negative output for
> G_L_L_T_V macro.
> If we add negative value there, will need to remove this check.

Yeah, agree. That's an error on my part, I wanted to do input validation here.
This should probably be something more like:
if (val < 

[Intel-gfx] [PATCH v2 1/2] drm/i915/uc: Introduce intel_uc_suspend|resume

[Michal Wajdeczko]

We want to use higher level 'uc' functions as the main entry points to
the GuC/HuC code to hide some details and keep code layered.

While here, move call to disable_guc_interrupts after sending suspend
action to the GuC to allow it work also with CTB as comm mechanism.

v2: update commit msg (Sagar)

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.c  |  6 +++---
 drivers/gpu/drm/i915/i915_gem.c  |  4 ++--
 drivers/gpu/drm/i915/intel_guc.c | 42 +
 drivers/gpu/drm/i915/intel_guc.h |  4 ++--
 drivers/gpu/drm/i915/intel_uc.c  | 45 
 drivers/gpu/drm/i915/intel_uc.h  |  2 ++
 6 files changed, 68 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aaa861b..d61b51c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2575,7 +2575,7 @@ static int intel_runtime_suspend(struct device *kdev)
 */
i915_gem_runtime_suspend(dev_priv);
 
-   intel_guc_suspend(dev_priv);
+   intel_uc_suspend(dev_priv);
 
intel_runtime_pm_disable_interrupts(dev_priv);
 
@@ -2597,7 +2597,7 @@ static int intel_runtime_suspend(struct device *kdev)
 
intel_runtime_pm_enable_interrupts(dev_priv);
 
-   intel_guc_resume(dev_priv);
+   intel_uc_resume(dev_priv);
 
i915_gem_init_swizzling(dev_priv);
i915_gem_restore_fences(dev_priv);
@@ -2683,7 +2683,7 @@ static int intel_runtime_resume(struct device *kdev)
 
intel_runtime_pm_enable_interrupts(dev_priv);
 
-   intel_guc_resume(dev_priv);
+   intel_uc_resume(dev_priv);
 
/*
 * No point of rolling back things in case of an error, as the best
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c29b1a1..8d107f2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4916,7 +4916,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
i915_gem_contexts_lost(dev_priv);
mutex_unlock(>struct_mutex);
 
-   intel_guc_suspend(dev_priv);
+   intel_uc_suspend(dev_priv);
 
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
cancel_delayed_work_sync(_priv->gt.retire_work);
@@ -4983,7 +4983,7 @@ void i915_gem_resume(struct drm_i915_private *i915)
if (i915_gem_init_hw(i915))
goto err_wedged;
 
-   intel_guc_resume(i915);
+   intel_uc_resume(i915);
 
/* Always reload a context for powersaving. */
if (i915_gem_switch_to_kernel_context(i915))
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index e6512cc..ff08ea0 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -403,22 +403,15 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 
rsa_offset)
 
 /**
  * intel_guc_suspend() - notify GuC entering suspend state
- * @dev_priv:  i915 device private
+ * @guc:   the guc
  */
-int intel_guc_suspend(struct drm_i915_private *dev_priv)
+int intel_guc_suspend(struct intel_guc *guc)
 {
-   struct intel_guc *guc = _priv->guc;
-   u32 data[3];
-
-   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
-   return 0;
-
-   gen9_disable_guc_interrupts(dev_priv);
-
-   data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
-   /* any value greater than GUC_POWER_D0 */
-   data[1] = GUC_POWER_D1;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   u32 data[] = {
+   INTEL_GUC_ACTION_ENTER_S_STATE,
+   GUC_POWER_D1, /* any value greater than GUC_POWER_D0 */
+   guc_ggtt_offset(guc->shared_data)
+   };
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -448,22 +441,15 @@ int intel_guc_reset_engine(struct intel_guc *guc,
 
 /**
  * intel_guc_resume() - notify GuC resuming from suspend state
- * @dev_priv:  i915 device private
+ * @guc:   the guc
  */
-int intel_guc_resume(struct drm_i915_private *dev_priv)
+int intel_guc_resume(struct intel_guc *guc)
 {
-   struct intel_guc *guc = _priv->guc;
-   u32 data[3];
-
-   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
-   return 0;
-
-   if (i915_modparams.guc_log_level)
-   gen9_enable_guc_interrupts(dev_priv);
-
-   data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
-   data[1] = GUC_POWER_D0;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   u32 data[] = {
+   INTEL_GUC_ACTION_EXIT_S_STATE,
+   GUC_POWER_D0,
+   guc_ggtt_offset(guc->shared_data)
+   };
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.h