Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make MG phy macros semantically consistent

2019-02-13 Thread Lucas De Marchi
On Tue, Feb 12, 2019 at 3:57 PM Manasi Navare  wrote:
>
> On Mon, Jan 28, 2019 at 02:00:12PM -0800, Aditya Swarup wrote:
> > Macros to be organized semantically by dword, lane and
> > port(in this order).
> >
> > Cc: Clint Taylor 
> > Cc: Imre Deak 
> > Cc: Jani Nikula 
> > Signed-off-by: Aditya Swarup 
>
> Also please add Fixes tag with SHA of the original patch that
> adds these macros.

but this doesn't fix a bug, does it? why would you propagate this to stable?

Lucas De Marchi

> With that,
>
> Reviewed-by: Manasi navare 
>
> Manasi
>
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  | 50 
> >  drivers/gpu/drm/i915/intel_ddi.c | 44 ++--
> >  2 files changed, 47 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index b0535073c3f0..da8fcdc456d2 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1897,7 +1897,7 @@ enum i915_power_well_id {
> >  #define   N_SCALAR(x)((x) << 24)
> >  #define   N_SCALAR_MASK  (0x7F << 24)
> >
> > -#define MG_PHY_PORT_LN(port, ln, ln0p1, ln0p2, ln1p1) \
> > +#define MG_PHY_PORT_LN(ln, port, ln0p1, ln0p2, ln1p1) \
> >   _MMIO(_PORT((port) - PORT_C, ln0p1, ln0p2) + (ln) * ((ln1p1) - 
> > (ln0p1)))
> >
> >  #define MG_TX_LINK_PARAMS_TX1LN0_PORT1   0x16812C
> > @@ -1908,8 +1908,8 @@ enum i915_power_well_id {
> >  #define MG_TX_LINK_PARAMS_TX1LN1_PORT3   0x16A52C
> >  #define MG_TX_LINK_PARAMS_TX1LN0_PORT4   0x16B12C
> >  #define MG_TX_LINK_PARAMS_TX1LN1_PORT4   0x16B52C
> > -#define MG_TX1_LINK_PARAMS(port, ln) \
> > - MG_PHY_PORT_LN(port, ln, MG_TX_LINK_PARAMS_TX1LN0_PORT1, \
> > +#define MG_TX1_LINK_PARAMS(ln, port) \
> > + MG_PHY_PORT_LN(ln, port, MG_TX_LINK_PARAMS_TX1LN0_PORT1, \
> >MG_TX_LINK_PARAMS_TX1LN0_PORT2, \
> >MG_TX_LINK_PARAMS_TX1LN1_PORT1)
> >
> > @@ -1921,8 +1921,8 @@ enum i915_power_well_id {
> >  #define MG_TX_LINK_PARAMS_TX2LN1_PORT3   0x16A4AC
> >  #define MG_TX_LINK_PARAMS_TX2LN0_PORT4   0x16B0AC
> >  #define MG_TX_LINK_PARAMS_TX2LN1_PORT4   0x16B4AC
> > -#define MG_TX2_LINK_PARAMS(port, ln) \
> > - MG_PHY_PORT_LN(port, ln, MG_TX_LINK_PARAMS_TX2LN0_PORT1, \
> > +#define MG_TX2_LINK_PARAMS(ln, port) \
> > + MG_PHY_PORT_LN(ln, port, MG_TX_LINK_PARAMS_TX2LN0_PORT1, \
> >MG_TX_LINK_PARAMS_TX2LN0_PORT2, \
> >MG_TX_LINK_PARAMS_TX2LN1_PORT1)
> >  #define   CRI_USE_FS32   (1 << 5)
> > @@ -1935,8 +1935,8 @@ enum i915_power_well_id {
> >  #define MG_TX_PISO_READLOAD_TX1LN1_PORT3 0x16A54C
> >  #define MG_TX_PISO_READLOAD_TX1LN0_PORT4 0x16B14C
> >  #define MG_TX_PISO_READLOAD_TX1LN1_PORT4 0x16B54C
> > -#define MG_TX1_PISO_READLOAD(port, ln) \
> > - MG_PHY_PORT_LN(port, ln, MG_TX_PISO_READLOAD_TX1LN0_PORT1, \
> > +#define MG_TX1_PISO_READLOAD(ln, port) \
> > + MG_PHY_PORT_LN(ln, port, MG_TX_PISO_READLOAD_TX1LN0_PORT1, \
> >MG_TX_PISO_READLOAD_TX1LN0_PORT2, \
> >MG_TX_PISO_READLOAD_TX1LN1_PORT1)
> >
> > @@ -1948,8 +1948,8 @@ enum i915_power_well_id {
> >  #define MG_TX_PISO_READLOAD_TX2LN1_PORT3 0x16A4CC
> >  #define MG_TX_PISO_READLOAD_TX2LN0_PORT4 0x16B0CC
> >  #define MG_TX_PISO_READLOAD_TX2LN1_PORT4 0x16B4CC
> > -#define MG_TX2_PISO_READLOAD(port, ln) \
> > - MG_PHY_PORT_LN(port, ln, MG_TX_PISO_READLOAD_TX2LN0_PORT1, \
> > +#define MG_TX2_PISO_READLOAD(ln, port) \
> > + MG_PHY_PORT_LN(ln, port, MG_TX_PISO_READLOAD_TX2LN0_PORT1, \
> >MG_TX_PISO_READLOAD_TX2LN0_PORT2, \
> >MG_TX_PISO_READLOAD_TX2LN1_PORT1)
> >  #define   CRI_CALCINIT   (1 << 1)
> > @@ -1962,8 +1962,8 @@ enum i915_power_well_id {
> >  #define MG_TX_SWINGCTRL_TX1LN1_PORT3 0x16A548
> >  #define MG_TX_SWINGCTRL_TX1LN0_PORT4 0x16B148
> >  #define MG_TX_SWINGCTRL_TX1LN1_PORT4 0x16B548
> > -#define MG_TX1_SWINGCTRL(port, ln) \
> > - MG_PHY_PORT_LN(port, ln, MG_TX_SWINGCTRL_TX1LN0_PORT1, \
> > +#define MG_TX1_SWINGCTRL(ln, port) \
> > + MG_PHY_PORT_LN(ln, port, MG_TX_SWINGCTRL_TX1LN0_PORT1, \
> >MG_TX_SWINGCTRL_TX1LN0_PORT2, \
> >MG_TX_SWINGCTRL_TX1LN1_PORT1)
> >
> > @@ -1975,8 +1975,8 @@ enum i915_power_well_id {
> >  #define MG_TX_SWINGCTRL_TX2LN1_PORT3 0x16A4C8
> >  #define MG_TX_SWINGCTRL_TX2LN0_PORT4 0x16B0C8
> >  #define MG_TX_SWINGCTRL_TX2LN1_PORT4 0x16B4C8
> > -#define MG_TX2_SWINGCTRL(port, ln) \
> > - MG_PHY_PORT_LN(port, ln, MG_TX_SWINGCTRL_TX2LN0_PORT1, \
> > 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move dsc rate params compute into drm

2019-02-13 Thread kbuild test robot
Hi David,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc4 next-20190213]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/David-Francis/Make-DRM-DSC-helpers-more-generally-usable/20190214-052541
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   net/mac80211/sta_info.h:590: warning: Function parameter or member 
'tx_stats.last_rate' not described in 'sta_info'
   net/mac80211/sta_info.h:590: warning: Function parameter or member 
'tx_stats.msdu' not described in 'sta_info'
   kernel/rcu/tree.c:711: warning: Excess function parameter 'irq' description 
in 'rcu_nmi_exit'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_excl.cb' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_excl.poll' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_excl.active' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_shared.cb' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_shared.poll' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_shared.active' not described in 'dma_buf'
   include/linux/dma-fence-array.h:54: warning: Function parameter or member 
'work' not described in 'dma_fence_array'
   include/linux/firmware/intel/stratix10-svc-client.h:1: warning: no 
structured comments found
   include/linux/gpio/driver.h:371: warning: Function parameter or member 
'init_valid_mask' not described in 'gpio_chip'
   include/linux/iio/hw-consumer.h:1: warning: no structured comments found
   include/linux/input/sparse-keymap.h:46: warning: Function parameter or 
member 'sw' not described in 'key_entry'
   drivers/mtd/nand/raw/nand_base.c:420: warning: Function parameter or member 
'chip' not described in 'nand_fill_oob'
   drivers/mtd/nand/raw/nand_bbt.c:173: warning: Function parameter or member 
'this' not described in 'read_bbt'
   drivers/mtd/nand/raw/nand_bbt.c:173: warning: Excess function parameter 
'chip' description in 'read_bbt'
   include/linux/regulator/machine.h:199: warning: Function parameter or member 
'max_uV_step' not described in 'regulation_constraints'
   include/linux/regulator/driver.h:228: warning: Function parameter or member 
'resume' not described in 'regulator_ops'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw0' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw1' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw2' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw3' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.eadm' not described in 'irb'
   drivers/slimbus/stream.c:1: warning: no structured comments found
   include/linux/spi/spi.h:180: warning: Function parameter or member 
'driver_override' not described in 'spi_device'
   drivers/target/target_core_device.c:1: warning: no structured comments found
   drivers/usb/typec/bus.c:1: warning: no structured comments found
   drivers/usb/typec/class.c:1: warning: no structured comments found
   include/linux/w1.h:281: warning: Function parameter or member 
'of_match_table' not described in 'w1_family'
   fs/direct-io.c:257: warning: Excess function parameter 'offset' description 
in 'dio_complete'
   fs/file_table.c:1: warning: no structured comments found
   fs/libfs.c:477: warning: Excess function parameter 'available' description 
in 'simple_write_end'
   fs/posix_acl.c:646: warning: Function parameter or member 'inode' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:646: warning: Function parameter or member 'mode_p' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:646: warning: Function parameter or member 'acl' not 
described in 'posix_acl_update_mode'
   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function 
parameter 'mm' description in 'amdgpu_mn_invalidate_range_start_hsa'
   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function 
parameter 'start' description in 'amdgpu_mn_invalidate_range_start_hsa'
   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function 
parameter 'end' description in 'amdgpu_mn_invalidate_range_start_hsa'
   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function 
parameter 'mm' description in 'amdgpu_mn_invalidate_range_end'
   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function 
parameter 'start' description in 'amdgpu_mn_invalidate_range_end'
   drivers/gpu/drm/amd/

[Intel-gfx] [PATCH v3 4/6] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

2019-02-13 Thread Carlos Santa
From: Michel Thierry 

Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.

The recommended default watchdog threshold for video engines is 6 us,
since this has been _empirically determined_ to be a good compromise for
low-latency requirements and low rate of false positives. The default
register value is ~106000us and the theoretical max value (all 1s) is
353 seconds.

[1] 
http://patchwork.freedesktop.org/patch/msgid/20170329135831.30254-2-ch...@chris-wilson.co.uk

v2: Fixed get api to return values in microseconds. Threshold updated to
be per context engine. Check for u32 overflow. Capture ctx threshold
value in error state.

v3: Add a way to get array size, short-cut to disable all thresholds,
return EFAULT / EINVAL as needed. Move the capture of the threshold
value in the error state into a new patch. BXT has a different
timestamp base (because why not?).

v4: Checking if watchdog is available should be the first thing to
do, instead of giving false hopes to abi users; remove unnecessary & in
set_watchdog; ignore args->size in getparam.

v5: GEN9-LP platforms have a different crystal clock frequency, use the
right timestamp base for them (magic 8-ball predicts this will change
again later on, so future-proof it). (Daniele)

v6: Rebase, no more mutex BLK in getparam_ioctl.

v7: use to_intel_context instead of ctx->engine.

v8: Rebase, remove extra mutex from i915_gem_context_set_watchdog (Tvrtko),
Update UAPI to use engine class while keeping thresholds per
engine class (Michel).

v9: Rebase,
Remove outdated comment from the commit message (Tvrtko)
Use the engine->flag to verify for gpu watchdog support (Tvrtko)
Use the standard copy_to_user() instead (Tvrtko)
Use the correct type when declaring engine class iterator (Tvrtko)
Remove yet another unncessary mutex_lock (Tvrtko)

Cc: Antonio Argenziano 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 50 +-
 drivers/gpu/drm/i915/i915_gem_context.c | 91 +
 include/uapi/drm/i915_drm.h |  1 +
 3 files changed, 141 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0fcb2df869a2..aaa5810ba76c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1582,6 +1582,9 @@ struct drm_i915_private {
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 
965 */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
 
+   /* Command stream timestamp base - helps define watchdog threshold */
+   u32 cs_timestamp_base;
+
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
unsigned int max_cdclk_freq;
@@ -3120,10 +3123,55 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
 }
 
+/*
+ * BDW, CHV & SKL+ Timestamp timer resolution = 0.080 uSec,
+ * or 1250 counts per second, or ~12 counts per microsecond.
+ *
+ * But BXT/GLK Timestamp timer resolution is different, 0.052 uSec,
+ * or 1920 counts per second, or ~19 counts per microsecond.
+ *
+ * Future-proofing, some day it won't be as simple as just GEN & IS_LP.
+ */
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+static inline u32 cs_timestamp_in_us(struct drm_i915_private *dev_priv)
+{
+   u32 cs_timestamp_base = dev_priv->cs_timestamp_base;
+
+   if (cs_timestamp_base)
+   return cs_timestamp_base;
+
+   switch (INTEL_GEN(dev_priv)) {
+   default:
+   MISSING_CASE(INTEL_GEN(dev_priv));
+   /* fall through */
+   case 9:
+   cs_timestamp_base = IS_GEN9_LP(dev_priv) ?
+   GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+   GEN8_TIMESTAMP_CNTS_PER_USEC;
+   break;
+   case 8:
+   cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+   break;
+   }
+
+   dev_priv->cs_timestamp_base = cs_timestamp_base;
+   return cs_timestamp_base;
+}
+
+static inline u32
+watchdog_to_us(struct drm_i915_private *dev_priv, u32 value_in_clock_counts)
+{
+   return value_in_clock_counts / cs_timestamp_in_us(dev_priv);
+}
+
 static inline u32
 watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
 {
-   u64 threshold = 0;
+   u64 threshold = value_in_us * cs_timestamp_in_us(dev_priv);
+
+   if (overflows_type(threshold, u32))
+   return -EINVAL;
 
return threshold;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index cbfe8f2eb3f2..e1abca28140b 100644
--- 

[Intel-gfx] [PATCH v3 3/6] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+

2019-02-13 Thread Carlos Santa
From: Michel Thierry 

Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.

v2: Support watchdog threshold per context engine, merge lri commands,
and move watchdog commands emission to emit_bb_start. Request space of
combined start_watchdog, bb_start and stop_watchdog to avoid any error
after emitting bb_start.

v3: There were too many req->engine in emit_bb_start.
Use GEM_BUG_ON instead of returning a very late EINVAL in the remote
case of watchdog misprogramming; set correct LRI cmd size in
emit_stop_watchdog. (Chris)

v4: Rebase.
v5: use to_intel_context instead of ctx->engine.
v6: Rebase.
v7: Rebase,
Store gpu watchdog capability in engine flag (Tvrtko)
Store WATCHDOG_DISABLE magic # in engine (Tvrtko)
No need to declare emit_{start|stop}_watchdog as vfuncs (Tvrtko)
Replace flag watchdog_running with enable_watchdog (Tvrtko)
Emit a single MI_NOOP by conditionally checking whether the #
of emitted OPs is odd (Tvrtko)

Cc: Chris Wilson 
Cc: Antonio Argenziano 
Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_gem_context.h |  4 ++
 drivers/gpu/drm/i915/intel_engine_cs.c  |  2 +
 drivers/gpu/drm/i915/intel_lrc.c| 78 +++--
 drivers/gpu/drm/i915/intel_lrc.h|  2 +
 drivers/gpu/drm/i915/intel_ringbuffer.h | 18 --
 5 files changed, 96 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index b1eeac64da8b..dcf4e98666a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -183,6 +183,10 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+   /** watchdog_threshold: hw watchdog threshold value,
+* in clock counts
+*/
+   u32 watchdog_threshold;
 
/**
 * active_tracker: Active tracker for the external rq activity
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 74f563d23cc8..438bf93a4340 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -324,6 +324,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
if (engine->context_size)
DRIVER_CAPS(dev_priv)->has_logical_contexts = true;
 
+   engine->watchdog_disable_id = get_watchdog_disable(engine);
+
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 41697fb468e3..abbac267c6f5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2193,16 +2193,74 @@ static void execlists_reset_finish(struct 
intel_engine_cs *engine)
  atomic_read(>tasklet.count));
 }
 
+static u32 *gen8_emit_start_watchdog(struct i915_request *rq, u32 *cs)
+{
+   struct intel_engine_cs *engine = rq->engine;
+   struct i915_gem_context *ctx = rq->gem_context;
+   struct intel_context *ce = to_intel_context(ctx, engine);
+
+   GEM_BUG_ON(!intel_engine_supports_watchdog(engine));
+
+   /*
+* watchdog register must never be programmed to zero. This would
+* cause the watchdog counter to exceed and not allow the engine to
+* go into IDLE state
+*/
+   GEM_BUG_ON(ce->watchdog_threshold == 0);
+
+   /* Set counter period */
+   *cs++ = MI_LOAD_REGISTER_IMM(2);
+   *cs++ = i915_mmio_reg_offset(RING_THRESH(engine->mmio_base));
+   *cs++ = ce->watchdog_threshold;
+   /* Start counter */
+   *cs++ = i915_mmio_reg_offset(RING_CNTR(engine->mmio_base));
+   *cs++ = GEN8_WATCHDOG_ENABLE;
+
+   return cs;
+}
+
+static u32 *gen8_emit_stop_watchdog(struct i915_request *rq, u32 *cs)
+{
+   struct intel_engine_cs *engine = rq->engine;
+
+   GEM_BUG_ON(!intel_engine_supports_watchdog(engine));
+
+   *cs++ = MI_LOAD_REGISTER_IMM(1);
+   *cs++ = i915_mmio_reg_offset(RING_CNTR(engine->mmio_base));
+   *cs++ = engine->watchdog_disable_id;
+
+   return cs;
+}
+
 static int gen8_emit_bb_start(struct i915_request *rq,
  u64 offset, u32 len,
  const unsigned int flags)
 {
+   struct intel_engine_cs *engine = rq->engine;
u32 *cs;
+   u32 num_dwords;
+   bool enable_watchdog = false;
 
-   cs = intel_ring_begin(rq, 6);
+   /* bb_start only */
+   num_dwords = 6;
+
+   /* check if watchdog will be required */
+   if (to_intel_context(rq->gem_context, engine)->watchdog_threshold != 0) 
{
+
+   /* + start_watchdog (6) + stop_watchdog (4) */
+   num_dwords += 10;
+   

[Intel-gfx] [PATCH v3 2/6] drm/i915: Watchdog timeout: IRQ handler for gen8+

2019-02-13 Thread Carlos Santa
From: Michel Thierry 

*** General ***

Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to support this form of hang detection
is to implement the interrupt handling support as well as watchdog command
emission before and after the emitted batch buffer start instruction in the
ring buffer.

The principle of the hang detection mechanism is as follows:

1. Once the decision has been made to enable watchdog timeout for a
particular batch buffer and the driver is in the process of emitting the
batch buffer start instruction into the ring buffer it also emits a
watchdog timer start instruction before and a watchdog timer cancellation
instruction after the batch buffer start instruction in the ring buffer.

2. Once the GPU execution reaches the watchdog timer start instruction
the hardware watchdog counter is started by the hardware. The counter
keeps counting until either reaching a previously configured threshold
value or the timer cancellation instruction is executed.

2a. If the counter reaches the threshold value the hardware fires a
watchdog interrupt that is picked up by the watchdog interrupt handler.
This means that a hang has been detected and the driver needs to deal with
it the same way it would deal with a engine hang detected by the periodic
hang checker. The only difference between the two is that we already blamed
the active request (to ensure an engine reset).

2b. If the batch buffer completes and the execution reaches the watchdog
cancellation instruction before the watchdog counter reaches its
threshold value the watchdog is cancelled and nothing more comes of it.
No hang is detected.

Note about future interaction with preemption: Preemption could happen
in a command sequence prior to watchdog counter getting disabled,
resulting in watchdog being triggered following preemption (e.g. when
watchdog had been enabled in the low priority batch). The driver will
need to explicitly disable the watchdog counter as part of the
preemption sequence.

*** This patch introduces: ***

1. IRQ handler code for watchdog timeout allowing direct hang recovery
based on hardware-driven hang detection, which then integrates directly
with the hang recovery path. This is independent of having per-engine reset
or just full gpu reset.

2. Watchdog specific register information.

Currently the render engine and all available media engines support
watchdog timeout (VECS is only supported in GEN9). The specifications elude
to the BCS engine being supported but that is currently not supported by
this commit.

Note that the value to stop the counter is different between render and
non-render engines in GEN8; GEN9 onwards it's the same.

v2: Move irq handler to tasklet, arm watchdog for a 2nd time to check
against false-positives.

v3: Don't use high priority tasklet, use engine_last_submit while
checking for false-positives. From GEN9 onwards, the stop counter bit is
the same for all engines.

v4: Remove unnecessary brackets, use current_seqno to mark the request
as guilty in the hangcheck/capture code.

v5: Rebased after RESET_ENGINEs flag.

v6: Don't capture error state in case of watchdog timeout. The capture
process is time consuming and this will align to what happens when we
use GuC to handle the watchdog timeout. (Chris)

v7: Rebase.

v8: Rebase, use HZ to reschedule.

v9: Rebase, get forcewake domains in function (no longer in execlists
struct).

v10: Rebase.

v11: Rebase,
 remove extra braces (Tvrtko),
 implement watchdog_to_clock_counts helper (Tvrtko),
 Move tasklet_kill(watchdog_tasklet) inside intel_engines (Tvrtko),
 Use a global heartbeat seqno instead of engine seqno (Chris)
 Make all engines checks all class based checks (Tvrtko)

Cc: Antonio Argenziano 
Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h |  8 +++
 drivers/gpu/drm/i915/i915_gpu_error.h   |  4 ++
 drivers/gpu/drm/i915/i915_irq.c | 12 +++-
 drivers/gpu/drm/i915/i915_reg.h |  6 ++
 drivers/gpu/drm/i915/intel_engine_cs.c  |  1 +
 drivers/gpu/drm/i915/intel_hangcheck.c  | 17 --
 drivers/gpu/drm/i915/intel_lrc.c| 81 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  6 ++
 8 files changed, 129 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 63a008aebfcd..0fcb2df869a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3120,6 +3120,14 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
 }
 
+static inline u32
+watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
+{
+   u64 threshold = 0;
+
+   return threshold;
+}
+
 int 

[Intel-gfx] [PATCH v3 6/6] drm/i915: Watchdog timeout: Blindly trust watchdog timeout for reset?

2019-02-13 Thread Carlos Santa
From: Michel Thierry 

XXX: What to do when the watchdog irq fired twice but our hangcheck
logic thinks the engine is not hung? For example, what if the
active-head moved since the irq handler?

One option is to just ignore the watchdog, if the engine is really hung,
then the driver will detect the hang by itself later on (I'm inclined to
this).

But the other option is to blindly trust the HW, which is what this patch
does...

v1: Rebase.

CC: Antonio Argenziano 
Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/intel_hangcheck.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index bc10acb24d9a..223b79001854 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -288,7 +288,8 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
hangcheck_accumulate_sample(engine, );
hangcheck_store_sample(engine, );
 
-   if (hc.stalled) {
+   if (hc.stalled ||
+   engine->hangcheck.watchdog == 
intel_engine_get_hangcheck_seqno(engine)) {
hung |= engine->mask;
if (hc.action != ENGINE_DEAD)
stuck |= engine->mask;
-- 
2.17.1

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

[Intel-gfx] [PATCH v3 0/6] GEN8+ GPU Watchdog Reset Support

2019-02-13 Thread Carlos Santa
This is a rebased on the original patch series from Michel Thierry
that can be found here:

https://patchwork.freedesktop.org/series/21868

Note that this series is only limited to the GPU Watchdog timeout
for execlists as it leaves out support
for GuC based submission for a later time.

PATCH v3 of this series was successfully tested from userspace
through an IGT test gem_watchdog --run-subtest basic-bsd1,
that test not in upstream yet.

Also, the changes on the i965 media userspace driver are currently
under review at

https://github.com/intel/intel-vaapi-driver/pull/429/files

The testbed used on this series included a SKL-based NUC with 
2 BSD rings as well as a KBL-based Chromebook with 1 BSD ring.

Michel Thierry (6):
  drm/i915: Add engine reset count in get-reset-stats ioctl
  drm/i915: Watchdog timeout: IRQ handler for gen8+
  drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+
  drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
  drm/i915: Watchdog timeout: Include threshold value in error state
  drm/i915: Watchdog timeout: Blindly trust watchdog timeout for reset?

 drivers/gpu/drm/i915/i915_drv.h |  56 +
 drivers/gpu/drm/i915/i915_gem_context.c | 103 +++-
 drivers/gpu/drm/i915/i915_gem_context.h |   4 +
 drivers/gpu/drm/i915/i915_gpu_error.c   |  12 +-
 drivers/gpu/drm/i915/i915_gpu_error.h   |   5 +
 drivers/gpu/drm/i915/i915_irq.c |  12 +-
 drivers/gpu/drm/i915/i915_reg.h |   6 +
 drivers/gpu/drm/i915/intel_engine_cs.c  |   3 +
 drivers/gpu/drm/i915/intel_hangcheck.c  |  20 ++-
 drivers/gpu/drm/i915/intel_lrc.c| 157 +++-
 drivers/gpu/drm/i915/intel_lrc.h|   2 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  24 +++-
 include/uapi/drm/i915_drm.h |   7 +-
 13 files changed, 390 insertions(+), 21 deletions(-)

-- 
2.17.1

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

[Intel-gfx] [PATCH v3 1/6] drm/i915: Add engine reset count in get-reset-stats ioctl

2019-02-13 Thread Carlos Santa
From: Michel Thierry 

Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
and unaffected.

To start the discussion, include just a total engine reset count. If it
is deemed useful, it can be extended to report each engine separately.

Our igt's gem_reset_stats test will need changes to ignore the pad field,
since it can now return reset_engine_count.

v2: s/engine_reset/reset_engine/, use union in uapi to not break compatibility.
v3: Keep rejecting attempts to use pad as input (Antonio)
v4: Rebased.
v5: Rebased.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Antonio Argenziano 
Cc: Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
 include/uapi/drm/i915_drm.h |  6 +-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 459f8eae1c39..cbfe8f2eb3f2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1889,6 +1889,8 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_reset_stats *args = data;
struct i915_gem_context *ctx;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
int ret;
 
if (args->flags || args->pad)
@@ -1907,10 +1909,16 @@ int i915_gem_context_reset_stats_ioctl(struct 
drm_device *dev,
 * we should wrap the hangstats with a seqlock.
 */
 
-   if (capable(CAP_SYS_ADMIN))
+   if (capable(CAP_SYS_ADMIN)) {
args->reset_count = i915_reset_count(_priv->gpu_error);
-   else
+   for_each_engine(engine, dev_priv, id)
+   args->reset_engine_count +=
+   i915_reset_engine_count(_priv->gpu_error,
+   engine);
+   } else {
args->reset_count = 0;
+   args->reset_engine_count = 0;
+   }
 
args->batch_active = atomic_read(>guilty_count);
args->batch_pending = atomic_read(>active_count);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index cc03ef9f885f..3f2c89740b0e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1642,7 +1642,11 @@ struct drm_i915_reset_stats {
/* Number of batches lost pending for execution, for this context */
__u32 batch_pending;
 
-   __u32 pad;
+   union {
+   __u32 pad;
+   /* Engine resets since boot/module reload, for all contexts */
+   __u32 reset_engine_count;
+   };
 };
 
 struct drm_i915_gem_userptr {
-- 
2.17.1

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

[Intel-gfx] [PATCH v3 5/6] drm/i915: Watchdog timeout: Include threshold value in error state

2019-02-13 Thread Carlos Santa
From: Michel Thierry 

Save the watchdog threshold (in us) as part of the engine state.

v2: Only do it for gen8+ (and prevent a missing-case warn).
v3: use ctx->__engine.
v4: Rebase.
v5: Rebase.

Cc: Antonio Argenziano 
Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 12 
 drivers/gpu/drm/i915/i915_gpu_error.h |  1 +
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 8792ad12373d..a2dddaaeb215 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -460,10 +460,12 @@ static void error_print_context(struct 
drm_i915_error_state_buf *m,
const char *header,
const struct drm_i915_error_context *ctx)
 {
-   err_printf(m, "%s%s[%d] user_handle %d hw_id %d, prio %d, ban score 
%d%s guilty %d active %d\n",
+   err_printf(m, "%s%s[%d] user_handle %d hw_id %d, prio %d, ban score 
%d%s guilty %d active %d, watchdog %dus\n",
   header, ctx->comm, ctx->pid, ctx->handle, ctx->hw_id,
   ctx->sched_attr.priority, ctx->ban_score, bannable(ctx),
-  ctx->guilty, ctx->active);
+  ctx->guilty, ctx->active,
+  INTEL_GEN(m->i915) >= 8 ?
+   watchdog_to_us(m->i915, ctx->watchdog_threshold) : 0);
 }
 
 static void error_print_engine(struct drm_i915_error_state_buf *m,
@@ -1348,7 +1350,8 @@ static void error_record_engine_execlists(struct 
intel_engine_cs *engine,
 }
 
 static void record_context(struct drm_i915_error_context *e,
-  struct i915_gem_context *ctx)
+  struct i915_gem_context *ctx,
+  u32 engine_id)
 {
if (ctx->pid) {
struct task_struct *task;
@@ -1369,6 +1372,7 @@ static void record_context(struct drm_i915_error_context 
*e,
e->bannable = i915_gem_context_is_bannable(ctx);
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
+   e->watchdog_threshold = ctx->__engine[engine_id].watchdog_threshold;
 }
 
 static void request_record_user_bo(struct i915_request *request,
@@ -1452,7 +1456,7 @@ static void gem_record_rings(struct i915_gpu_state *error)
 
ee->vm = ctx->ppgtt ? >ppgtt->vm : >vm;
 
-   record_context(>context, ctx);
+   record_context(>context, ctx, engine->id);
 
/* We need to copy these to an anonymous buffer
 * as the simplest method to avoid being overwritten
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index bd1821c73ecd..454707848248 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -122,6 +122,7 @@ struct i915_gpu_state {
int ban_score;
int active;
int guilty;
+   int watchdog_threshold;
bool bannable;
struct i915_sched_attr sched_attr;
} context;
-- 
2.17.1

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

[Intel-gfx] [PATCH 4/4] drm/i915: Enable PSR2 by default

2019-02-13 Thread José Roberto de Souza
The support for PSR2 was polished, IGT tests for PSR2 was added and
it was tested performing regular user workloads like browsing,
editing documents and compiling Linux, so it is time to enable it by
default and enjoy even more power-savings.

Cc: Rodrigo Vivi 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---

We can hold this patch a little longer, I'm mainly sending it to
show that 'drm/i915: Disable PSR2 while getting pipe CRC' fixed
the CRC tests when PSR2 is enabled.

 drivers/gpu/drm/i915/intel_psr.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 7b12b888061c..3d8a050407f6 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -80,9 +80,6 @@ static bool intel_psr2_enabled(struct drm_i915_private 
*dev_priv,
case I915_PSR_DEBUG_DISABLE:
case I915_PSR_DEBUG_FORCE_PSR1:
return false;
-   case I915_PSR_DEBUG_DEFAULT:
-   if (i915_modparams.enable_psr <= 0)
-   return false;
default:
return crtc_state->has_psr2;
}
-- 
2.20.1

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

[Intel-gfx] [PATCH 2/4] drm/i915: Disable PSR2 while getting pipe CRC

2019-02-13 Thread José Roberto de Souza
As stated in CRC_CTL spec, after PSR entry state CRC will not be
calculated anymore what is not a problem as IGT tests do some screen
change and then request the pipe CRC right after the change so PSR
will go to idle state and only will entry again after at least 6
idles frames.

But for PSR2 it is more problematic as any change to the screen could
trigger a selective/partial update causing the CRC value not to be
calculated over the full frame.

So here it disables PSR2 and keep it disabled while user is
requesting pipe CRC.

BSpec: 7536

Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 10 ++
 drivers/gpu/drm/i915/intel_psr.c  | 23 +++
 4 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 17fe942eaafa..609e9c5bd453 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -520,6 +520,7 @@ struct i915_psr {
bool sink_not_reliable;
bool irq_aux_error;
u16 su_x_granularity;
+   bool pipe_crc_enabled;
 };
 
 enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3398b28c053b..40ce7a600585 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2103,6 +2103,7 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp);
 int intel_psr_wait_for_idle(const struct intel_crtc_state *new_crtc_state,
u32 *out_value);
 bool intel_psr_enabled(struct intel_dp *intel_dp);
+void intel_psr_crc_prepare_or_finish(struct drm_i915_private *dev_priv, enum 
pipe pipe, bool prepare);
 
 /* intel_quirks.c */
 void intel_init_quirks(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index a8554dc4f196..5d8772399f60 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -583,6 +583,14 @@ int intel_crtc_verify_crc_source(struct drm_crtc *crtc, 
const char *source_name,
return -EINVAL;
 }
 
+static inline void intel_crtc_crc_prepare_or_finish(struct drm_crtc *crtc, 
bool prepare)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+   intel_psr_crc_prepare_or_finish(dev_priv, intel_crtc->pipe, prepare);
+}
+
 int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
@@ -609,6 +617,8 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc, const 
char *source_name)
if (ret != 0)
goto out;
 
+   intel_crtc_crc_prepare_or_finish(crtc, source != 
INTEL_PIPE_CRC_SOURCE_NONE);
+
pipe_crc->source = source;
I915_WRITE(PIPE_CRC_CTL(crtc->index), val);
POSTING_READ(PIPE_CRC_CTL(crtc->index));
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 08967836b48e..9c93138988aa 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -577,6 +577,9 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
+   if (dev_priv->psr.pipe_crc_enabled)
+   return false;
+
return true;
 }
 
@@ -1291,3 +1294,23 @@ bool intel_psr_enabled(struct intel_dp *intel_dp)
 
return ret;
 }
+
+void intel_psr_crc_prepare_or_finish(struct drm_i915_private *dev_priv, enum 
pipe pipe, bool prepare)
+{
+   bool fastset = false;
+
+   if (!CAN_PSR(dev_priv))
+   return;
+
+   mutex_lock(_priv->psr.lock);
+
+   if (dev_priv->psr.pipe == pipe) {
+   dev_priv->psr.pipe_crc_enabled = prepare;
+   fastset = !prepare || dev_priv->psr.psr2_enabled;
+   }
+
+   mutex_unlock(_priv->psr.lock);
+
+   if (fastset)
+   intel_psr_fastset_force(dev_priv);
+}
-- 
2.20.1

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

[Intel-gfx] [PATCH 3/4] drm/i915/psr: Remove PSR2 FIXME

2019-02-13 Thread José Roberto de Souza
Now we are checking sink capabilities when probing PSR DPCD register
and then dynamically checking in if new state is compatible with PSR
in, so this FIXME can be dropped.

Reviewed-by: Dhinakaran Pandiyan 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 9c93138988aa..7b12b888061c 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -532,11 +532,6 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
int crtc_vdisplay = crtc_state->base.adjusted_mode.crtc_vdisplay;
int psr_max_h = 0, psr_max_v = 0;
 
-   /*
-* FIXME psr2_support is messed up. It's both computed
-* dynamically during PSR enable, and extracted from sink
-* caps during eDP detection.
-*/
if (!dev_priv->psr.sink_psr2_support)
return false;
 
-- 
2.20.1

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

[Intel-gfx] [PATCH 1/4] drm/i915/psr: Only lookup for enabled CRTCs when forcing a fastset

2019-02-13 Thread José Roberto de Souza
Forcing a specific CRTC to the eDP connector was causing the
intel_psr_fastset_force() to mark mode_chaged in the wrong and
disabled CRTC causing no update in the PSR state.

Looks like our internal state track do not clear output_types and
has_psr in the disabled CRTCs, not sure if this is the expected
behavior or not but in the mean time this fix the issue.

Cc: Maarten Lankhorst 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 75c1a5deebf5..08967836b48e 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -986,7 +986,8 @@ static int intel_psr_fastset_force(struct drm_i915_private 
*dev_priv)
 
intel_crtc_state = to_intel_crtc_state(crtc_state);
 
-   if (intel_crtc_has_type(intel_crtc_state, INTEL_OUTPUT_EDP) &&
+   if (crtc_state->enable &&
+   intel_crtc_has_type(intel_crtc_state, INTEL_OUTPUT_EDP) &&
intel_crtc_state->has_psr) {
/* Mark mode as changed to trigger a pipe->update() */
crtc_state->mode_changed = true;
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH v5 0/3] Support 64 bpp half float formats

2019-02-13 Thread Strasser, Kevin
Maarten Lankhorst wrote:
> Op 13-02-2019 om 16:53 schreef Ville Syrjälä:
> > On Fri, Feb 08, 2019 at 01:49:40PM -0800, Kevin Strasser wrote:
> >> This series defines new formats and adds implementation to the i915 driver.
> >> Since posting v1 I have removed the pixel normalize property, as it's not
> >> needed
> >> for basic functionality. Also, I have been working on adding support to
> >> userspace, but we can't land any patches until drm_fourcc.h has been 
> >> updated
> >> here.
> >>
> >> I have submitted a series to Mesa to make use of the RGBA ordered formats:
> >>   https://patchwork.freedesktop.org/series/54759/
> >>
> >> My igt branch is reworked to drop usage of pixel normalize and includes use
> >> of f16c intrinsics to speed up conversion:
> >>   https://gitlab.freedesktop.org/strassek/igt-gpu-tools/commits/fp16
> > Was that posted to the ml? I can't seem to find it.
> >
> > Anyways, a quick look at the web thing tells me this predates
> > Maarten's cairo float stuff. I believe that has now landed so you
> > should probably switch to using that instead of rendering at 8bpc.
>
> Yes, it's now in upstream igt. :)
>
> RGB96F is just a float[3] = { r, g, b }; RGBA128F is the same with the alpha
> channel at the end,
>
> should be possible to convert to half float with the right changes to the
> conversion function.

I've updated my branch to use the new float formats. Here is a link to the 
relevant commit:
https://gitlab.freedesktop.org/strassek/igt-gpu-tools/commit/11d14a37859e9dfd43755feb631e4b530d666392

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

Re: [Intel-gfx] [PATCH 4/6] drm/i915/psr: Remove PSR2 FIXME

2019-02-13 Thread Dhinakaran Pandiyan
On Thu, 2019-02-07 at 14:24 -0800, José Roberto de Souza wrote:
> Now we are checking sink capabilities when probing PSR DPCD register
> and then dynamically checking in if new state is compatible with PSR
> in, so this FIXME can be dropped.

Right, this was fixed a while ago.

Reviewed-by: Dhinakaran Pandiyan 
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 75c1a5deebf5..8bed73914876 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -532,11 +532,6 @@ static bool intel_psr2_config_valid(struct
> intel_dp *intel_dp,
>   int crtc_vdisplay = crtc_state-
> >base.adjusted_mode.crtc_vdisplay;
>   int psr_max_h = 0, psr_max_v = 0;
>  
> - /*
> -  * FIXME psr2_support is messed up. It's both computed
> -  * dynamically during PSR enable, and extracted from sink
> -  * caps during eDP detection.
> -  */
>   if (!dev_priv->psr.sink_psr2_support)
>   return false;
>  

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

[Intel-gfx] [PATCH] drm/i915: Only try to stop engines after a failed reset

2019-02-13 Thread Chris Wilson
Currently we try to stop the engine by programming the ring registers to
be disabled before we perform the reset. Sometimes, we see the context
image also have invalid ring registers, which one presumes may be
actually caused by us doing so. Lets risk not doing programming the
ring to zero on the first attempt to avoid preserving that corruption
into the context image, leaving the w/a in place for subsequent
reset attempts.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_reset.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reset.c 
b/drivers/gpu/drm/i915/i915_reset.c
index 12e74decd7a2..dfced5be1042 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -119,8 +119,10 @@ static void gen3_stop_engine(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
const u32 base = engine->mmio_base;
 
+   GEM_TRACE("%s\n", engine->name);
+
if (intel_engine_stop_cs(engine))
-   DRM_DEBUG_DRIVER("%s: timed out on STOP_RING\n", engine->name);
+   GEM_TRACE("%s: timed out on STOP_RING\n", engine->name);
 
I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
@@ -133,9 +135,9 @@ static void gen3_stop_engine(struct intel_engine_cs *engine)
I915_WRITE_FW(RING_CTL(base), 0);
 
/* Check acts as a post */
-   if (I915_READ_FW(RING_HEAD(base)) != 0)
-   DRM_DEBUG_DRIVER("%s: ring head not parked\n",
-engine->name);
+   if (I915_READ_FW(RING_HEAD(base)))
+   GEM_TRACE("%s: ring head [%x] not parked\n",
+ engine->name, I915_READ_FW(RING_HEAD(base)));
 }
 
 static void i915_stop_engines(struct drm_i915_private *i915,
@@ -579,7 +581,8 @@ int intel_gpu_reset(struct drm_i915_private *i915, unsigned 
int engine_mask)
 *
 * FIXME: Wa for more modern gens needs to be validated
 */
-   i915_stop_engines(i915, engine_mask);
+   if (retry)
+   i915_stop_engines(i915, engine_mask);
 
GEM_TRACE("engine_mask=%x\n", engine_mask);
preempt_disable();
-- 
2.20.1

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

[Intel-gfx] [PATCH] drm/i915/selftests: Always use an active engine while resetting

2019-02-13 Thread Chris Wilson
Currently, we only try to reset a live engine for checking the whitelist
retention across a per-engine reset. For safety, it appears we need to
prime the system with a hanging spinner before performing a full-device
reset. (Figuring out the root cause behind the instability with handling
a reset during a no-op request is a challenge for another test, the
whitelist test has its own purpose.)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109626
Signed-off-by: Chris Wilson 
---
 .../drm/i915/selftests/intel_workarounds.c| 27 ++-
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c 
b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
index b15c4f26c593..d6bb2005024d 100644
--- a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
@@ -237,14 +237,8 @@ switch_to_scratch_context(struct intel_engine_cs *engine,
return PTR_ERR(ctx);
 
rq = ERR_PTR(-ENODEV);
-   with_intel_runtime_pm(engine->i915, wakeref) {
-   if (spin)
-   rq = igt_spinner_create_request(spin,
-   ctx, engine,
-   MI_NOOP);
-   else
-   rq = i915_request_alloc(engine, ctx);
-   }
+   with_intel_runtime_pm(engine->i915, wakeref)
+   rq = igt_spinner_create_request(spin, ctx, engine, MI_NOOP);
 
kernel_context_close(ctx);
 
@@ -273,7 +267,6 @@ static int check_whitelist_across_reset(struct 
intel_engine_cs *engine,
const char *name)
 {
struct drm_i915_private *i915 = engine->i915;
-   bool want_spin = reset == do_engine_reset;
struct i915_gem_context *ctx;
struct igt_spinner spin;
intel_wakeref_t wakeref;
@@ -282,11 +275,9 @@ static int check_whitelist_across_reset(struct 
intel_engine_cs *engine,
pr_info("Checking %d whitelisted registers (RING_NONPRIV) [%s]\n",
engine->whitelist.count, name);
 
-   if (want_spin) {
-   err = igt_spinner_init(, i915);
-   if (err)
-   return err;
-   }
+   err = igt_spinner_init(, i915);
+   if (err)
+   return err;
 
ctx = kernel_context(i915);
if (IS_ERR(ctx))
@@ -298,17 +289,15 @@ static int check_whitelist_across_reset(struct 
intel_engine_cs *engine,
goto out;
}
 
-   err = switch_to_scratch_context(engine, want_spin ?  : NULL);
+   err = switch_to_scratch_context(engine, );
if (err)
goto out;
 
with_intel_runtime_pm(i915, wakeref)
err = reset(engine);
 
-   if (want_spin) {
-   igt_spinner_end();
-   igt_spinner_fini();
-   }
+   igt_spinner_end();
+   igt_spinner_fini();
 
if (err) {
pr_err("%s reset failed\n", name);
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH] snd/hda, drm/i915: Track the display_power_status using a cookie

2019-02-13 Thread Chris Wilson
Quoting Takashi Iwai (2019-02-13 21:48:50)
> On Wed, 13 Feb 2019 16:21:09 +0100,
> Chris Wilson wrote:
> > 
> > drm/i915 is tracking all wakeref owners with a cookie in order to
> > identify leaks. To that end, each rpm acquisition ops->get_power is
> > assigned a cookie which should be passed to ops->put_power to signify
> > its release (and removal from the list of wakeref owners). As snd/hda is
> > already using a bool to track current status of display_power extending
> > that to an unsigned long to hold the boolean cookie is a trivial
> > extension, and will quell all doubt that snd/hda is the cause of the
> > device runtime pm leaks.
> > 
> > v2: Keep using the power abstraction for local wakeref tracking.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Takashi Iwai 
> > Cc: Jani Nikula 
> 
> Feel free to take my ack:
>   Reviewed-by: Takashi Iwai 
> 
> Or let me know if you guys want to apply this through sound tree for
> 5.1 merge.

It's a debug featurette so it's not urgent in any way; it's just for
identifying bugs in CI. I think we're good to go in through
drm-intel-next-queued for 5.2
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] snd/hda, drm/i915: Track the display_power_status using a cookie

2019-02-13 Thread Takashi Iwai
On Wed, 13 Feb 2019 16:21:09 +0100,
Chris Wilson wrote:
> 
> drm/i915 is tracking all wakeref owners with a cookie in order to
> identify leaks. To that end, each rpm acquisition ops->get_power is
> assigned a cookie which should be passed to ops->put_power to signify
> its release (and removal from the list of wakeref owners). As snd/hda is
> already using a bool to track current status of display_power extending
> that to an unsigned long to hold the boolean cookie is a trivial
> extension, and will quell all doubt that snd/hda is the cause of the
> device runtime pm leaks.
> 
> v2: Keep using the power abstraction for local wakeref tracking.
> 
> Signed-off-by: Chris Wilson 
> Cc: Takashi Iwai 
> Cc: Jani Nikula 

Feel free to take my ack:
  Reviewed-by: Takashi Iwai 

Or let me know if you guys want to apply this through sound tree for
5.1 merge.


thanks,

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Implement new w/a for underruns with wm1+ disabled

2019-02-13 Thread Clinton Taylor
Tested with dual CRTC configuration shows many FIFO underruns even with 
this code. Single CRTC has not produced a FIFO underrun yet.


[ 7037.510737] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU 
pipe A FIFO underrun
[ 7040.769741] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU 
pipe A FIFO underrun
[ 7042.029447] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU 
pipe B FIFO underrun
[ 7056.579801] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU 
pipe A FIFO underrun
[ 7057.105212] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU 
pipe B FIFO underrun
[ 7063.600646] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU 
pipe A FIFO underrun
[ 7072.373733] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU 
pipe B FIFO underrun


-Clint



On 2/13/19 12:04 PM, Clinton Taylor wrote:

Reviewed-by: Clint Taylor 

-Clint

On 2/13/19 8:54 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

The new workaround from the hw team involves programming the
leaving WM1 still disabled but programming the blocks value
identically to WM0, and we also need to set the "ignore
lines watermark" bit for WM1.

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

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

index 7dd2ab0ca21b..4c0e43caa5cd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4466,6 +4466,13 @@ skl_allocate_pipe_ddb(struct intel_crtc_state 
*cstate,

  for_each_plane_id_on_crtc(intel_crtc, plane_id) {
  wm = >wm.skl.optimal.planes[plane_id];
  memset(>wm[level], 0, sizeof(wm->wm[level]));
+
+    /* W/A for underruns with WM1+ disabled */
+    if (IS_ICELAKE(dev_priv) &&
+    level == 1 && wm->wm[0].plane_en) {
+    wm->wm[level].plane_res_b = wm->wm[0].plane_res_b;
+    wm->wm[level].ignore_lines = true;
+    }
  }
  }

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

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Include "ignore lines" in skl+ wm state

2019-02-13 Thread Ville Syrjälä
On Wed, Feb 13, 2019 at 11:44:44AM -0800, Clinton Taylor wrote:
> 
> On 2/13/19 8:54 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > We'll need to poke at the "ignore lines" bit in the skl+
> > watermark registers for a w/a. Include that bit in the wm
> > state.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/i915_drv.h |  1 +
> >   drivers/gpu/drm/i915/i915_reg.h |  1 +
> >   drivers/gpu/drm/i915/intel_pm.c | 44 +
> >   3 files changed, 30 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 17fe942eaafa..5c8d0489a1cd 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1126,6 +1126,7 @@ struct skl_wm_level {
> > u16 plane_res_b;
> > u8 plane_res_l;
> > bool plane_en;
> > +   bool ignore_lines;
> >   };
> >   
> >   /* Stores plane specific WM parameters */
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index f3f0b53c9e0e..7b3c41e9771f 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6032,6 +6032,7 @@ enum {
> >   #define _CUR_WM_TRANS_A_0 0x70168
> >   #define _CUR_WM_TRANS_B_0 0x71168
> >   #define   PLANE_WM_EN (1 << 31)
> > +#define   PLANE_WM_IGNORE_LINES(1 << 30)
> >   #define   PLANE_WM_LINES_SHIFT14
> >   #define   PLANE_WM_LINES_MASK 0x1f
> >   #define   PLANE_WM_BLOCKS_MASK0x7ff /* skl+: 10 bits, icl+ 11 bits */
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index ea492fff6bf8..7dd2ab0ca21b 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5056,11 +5056,12 @@ static void skl_write_wm_level(struct 
> > drm_i915_private *dev_priv,
> >   {
> > u32 val = 0;
> >   
> > -   if (level->plane_en) {
> > +   if (level->plane_en)
> > val |= PLANE_WM_EN;
> > -   val |= level->plane_res_b;
> > -   val |= level->plane_res_l << PLANE_WM_LINES_SHIFT;
> > -   }
> > +   if (level->ignore_lines)
> > +   val |= PLANE_WM_IGNORE_LINES;
> > +   val |= level->plane_res_b;
> > +   val |= level->plane_res_l << PLANE_WM_LINES_SHIFT;
> 
> Is there a reason to program IGNORE_LINES, plane_res_b, and plane_res_l 
> even when PLANE_WM_EN is not set? This is a change to functionality not 
> described in the commit message.

Everything will be zero when the wm is disabled, except in
this special case for wm1. Just programming everything always
makes the code less messy.

> 
> Since the WM is not enabled anyway:
> 
> Reviewed-by: Clint Taylor 
> 
> -Clint
> 
> 
> >   
> > I915_WRITE_FW(reg, val);
> >   }
> > @@ -5126,6 +5127,7 @@ bool skl_wm_level_equals(const struct skl_wm_level 
> > *l1,
> >  const struct skl_wm_level *l2)
> >   {
> > return l1->plane_en == l2->plane_en &&
> > +   l1->ignore_lines == l2->ignore_lines &&
> > l1->plane_res_l == l2->plane_res_l &&
> > l1->plane_res_b == l2->plane_res_b;
> >   }
> > @@ -5334,19 +5336,28 @@ skl_print_wm_changes(struct intel_atomic_state 
> > *state)
> >   enast(new_wm->wm[6].plane_en), 
> > enast(new_wm->wm[7].plane_en),
> >   enast(new_wm->trans_wm.plane_en));
> >   
> > -   DRM_DEBUG_KMS("[PLANE:%d:%s]   lines 
> > %4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d"
> > - " -> 
> > %4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d\n",
> > +   DRM_DEBUG_KMS("[PLANE:%d:%s]   lines 
> > %c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d"
> > + " -> 
> > %c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d\n",
> >   plane->base.base.id, plane->base.name,
> > - old_wm->wm[0].plane_res_l, 
> > old_wm->wm[1].plane_res_l,
> > - old_wm->wm[2].plane_res_l, 
> > old_wm->wm[3].plane_res_l,
> > - old_wm->wm[4].plane_res_l, 
> > old_wm->wm[5].plane_res_l,
> > - old_wm->wm[6].plane_res_l, 
> > old_wm->wm[7].plane_res_l,
> > - old_wm->trans_wm.plane_res_l,
> > - new_wm->wm[0].plane_res_l, 
> > new_wm->wm[1].plane_res_l,
> > - new_wm->wm[2].plane_res_l, 
> > new_wm->wm[3].plane_res_l,
> > - new_wm->wm[4].plane_res_l, 
> > new_wm->wm[5].plane_res_l,
> > - new_wm->wm[6].plane_res_l, 
> > new_wm->wm[7].plane_res_l,
> > - new_wm->trans_wm.plane_res_l);
> > + enast(old_wm->wm[0].ignore_lines), 
> > old_wm->wm[0].plane_res_l,
> > + 

Re: [Intel-gfx] [PATCH 3/3] drm/dsc: Change infoframe_pack to payload_pack

2019-02-13 Thread Manasi Navare
On Wed, Feb 13, 2019 at 09:45:36AM -0500, David Francis wrote:
> The function drm_dsc_pps_infoframe_pack only
> packed the payload portion of the infoframe.
> Change the input struct to the PPS payload
> to clarify the function's purpose and allow
> for drivers with their own handling of sdp.
> (e.g. drivers with their own struct for
> all SDP transactions)
>

I think if we are just sending pps_payload as an argument to this function
to pack payload, it also makes sense to just send pps_header as an input
to drm_dsc_dp_pps_header_init() to follow the consistency there.
So with that the caller will have to call the header_init first , initialize the
sdp header and then call the _payload_pack to pack the payload bytes.
And then send the entire infoframe to the sink.

Could you please also make that change in this patch?

Regards
Manasi
 
> Signed-off-by: David Francis 
> ---
>  drivers/gpu/drm/drm_dsc.c | 86 +++
>  drivers/gpu/drm/i915/intel_vdsc.c |  2 +-
>  include/drm/drm_dsc.h |  2 +-
>  3 files changed, 45 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 9e675dd39a44..4ada4d4f59ac 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -38,42 +38,42 @@ void drm_dsc_dp_pps_header_init(struct 
> drm_dsc_pps_infoframe *pps_sdp)
>  EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
>  
>  /**
> - * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
> + * drm_dsc_pps_payload_pack() - Populates the DSC PPS payload
>   * using the DSC configuration parameters in the order expected
>   * by the DSC Display Sink device. For the DSC, the sink device
>   * expects the PPS payload in the big endian format for the fields
>   * that span more than 1 byte.
>   *
> - * @pps_sdp:
> - * Secondary data packet for DSC Picture Parameter Set
> + * @pps_payload:
> + * DSC Picture Parameter Set
>   * @dsc_cfg:
>   * DSC Configuration data filled by driver
>   */
> -void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
> +void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set 
> *pps_payload,
>   const struct drm_dsc_config *dsc_cfg)
>  {
>   int i;
>  
>   /* Protect against someone accidently changing struct size */
> - BUILD_BUG_ON(sizeof(pps_sdp->pps_payload) !=
> + BUILD_BUG_ON(sizeof(*pps_payload) !=
>DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
>  
> - memset(_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
> + memset(pps_payload, 0, sizeof(*pps_payload));
>  
>   /* PPS 0 */
> - pps_sdp->pps_payload.dsc_version =
> + pps_payload->dsc_version =
>   dsc_cfg->dsc_version_minor |
>   dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
>  
>   /* PPS 1, 2 is 0 */
>  
>   /* PPS 3 */
> - pps_sdp->pps_payload.pps_3 =
> + pps_payload->pps_3 =
>   dsc_cfg->line_buf_depth |
>   dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
>  
>   /* PPS 4 */
> - pps_sdp->pps_payload.pps_4 =
> + pps_payload->pps_4 =
>   ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT) |
>   dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> @@ -82,7 +82,7 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
>  
>   /* PPS 5 */
> - pps_sdp->pps_payload.bits_per_pixel_low =
> + pps_payload->bits_per_pixel_low =
>   (dsc_cfg->bits_per_pixel & DSC_PPS_LSB_MASK);
>  
>   /*
> @@ -93,103 +93,103 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>*/
>  
>   /* PPS 6, 7 */
> - pps_sdp->pps_payload.pic_height = cpu_to_be16(dsc_cfg->pic_height);
> + pps_payload->pic_height = cpu_to_be16(dsc_cfg->pic_height);
>  
>   /* PPS 8, 9 */
> - pps_sdp->pps_payload.pic_width = cpu_to_be16(dsc_cfg->pic_width);
> + pps_payload->pic_width = cpu_to_be16(dsc_cfg->pic_width);
>  
>   /* PPS 10, 11 */
> - pps_sdp->pps_payload.slice_height = cpu_to_be16(dsc_cfg->slice_height);
> + pps_payload->slice_height = cpu_to_be16(dsc_cfg->slice_height);
>  
>   /* PPS 12, 13 */
> - pps_sdp->pps_payload.slice_width = cpu_to_be16(dsc_cfg->slice_width);
> + pps_payload->slice_width = cpu_to_be16(dsc_cfg->slice_width);
>  
>   /* PPS 14, 15 */
> - pps_sdp->pps_payload.chunk_size = 
> cpu_to_be16(dsc_cfg->slice_chunk_size);
> + pps_payload->chunk_size = cpu_to_be16(dsc_cfg->slice_chunk_size);
>  
>   /* PPS 16 */
> - pps_sdp->pps_payload.initial_xmit_delay_high =
> + pps_payload->initial_xmit_delay_high =
>   ((dsc_cfg->initial_xmit_delay &
> DSC_PPS_INIT_XMIT_DELAY_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT);
>  
>   /* PPS 17 */
> - 

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Implement new w/a for underruns with wm1+ disabled

2019-02-13 Thread Clinton Taylor

Reviewed-by: Clint Taylor 

-Clint

On 2/13/19 8:54 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

The new workaround from the hw team involves programming the
leaving WM1 still disabled but programming the blocks value
identically to WM0, and we also need to set the "ignore
lines watermark" bit for WM1.

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7dd2ab0ca21b..4c0e43caa5cd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4466,6 +4466,13 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
for_each_plane_id_on_crtc(intel_crtc, plane_id) {
wm = >wm.skl.optimal.planes[plane_id];
memset(>wm[level], 0, sizeof(wm->wm[level]));
+
+   /* W/A for underruns with WM1+ disabled */
+   if (IS_ICELAKE(dev_priv) &&
+   level == 1 && wm->wm[0].plane_en) {
+   wm->wm[level].plane_res_b = 
wm->wm[0].plane_res_b;
+   wm->wm[level].ignore_lines = true;
+   }
}
}
  

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Include "ignore lines" in skl+ wm state

2019-02-13 Thread Clinton Taylor


On 2/13/19 8:54 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

We'll need to poke at the "ignore lines" bit in the skl+
watermark registers for a w/a. Include that bit in the wm
state.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/i915_drv.h |  1 +
  drivers/gpu/drm/i915/i915_reg.h |  1 +
  drivers/gpu/drm/i915/intel_pm.c | 44 +
  3 files changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 17fe942eaafa..5c8d0489a1cd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1126,6 +1126,7 @@ struct skl_wm_level {
u16 plane_res_b;
u8 plane_res_l;
bool plane_en;
+   bool ignore_lines;
  };
  
  /* Stores plane specific WM parameters */

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f3f0b53c9e0e..7b3c41e9771f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6032,6 +6032,7 @@ enum {
  #define _CUR_WM_TRANS_A_0 0x70168
  #define _CUR_WM_TRANS_B_0 0x71168
  #define   PLANE_WM_EN (1 << 31)
+#define   PLANE_WM_IGNORE_LINES(1 << 30)
  #define   PLANE_WM_LINES_SHIFT14
  #define   PLANE_WM_LINES_MASK 0x1f
  #define   PLANE_WM_BLOCKS_MASK0x7ff /* skl+: 10 bits, icl+ 11 bits */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ea492fff6bf8..7dd2ab0ca21b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5056,11 +5056,12 @@ static void skl_write_wm_level(struct drm_i915_private 
*dev_priv,
  {
u32 val = 0;
  
-	if (level->plane_en) {

+   if (level->plane_en)
val |= PLANE_WM_EN;
-   val |= level->plane_res_b;
-   val |= level->plane_res_l << PLANE_WM_LINES_SHIFT;
-   }
+   if (level->ignore_lines)
+   val |= PLANE_WM_IGNORE_LINES;
+   val |= level->plane_res_b;
+   val |= level->plane_res_l << PLANE_WM_LINES_SHIFT;


Is there a reason to program IGNORE_LINES, plane_res_b, and plane_res_l 
even when PLANE_WM_EN is not set? This is a change to functionality not 
described in the commit message.


Since the WM is not enabled anyway:

Reviewed-by: Clint Taylor 

-Clint


  
  	I915_WRITE_FW(reg, val);

  }
@@ -5126,6 +5127,7 @@ bool skl_wm_level_equals(const struct skl_wm_level *l1,
 const struct skl_wm_level *l2)
  {
return l1->plane_en == l2->plane_en &&
+   l1->ignore_lines == l2->ignore_lines &&
l1->plane_res_l == l2->plane_res_l &&
l1->plane_res_b == l2->plane_res_b;
  }
@@ -5334,19 +5336,28 @@ skl_print_wm_changes(struct intel_atomic_state *state)
  enast(new_wm->wm[6].plane_en), 
enast(new_wm->wm[7].plane_en),
  enast(new_wm->trans_wm.plane_en));
  
-			DRM_DEBUG_KMS("[PLANE:%d:%s]   lines %4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d"

- " -> 
%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d\n",
+   DRM_DEBUG_KMS("[PLANE:%d:%s]   lines 
%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d"
+ " -> 
%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d\n",
  plane->base.base.id, plane->base.name,
- old_wm->wm[0].plane_res_l, 
old_wm->wm[1].plane_res_l,
- old_wm->wm[2].plane_res_l, 
old_wm->wm[3].plane_res_l,
- old_wm->wm[4].plane_res_l, 
old_wm->wm[5].plane_res_l,
- old_wm->wm[6].plane_res_l, 
old_wm->wm[7].plane_res_l,
- old_wm->trans_wm.plane_res_l,
- new_wm->wm[0].plane_res_l, 
new_wm->wm[1].plane_res_l,
- new_wm->wm[2].plane_res_l, 
new_wm->wm[3].plane_res_l,
- new_wm->wm[4].plane_res_l, 
new_wm->wm[5].plane_res_l,
- new_wm->wm[6].plane_res_l, 
new_wm->wm[7].plane_res_l,
- new_wm->trans_wm.plane_res_l);
+ enast(old_wm->wm[0].ignore_lines), 
old_wm->wm[0].plane_res_l,
+ enast(old_wm->wm[1].ignore_lines), 
old_wm->wm[1].plane_res_l,
+ enast(old_wm->wm[2].ignore_lines), 
old_wm->wm[2].plane_res_l,
+ enast(old_wm->wm[3].ignore_lines), 
old_wm->wm[3].plane_res_l,
+ enast(old_wm->wm[4].ignore_lines), 
old_wm->wm[4].plane_res_l,
+ enast(old_wm->wm[5].ignore_lines), 
old_wm->wm[5].plane_res_l,
+ enast(old_wm->wm[6].ignore_lines), 

Re: [Intel-gfx] [PATCH 1/3] Revert "drm/i915: W/A for underruns with WM1+ disabled on icl"

2019-02-13 Thread Clinton Taylor

Reviewed-by: Clint Taylor 

-Clint


On 2/13/19 8:54 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

This reverts commit bf002c100740f4ae01d0d86b44f65a712ee14031.

The hw team has come up with a better workaround. So
let's get rid of this one.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/i915_reg.h  | 1 -
  drivers/gpu/drm/i915/intel_display.c | 6 --
  2 files changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0df8c6e76da7..f3f0b53c9e0e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7653,7 +7653,6 @@ enum {
  #define _PIPEB_CHICKEN0x71038
  #define _PIPEC_CHICKEN0x72038
  #define  PER_PIXEL_ALPHA_BYPASS_EN(1 << 7)
-#define  PM_FILL_MAINTAIN_DBUF_FULLNESS(1 << 0)
  #define PIPE_CHICKEN(pipe)_MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
   _PIPEB_CHICKEN)
  
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

index 0a8913b2059e..73a107b6eb9a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3971,12 +3971,6 @@ static void icl_set_pipe_chicken(struct intel_crtc *crtc)
 */
tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
  
-	/*

-* W/A for underruns with linear/X-tiled with
-* WM1+ disabled.
-*/
-   tmp |= PM_FILL_MAINTAIN_DBUF_FULLNESS;
-
I915_WRITE(PIPE_CHICKEN(pipe), tmp);
  }
  

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

Re: [Intel-gfx] [PATCH 2/3] drm/dsc: Add native 420 and 422 support to compute_rc_params

2019-02-13 Thread Manasi Navare
On Wed, Feb 13, 2019 at 09:45:35AM -0500, David Francis wrote:
> Native 420 and 422 transfer modes are new in DSC1.2
> 
> In these modes, each two pixels of a slice are treated as one
> pixel, so the slice width is half as large (round down) for
> the purposes of calucating the groups per line and chunk size
> in bytes
> 
> In native 422 mode, each pixel has four components, so the
> mux component of a group is larger by one additional mux word
> and one additional component
> 
> Now that there is native 422 support, the configuration option
> previously called enable422 is renamed to simple_422 to avoid
> confusion
> 
> Signed-off-by: David Francis 

This looks good and verified that the DSC 1.2 spec actually renames it
as simple_422.

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/drm_dsc.c | 31 +++
>  drivers/gpu/drm/i915/intel_vdsc.c |  4 ++--
>  include/drm/drm_dsc.h |  4 ++--
>  3 files changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 4b0e3c9c3ff8..9e675dd39a44 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -77,7 +77,7 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT) |
>   dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> - dsc_cfg->enable422 << DSC_PPS_SIMPLE422_SHIFT |
> + dsc_cfg->simple_422 << DSC_PPS_SIMPLE422_SHIFT |
>   dsc_cfg->convert_rgb << DSC_PPS_CONVERT_RGB_SHIFT |
>   dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
>  
> @@ -246,19 +246,34 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
> *vdsc_cfg)
>   unsigned long final_scale = 0;
>   unsigned long rbs_min = 0;
>  
> - /* Number of groups used to code each line of a slice */
> - groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> -DSC_RC_PIXELS_PER_GROUP);
> + if (vdsc_cfg->native_420 || vdsc_cfg->native_422) {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width / 2,
> +DSC_RC_PIXELS_PER_GROUP);
>  
> - /* chunksize in Bytes */
> - vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> -   vdsc_cfg->bits_per_pixel,
> -   (8 * 16));
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> / 2 *
> +   
> vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> + } else {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> *
> +   
> vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> + }
>  
>   if (vdsc_cfg->convert_rgb)
>   num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> (4 * vdsc_cfg->bits_per_component + 4)
> - 2);
> + else if (vdsc_cfg->native_422)
> + num_extra_mux_bits = 4 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 3 * (4 * vdsc_cfg->bits_per_component) - 2;
>   else
>   num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
>   (4 * vdsc_cfg->bits_per_component + 4) +
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index c76cec8bfb74..7702c5c8b3f2 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -369,7 +369,7 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
>   DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
>  
>   /* Gen 11 does not support YCbCr */
> - vdsc_cfg->enable422 = false;
> + vdsc_cfg->simple_422 = false;
>   /* Gen 11 does not support VBR */
>   vdsc_cfg->vbr_enable = false;
>   vdsc_cfg->block_pred_enable =
> @@ -496,7 +496,7 @@ static void intel_configure_pps_for_dsc_encoder(struct 
> intel_encoder *encoder,
>   pps_val |= DSC_BLOCK_PREDICTION;
>   if (vdsc_cfg->convert_rgb)
>   pps_val |= DSC_COLOR_SPACE_CONVERSION;
> - if (vdsc_cfg->enable422)
> + if (vdsc_cfg->simple_422)
>   

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move dsc rate params compute into drm

2019-02-13 Thread Manasi Navare
On Wed, Feb 13, 2019 at 09:45:34AM -0500, David Francis wrote:
> The function intel_compute_rc_parameters is part of the dsc spec
> and is not driver-specific. Other drm drivers might like to use
> it.  The function is not changed; just moved and renamed.
>

Yes this sounds fair since its DSC spec related and can move to drm_dsc.c.
As a part of this series or later you should also consider moving the
rc_parameters struct for input bpc/output BPP combinations to DRM since that
is also purely spec related.

With this change and compute_rc_params function in DRM, please add appropriate
description of the function as part of kernel documentation.

With the documentation change, you have my r-b.

Regards
Manasi
 
> Signed-off-by: David Francis 
> ---
>  drivers/gpu/drm/drm_dsc.c | 133 ++
>  drivers/gpu/drm/i915/intel_vdsc.c | 125 +---
>  include/drm/drm_dsc.h |   1 +
>  3 files changed, 135 insertions(+), 124 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index bc2b23adb072..4b0e3c9c3ff8 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -226,3 +227,135 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   /* PPS 94 - 127 are O */
>  }
>  EXPORT_SYMBOL(drm_dsc_pps_infoframe_pack);
> +
> +/**
> + * drm_dsc_compute_rc_parameters() - Write rate control
> + * parameters to the dsc configuration. Some configuration
> + * fields must be present beforehand.
> + *
> + * @dsc_cfg:
> + * DSC Configuration data partially filled by driver
> + */
> +int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
> +{
> + unsigned long groups_per_line = 0;
> + unsigned long groups_total = 0;
> + unsigned long num_extra_mux_bits = 0;
> + unsigned long slice_bits = 0;
> + unsigned long hrd_delay = 0;
> + unsigned long final_scale = 0;
> + unsigned long rbs_min = 0;
> +
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> +   vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> +
> + if (vdsc_cfg->convert_rgb)
> + num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> +   (4 * vdsc_cfg->bits_per_component + 4)
> +   - 2);
> + else
> + num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 2 * (4 * vdsc_cfg->bits_per_component) - 2;
> + /* Number of bits in one Slice */
> + slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
> +
> + while ((num_extra_mux_bits > 0) &&
> +((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
> + num_extra_mux_bits--;
> +
> + if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
> + vdsc_cfg->initial_scale_value = groups_per_line + 8;
> +
> + /* scale_decrement_interval calculation according to DSC spec 1.11 */
> + if (vdsc_cfg->initial_scale_value > 8)
> + vdsc_cfg->scale_decrement_interval = groups_per_line /
> + (vdsc_cfg->initial_scale_value - 8);
> + else
> + vdsc_cfg->scale_decrement_interval = 
> DSC_SCALE_DECREMENT_INTERVAL_MAX;
> +
> + vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
> + (vdsc_cfg->initial_xmit_delay *
> +  vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
> +
> + if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
> + DRM_DEBUG_KMS("FinalOfs < RcModelSze for this 
> InitialXmitDelay\n");
> + return -ERANGE;
> + }
> +
> + final_scale = (vdsc_cfg->rc_model_size * 8) /
> + (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
> + if (vdsc_cfg->slice_height > 1)
> + /*
> +  * NflBpgOffset is 16 bit value with 11 fractional bits
> +  * hence we multiply by 2^11 for preserving the
> +  * fractional part
> +  */
> + vdsc_cfg->nfl_bpg_offset = 
> DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
> + (vdsc_cfg->slice_height 
> - 1));
> + else
> + vdsc_cfg->nfl_bpg_offset = 0;
> +
> + /* 2^16 - 1 */
> + if (vdsc_cfg->nfl_bpg_offset > 65535) {
> + DRM_DEBUG_KMS("NflBpgOffset is too large for this slice 
> height\n");
> + return -ERANGE;
> + }
> +
> + /* Number of 

[Intel-gfx] [PATCH] drm/i915: Defer application of request banning to submission

2019-02-13 Thread Chris Wilson
As we currently do not check on submission whether the context is banned
in a timely manner it is possible for some requests to escape
cancellation after their parent context is banned. By moving the ban
into the request submission under the engine->timeline.lock, we
serialise it with the reset and setting of the context ban.

References: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on 
struct_mutex")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_request.c |  3 +++
 drivers/gpu/drm/i915/i915_reset.c   | 19 +--
 2 files changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 0acd6baa3c88..5ab4e1c01618 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -366,6 +366,9 @@ void __i915_request_submit(struct i915_request *request)
GEM_BUG_ON(!irqs_disabled());
lockdep_assert_held(>timeline.lock);
 
+   if (i915_gem_context_is_banned(request->gem_context))
+   i915_request_skip(request, -EIO);
+
GEM_BUG_ON(request->global_seqno);
 
seqno = next_global_seqno(>timeline);
diff --git a/drivers/gpu/drm/i915/i915_reset.c 
b/drivers/gpu/drm/i915/i915_reset.c
index 12e74decd7a2..7fa97ce19bfd 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -22,24 +22,15 @@ static void engine_skip_context(struct i915_request *rq)
 {
struct intel_engine_cs *engine = rq->engine;
struct i915_gem_context *hung_ctx = rq->gem_context;
-   struct i915_timeline *timeline = rq->timeline;
 
lockdep_assert_held(>timeline.lock);
-   GEM_BUG_ON(timeline == >timeline);
 
-   spin_lock(>lock);
-
-   if (i915_request_is_active(rq)) {
-   list_for_each_entry_continue(rq,
->timeline.requests, link)
-   if (rq->gem_context == hung_ctx)
-   i915_request_skip(rq, -EIO);
-   }
-
-   list_for_each_entry(rq, >requests, link)
-   i915_request_skip(rq, -EIO);
+   if (!i915_request_is_active(rq))
+   return;
 
-   spin_unlock(>lock);
+   list_for_each_entry_continue(rq, >timeline.requests, link)
+   if (rq->gem_context == hung_ctx)
+   i915_request_skip(rq, -EIO);
 }
 
 static void client_mark_guilty(struct drm_i915_file_private *file_priv,
-- 
2.20.1

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

[Intel-gfx] [PATCH] drm/i915: Defer application of request banning to submission

2019-02-13 Thread Chris Wilson
As we currently do not check on submission whether the context is banned
in a timely manner it is possible for some requests to escape
cancellation after their parent context is banned. By moving the ban
into the request submission under the engine->timeline.lock, we
serialise it with the reset and setting of the context ban.

References: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on 
struct_mutex")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_request.c |  3 +++
 drivers/gpu/drm/i915/i915_reset.c   | 19 ---
 2 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 0acd6baa3c88..5ab4e1c01618 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -366,6 +366,9 @@ void __i915_request_submit(struct i915_request *request)
GEM_BUG_ON(!irqs_disabled());
lockdep_assert_held(>timeline.lock);
 
+   if (i915_gem_context_is_banned(request->gem_context))
+   i915_request_skip(request, -EIO);
+
GEM_BUG_ON(request->global_seqno);
 
seqno = next_global_seqno(>timeline);
diff --git a/drivers/gpu/drm/i915/i915_reset.c 
b/drivers/gpu/drm/i915/i915_reset.c
index 12e74decd7a2..c69b520ce1cf 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -22,24 +22,13 @@ static void engine_skip_context(struct i915_request *rq)
 {
struct intel_engine_cs *engine = rq->engine;
struct i915_gem_context *hung_ctx = rq->gem_context;
-   struct i915_timeline *timeline = rq->timeline;
 
lockdep_assert_held(>timeline.lock);
-   GEM_BUG_ON(timeline == >timeline);
+   GEM_BUG_ON(!i915_request_is_active(rq));
 
-   spin_lock(>lock);
-
-   if (i915_request_is_active(rq)) {
-   list_for_each_entry_continue(rq,
->timeline.requests, link)
-   if (rq->gem_context == hung_ctx)
-   i915_request_skip(rq, -EIO);
-   }
-
-   list_for_each_entry(rq, >requests, link)
-   i915_request_skip(rq, -EIO);
-
-   spin_unlock(>lock);
+   list_for_each_entry_continue(rq, >timeline.requests, link)
+   if (rq->gem_context == hung_ctx)
+   i915_request_skip(rq, -EIO);
 }
 
 static void client_mark_guilty(struct drm_i915_file_private *file_priv,
-- 
2.20.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 snd/hda, drm/i915: Track the display_power_status using a cookie

2019-02-13 Thread Patchwork
== Series Details ==

Series: snd/hda, drm/i915: Track the display_power_status using a cookie
URL   : https://patchwork.freedesktop.org/series/56615/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5598_full -> Patchwork_12213_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12213_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12213_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_12213_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_color@pipe-a-ctm-max:
- shard-glk:  NOTRUN -> FAIL

  
 Warnings 

  * igt@gem_cpu_reloc@full:
- shard-hsw:  ( 2 PASS ) -> PASS +209

  * igt@gem_cs_tlb@basic-default:
- shard-iclb: ( 2 PASS ) -> PASS +140

  * igt@gem_mmap_wc@set-cache-level:
- shard-glk:  ( 2 PASS ) -> PASS +98

  * igt@kms_color@pipe-c-ctm-max:
- shard-iclb: ( 2 DMESG-FAIL ) -> DMESG-FAIL

  * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-ytiled:
- shard-apl:  ( 2 PASS ) -> PASS +219

  * igt@kms_flip@wf_vblank-ts-check-interruptible:
- shard-kbl:  ( 2 PASS ) -> PASS +417

  * igt@kms_rmfb@rmfb-ioctl:
- shard-kbl:  ( 3 PASS ) -> PASS +59

  * igt@syncobj_wait@invalid-wait-bad-flags:
- shard-snb:  ( 2 PASS ) -> PASS +151

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * {igt@runner@aborted}:
- shard-iclb: ( 15 FAIL ) -> ( 14 FAIL )

  
Known issues


  Here are the changes found in Patchwork_12213_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-hsw:  NOTRUN -> DMESG-WARN [fdo#107956] +1
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-kbl:  NOTRUN -> DMESG-WARN [fdo#107956] +1

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-snb:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-pageflip-hang-newfb-render-b:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#107956] +1
- shard-glk:  NOTRUN -> DMESG-WARN [fdo#107956] +1

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk:  PASS -> FAIL [fdo#108145]
- shard-kbl:  ( 2 PASS ) -> FAIL [fdo#107725] / [fdo#108145]

  * igt@kms_content_protection@legacy:
- shard-apl:  NOTRUN -> FAIL [fdo#108597]

  * igt@kms_cursor_crc@cursor-256x256-onscreen:
- shard-glk:  NOTRUN -> FAIL [fdo#103232] +2

  * igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +5

  * igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-iclb: NOTRUN -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl:  ( 2 PASS ) -> FAIL [fdo#103232]

  * igt@kms_fbcon_fbt@psr:
- shard-iclb: NOTRUN -> FAIL [fdo#103833]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl:  PASS -> FAIL [fdo#103167] +3
- shard-kbl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk:  PASS -> FAIL [fdo#103167] +3

  * igt@kms_plane@pixel-format-pipe-a-planes:
- shard-glk:  NOTRUN -> FAIL [fdo#103166]

  * igt@kms_plane@pixel-format-pipe-c-planes:
- shard-iclb: NOTRUN -> FAIL [fdo#103166]

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk:  PASS -> FAIL [fdo#108948]

  * igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-apl:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl:  NOTRUN -> FAIL [fdo#103166] +1

  * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] +2
- shard-glk:  NOTRUN -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] / [fdo#108590] +1

  * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-apl:  NOTRUN -> FAIL [fdo#108145] +1

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-iclb: PASS -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-kbl: 

Re: [Intel-gfx] [PATCH v12 21/38] mei: me: add ice lake point device id.

2019-02-13 Thread Sasha Levin
Hi,

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v4.20.7, v4.19.20, v4.14.98, v4.9.155, 
v4.4.173, v3.18.134.

v4.20.7: Build OK!
v4.19.20: Build OK!
v4.14.98: Build failed! Errors:
drivers/misc/mei/pci-me.c:108:37: error: ‘MEI_ME_PCH12_CFG’ undeclared 
here (not in a function); did you mean ‘MEI_ME_PCH8_CFG’?

v4.9.155: Failed to apply! Possible dependencies:
f8f4aa68a8ae ("mei: me: add cannon point device ids")

v4.4.173: Failed to apply! Possible dependencies:
f8f4aa68a8ae ("mei: me: add cannon point device ids")

v3.18.134: Build failed! Errors:
drivers/misc/mei/pci-me.c:86:37: error: ‘MEI_ME_PCH12_CFG’ undeclared 
here (not in a function)


How should we proceed with this patch?

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Wrap plane update/disable hook calls

2019-02-13 Thread Rodrigo Vivi
On Wed, Feb 06, 2019 at 10:49:10PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Wrap the .update_plane()/.update_slave()/.disable_plane() vfunc
> calls into helpers which also take care to emit the appropriate
> tracepoint.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_atomic_plane.c | 49 +--
>  drivers/gpu/drm/i915/intel_display.c  | 19 -
>  drivers/gpu/drm/i915/intel_drv.h  |  8 
>  3 files changed, 51 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index a1a263026574..f9fc06017a39 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -212,6 +212,35 @@ skl_next_plane_to_commit(struct intel_atomic_state 
> *state,
>   return NULL;
>  }
>  
> +void intel_update_plane(struct intel_plane *plane,
> + const struct intel_crtc_state *crtc_state,
> + const struct intel_plane_state *plane_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> +
> + trace_intel_update_plane(>base, crtc);
> + plane->update_plane(plane, crtc_state, plane_state);
> +}
> +
> +void intel_update_slave(struct intel_plane *plane,
> + const struct intel_crtc_state *crtc_state,
> + const struct intel_plane_state *plane_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> +
> + trace_intel_update_plane(>base, crtc);
> + plane->update_slave(plane, crtc_state, plane_state);
> +}
> +
> +void intel_disable_plane(struct intel_plane *plane,
> +  const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> +
> + trace_intel_disable_plane(>base, crtc);
> + plane->disable_plane(plane, crtc_state);
> +}
> +
>  void skl_update_planes_on_crtc(struct intel_atomic_state *state,
>  struct intel_crtc *crtc)
>  {
> @@ -236,8 +265,7 @@ void skl_update_planes_on_crtc(struct intel_atomic_state 
> *state,
>   intel_atomic_get_new_plane_state(state, plane);
>  
>   if (new_plane_state->base.visible) {
> - trace_intel_update_plane(>base, crtc);
> - plane->update_plane(plane, new_crtc_state, 
> new_plane_state);
> + intel_update_plane(plane, new_crtc_state, 
> new_plane_state);
>   } else if (new_plane_state->slave) {
>   struct intel_plane *master =
>   new_plane_state->linked_plane;
> @@ -254,11 +282,9 @@ void skl_update_planes_on_crtc(struct intel_atomic_state 
> *state,
>   new_plane_state =
>   intel_atomic_get_new_plane_state(state, master);
>  
> - trace_intel_update_plane(>base, crtc);
> - plane->update_slave(plane, new_crtc_state, 
> new_plane_state);
> + intel_update_slave(plane, new_crtc_state, 
> new_plane_state);
>   } else {
> - trace_intel_disable_plane(>base, crtc);
> - plane->disable_plane(plane, new_crtc_state);
> + intel_disable_plane(plane, new_crtc_state);
>   }
>   }
>  }
> @@ -278,13 +304,10 @@ void i9xx_update_planes_on_crtc(struct 
> intel_atomic_state *state,
>   !(update_mask & BIT(plane->id)))
>   continue;
>  
> - if (new_plane_state->base.visible) {
> - trace_intel_update_plane(>base, crtc);
> - plane->update_plane(plane, new_crtc_state, 
> new_plane_state);
> - } else {
> - trace_intel_disable_plane(>base, crtc);
> - plane->disable_plane(plane, new_crtc_state);
> - }
> + if (new_plane_state->base.visible)
> + intel_update_plane(plane, new_crtc_state, 
> new_plane_state);
> + else
> + intel_disable_plane(plane, new_crtc_state);
>   }
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e404e9000893..de0e871da8db 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2820,8 +2820,7 @@ static void intel_plane_disable_noatomic(struct 
> intel_crtc *crtc,
>   if (plane->id == PLANE_PRIMARY)
>   intel_pre_disable_primary_noatomic(>base);
>  
> - trace_intel_disable_plane(>base, crtc);
> - plane->disable_plane(plane, crtc_state);
> + intel_disable_plane(plane, crtc_state);
>  }
>  
>  static void
> @@ -5524,8 +5523,7 @@ static void intel_crtc_disable_planes(struct 
> intel_atomic_state *state,
>   

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add overlooked plane disable tracepoint into intel_crtc_disable_planes()

2019-02-13 Thread Rodrigo Vivi
On Wed, Feb 06, 2019 at 10:49:09PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> intel_crtc_disable_planes() disables the planes so it should
> trigger the appropriate tracepoint.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 4e3ea2d1a880..e404e9000893 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5524,6 +5524,7 @@ static void intel_crtc_disable_planes(struct 
> intel_atomic_state *state,
>   !(update_mask & BIT(plane->id)))
>   continue;
>  
> + trace_intel_disable_plane(>base, crtc);
>   plane->disable_plane(plane, new_crtc_state);
>  
>   if (old_plane_state->base.visible)
> -- 
> 2.19.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Add pipe crc tracepoint

2019-02-13 Thread Rodrigo Vivi
On Wed, Feb 06, 2019 at 10:49:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Add a tracepoint for pipe crc. Makes life much simpler when staring at
> traces when hunting for fifo underruns and other issues which cause
> corrupted frames. We'll add the tracepoint before filtering out any
> potentially bogus crcs during modeset (should actually verify if that
> filtering is even correct anymore...)
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_irq.c   |  9 +++--
>  drivers/gpu/drm/i915/i915_trace.h | 25 +
>  2 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 441d2674b272..92bb32ed27fb 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1693,7 +1693,9 @@ static void display_pipe_crc_irq_handler(struct 
> drm_i915_private *dev_priv,
>  {
>   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[pipe];
>   struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> - u32 crcs[5];
> + u32 crcs[5] = { crc0, crc1, crc2, crc3, crc4 };
> +
> + trace_intel_pipe_crc(crtc, crcs);
>  
>   spin_lock(_crc->lock);
>   /*
> @@ -1712,11 +1714,6 @@ static void display_pipe_crc_irq_handler(struct 
> drm_i915_private *dev_priv,
>   }
>   spin_unlock(_crc->lock);
>  
> - crcs[0] = crc0;
> - crcs[1] = crc1;
> - crcs[2] = crc2;
> - crcs[3] = crc3;
> - crcs[4] = crc4;
>   drm_crtc_add_crc_entry(>base, true,
>   drm_crtc_accurate_vblank_count(>base),
>   crcs);
> diff --git a/drivers/gpu/drm/i915/i915_trace.h 
> b/drivers/gpu/drm/i915/i915_trace.h
> index eab313c3163c..308d36926335 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -18,6 +18,31 @@
>  
>  /* watermark/fifo updates */
>  
> +TRACE_EVENT(intel_pipe_crc,
> + TP_PROTO(struct intel_crtc *crtc, const u32 crcs[5]),
> + TP_ARGS(crtc, crcs),
> +
> + TP_STRUCT__entry(
> +  __field(enum pipe, pipe)
> +  __field(u32, frame)
> +  __field(u32, scanline)
> +  __array(u32, crcs, 5)
> +  ),
> +
> + TP_fast_assign(
> +__entry->pipe = crtc->pipe;
> +__entry->frame = 
> crtc->base.dev->driver->get_vblank_counter(crtc->base.dev,
> + 
>crtc->pipe);
> +__entry->scanline = intel_get_crtc_scanline(crtc);
> +memcpy(__entry->crcs, crcs, sizeof(__entry->crcs));
> +),
> +
> + TP_printk("pipe %c, frame=%u, scanline=%u crc=%08x %08x %08x %08x 
> %08x",
> +   pipe_name(__entry->pipe), __entry->frame, 
> __entry->scanline,
> +   __entry->crcs[0], __entry->crcs[1], __entry->crcs[2],
> +   __entry->crcs[3], __entry->crcs[4])
> +);
> +
>  TRACE_EVENT(intel_cpu_fifo_underrun,
>   TP_PROTO(struct drm_i915_private *dev_priv, enum pipe pipe),
>   TP_ARGS(dev_priv, pipe),
> -- 
> 2.19.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Add pipe enable/disable tracepoints

2019-02-13 Thread Rodrigo Vivi
On Wed, Feb 06, 2019 at 10:49:08PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Add tracepoints for pipe enable/disable. We'll include the
> frame/scanline counters for all pipes in these tracepoints to
> help in diagnosing underruns and whatnot when enabling/disabling
> pipes in parallel with plane updates/flips on another pipe.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_trace.h| 56 
>  drivers/gpu/drm/i915/intel_display.c |  4 ++
>  2 files changed, 60 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_trace.h 
> b/drivers/gpu/drm/i915/i915_trace.h
> index 308d36926335..96dfe651ffd0 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -18,6 +18,62 @@
>  
>  /* watermark/fifo updates */
>  
> +TRACE_EVENT(intel_pipe_enable,
> + TP_PROTO(struct drm_i915_private *dev_priv, enum pipe pipe),
> + TP_ARGS(dev_priv, pipe),
> +
> + TP_STRUCT__entry(
> +  __array(u32, frame, 3)
> +  __array(u32, scanline, 3)
> +  __field(enum pipe, pipe)
> +  ),
> +
> + TP_fast_assign(
> +enum pipe _pipe;
> +for_each_pipe(dev_priv, _pipe) {
> +__entry->frame[_pipe] =
> +
> dev_priv->drm.driver->get_vblank_counter(_priv->drm, _pipe);
> +__entry->scanline[_pipe] =
> +
> intel_get_crtc_scanline(intel_get_crtc_for_pipe(dev_priv, _pipe));
> +}
> +__entry->pipe = pipe;
> +),
> +
> + TP_printk("pipe %c enable, pipe A: frame=%u, scanline=%u, pipe B: 
> frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u",
> +   pipe_name(__entry->pipe),
> +   __entry->frame[PIPE_A], __entry->scanline[PIPE_A],
> +   __entry->frame[PIPE_B], __entry->scanline[PIPE_B],
> +   __entry->frame[PIPE_C], __entry->scanline[PIPE_C])
> +);
> +
> +TRACE_EVENT(intel_pipe_disable,
> + TP_PROTO(struct drm_i915_private *dev_priv, enum pipe pipe),
> + TP_ARGS(dev_priv, pipe),
> +
> + TP_STRUCT__entry(
> +  __array(u32, frame, 3)
> +  __array(u32, scanline, 3)
> +  __field(enum pipe, pipe)
> +  ),
> +
> + TP_fast_assign(
> +enum pipe _pipe;
> +for_each_pipe(dev_priv, _pipe) {
> +__entry->frame[_pipe] =
> +
> dev_priv->drm.driver->get_vblank_counter(_priv->drm, _pipe);
> +__entry->scanline[_pipe] =
> +
> intel_get_crtc_scanline(intel_get_crtc_for_pipe(dev_priv, _pipe));
> +}
> +__entry->pipe = pipe;
> +),
> +
> + TP_printk("pipe %c disable, pipe A: frame=%u, scanline=%u, pipe B: 
> frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u",
> +   pipe_name(__entry->pipe),
> +   __entry->frame[PIPE_A], __entry->scanline[PIPE_A],
> +   __entry->frame[PIPE_B], __entry->scanline[PIPE_B],
> +   __entry->frame[PIPE_C], __entry->scanline[PIPE_C])
> +);
> +
>  TRACE_EVENT(intel_pipe_crc,
>   TP_PROTO(struct intel_crtc *crtc, const u32 crcs[5]),
>   TP_ARGS(crtc, crcs),
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 4d5ec929f987..4e3ea2d1a880 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1821,6 +1821,8 @@ static void intel_enable_pipe(const struct 
> intel_crtc_state *new_crtc_state)
>   /* FIXME: assert CPU port conditions for SNB+ */
>   }
>  
> + trace_intel_pipe_enable(dev_priv, pipe);
> +
>   reg = PIPECONF(cpu_transcoder);
>   val = I915_READ(reg);
>   if (val & PIPECONF_ENABLE) {
> @@ -1860,6 +1862,8 @@ static void intel_disable_pipe(const struct 
> intel_crtc_state *old_crtc_state)
>*/
>   assert_planes_disabled(crtc);
>  
> + trace_intel_pipe_disable(dev_priv, pipe);
> +
>   reg = PIPECONF(cpu_transcoder);
>   val = I915_READ(reg);
>   if ((val & PIPECONF_ENABLE) == 0)
> -- 
> 2.19.2
> 
> ___
> 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] [PATCH 1/3] Revert "drm/i915: W/A for underruns with WM1+ disabled on icl"

2019-02-13 Thread Ville Syrjala
From: Ville Syrjälä 

This reverts commit bf002c100740f4ae01d0d86b44f65a712ee14031.

The hw team has come up with a better workaround. So
let's get rid of this one.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  | 1 -
 drivers/gpu/drm/i915/intel_display.c | 6 --
 2 files changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0df8c6e76da7..f3f0b53c9e0e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7653,7 +7653,6 @@ enum {
 #define _PIPEB_CHICKEN 0x71038
 #define _PIPEC_CHICKEN 0x72038
 #define  PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
-#define  PM_FILL_MAINTAIN_DBUF_FULLNESS(1 << 0)
 #define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
   _PIPEB_CHICKEN)
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0a8913b2059e..73a107b6eb9a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3971,12 +3971,6 @@ static void icl_set_pipe_chicken(struct intel_crtc *crtc)
 */
tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
 
-   /*
-* W/A for underruns with linear/X-tiled with
-* WM1+ disabled.
-*/
-   tmp |= PM_FILL_MAINTAIN_DBUF_FULLNESS;
-
I915_WRITE(PIPE_CHICKEN(pipe), tmp);
 }
 
-- 
2.19.2

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

[Intel-gfx] [PATCH 3/3] drm/i915: Implement new w/a for underruns with wm1+ disabled

2019-02-13 Thread Ville Syrjala
From: Ville Syrjälä 

The new workaround from the hw team involves programming the
leaving WM1 still disabled but programming the blocks value
identically to WM0, and we also need to set the "ignore
lines watermark" bit for WM1.

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7dd2ab0ca21b..4c0e43caa5cd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4466,6 +4466,13 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
for_each_plane_id_on_crtc(intel_crtc, plane_id) {
wm = >wm.skl.optimal.planes[plane_id];
memset(>wm[level], 0, sizeof(wm->wm[level]));
+
+   /* W/A for underruns with WM1+ disabled */
+   if (IS_ICELAKE(dev_priv) &&
+   level == 1 && wm->wm[0].plane_en) {
+   wm->wm[level].plane_res_b = 
wm->wm[0].plane_res_b;
+   wm->wm[level].ignore_lines = true;
+   }
}
}
 
-- 
2.19.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: Include "ignore lines" in skl+ wm state

2019-02-13 Thread Ville Syrjala
From: Ville Syrjälä 

We'll need to poke at the "ignore lines" bit in the skl+
watermark registers for a w/a. Include that bit in the wm
state.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_reg.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 44 +
 3 files changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 17fe942eaafa..5c8d0489a1cd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1126,6 +1126,7 @@ struct skl_wm_level {
u16 plane_res_b;
u8 plane_res_l;
bool plane_en;
+   bool ignore_lines;
 };
 
 /* Stores plane specific WM parameters */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f3f0b53c9e0e..7b3c41e9771f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6032,6 +6032,7 @@ enum {
 #define _CUR_WM_TRANS_A_0  0x70168
 #define _CUR_WM_TRANS_B_0  0x71168
 #define   PLANE_WM_EN  (1 << 31)
+#define   PLANE_WM_IGNORE_LINES(1 << 30)
 #define   PLANE_WM_LINES_SHIFT 14
 #define   PLANE_WM_LINES_MASK  0x1f
 #define   PLANE_WM_BLOCKS_MASK 0x7ff /* skl+: 10 bits, icl+ 11 bits */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ea492fff6bf8..7dd2ab0ca21b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5056,11 +5056,12 @@ static void skl_write_wm_level(struct drm_i915_private 
*dev_priv,
 {
u32 val = 0;
 
-   if (level->plane_en) {
+   if (level->plane_en)
val |= PLANE_WM_EN;
-   val |= level->plane_res_b;
-   val |= level->plane_res_l << PLANE_WM_LINES_SHIFT;
-   }
+   if (level->ignore_lines)
+   val |= PLANE_WM_IGNORE_LINES;
+   val |= level->plane_res_b;
+   val |= level->plane_res_l << PLANE_WM_LINES_SHIFT;
 
I915_WRITE_FW(reg, val);
 }
@@ -5126,6 +5127,7 @@ bool skl_wm_level_equals(const struct skl_wm_level *l1,
 const struct skl_wm_level *l2)
 {
return l1->plane_en == l2->plane_en &&
+   l1->ignore_lines == l2->ignore_lines &&
l1->plane_res_l == l2->plane_res_l &&
l1->plane_res_b == l2->plane_res_b;
 }
@@ -5334,19 +5336,28 @@ skl_print_wm_changes(struct intel_atomic_state *state)
  enast(new_wm->wm[6].plane_en), 
enast(new_wm->wm[7].plane_en),
  enast(new_wm->trans_wm.plane_en));
 
-   DRM_DEBUG_KMS("[PLANE:%d:%s]   lines 
%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d"
- " -> 
%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d\n",
+   DRM_DEBUG_KMS("[PLANE:%d:%s]   lines 
%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d"
+ " -> 
%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d\n",
  plane->base.base.id, plane->base.name,
- old_wm->wm[0].plane_res_l, 
old_wm->wm[1].plane_res_l,
- old_wm->wm[2].plane_res_l, 
old_wm->wm[3].plane_res_l,
- old_wm->wm[4].plane_res_l, 
old_wm->wm[5].plane_res_l,
- old_wm->wm[6].plane_res_l, 
old_wm->wm[7].plane_res_l,
- old_wm->trans_wm.plane_res_l,
- new_wm->wm[0].plane_res_l, 
new_wm->wm[1].plane_res_l,
- new_wm->wm[2].plane_res_l, 
new_wm->wm[3].plane_res_l,
- new_wm->wm[4].plane_res_l, 
new_wm->wm[5].plane_res_l,
- new_wm->wm[6].plane_res_l, 
new_wm->wm[7].plane_res_l,
- new_wm->trans_wm.plane_res_l);
+ enast(old_wm->wm[0].ignore_lines), 
old_wm->wm[0].plane_res_l,
+ enast(old_wm->wm[1].ignore_lines), 
old_wm->wm[1].plane_res_l,
+ enast(old_wm->wm[2].ignore_lines), 
old_wm->wm[2].plane_res_l,
+ enast(old_wm->wm[3].ignore_lines), 
old_wm->wm[3].plane_res_l,
+ enast(old_wm->wm[4].ignore_lines), 
old_wm->wm[4].plane_res_l,
+ enast(old_wm->wm[5].ignore_lines), 
old_wm->wm[5].plane_res_l,
+ enast(old_wm->wm[6].ignore_lines), 
old_wm->wm[6].plane_res_l,
+ enast(old_wm->wm[7].ignore_lines), 
old_wm->wm[7].plane_res_l,
+ enast(old_wm->trans_wm.ignore_lines), 
old_wm->trans_wm.plane_res_l,
+
+ 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Bump vblank evasion time for seamless updates

2019-02-13 Thread Chris Wilson
Quoting Ville Syrjälä (2019-02-13 16:30:10)
> On Wed, Feb 13, 2019 at 04:21:42PM +, Chris Wilson wrote:
> > Each set of registers we need to rewrite during a pageflip/modeset
> > increases the required evasion window. Modesets with PSR enabled
> > empirically take up to 350us to complete the register programming, so
> > provide a corresponding boost to the evasion window.
> 
> We should have exited PSR before the evasion. Is that code not working?

I'm just correlating the reports that with PSR we get more missed vblank
evasion warnings; iirc CI showed the same when it was force enabled.

It was a neat theory to start explaining how to decide how high an
evasion time we require.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/psr: Bump vblank evasion time for seamless updates

2019-02-13 Thread Ville Syrjälä
On Wed, Feb 13, 2019 at 04:21:42PM +, Chris Wilson wrote:
> Each set of registers we need to rewrite during a pageflip/modeset
> increases the required evasion window. Modesets with PSR enabled
> empirically take up to 350us to complete the register programming, so
> provide a corresponding boost to the evasion window.

We should have exited PSR before the evasion. Is that code not working?

> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105870
> Signed-off-by: Chris Wilson 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> Cc: Jose Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 610398607e8e..03cafb953538 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -84,14 +84,30 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
>   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
>   DEFINE_WAIT(wait);
>   u32 psr_status;
> + int evasion;
>  
>   vblank_start = adjusted_mode->crtc_vblank_start;
>   if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
>   vblank_start = DIV_ROUND_UP(vblank_start, 2);
>  
> + /*
> +  * Estimate how long it will take to reprogram display registers.
> +  *
> +  * As we wish to avoid changing registers across the vblank to
> +  * avoid register write tearing, where the new frame uses an incomplete
> +  * mismash of state, we aim to complete our writes before the start
> +  * of the vblank. So we must delay starting our writes until after our
> +  * evasion window.
> +  *
> +  * Each additional bit of state adds a set of registers we need to
> +  * reprogram, increasing our required evasion window.
> +  */
> + evasion = VBLANK_EVASION_TIME_US;
> + if (dev_priv->psr.enabled || new_crtc_state->has_psr)
> + evasion += 300;
> +
>   /* FIXME needs to be calibrated sensibly */
> - min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> -   VBLANK_EVASION_TIME_US);
> + min = vblank_start - intel_usecs_to_scanlines(adjusted_mode, evasion);
>   max = vblank_start - 1;
>  
>   if (min <= 0 || max <= 0)
> -- 
> 2.20.1

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

[Intel-gfx] [PATCH] drm/i915/psr: Bump vblank evasion time for seamless updates

2019-02-13 Thread Chris Wilson
Each set of registers we need to rewrite during a pageflip/modeset
increases the required evasion window. Modesets with PSR enabled
empirically take up to 350us to complete the register programming, so
provide a corresponding boost to the evasion window.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105870
Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
Cc: Jose Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_sprite.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 610398607e8e..03cafb953538 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -84,14 +84,30 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
DEFINE_WAIT(wait);
u32 psr_status;
+   int evasion;
 
vblank_start = adjusted_mode->crtc_vblank_start;
if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
vblank_start = DIV_ROUND_UP(vblank_start, 2);
 
+   /*
+* Estimate how long it will take to reprogram display registers.
+*
+* As we wish to avoid changing registers across the vblank to
+* avoid register write tearing, where the new frame uses an incomplete
+* mismash of state, we aim to complete our writes before the start
+* of the vblank. So we must delay starting our writes until after our
+* evasion window.
+*
+* Each additional bit of state adds a set of registers we need to
+* reprogram, increasing our required evasion window.
+*/
+   evasion = VBLANK_EVASION_TIME_US;
+   if (dev_priv->psr.enabled || new_crtc_state->has_psr)
+   evasion += 300;
+
/* FIXME needs to be calibrated sensibly */
-   min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
- VBLANK_EVASION_TIME_US);
+   min = vblank_start - intel_usecs_to_scanlines(adjusted_mode, evasion);
max = vblank_start - 1;
 
if (min <= 0 || max <= 0)
-- 
2.20.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for snd/hda, drm/i915: Track the display_power_status using a cookie

2019-02-13 Thread Patchwork
== Series Details ==

Series: snd/hda, drm/i915: Track the display_power_status using a cookie
URL   : https://patchwork.freedesktop.org/series/56615/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5598 -> Patchwork_12213


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56615/revisions/1/mbox/

Known issues


  Here are the changes found in Patchwork_12213 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_hangcheck:
- fi-skl-iommu:   PASS -> INCOMPLETE [fdo#108602] / [fdo#108744]

  * igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: PASS -> FAIL [fdo#103167]

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]

  
 Possible fixes 

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> PASS

  * igt@pm_rpm@module-reload:
- fi-skl-6770hq:  FAIL [fdo#108511] -> PASS

  * igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u:   {SKIP} [fdo#109271] -> PASS +33

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
  [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
  [fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
  [fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530


Participating hosts (40 -> 38)
--

  Additional (4): fi-icl-y fi-bdw-5557u fi-skl-6700k2 fi-kbl-r 
  Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-j1900 fi-byt-squawks 
fi-bsw-cyan fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5598 -> Patchwork_12213

  CI_DRM_5598: 0d4420ccb7b8a3386fefc3719e71b5e8e69d3abb @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4820: 368237db1149033d8274248489ffec671ea1f7d8 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12213: 3b218178e779e30d5afe4f0260908c0981379a7b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

3b218178e779 snd/hda, drm/i915: Track the display_power_status using a cookie

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for snd/hda, drm/i915: Track the display_power_status using a cookie

2019-02-13 Thread Patchwork
== Series Details ==

Series: snd/hda, drm/i915: Track the display_power_status using a cookie
URL   : https://patchwork.freedesktop.org/series/56615/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3b218178e779 snd/hda, drm/i915: Track the display_power_status using a cookie
-:107: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct device 
*' should also have an identifier name
#107: FILE: include/drm/drm_audio_component.h:25:
+   unsigned long (*get_power)(struct device *);

-:114: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct device 
*' should also have an identifier name
#114: FILE: include/drm/drm_audio_component.h:31:
+   void (*put_power)(struct device *, unsigned long);

-:114: WARNING:FUNCTION_ARGUMENTS: function definition argument 'unsigned long' 
should also have an identifier name
#114: FILE: include/drm/drm_audio_component.h:31:
+   void (*put_power)(struct device *, unsigned long);

total: 0 errors, 3 warnings, 0 checks, 129 lines checked

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

Re: [Intel-gfx] [PATCH v5 0/3] Support 64 bpp half float formats

2019-02-13 Thread Maarten Lankhorst
Op 13-02-2019 om 16:53 schreef Ville Syrjälä:
> On Fri, Feb 08, 2019 at 01:49:40PM -0800, Kevin Strasser wrote:
>> This series defines new formats and adds implementation to the i915 driver.
>> Since posting v1 I have removed the pixel normalize property, as it's not 
>> needed
>> for basic functionality. Also, I have been working on adding support to
>> userspace, but we can't land any patches until drm_fourcc.h has been updated
>> here.
>>
>> I have submitted a series to Mesa to make use of the RGBA ordered formats:
>>   https://patchwork.freedesktop.org/series/54759/
>>
>> My igt branch is reworked to drop usage of pixel normalize and includes use
>> of f16c intrinsics to speed up conversion:
>>   https://gitlab.freedesktop.org/strassek/igt-gpu-tools/commits/fp16
> Was that posted to the ml? I can't seem to find it.
>
> Anyways, a quick look at the web thing tells me this predates
> Maarten's cairo float stuff. I believe that has now landed so you
> should probably switch to using that instead of rendering at 8bpc.

Yes, it's now in upstream igt. :)

RGB96F is just a float[3] = { r, g, b }; RGBA128F is the same with the alpha 
channel at the end,

should be possible to convert to half float with the right changes to the 
conversion function.

~Maarten

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

Re: [Intel-gfx] [PATCH v5 0/3] Support 64 bpp half float formats

2019-02-13 Thread Ville Syrjälä
On Fri, Feb 08, 2019 at 01:49:40PM -0800, Kevin Strasser wrote:
> This series defines new formats and adds implementation to the i915 driver.
> Since posting v1 I have removed the pixel normalize property, as it's not 
> needed
> for basic functionality. Also, I have been working on adding support to
> userspace, but we can't land any patches until drm_fourcc.h has been updated
> here.
> 
> I have submitted a series to Mesa to make use of the RGBA ordered formats:
>   https://patchwork.freedesktop.org/series/54759/
> 
> My igt branch is reworked to drop usage of pixel normalize and includes use
> of f16c intrinsics to speed up conversion:
>   https://gitlab.freedesktop.org/strassek/igt-gpu-tools/commits/fp16

Was that posted to the ml? I can't seem to find it.

Anyways, a quick look at the web thing tells me this predates
Maarten's cairo float stuff. I believe that has now landed so you
should probably switch to using that instead of rendering at 8bpc.

> 
> I also have a libdrm branch with fp16 coverage added to modetest:
>   https://gitlab.freedesktop.org/strassek/drm/commits/fp16
> 
> To serve as a smoke test of the whole stack I have a modified version of
> kmscube:
>   https://gitlab.freedesktop.org/strassek/kmscube/commits/fp16
> 
> Kevin Strasser (3):
>   drm/fourcc: Add 64 bpp half float formats
>   drm/i915: Refactor icl_is_hdr_plane
>   drm/i915/icl: Implement half float formats
> 
>  drivers/gpu/drm/drm_fourcc.c |  4 ++
>  drivers/gpu/drm/i915/intel_atomic.c  |  3 +-
>  drivers/gpu/drm/i915/intel_display.c | 29 +-
>  drivers/gpu/drm/i915/intel_drv.h |  7 ++--
>  drivers/gpu/drm/i915/intel_sprite.c  | 73 
> +++-
>  include/uapi/drm/drm_fourcc.h| 11 ++
>  6 files changed, 112 insertions(+), 15 deletions(-)
> 
> -- 
> 2.7.4

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Make DRM DSC helpers more generally usable

2019-02-13 Thread Patchwork
== Series Details ==

Series: Make DRM DSC helpers more generally usable
URL   : https://patchwork.freedesktop.org/series/56608/
State : failure

== Summary ==

Applying: drm/i915: Move dsc rate params compute into drm
Applying: drm/dsc: Add native 420 and 422 support to compute_rc_params
error: sha1 information is lacking or useless (drivers/gpu/drm/drm_dsc.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0002 drm/dsc: Add native 420 and 422 support to 
compute_rc_params
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH 3/3] drm/dsc: Change infoframe_pack to payload_pack

2019-02-13 Thread Wentland, Harry
On 2019-02-13 9:45 a.m., David Francis wrote:
> The function drm_dsc_pps_infoframe_pack only
> packed the payload portion of the infoframe.
> Change the input struct to the PPS payload
> to clarify the function's purpose and allow
> for drivers with their own handling of sdp.
> (e.g. drivers with their own struct for
> all SDP transactions)
> 
> Signed-off-by: David Francis 

Reviewed-by: Harry Wentland 

Again, ideally we'd want an AB from i915 guys as well.

Harry

> ---
>  drivers/gpu/drm/drm_dsc.c | 86 +++
>  drivers/gpu/drm/i915/intel_vdsc.c |  2 +-
>  include/drm/drm_dsc.h |  2 +-
>  3 files changed, 45 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 9e675dd39a44..4ada4d4f59ac 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -38,42 +38,42 @@ void drm_dsc_dp_pps_header_init(struct 
> drm_dsc_pps_infoframe *pps_sdp)
>  EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
>  
>  /**
> - * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
> + * drm_dsc_pps_payload_pack() - Populates the DSC PPS payload
>   * using the DSC configuration parameters in the order expected
>   * by the DSC Display Sink device. For the DSC, the sink device
>   * expects the PPS payload in the big endian format for the fields
>   * that span more than 1 byte.
>   *
> - * @pps_sdp:
> - * Secondary data packet for DSC Picture Parameter Set
> + * @pps_payload:
> + * DSC Picture Parameter Set
>   * @dsc_cfg:
>   * DSC Configuration data filled by driver
>   */
> -void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
> +void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set 
> *pps_payload,
>   const struct drm_dsc_config *dsc_cfg)
>  {
>   int i;
>  
>   /* Protect against someone accidently changing struct size */
> - BUILD_BUG_ON(sizeof(pps_sdp->pps_payload) !=
> + BUILD_BUG_ON(sizeof(*pps_payload) !=
>DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
>  
> - memset(_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
> + memset(pps_payload, 0, sizeof(*pps_payload));
>  
>   /* PPS 0 */
> - pps_sdp->pps_payload.dsc_version =
> + pps_payload->dsc_version =
>   dsc_cfg->dsc_version_minor |
>   dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
>  
>   /* PPS 1, 2 is 0 */
>  
>   /* PPS 3 */
> - pps_sdp->pps_payload.pps_3 =
> + pps_payload->pps_3 =
>   dsc_cfg->line_buf_depth |
>   dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
>  
>   /* PPS 4 */
> - pps_sdp->pps_payload.pps_4 =
> + pps_payload->pps_4 =
>   ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT) |
>   dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> @@ -82,7 +82,7 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
>  
>   /* PPS 5 */
> - pps_sdp->pps_payload.bits_per_pixel_low =
> + pps_payload->bits_per_pixel_low =
>   (dsc_cfg->bits_per_pixel & DSC_PPS_LSB_MASK);
>  
>   /*
> @@ -93,103 +93,103 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>*/
>  
>   /* PPS 6, 7 */
> - pps_sdp->pps_payload.pic_height = cpu_to_be16(dsc_cfg->pic_height);
> + pps_payload->pic_height = cpu_to_be16(dsc_cfg->pic_height);
>  
>   /* PPS 8, 9 */
> - pps_sdp->pps_payload.pic_width = cpu_to_be16(dsc_cfg->pic_width);
> + pps_payload->pic_width = cpu_to_be16(dsc_cfg->pic_width);
>  
>   /* PPS 10, 11 */
> - pps_sdp->pps_payload.slice_height = cpu_to_be16(dsc_cfg->slice_height);
> + pps_payload->slice_height = cpu_to_be16(dsc_cfg->slice_height);
>  
>   /* PPS 12, 13 */
> - pps_sdp->pps_payload.slice_width = cpu_to_be16(dsc_cfg->slice_width);
> + pps_payload->slice_width = cpu_to_be16(dsc_cfg->slice_width);
>  
>   /* PPS 14, 15 */
> - pps_sdp->pps_payload.chunk_size = 
> cpu_to_be16(dsc_cfg->slice_chunk_size);
> + pps_payload->chunk_size = cpu_to_be16(dsc_cfg->slice_chunk_size);
>  
>   /* PPS 16 */
> - pps_sdp->pps_payload.initial_xmit_delay_high =
> + pps_payload->initial_xmit_delay_high =
>   ((dsc_cfg->initial_xmit_delay &
> DSC_PPS_INIT_XMIT_DELAY_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT);
>  
>   /* PPS 17 */
> - pps_sdp->pps_payload.initial_xmit_delay_low =
> + pps_payload->initial_xmit_delay_low =
>   (dsc_cfg->initial_xmit_delay & DSC_PPS_LSB_MASK);
>  
>   /* PPS 18, 19 */
> - pps_sdp->pps_payload.initial_dec_delay =
> + pps_payload->initial_dec_delay =
>   cpu_to_be16(dsc_cfg->initial_dec_delay);
>  
>   /* PPS 20 is 0 */
>  
>   /* PPS 21 */
> - 

Re: [Intel-gfx] [PATCH 2/3] drm/dsc: Add native 420 and 422 support to compute_rc_params

2019-02-13 Thread Wentland, Harry
On 2019-02-13 9:45 a.m., David Francis wrote:
> Native 420 and 422 transfer modes are new in DSC1.2
> 
> In these modes, each two pixels of a slice are treated as one
> pixel, so the slice width is half as large (round down) for
> the purposes of calucating the groups per line and chunk size
> in bytes
> 
> In native 422 mode, each pixel has four components, so the
> mux component of a group is larger by one additional mux word
> and one additional component
> 
> Now that there is native 422 support, the configuration option
> previously called enable422 is renamed to simple_422 to avoid
> confusion
> 
> Signed-off-by: David Francis 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dsc.c | 31 +++
>  drivers/gpu/drm/i915/intel_vdsc.c |  4 ++--
>  include/drm/drm_dsc.h |  4 ++--
>  3 files changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 4b0e3c9c3ff8..9e675dd39a44 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -77,7 +77,7 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT) |
>   dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> - dsc_cfg->enable422 << DSC_PPS_SIMPLE422_SHIFT |
> + dsc_cfg->simple_422 << DSC_PPS_SIMPLE422_SHIFT |
>   dsc_cfg->convert_rgb << DSC_PPS_CONVERT_RGB_SHIFT |
>   dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
>  
> @@ -246,19 +246,34 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
> *vdsc_cfg)
>   unsigned long final_scale = 0;
>   unsigned long rbs_min = 0;
>  
> - /* Number of groups used to code each line of a slice */
> - groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> -DSC_RC_PIXELS_PER_GROUP);
> + if (vdsc_cfg->native_420 || vdsc_cfg->native_422) {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width / 2,
> +DSC_RC_PIXELS_PER_GROUP);
>  
> - /* chunksize in Bytes */
> - vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> -   vdsc_cfg->bits_per_pixel,
> -   (8 * 16));
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> / 2 *
> +   
> vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> + } else {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> *
> +   
> vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> + }
>  
>   if (vdsc_cfg->convert_rgb)
>   num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> (4 * vdsc_cfg->bits_per_component + 4)
> - 2);
> + else if (vdsc_cfg->native_422)
> + num_extra_mux_bits = 4 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 3 * (4 * vdsc_cfg->bits_per_component) - 2;
>   else
>   num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
>   (4 * vdsc_cfg->bits_per_component + 4) +
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index c76cec8bfb74..7702c5c8b3f2 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -369,7 +369,7 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
>   DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
>  
>   /* Gen 11 does not support YCbCr */
> - vdsc_cfg->enable422 = false;
> + vdsc_cfg->simple_422 = false;
>   /* Gen 11 does not support VBR */
>   vdsc_cfg->vbr_enable = false;
>   vdsc_cfg->block_pred_enable =
> @@ -496,7 +496,7 @@ static void intel_configure_pps_for_dsc_encoder(struct 
> intel_encoder *encoder,
>   pps_val |= DSC_BLOCK_PREDICTION;
>   if (vdsc_cfg->convert_rgb)
>   pps_val |= DSC_COLOR_SPACE_CONVERSION;
> - if (vdsc_cfg->enable422)
> + if (vdsc_cfg->simple_422)
>   pps_val |= DSC_422_ENABLE;
>   if (vdsc_cfg->vbr_enable)
>   pps_val |= DSC_VBR_ENABLE;
> 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move dsc rate params compute into drm

2019-02-13 Thread Wentland, Harry
On 2019-02-13 9:45 a.m., David Francis wrote:
> The function intel_compute_rc_parameters is part of the dsc spec
> and is not driver-specific. Other drm drivers might like to use
> it.  The function is not changed; just moved and renamed.
> 
> Signed-off-by: David Francis 

Reviewed-by: Harry Wentland 

This one also needs an RB or AB from i915 guys.

Harry

> ---
>  drivers/gpu/drm/drm_dsc.c | 133 ++
>  drivers/gpu/drm/i915/intel_vdsc.c | 125 +---
>  include/drm/drm_dsc.h |   1 +
>  3 files changed, 135 insertions(+), 124 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index bc2b23adb072..4b0e3c9c3ff8 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -226,3 +227,135 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   /* PPS 94 - 127 are O */
>  }
>  EXPORT_SYMBOL(drm_dsc_pps_infoframe_pack);
> +
> +/**
> + * drm_dsc_compute_rc_parameters() - Write rate control
> + * parameters to the dsc configuration. Some configuration
> + * fields must be present beforehand.
> + *
> + * @dsc_cfg:
> + * DSC Configuration data partially filled by driver
> + */
> +int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
> +{
> + unsigned long groups_per_line = 0;
> + unsigned long groups_total = 0;
> + unsigned long num_extra_mux_bits = 0;
> + unsigned long slice_bits = 0;
> + unsigned long hrd_delay = 0;
> + unsigned long final_scale = 0;
> + unsigned long rbs_min = 0;
> +
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> +   vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> +
> + if (vdsc_cfg->convert_rgb)
> + num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> +   (4 * vdsc_cfg->bits_per_component + 4)
> +   - 2);
> + else
> + num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 2 * (4 * vdsc_cfg->bits_per_component) - 2;
> + /* Number of bits in one Slice */
> + slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
> +
> + while ((num_extra_mux_bits > 0) &&
> +((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
> + num_extra_mux_bits--;
> +
> + if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
> + vdsc_cfg->initial_scale_value = groups_per_line + 8;
> +
> + /* scale_decrement_interval calculation according to DSC spec 1.11 */
> + if (vdsc_cfg->initial_scale_value > 8)
> + vdsc_cfg->scale_decrement_interval = groups_per_line /
> + (vdsc_cfg->initial_scale_value - 8);
> + else
> + vdsc_cfg->scale_decrement_interval = 
> DSC_SCALE_DECREMENT_INTERVAL_MAX;
> +
> + vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
> + (vdsc_cfg->initial_xmit_delay *
> +  vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
> +
> + if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
> + DRM_DEBUG_KMS("FinalOfs < RcModelSze for this 
> InitialXmitDelay\n");
> + return -ERANGE;
> + }
> +
> + final_scale = (vdsc_cfg->rc_model_size * 8) /
> + (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
> + if (vdsc_cfg->slice_height > 1)
> + /*
> +  * NflBpgOffset is 16 bit value with 11 fractional bits
> +  * hence we multiply by 2^11 for preserving the
> +  * fractional part
> +  */
> + vdsc_cfg->nfl_bpg_offset = 
> DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
> + (vdsc_cfg->slice_height 
> - 1));
> + else
> + vdsc_cfg->nfl_bpg_offset = 0;
> +
> + /* 2^16 - 1 */
> + if (vdsc_cfg->nfl_bpg_offset > 65535) {
> + DRM_DEBUG_KMS("NflBpgOffset is too large for this slice 
> height\n");
> + return -ERANGE;
> + }
> +
> + /* Number of groups used to code the entire slice */
> + groups_total = groups_per_line * vdsc_cfg->slice_height;
> +
> + /* slice_bpg_offset is 16 bit value with 11 fractional bits */
> + vdsc_cfg->slice_bpg_offset = DIV_ROUND_UP(((vdsc_cfg->rc_model_size -
> + vdsc_cfg->initial_offset +
> + 

[Intel-gfx] [PATCH] snd/hda, drm/i915: Track the display_power_status using a cookie

2019-02-13 Thread Chris Wilson
drm/i915 is tracking all wakeref owners with a cookie in order to
identify leaks. To that end, each rpm acquisition ops->get_power is
assigned a cookie which should be passed to ops->put_power to signify
its release (and removal from the list of wakeref owners). As snd/hda is
already using a bool to track current status of display_power extending
that to an unsigned long to hold the boolean cookie is a trivial
extension, and will quell all doubt that snd/hda is the cause of the
device runtime pm leaks.

v2: Keep using the power abstraction for local wakeref tracking.

Signed-off-by: Chris Wilson 
Cc: Takashi Iwai 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_audio.c | 20 +++-
 include/drm/drm_audio_component.h  |  7 +--
 include/sound/hdaudio.h|  2 +-
 sound/hda/hdac_component.c | 18 --
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 5104c6bbd66f..a1e60370eb34 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -741,27 +741,28 @@ void intel_init_audio_hooks(struct drm_i915_private 
*dev_priv)
}
 }
 
-static void i915_audio_component_get_power(struct device *kdev)
+static unsigned long i915_audio_component_get_power(struct device *kdev)
 {
-   intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
+   return intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
 }
 
-static void i915_audio_component_put_power(struct device *kdev)
+static void i915_audio_component_put_power(struct device *kdev,
+  unsigned long cookie)
 {
-   intel_display_power_put_unchecked(kdev_to_i915(kdev),
- POWER_DOMAIN_AUDIO);
+   intel_display_power_put(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO, cookie);
 }
 
 static void i915_audio_component_codec_wake_override(struct device *kdev,
 bool enable)
 {
struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
+   unsigned long wakeref;
u32 tmp;
 
if (!IS_GEN(dev_priv, 9))
return;
 
-   i915_audio_component_get_power(kdev);
+   wakeref = i915_audio_component_get_power(kdev);
 
/*
 * Enable/disable generating the codec wake signal, overriding the
@@ -779,7 +780,7 @@ static void i915_audio_component_codec_wake_override(struct 
device *kdev,
usleep_range(1000, 1500);
}
 
-   i915_audio_component_put_power(kdev);
+   i915_audio_component_put_power(kdev, wakeref);
 }
 
 /* Get CDCLK in kHz  */
@@ -850,12 +851,13 @@ static int i915_audio_component_sync_audio_rate(struct 
device *kdev, int port,
struct i915_audio_component *acomp = dev_priv->audio_component;
struct intel_encoder *encoder;
struct intel_crtc *crtc;
+   unsigned long wakeref;
int err = 0;
 
if (!HAS_DDI(dev_priv))
return 0;
 
-   i915_audio_component_get_power(kdev);
+   wakeref = i915_audio_component_get_power(kdev);
mutex_lock(_priv->av_mutex);
 
/* 1. get the pipe */
@@ -875,7 +877,7 @@ static int i915_audio_component_sync_audio_rate(struct 
device *kdev, int port,
 
  unlock:
mutex_unlock(_priv->av_mutex);
-   i915_audio_component_put_power(kdev);
+   i915_audio_component_put_power(kdev, wakeref);
return err;
 }
 
diff --git a/include/drm/drm_audio_component.h 
b/include/drm/drm_audio_component.h
index 4923b00328c1..d0c7444319f5 100644
--- a/include/drm/drm_audio_component.h
+++ b/include/drm/drm_audio_component.h
@@ -18,14 +18,17 @@ struct drm_audio_component_ops {
 * @get_power: get the POWER_DOMAIN_AUDIO power well
 *
 * Request the power well to be turned on.
+*
+* Returns a wakeref cookie to be passed back to the corresponding
+* call to @put_power.
 */
-   void (*get_power)(struct device *);
+   unsigned long (*get_power)(struct device *);
/**
 * @put_power: put the POWER_DOMAIN_AUDIO power well
 *
 * Allow the power well to be turned off.
 */
-   void (*put_power)(struct device *);
+   void (*put_power)(struct device *, unsigned long);
/**
 * @codec_wake_override: Enable/disable codec wake signal
 */
diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h
index 45f944d57982..06f504c10b80 100644
--- a/include/sound/hdaudio.h
+++ b/include/sound/hdaudio.h
@@ -367,7 +367,7 @@ struct hdac_bus {
/* DRM component interface */
struct drm_audio_component *audio_component;
long display_power_status;
-   bool display_power_active;
+   unsigned long display_power_active;
 
/* parameters required for enhanced capabilities */
int num_streams;
diff --git 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Assert that VED and ISP are power gated

2019-02-13 Thread Imre Deak
On Thu, Nov 29, 2018 at 07:55:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> As there are no upstream drivers for VED or ISP let's just
> assert that they are power gated. Otherwise they would
> prevent s0ix entry.
> 
> For ISP this is only relevant when it is not exposed as a
> PCI device and instead is a subordinate of the gunit. When
> exposed as a PCI device it will be handled by the
> atomisp2_pm driver.
> 
> On my VLV FFRD8 board the firmware power gates both of these
> by default. Let's assume that is always the case and just
> WARN if we ever encounter something different.
> 
> Cc: Hans de Goede 
> Cc: Alan Cox 
> Cc: Andy Shevchenko 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 28 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 33 +
>  2 files changed, 61 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 42d25872ecfe..c2ecac4cb51b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1020,6 +1020,31 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  /* See configdb bunit SB addr map */
>  #define BUNIT_REG_BISOC  0x11
>  
> +/* PUNIT_REG_*SSPM0 */
> +#define   _SSPM0_SSC(val)((val) << 0)
> +#define   SSPM0_SSC_MASK _SSPM0_SSC(0x3)
> +#define   SSPM0_SSC_PWR_ON   _SSPM0_SSC(0x0)
> +#define   SSPM0_SSC_CLK_GATE _SSPM0_SSC(0x1)
> +#define   SSPM0_SSC_RESET_SSPM0_SSC(0x2)
> +#define   SSPM0_SSC_PWR_GATE _SSPM0_SSC(0x3)
> +#define   _SSPM0_SSS(val)((val) << 24)
> +#define   SSPM0_SSS_MASK _SSPM0_SSS(0x3)
> +#define   SSPM0_SSS_PWR_ON   _SSPM0_SSS(0x0)
> +#define   SSPM0_SSS_CLK_GATE _SSPM0_SSS(0x1)
> +#define   SSPM0_SSS_RESET_SSPM0_SSS(0x2)
> +#define   SSPM0_SSS_PWR_GATE _SSPM0_SSS(0x3)
> +
> +/* PUNIT_REG_*SSPM1 */
> +#define   SSPM1_FREQSTAT_SHIFT   24
> +#define   SSPM1_FREQSTAT_MASK(0x1f << 
> SSPM1_FREQSTAT_SHIFT)
> +#define   SSPM1_FREQGUAR_SHIFT   8
> +#define   SSPM1_FREQGUAR_MASK(0x1f << 
> SSPM1_FREQGUAR_SHIFT)
> +#define   SSPM1_FREQ_SHIFT   0
> +#define   SSPM1_FREQ_MASK(0x1f << SSPM1_FREQ_SHIFT)
> +
> +#define PUNIT_REG_VEDSSPM0   0x32
> +#define PUNIT_REG_VEDSSPM1   0x33
> +
>  #define PUNIT_REG_DSPSSPM0x36
>  #define   DSPFREQSTAT_SHIFT_CHV  24
>  #define   DSPFREQSTAT_MASK_CHV   (0x1f << 
> DSPFREQSTAT_SHIFT_CHV)
> @@ -1045,6 +1070,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define   DP_SSS_RESET(pipe) _DP_SSS(0x2, (pipe))
>  #define   DP_SSS_PWR_GATE(pipe)  _DP_SSS(0x3, (pipe))
>  
> +#define PUNIT_REG_ISPSSPM0   0x39
> +#define PUNIT_REG_ISPSSPM1   0x3a
> +
>  /*
>   * i915_power_well_id:
>   *
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index af499d4a0c66..416521f45ec7 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -3706,6 +3706,36 @@ static void vlv_cmnlane_wa(struct drm_i915_private 
> *dev_priv)
>   cmn->desc->ops->disable(dev_priv, cmn);
>  }
>  
> +static bool vlv_punit_is_power_gated(struct drm_i915_private *dev_priv, u32 
> reg0)
> +{
> + bool ret;
> +
> + mutex_lock(_priv->pcu_lock);
> + ret = (vlv_punit_read(dev_priv, reg0) & SSPM0_SSC_MASK) == 
> SSPM0_SSC_PWR_GATE;
> + mutex_unlock(_priv->pcu_lock);
> +
> + return ret;
> +}
> +
> +static void assert_ved_power_gated(struct drm_i915_private *dev_priv)
> +{
> + WARN(!vlv_punit_is_power_gated(dev_priv, PUNIT_REG_VEDSSPM0),
> +  "VED not power gated\n");
> +}
> +
> +static void assert_isp_power_gated(struct drm_i915_private *dev_priv)
> +{
> + static const struct pci_device_id isp_ids[] = {
> + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0f38)},
> + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x22b8)},
> + {}
> + };
> +
> + WARN(!pci_dev_present(isp_ids) &&
> +  !vlv_punit_is_power_gated(dev_priv, PUNIT_REG_ISPSSPM0),
> +  "ISP not power gated\n");
> +}
> +
>  static void intel_power_domains_verify_state(struct drm_i915_private 
> *dev_priv);
>  
>  /**
> @@ -3742,10 +3772,13 @@ void intel_power_domains_init_hw(struct 
> drm_i915_private *dev_priv, bool resume)
>   mutex_lock(_domains->lock);
>   chv_phy_control_init(dev_priv);
>   mutex_unlock(_domains->lock);
> + assert_isp_power_gated(dev_priv);
>   } else if 

[Intel-gfx] [PATCH 3/3] drm/dsc: Change infoframe_pack to payload_pack

2019-02-13 Thread David Francis
The function drm_dsc_pps_infoframe_pack only
packed the payload portion of the infoframe.
Change the input struct to the PPS payload
to clarify the function's purpose and allow
for drivers with their own handling of sdp.
(e.g. drivers with their own struct for
all SDP transactions)

Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dsc.c | 86 +++
 drivers/gpu/drm/i915/intel_vdsc.c |  2 +-
 include/drm/drm_dsc.h |  2 +-
 3 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index 9e675dd39a44..4ada4d4f59ac 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -38,42 +38,42 @@ void drm_dsc_dp_pps_header_init(struct 
drm_dsc_pps_infoframe *pps_sdp)
 EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
 
 /**
- * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
+ * drm_dsc_pps_payload_pack() - Populates the DSC PPS payload
  * using the DSC configuration parameters in the order expected
  * by the DSC Display Sink device. For the DSC, the sink device
  * expects the PPS payload in the big endian format for the fields
  * that span more than 1 byte.
  *
- * @pps_sdp:
- * Secondary data packet for DSC Picture Parameter Set
+ * @pps_payload:
+ * DSC Picture Parameter Set
  * @dsc_cfg:
  * DSC Configuration data filled by driver
  */
-void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
+void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set 
*pps_payload,
const struct drm_dsc_config *dsc_cfg)
 {
int i;
 
/* Protect against someone accidently changing struct size */
-   BUILD_BUG_ON(sizeof(pps_sdp->pps_payload) !=
+   BUILD_BUG_ON(sizeof(*pps_payload) !=
 DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
 
-   memset(_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
+   memset(pps_payload, 0, sizeof(*pps_payload));
 
/* PPS 0 */
-   pps_sdp->pps_payload.dsc_version =
+   pps_payload->dsc_version =
dsc_cfg->dsc_version_minor |
dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
 
/* PPS 1, 2 is 0 */
 
/* PPS 3 */
-   pps_sdp->pps_payload.pps_3 =
+   pps_payload->pps_3 =
dsc_cfg->line_buf_depth |
dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
 
/* PPS 4 */
-   pps_sdp->pps_payload.pps_4 =
+   pps_payload->pps_4 =
((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
 DSC_PPS_MSB_SHIFT) |
dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
@@ -82,7 +82,7 @@ void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe 
*pps_sdp,
dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
 
/* PPS 5 */
-   pps_sdp->pps_payload.bits_per_pixel_low =
+   pps_payload->bits_per_pixel_low =
(dsc_cfg->bits_per_pixel & DSC_PPS_LSB_MASK);
 
/*
@@ -93,103 +93,103 @@ void drm_dsc_pps_infoframe_pack(struct 
drm_dsc_pps_infoframe *pps_sdp,
 */
 
/* PPS 6, 7 */
-   pps_sdp->pps_payload.pic_height = cpu_to_be16(dsc_cfg->pic_height);
+   pps_payload->pic_height = cpu_to_be16(dsc_cfg->pic_height);
 
/* PPS 8, 9 */
-   pps_sdp->pps_payload.pic_width = cpu_to_be16(dsc_cfg->pic_width);
+   pps_payload->pic_width = cpu_to_be16(dsc_cfg->pic_width);
 
/* PPS 10, 11 */
-   pps_sdp->pps_payload.slice_height = cpu_to_be16(dsc_cfg->slice_height);
+   pps_payload->slice_height = cpu_to_be16(dsc_cfg->slice_height);
 
/* PPS 12, 13 */
-   pps_sdp->pps_payload.slice_width = cpu_to_be16(dsc_cfg->slice_width);
+   pps_payload->slice_width = cpu_to_be16(dsc_cfg->slice_width);
 
/* PPS 14, 15 */
-   pps_sdp->pps_payload.chunk_size = 
cpu_to_be16(dsc_cfg->slice_chunk_size);
+   pps_payload->chunk_size = cpu_to_be16(dsc_cfg->slice_chunk_size);
 
/* PPS 16 */
-   pps_sdp->pps_payload.initial_xmit_delay_high =
+   pps_payload->initial_xmit_delay_high =
((dsc_cfg->initial_xmit_delay &
  DSC_PPS_INIT_XMIT_DELAY_HIGH_MASK) >>
 DSC_PPS_MSB_SHIFT);
 
/* PPS 17 */
-   pps_sdp->pps_payload.initial_xmit_delay_low =
+   pps_payload->initial_xmit_delay_low =
(dsc_cfg->initial_xmit_delay & DSC_PPS_LSB_MASK);
 
/* PPS 18, 19 */
-   pps_sdp->pps_payload.initial_dec_delay =
+   pps_payload->initial_dec_delay =
cpu_to_be16(dsc_cfg->initial_dec_delay);
 
/* PPS 20 is 0 */
 
/* PPS 21 */
-   pps_sdp->pps_payload.initial_scale_value =
+   pps_payload->initial_scale_value =
dsc_cfg->initial_scale_value;
 
/* PPS 22, 23 */
-   pps_sdp->pps_payload.scale_increment_interval =
+   pps_payload->scale_increment_interval =

[Intel-gfx] [PATCH 1/3] drm/i915: Move dsc rate params compute into drm

2019-02-13 Thread David Francis
The function intel_compute_rc_parameters is part of the dsc spec
and is not driver-specific. Other drm drivers might like to use
it.  The function is not changed; just moved and renamed.

Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dsc.c | 133 ++
 drivers/gpu/drm/i915/intel_vdsc.c | 125 +---
 include/drm/drm_dsc.h |   1 +
 3 files changed, 135 insertions(+), 124 deletions(-)

diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index bc2b23adb072..4b0e3c9c3ff8 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -226,3 +227,135 @@ void drm_dsc_pps_infoframe_pack(struct 
drm_dsc_pps_infoframe *pps_sdp,
/* PPS 94 - 127 are O */
 }
 EXPORT_SYMBOL(drm_dsc_pps_infoframe_pack);
+
+/**
+ * drm_dsc_compute_rc_parameters() - Write rate control
+ * parameters to the dsc configuration. Some configuration
+ * fields must be present beforehand.
+ *
+ * @dsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
+{
+   unsigned long groups_per_line = 0;
+   unsigned long groups_total = 0;
+   unsigned long num_extra_mux_bits = 0;
+   unsigned long slice_bits = 0;
+   unsigned long hrd_delay = 0;
+   unsigned long final_scale = 0;
+   unsigned long rbs_min = 0;
+
+   /* Number of groups used to code each line of a slice */
+   groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
+  DSC_RC_PIXELS_PER_GROUP);
+
+   /* chunksize in Bytes */
+   vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
+ vdsc_cfg->bits_per_pixel,
+ (8 * 16));
+
+   if (vdsc_cfg->convert_rgb)
+   num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
+ (4 * vdsc_cfg->bits_per_component + 4)
+ - 2);
+   else
+   num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
+   (4 * vdsc_cfg->bits_per_component + 4) +
+   2 * (4 * vdsc_cfg->bits_per_component) - 2;
+   /* Number of bits in one Slice */
+   slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
+
+   while ((num_extra_mux_bits > 0) &&
+  ((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
+   num_extra_mux_bits--;
+
+   if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
+   vdsc_cfg->initial_scale_value = groups_per_line + 8;
+
+   /* scale_decrement_interval calculation according to DSC spec 1.11 */
+   if (vdsc_cfg->initial_scale_value > 8)
+   vdsc_cfg->scale_decrement_interval = groups_per_line /
+   (vdsc_cfg->initial_scale_value - 8);
+   else
+   vdsc_cfg->scale_decrement_interval = 
DSC_SCALE_DECREMENT_INTERVAL_MAX;
+
+   vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
+   (vdsc_cfg->initial_xmit_delay *
+vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
+
+   if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
+   DRM_DEBUG_KMS("FinalOfs < RcModelSze for this 
InitialXmitDelay\n");
+   return -ERANGE;
+   }
+
+   final_scale = (vdsc_cfg->rc_model_size * 8) /
+   (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
+   if (vdsc_cfg->slice_height > 1)
+   /*
+* NflBpgOffset is 16 bit value with 11 fractional bits
+* hence we multiply by 2^11 for preserving the
+* fractional part
+*/
+   vdsc_cfg->nfl_bpg_offset = 
DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
+   (vdsc_cfg->slice_height 
- 1));
+   else
+   vdsc_cfg->nfl_bpg_offset = 0;
+
+   /* 2^16 - 1 */
+   if (vdsc_cfg->nfl_bpg_offset > 65535) {
+   DRM_DEBUG_KMS("NflBpgOffset is too large for this slice 
height\n");
+   return -ERANGE;
+   }
+
+   /* Number of groups used to code the entire slice */
+   groups_total = groups_per_line * vdsc_cfg->slice_height;
+
+   /* slice_bpg_offset is 16 bit value with 11 fractional bits */
+   vdsc_cfg->slice_bpg_offset = DIV_ROUND_UP(((vdsc_cfg->rc_model_size -
+   vdsc_cfg->initial_offset +
+   num_extra_mux_bits) << 11),
+ groups_total);
+
+   if (final_scale > 9) {
+   /*
+* ScaleIncrementInterval =
+* finaloffset/((NflBpgOffset + 

[Intel-gfx] [PATCH 2/3] drm/dsc: Add native 420 and 422 support to compute_rc_params

2019-02-13 Thread David Francis
Native 420 and 422 transfer modes are new in DSC1.2

In these modes, each two pixels of a slice are treated as one
pixel, so the slice width is half as large (round down) for
the purposes of calucating the groups per line and chunk size
in bytes

In native 422 mode, each pixel has four components, so the
mux component of a group is larger by one additional mux word
and one additional component

Now that there is native 422 support, the configuration option
previously called enable422 is renamed to simple_422 to avoid
confusion

Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dsc.c | 31 +++
 drivers/gpu/drm/i915/intel_vdsc.c |  4 ++--
 include/drm/drm_dsc.h |  4 ++--
 3 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index 4b0e3c9c3ff8..9e675dd39a44 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -77,7 +77,7 @@ void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe 
*pps_sdp,
((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
 DSC_PPS_MSB_SHIFT) |
dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
-   dsc_cfg->enable422 << DSC_PPS_SIMPLE422_SHIFT |
+   dsc_cfg->simple_422 << DSC_PPS_SIMPLE422_SHIFT |
dsc_cfg->convert_rgb << DSC_PPS_CONVERT_RGB_SHIFT |
dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
 
@@ -246,19 +246,34 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
*vdsc_cfg)
unsigned long final_scale = 0;
unsigned long rbs_min = 0;
 
-   /* Number of groups used to code each line of a slice */
-   groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
-  DSC_RC_PIXELS_PER_GROUP);
+   if (vdsc_cfg->native_420 || vdsc_cfg->native_422) {
+   /* Number of groups used to code each line of a slice */
+   groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width / 2,
+  DSC_RC_PIXELS_PER_GROUP);
 
-   /* chunksize in Bytes */
-   vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
- vdsc_cfg->bits_per_pixel,
- (8 * 16));
+   /* chunksize in Bytes */
+   vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
/ 2 *
+ 
vdsc_cfg->bits_per_pixel,
+ (8 * 16));
+   } else {
+   /* Number of groups used to code each line of a slice */
+   groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
+  DSC_RC_PIXELS_PER_GROUP);
+
+   /* chunksize in Bytes */
+   vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
*
+ 
vdsc_cfg->bits_per_pixel,
+ (8 * 16));
+   }
 
if (vdsc_cfg->convert_rgb)
num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
  (4 * vdsc_cfg->bits_per_component + 4)
  - 2);
+   else if (vdsc_cfg->native_422)
+   num_extra_mux_bits = 4 * vdsc_cfg->mux_word_size +
+   (4 * vdsc_cfg->bits_per_component + 4) +
+   3 * (4 * vdsc_cfg->bits_per_component) - 2;
else
num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
(4 * vdsc_cfg->bits_per_component + 4) +
diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
b/drivers/gpu/drm/i915/intel_vdsc.c
index c76cec8bfb74..7702c5c8b3f2 100644
--- a/drivers/gpu/drm/i915/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/intel_vdsc.c
@@ -369,7 +369,7 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
 
/* Gen 11 does not support YCbCr */
-   vdsc_cfg->enable422 = false;
+   vdsc_cfg->simple_422 = false;
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
vdsc_cfg->block_pred_enable =
@@ -496,7 +496,7 @@ static void intel_configure_pps_for_dsc_encoder(struct 
intel_encoder *encoder,
pps_val |= DSC_BLOCK_PREDICTION;
if (vdsc_cfg->convert_rgb)
pps_val |= DSC_COLOR_SPACE_CONVERSION;
-   if (vdsc_cfg->enable422)
+   if (vdsc_cfg->simple_422)
pps_val |= DSC_422_ENABLE;
if (vdsc_cfg->vbr_enable)
pps_val |= DSC_VBR_ENABLE;
diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
index ad43494f1cc8..4e55e37943d7 100644
--- a/include/drm/drm_dsc.h
+++ b/include/drm/drm_dsc.h
@@ -70,10 +70,10 @@ struct 

[Intel-gfx] [PATCH 0/3] Make DRM DSC helpers more generally usable

2019-02-13 Thread David Francis
drm_dsc could use some work so that drm drivers other than
i915 can make use of it their own DSC implementations

Move rc compute, a function that forms part of the DSC spec,
into drm. Update it to DSC 1.2. Also change the packing function
to operate only on the packing struct, to allow for drivers with
their own SDP struct headers

David Francis (3):
  drm/i915: Move dsc rate params compute into drm
  drm/dsc: Add native 420 and 422 support to compute_rc_params
  drm/dsc: Change infoframe_pack to payload_pack

 drivers/gpu/drm/drm_dsc.c | 236 --
 drivers/gpu/drm/i915/intel_vdsc.c | 131 +
 include/drm/drm_dsc.h |   7 +-
 3 files changed, 200 insertions(+), 174 deletions(-)

-- 
2.17.1

___
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: s/PUNIT_REG_DSPFREQ/PUNIT_REG_DSPSSPM/

2019-02-13 Thread Imre Deak
On Thu, Nov 29, 2018 at 07:55:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Rename the punit display power register to match the spec.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_reg.h |  2 +-
>  drivers/gpu/drm/i915/intel_cdclk.c  | 14 +++---
>  drivers/gpu/drm/i915/intel_pm.c |  6 +++---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
>  4 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 47baf2fe8f71..42d25872ecfe 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1020,7 +1020,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  /* See configdb bunit SB addr map */
>  #define BUNIT_REG_BISOC  0x11
>  
> -#define PUNIT_REG_DSPFREQ0x36
> +#define PUNIT_REG_DSPSSPM0x36
>  #define   DSPFREQSTAT_SHIFT_CHV  24
>  #define   DSPFREQSTAT_MASK_CHV   (0x1f << 
> DSPFREQSTAT_SHIFT_CHV)
>  #define   DSPFREQGUAR_SHIFT_CHV  8
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 25e3aba9cded..82f60f8a15e9 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -468,7 +468,7 @@ static void vlv_get_cdclk(struct drm_i915_private 
> *dev_priv,
>  cdclk_state->vco);
>  
>   mutex_lock(_priv->pcu_lock);
> - val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> + val = vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM);
>   mutex_unlock(_priv->pcu_lock);
>  
>   if (IS_VALLEYVIEW(dev_priv))
> @@ -542,11 +542,11 @@ static void vlv_set_cdclk(struct drm_i915_private 
> *dev_priv,
>   intel_display_power_get(dev_priv, POWER_DOMAIN_PIPE_A);
>  
>   mutex_lock(_priv->pcu_lock);
> - val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> + val = vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM);
>   val &= ~DSPFREQGUAR_MASK;
>   val |= (cmd << DSPFREQGUAR_SHIFT);
> - vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
> - if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ) &
> + vlv_punit_write(dev_priv, PUNIT_REG_DSPSSPM, val);
> + if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM) &
> DSPFREQSTAT_MASK) == (cmd << DSPFREQSTAT_SHIFT),
>50)) {
>   DRM_ERROR("timed out waiting for CDclk change\n");
> @@ -622,11 +622,11 @@ static void chv_set_cdclk(struct drm_i915_private 
> *dev_priv,
>   intel_display_power_get(dev_priv, POWER_DOMAIN_PIPE_A);
>  
>   mutex_lock(_priv->pcu_lock);
> - val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> + val = vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM);
>   val &= ~DSPFREQGUAR_MASK_CHV;
>   val |= (cmd << DSPFREQGUAR_SHIFT_CHV);
> - vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
> - if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ) &
> + vlv_punit_write(dev_priv, PUNIT_REG_DSPSSPM, val);
> + if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM) &
> DSPFREQSTAT_MASK_CHV) == (cmd << DSPFREQSTAT_SHIFT_CHV),
>50)) {
>   DRM_ERROR("timed out waiting for CDclk change\n");
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a26b4eddda25..a67ec01dd958 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -335,12 +335,12 @@ static void chv_set_memory_pm5(struct drm_i915_private 
> *dev_priv, bool enable)
>  
>   mutex_lock(_priv->pcu_lock);
>  
> - val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> + val = vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM);
>   if (enable)
>   val |= DSP_MAXFIFO_PM5_ENABLE;
>   else
>   val &= ~DSP_MAXFIFO_PM5_ENABLE;
> - vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
> + vlv_punit_write(dev_priv, PUNIT_REG_DSPSSPM, val);
>  
>   mutex_unlock(_priv->pcu_lock);
>  }
> @@ -6082,7 +6082,7 @@ void vlv_wm_get_hw_state(struct drm_device *dev)
>   if (IS_CHERRYVIEW(dev_priv)) {
>   mutex_lock(_priv->pcu_lock);
>  
> - val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> + val = vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM);
>   if (val & DSP_MAXFIFO_PM5_ENABLE)
>   wm->level = VLV_WM_LEVEL_PM5;
>  
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 1c2de9b69a19..af499d4a0c66 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1494,7 +1494,7 @@ static bool chv_pipe_power_well_enabled(struct 
> drm_i915_private *dev_priv,
>  
>   mutex_lock(_priv->pcu_lock);
>  

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_sseu: Fix 32-bit build

2019-02-13 Thread Chris Wilson
Quoting Chris Wilson (2019-02-13 14:08:02)
> Quoting Guillaume Tucker (2019-02-13 09:31:37)
> > This fixes a compiler warning treated as an error when building for
> > 32-bit architectures since their pointer size does not match the size
> > of drm_i915_gem_context_param.value which is 64 bits:
> > 
> >   CC   i915/gem_ctx_sseu.o
> >   i915/gem_ctx_sseu.c: In function ‘test_ggtt_args’:
> >   i915/gem_ctx_sseu.c:384:9: error: cast to pointer from integer of 
> > different size [-Werror=int-to-pointer-cast]
> > munmap((void *)arg.value, 4096);
> > 
> > It was found while building for arm with gcc 6.3.0 and I suspect the
> > same problem would arise for i386 or other 32-bit architectures.  The
> > uintptr_t type is by definition an unsigned integer of the same length
> > as a pointer on a given architecture, so this should fix the problem
> > for all architectures up to 64 bits.
> > 
> > Signed-off-by: Guillaume Tucker 
> 
> At some point, we should save our eyesight and do u64_to_pointer().
> Reviewed-by: Chris Wilson 

And pushed, having forgotten I wasn't using dim and forgot to auto-sob.
-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] i915/gem_ctx_sseu: Fix 32-bit build

2019-02-13 Thread Chris Wilson
Quoting Guillaume Tucker (2019-02-13 09:31:37)
> This fixes a compiler warning treated as an error when building for
> 32-bit architectures since their pointer size does not match the size
> of drm_i915_gem_context_param.value which is 64 bits:
> 
>   CC   i915/gem_ctx_sseu.o
>   i915/gem_ctx_sseu.c: In function ‘test_ggtt_args’:
>   i915/gem_ctx_sseu.c:384:9: error: cast to pointer from integer of different 
> size [-Werror=int-to-pointer-cast]
> munmap((void *)arg.value, 4096);
> 
> It was found while building for arm with gcc 6.3.0 and I suspect the
> same problem would arise for i386 or other 32-bit architectures.  The
> uintptr_t type is by definition an unsigned integer of the same length
> as a pointer on a given architecture, so this should fix the problem
> for all architectures up to 64 bits.
> 
> Signed-off-by: Guillaume Tucker 

At some point, we should save our eyesight and do u64_to_pointer().
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats

2019-02-13 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats
URL   : https://patchwork.freedesktop.org/series/56606/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add P010, P012, P016 plane control definitions
Okay!

Commit: drm/i915: Preparations for enabling P010, P012, P016 formats
-O:drivers/gpu/drm/i915/intel_display.c:13835:21: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_display.c:13835:21: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_display.c:13850:21: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_display.c:13850:21: warning: expression using 
sizeof(void)

Commit: drm/i915: Enable P010, P012, P016 formats for primary and sprite planes
Okay!

Commit: drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
Okay!

Commit: drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions
Okay!

Commit: drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for 
universal planes
Okay!

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats

2019-02-13 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats
URL   : https://patchwork.freedesktop.org/series/56606/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
cb165e09561e drm/i915: Add P010, P012, P016 plane control definitions
faf842adb452 drm/i915: Preparations for enabling P010, P012, P016 formats
c56b1f27606c drm/i915: Enable P010, P012, P016 formats for primary and sprite 
planes
-:22: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#22: FILE: drivers/gpu/drm/i915/intel_sprite.c:1835:
+static const uint32_t glk_planar_formats[] = {

total: 0 errors, 0 warnings, 1 checks, 40 lines checked
40637208986a drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
-:47: WARNING:LONG_LINE: line over 100 characters
#47: FILE: drivers/gpu/drm/drm_fourcc.c:229:
+   { .format = DRM_FORMAT_Y210,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },

-:48: WARNING:LONG_LINE: line over 100 characters
#48: FILE: drivers/gpu/drm/drm_fourcc.c:230:
+   { .format = DRM_FORMAT_Y212,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },

-:49: WARNING:LONG_LINE: line over 100 characters
#49: FILE: drivers/gpu/drm/drm_fourcc.c:231:
+   { .format = DRM_FORMAT_Y216,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },

-:50: WARNING:LONG_LINE: line over 100 characters
#50: FILE: drivers/gpu/drm/drm_fourcc.c:232:
+   { .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

-:51: WARNING:LONG_LINE: line over 100 characters
#51: FILE: drivers/gpu/drm/drm_fourcc.c:233:
+   { .format = DRM_FORMAT_Y412,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

-:52: WARNING:LONG_LINE: line over 100 characters
#52: FILE: drivers/gpu/drm/drm_fourcc.c:234:
+   { .format = DRM_FORMAT_Y416,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

-:65: WARNING:LONG_LINE_COMMENT: line over 100 characters
#65: FILE: include/uapi/drm/drm_fourcc.h:154:
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0] 
X:Y:Cb:Cr 8:8:8:8 little endian */

-:71: WARNING:LONG_LINE_COMMENT: line over 100 characters
#71: FILE: include/uapi/drm/drm_fourcc.h:160:
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */

-:72: WARNING:LONG_LINE_COMMENT: line over 100 characters
#72: FILE: include/uapi/drm/drm_fourcc.h:161:
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */

-:73: WARNING:LONG_LINE_COMMENT: line over 100 characters
#73: FILE: include/uapi/drm/drm_fourcc.h:162:
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0] 
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */

-:79: WARNING:LONG_LINE_COMMENT: line over 100 characters
#79: FILE: include/uapi/drm/drm_fourcc.h:168:
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0] 
X:V:Y:U 2:10:10:10 little endian */

-:80: WARNING:LONG_LINE_COMMENT: line over 100 characters
#80: FILE: include/uapi/drm/drm_fourcc.h:169:
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [63:0] 
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */

-:81: WARNING:LONG_LINE_COMMENT: line over 100 characters
#81: FILE: include/uapi/drm/drm_fourcc.h:170:
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6') /* [63:0] 
X:V:Y:U 16:16:16:16 little endian */

total: 0 errors, 13 warnings, 0 checks, 36 lines checked
b92638041b15 drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control 
definitions
8a4ad917dbb2 drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for 
universal planes
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

-:75: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#75: FILE: drivers/gpu/drm/i915/intel_sprite.c:1819:
+static const uint32_t icl_plane_formats[] = {

-:103: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#103: FILE: drivers/gpu/drm/i915/intel_sprite.c:1875:
+static const uint32_t icl_planar_formats[] = {

total: 0 errors, 1 warnings, 2 checks, 138 lines checked

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

[Intel-gfx] [PATCH 3/6] drm/i915: Enable P010, P012, P016 formats for primary and sprite planes

2019-02-13 Thread Swati Sharma
From: Juha-Pekka Heikkila 

Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.

Signed-off-by: Juha-Pekka Heikkila 
Signed-off-by: Swati Sharma 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_sprite.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 1be7d59..0db3c5d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1832,6 +1832,25 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device 
*dev, void *data,
DRM_FORMAT_NV12,
 };
 
+static const uint32_t glk_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+   DRM_FORMAT_P010,
+   DRM_FORMAT_P012,
+   DRM_FORMAT_P016,
+};
+
 static const u64 skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -2114,8 +2133,13 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
 
if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
-   formats = skl_planar_formats;
-   num_formats = ARRAY_SIZE(skl_planar_formats);
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+   formats = glk_planar_formats;
+   num_formats = ARRAY_SIZE(glk_planar_formats);
+   } else {
+   formats = skl_planar_formats;
+   num_formats = ARRAY_SIZE(skl_planar_formats);
+   }
} else {
formats = skl_plane_formats;
num_formats = ARRAY_SIZE(skl_plane_formats);
-- 
1.9.1

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

[Intel-gfx] [PATCH 6/6] drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes

2019-02-13 Thread Swati Sharma
Signed-off-by: Swati Sharma 
Signed-off-by: Vidya Srinivas 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 30 ++
 drivers/gpu/drm/i915/intel_sprite.c  | 60 +++-
 2 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 77bc046..ffceaa7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2683,6 +2683,18 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
bool alpha)
return DRM_FORMAT_P012;
case PLANE_CTL_FORMAT_P016:
return DRM_FORMAT_P016;
+   case PLANE_CTL_FORMAT_Y210:
+   return DRM_FORMAT_Y210;
+   case PLANE_CTL_FORMAT_Y212:
+   return DRM_FORMAT_Y212;
+   case PLANE_CTL_FORMAT_Y216:
+   return DRM_FORMAT_Y216;
+   case PLANE_CTL_FORMAT_Y410:
+   return DRM_FORMAT_Y410;
+   case PLANE_CTL_FORMAT_Y412:
+   return DRM_FORMAT_Y412;
+   case PLANE_CTL_FORMAT_Y416:
+   return DRM_FORMAT_Y416;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3613,6 +3625,18 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_P012;
case DRM_FORMAT_P016:
return PLANE_CTL_FORMAT_P016;
+   case DRM_FORMAT_Y210:
+   return PLANE_CTL_FORMAT_Y210;
+   case DRM_FORMAT_Y212:
+   return PLANE_CTL_FORMAT_Y212;
+   case DRM_FORMAT_Y216:
+   return PLANE_CTL_FORMAT_Y216;
+   case DRM_FORMAT_Y410:
+   return PLANE_CTL_FORMAT_Y410;
+   case DRM_FORMAT_Y412:
+   return PLANE_CTL_FORMAT_Y412;
+   case DRM_FORMAT_Y416:
+   return PLANE_CTL_FORMAT_Y416;
default:
MISSING_CASE(pixel_format);
}
@@ -5161,6 +5185,12 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
+   case DRM_FORMAT_Y210:
+   case DRM_FORMAT_Y212:
+   case DRM_FORMAT_Y216:
+   case DRM_FORMAT_Y410:
+   case DRM_FORMAT_Y412:
+   case DRM_FORMAT_Y416:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0db3c5d..89d7bf7 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1816,6 +1816,27 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device 
*dev, void *data,
DRM_FORMAT_VYUY,
 };
 
+static const uint32_t icl_plane_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_Y210,
+   DRM_FORMAT_Y212,
+   DRM_FORMAT_Y216,
+   DRM_FORMAT_Y410,
+   DRM_FORMAT_Y412,
+   DRM_FORMAT_Y416,
+};
+
 static const u32 skl_planar_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -1851,6 +1872,31 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device 
*dev, void *data,
DRM_FORMAT_P016,
 };
 
+static const uint32_t icl_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+   DRM_FORMAT_P010,
+   DRM_FORMAT_P012,
+   DRM_FORMAT_P016,
+   DRM_FORMAT_Y210,
+   DRM_FORMAT_Y212,
+   DRM_FORMAT_Y216,
+   DRM_FORMAT_Y410,
+   DRM_FORMAT_Y412,
+   DRM_FORMAT_Y416,
+};
+
 static const u64 skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1993,6 +2039,12 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
+   case DRM_FORMAT_Y210:
+   case DRM_FORMAT_Y212:
+   case DRM_FORMAT_Y216:
+   case DRM_FORMAT_Y410:
+   case DRM_FORMAT_Y412:
+   case DRM_FORMAT_Y416:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -2133,13 +2185,19 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
 
if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
-   

[Intel-gfx] [PATCH 1/6] drm/i915: Add P010, P012, P016 plane control definitions

2019-02-13 Thread Swati Sharma
From: Juha-Pekka Heikkila 

Add needed plane control flag definitions for P010, P012 and
P016 formats.

Signed-off-by: Juha-Pekka Heikkila 
Signed-off-by: Swati Sharma 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 11bf60d..d0c5395 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6563,8 +6563,11 @@ enum {
 #define   PLANE_CTL_FORMAT_YUV422  (0 << 24)
 #define   PLANE_CTL_FORMAT_NV12(1 << 24)
 #define   PLANE_CTL_FORMAT_XRGB_2101010(2 << 24)
+#define   PLANE_CTL_FORMAT_P010(3 << 24)
 #define   PLANE_CTL_FORMAT_XRGB_   (4 << 24)
+#define   PLANE_CTL_FORMAT_P012(5 << 24)
 #define   PLANE_CTL_FORMAT_XRGB_16161616F  (6 << 24)
+#define   PLANE_CTL_FORMAT_P016(7 << 24)
 #define   PLANE_CTL_FORMAT_AYUV(8 << 24)
 #define   PLANE_CTL_FORMAT_INDEXED (12 << 24)
 #define   PLANE_CTL_FORMAT_RGB_565 (14 << 24)
-- 
1.9.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: Preparations for enabling P010, P012, P016 formats

2019-02-13 Thread Swati Sharma
From: Juha-Pekka Heikkila 

Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.

Signed-off-by: Juha-Pekka Heikkila 
Signed-off-by: Swati Sharma 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c  | 27 +--
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_pm.c   | 14 +++---
 drivers/gpu/drm/i915/intel_sprite.c   | 22 +++---
 5 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 01bf3ce..c802987 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -136,7 +136,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
new_crtc_state->active_planes |= BIT(plane->id);
 
if (new_plane_state->base.visible &&
-   new_plane_state->base.fb->format->format == DRM_FORMAT_NV12)
+   is_planar_yuv_format(new_plane_state->base.fb->format->format))
new_crtc_state->nv12_planes |= BIT(plane->id);
 
if (new_plane_state->base.visible &&
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5b8dabd..77bc046 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2677,6 +2677,12 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+   case PLANE_CTL_FORMAT_P010:
+   return DRM_FORMAT_P010;
+   case PLANE_CTL_FORMAT_P012:
+   return DRM_FORMAT_P012;
+   case PLANE_CTL_FORMAT_P016:
+   return DRM_FORMAT_P016;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3176,7 +3182,7 @@ int skl_check_plane_surface(struct intel_plane_state 
*plane_state)
 * Handle the AUX surface first since
 * the main surface setup depends on it.
 */
-   if (fb->format->format == DRM_FORMAT_NV12) {
+   if (is_planar_yuv_format(fb->format->format)) {
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
@@ -3601,6 +3607,12 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+   case DRM_FORMAT_P010:
+   return PLANE_CTL_FORMAT_P010;
+   case DRM_FORMAT_P012:
+   return PLANE_CTL_FORMAT_P012;
+   case DRM_FORMAT_P016:
+   return PLANE_CTL_FORMAT_P016;
default:
MISSING_CASE(pixel_format);
}
@@ -5033,9 +5045,9 @@ u16 skl_scaler_calc_phase(int sub, int scale, bool 
chroma_cosited)
return 0;
}
 
-   if (format && format->format == DRM_FORMAT_NV12 &&
+   if (format && is_planar_yuv_format(format->format) &&
(src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
-   DRM_DEBUG_KMS("NV12: src dimensions not met\n");
+   DRM_DEBUG_KMS("Planar YUV: src dimensions not met\n");
return -EINVAL;
}
 
@@ -5109,7 +5121,7 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
 
/* Pre-gen11 and SDR planes always need a scaler for planar formats. */
if (!icl_is_hdr_plane(intel_plane) &&
-   fb && fb->format->format == DRM_FORMAT_NV12)
+   fb && is_planar_yuv_format(fb->format->format))
need_scaler = true;
 
ret = skl_update_scaler(crtc_state, force_detach,
@@ -5146,6 +5158,9 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+   case DRM_FORMAT_P010:
+   case DRM_FORMAT_P012:
+   case DRM_FORMAT_P016:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
@@ -11198,7 +11213,7 @@ static int icl_check_nv12_planes(struct 
intel_crtc_state *crtc_state)
}
 
if (!linked_state) {
-   DRM_DEBUG_KMS("Need %d free Y planes for NV12\n",
+   DRM_DEBUG_KMS("Need %d free Y planes for planar YUV\n",
  hweight8(crtc_state->nv12_planes));
 
return -EINVAL;
@@ -13829,7 +13844,7 @@ static void fb_obj_bump_render_priority(struct 
drm_i915_gem_object *obj)
 *or
 *cdclk/crtc_clock
 */
-   mult = pixel_format == DRM_FORMAT_NV12 ? 2 : 3;
+   mult = 

[Intel-gfx] [PATCH 5/6] drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions

2019-02-13 Thread Swati Sharma
Added needed plane control flag definitions for Y2xx and Y4xx (10, 12 and
16 bits)

Signed-off-by: Swati Sharma 
Signed-off-by: Vidya Srinivas 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_reg.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d0c5395..f33a361 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6573,6 +6573,12 @@ enum {
 #define   PLANE_CTL_FORMAT_RGB_565 (14 << 24)
 #define   ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
 #define   PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
+#define   PLANE_CTL_FORMAT_Y210 (1 << 23)
+#define   PLANE_CTL_FORMAT_Y212 (3 << 23)
+#define   PLANE_CTL_FORMAT_Y216 (5 << 23)
+#define   PLANE_CTL_FORMAT_Y410 (7 << 23)
+#define   PLANE_CTL_FORMAT_Y412 (9 << 23)
+#define   PLANE_CTL_FORMAT_Y416 (0xb << 23)
 #define   PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
 #define   PLANE_CTL_KEY_ENABLE_SOURCE  (1 << 21)
 #define   PLANE_CTL_KEY_ENABLE_DESTINATION (2 << 21)
-- 
1.9.1

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

[Intel-gfx] [PATCH 0/6] Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats

2019-02-13 Thread Swati Sharma
This patch series is for enabling P0xx, Y2xx and Y4xx pixel formats for
intel's i915 driver.

In this patch series, Juha Pekka's patch series Gen10+ P0xx formats
https://patchwork.freedesktop.org/series/56053/ is combined with Swati's
https://patchwork.freedesktop.org/series/55035/ for Gen11+ pixel formats
(Y2xx and Y4xx).

P0xx pixel formats are enabled from GLK whereas Y2xx and Y4xx are enabled
from ICL platform.

These patches enable planar formats YUV420-P010, P012 and  P016
(Intial 3 patches of Juha) for GLK+ platform and packed format YUV422-Y210,
Y212 and Y216 and YUV444-Y410, Y412, Y416 for 10, 12 and 16 bits for ICL+
platforms.

IGT validating all these pixel formats is written by Maarten Lankhorst 
https://patchwork.freedesktop.org/patch/284508/

IGT needs libraries for pixman and cairo to support more than 8bpc. Need 
cairo >= 1.17.2 and pixman-1 >= 0.36.0.

Tested with custom cairo and pixman. P0xx and Y2xx successfully validated for
HDR planes, SDR planes having CRC mismatch (known bug for all YUV formats).
IGT for Y410 and Y416 is alpha enabled whereas kernel patches are non-alpha;
depending upon review comments will make changes either in IGT or kernel.
TODO: IGT for Y412 yet to be written

Also, need community feedback if Y4xx pixel formats should be renamed to 
XYUV_2101010/
XYUV_12121212/XYUV16161616.

Juha-Pekka Heikkila (3):
  drm/i915: Add P010, P012, P016 plane control definitions
  drm/i915: Preparations for enabling P010, P012, P016 formats
  drm/i915: Enable P010, P012, P016 formats for primary and sprite
planes

Swati Sharma (3):
  drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
  drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control
definitions
  drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for
universal planes

 drivers/gpu/drm/drm_fourcc.c  |   6 ++
 drivers/gpu/drm/i915/i915_reg.h   |   9 +++
 drivers/gpu/drm/i915/intel_atomic_plane.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c  |  57 ++--
 drivers/gpu/drm/i915/intel_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_pm.c   |  14 ++--
 drivers/gpu/drm/i915/intel_sprite.c   | 108 --
 include/uapi/drm/drm_fourcc.h |  18 -
 8 files changed, 195 insertions(+), 20 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 4/6] drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc

2019-02-13 Thread Swati Sharma
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.

Y210:   For each component, valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212:   For each component, valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216:   For each component valid data occupies 16 bits,
doesn't require any padding bits.

First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.

The following pixel formats are packed format that follows 4:4:4
chroma sampling. Channels are arranged in the order UYVA in
increasing memory order.

Y410:   Each color component occupies 10 bits and X component
takes 2 bits, thus each pixel occupies 32 bits.
Y412:   Each color component is 16 bits where valid data
occupies MSB 12 bits. LSB 4 bits are filled with zeroes.
Thus, each pixel occupies 64 bits.
Y416:   Each color component occupies 16 bits for valid data,
doesn't require any padding bits. Thus, each pixel
occupies 64 bits.

Signed-off-by: Swati Sharma 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/drm_fourcc.c  |  6 ++
 include/uapi/drm/drm_fourcc.h | 18 +-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index ba7e19d..45c9882 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -226,6 +226,12 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_XYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
+   { .format = DRM_FORMAT_Y210,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y212,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y216,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y412,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y416,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,  
.num_planes = 1,
  .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 }, 
.block_h = { 2, 0, 0 },
  .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index bab2029..6e20ced 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -151,7 +151,23 @@
 #define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /* 
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
 
 #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
-#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* 
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0] 
X:Y:Cb:Cr 8:8:8:8 little endian */
+
+/*
+ * packed Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0] 
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */
+
+/*
+ * packed Y4xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb except Y410
+ */
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0] 
X:V:Y:U 2:10:10:10 little endian */
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [63:0] 
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Chris Wilson
Quoting Daniel Vetter (2019-02-13 13:08:32)
> On Wed, Feb 13, 2019 at 2:05 PM Chris Wilson  wrote:
> >
> > Quoting Daniel Vetter (2019-02-13 13:02:29)
> > > On Wed, Feb 13, 2019 at 11:15 AM Chris Wilson  
> > > wrote:
> > > > Quoting Daniel Vetter (2019-02-13 10:11:27)
> > > > > On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> > > > > > CI complains that the exhaustive test of trying every size up to the
> > > > > > limit is too slow, so add a simple test that tries to submit one
> > > > > > extreme batch buffer and check all the relocations land.
> > > > > >
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
> > > > > > Signed-off-by: Chris Wilson 
> > > > > > ---
> > > > > >  tests/i915/gem_exec_big.c| 70 
> > > > > > ++--
> > > > > >  tests/intel-ci/blacklist.txt |  1 +
> > > > > >  2 files changed, 60 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c
> > > > > > index a15672f66..6d7041cf4 100644
> > > > > > --- a/tests/i915/gem_exec_big.c
> > > > > > +++ b/tests/i915/gem_exec_big.c
> > > > > > @@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, 
> > > > > > uint64_t reloc_ofs, unsigned flags, c
> > > > > >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> > > > > >   gem_exec[0].alignment = 0;
> > > > > >   gem_exec[0].offset = 0;
> > > > > > - gem_exec[0].flags = 0;
> > > > > > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > > > > >   gem_exec[0].rsvd1 = 0;
> > > > > >   gem_exec[0].rsvd2 = 0;
> > > > > >
> > > > > > @@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, 
> > > > > > uint64_t batch_size, unsigned flags,
> > > > > >   gem_exec[0].handle = handle;
> > > > > >   gem_exec[0].relocation_count = nreloc;
> > > > > >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> > > > > > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > > > > >
> > > > > >   memset(, 0, sizeof(execbuf));
> > > > > >   execbuf.buffers_ptr = to_user_pointer(gem_exec);
> > > > > >   execbuf.buffer_count = 1;
> > > > > > - execbuf.batch_start_offset = 0;
> > > > > > - execbuf.batch_len = 8;
> > > > > >   execbuf.flags = flags;
> > > > > >
> > > > > >   /* Avoid hitting slowpaths in the reloc processing which 
> > > > > > might yield a
> > > > > > @@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, 
> > > > > > uint64_t batch_size, unsigned flags,
> > > > > >  #undef reloc_ofs
> > > > > >  }
> > > > > >
> > > > > > -igt_simple_main
> > > > > > +static void exhaustive(int fd)
> > > > > >  {
> > > > > >   uint32_t batch[2] = {MI_BATCH_BUFFER_END};
> > > > > >   uint64_t batch_size, max, ggtt_max, reloc_ofs;
> > > > > > - int fd;
> > > > > > -
> > > > > > - fd = drm_open_driver(DRIVER_INTEL);
> > > > > > - igt_require_gem(fd);
> > > > > > -
> > > > > > - use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8;
> > > > > >
> > > > > >   max = 3 * gem_aperture_size(fd) / 4;
> > > > > >   ggtt_max = 3 * gem_global_aperture_size(fd) / 4;
> > > > > > @@ -258,6 +251,61 @@ igt_simple_main
> > > > > >   else
> > > > > >   batch_size *= 2;
> > > > > >   }
> > > > > > +}
> > > > > > +
> > > > > > +static void single(int i915)
> > > > > > +{
> > > > > > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > > > > > + uint64_t batch_size, limit;
> > > > > > + uint32_t handle;
> > > > > > + void *ptr;
> > > > > > +
> > > > > > + batch_size = (intel_get_avail_ram_mb() - 4) << 20; /* 
> > > > > > internal slack */
> > > > > > + limit = gem_aperture_size(i915) - (256 << 10); /* low pages 
> > > > > > reserved */
> > > > > > + if (!gem_uses_full_ppgtt(i915))
> > > > > > + limit = 3 * limit / 4;
> > > > > > +
> > > > > > + batch_size = min(batch_size, limit);
> > > > > > + batch_size = ALIGN(batch_size, 4096);
> > > > > > + igt_info("Submitting a %'"PRId64"MiB batch, %saperture size 
> > > > > > %'"PRId64"MiB\n",
> > > > > > +  batch_size >> 20,
> > > > > > +  gem_uses_full_ppgtt(i915) ? "" : "shared ",
> > > > > > +  gem_aperture_size(i915) >> 20);
> > > > > > + intel_require_memory(1, batch_size, CHECK_RAM);
> > > > > > +
> > > > > > + handle = gem_create(i915, batch_size);
> > > > > > + gem_write(i915, handle, 0, , sizeof(bbe));
> > > > > > +
> > > > > > + if (!FORCE_PREAD_PWRITE && gem_has_llc(i915))
> > > > > > + ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, 
> > > > > > PROT_READ);
> > > > > > + else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915))
> > > > > > + ptr = __gem_mmap__wc(i915, handle, 0, batch_size, 
> > > > > > PROT_READ);
> > > > > > + else
> > > > > > + ptr = NULL;
> > > > > > +
> > > > > > + execN(i915, handle, batch_size, 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Daniel Vetter
On Wed, Feb 13, 2019 at 2:05 PM Chris Wilson  wrote:
>
> Quoting Daniel Vetter (2019-02-13 13:02:29)
> > On Wed, Feb 13, 2019 at 11:15 AM Chris Wilson  
> > wrote:
> > > Quoting Daniel Vetter (2019-02-13 10:11:27)
> > > > On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> > > > > CI complains that the exhaustive test of trying every size up to the
> > > > > limit is too slow, so add a simple test that tries to submit one
> > > > > extreme batch buffer and check all the relocations land.
> > > > >
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
> > > > > Signed-off-by: Chris Wilson 
> > > > > ---
> > > > >  tests/i915/gem_exec_big.c| 70 
> > > > > ++--
> > > > >  tests/intel-ci/blacklist.txt |  1 +
> > > > >  2 files changed, 60 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c
> > > > > index a15672f66..6d7041cf4 100644
> > > > > --- a/tests/i915/gem_exec_big.c
> > > > > +++ b/tests/i915/gem_exec_big.c
> > > > > @@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t 
> > > > > reloc_ofs, unsigned flags, c
> > > > >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> > > > >   gem_exec[0].alignment = 0;
> > > > >   gem_exec[0].offset = 0;
> > > > > - gem_exec[0].flags = 0;
> > > > > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > > > >   gem_exec[0].rsvd1 = 0;
> > > > >   gem_exec[0].rsvd2 = 0;
> > > > >
> > > > > @@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, 
> > > > > uint64_t batch_size, unsigned flags,
> > > > >   gem_exec[0].handle = handle;
> > > > >   gem_exec[0].relocation_count = nreloc;
> > > > >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> > > > > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > > > >
> > > > >   memset(, 0, sizeof(execbuf));
> > > > >   execbuf.buffers_ptr = to_user_pointer(gem_exec);
> > > > >   execbuf.buffer_count = 1;
> > > > > - execbuf.batch_start_offset = 0;
> > > > > - execbuf.batch_len = 8;
> > > > >   execbuf.flags = flags;
> > > > >
> > > > >   /* Avoid hitting slowpaths in the reloc processing which might 
> > > > > yield a
> > > > > @@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, 
> > > > > uint64_t batch_size, unsigned flags,
> > > > >  #undef reloc_ofs
> > > > >  }
> > > > >
> > > > > -igt_simple_main
> > > > > +static void exhaustive(int fd)
> > > > >  {
> > > > >   uint32_t batch[2] = {MI_BATCH_BUFFER_END};
> > > > >   uint64_t batch_size, max, ggtt_max, reloc_ofs;
> > > > > - int fd;
> > > > > -
> > > > > - fd = drm_open_driver(DRIVER_INTEL);
> > > > > - igt_require_gem(fd);
> > > > > -
> > > > > - use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8;
> > > > >
> > > > >   max = 3 * gem_aperture_size(fd) / 4;
> > > > >   ggtt_max = 3 * gem_global_aperture_size(fd) / 4;
> > > > > @@ -258,6 +251,61 @@ igt_simple_main
> > > > >   else
> > > > >   batch_size *= 2;
> > > > >   }
> > > > > +}
> > > > > +
> > > > > +static void single(int i915)
> > > > > +{
> > > > > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > > > > + uint64_t batch_size, limit;
> > > > > + uint32_t handle;
> > > > > + void *ptr;
> > > > > +
> > > > > + batch_size = (intel_get_avail_ram_mb() - 4) << 20; /* internal 
> > > > > slack */
> > > > > + limit = gem_aperture_size(i915) - (256 << 10); /* low pages 
> > > > > reserved */
> > > > > + if (!gem_uses_full_ppgtt(i915))
> > > > > + limit = 3 * limit / 4;
> > > > > +
> > > > > + batch_size = min(batch_size, limit);
> > > > > + batch_size = ALIGN(batch_size, 4096);
> > > > > + igt_info("Submitting a %'"PRId64"MiB batch, %saperture size 
> > > > > %'"PRId64"MiB\n",
> > > > > +  batch_size >> 20,
> > > > > +  gem_uses_full_ppgtt(i915) ? "" : "shared ",
> > > > > +  gem_aperture_size(i915) >> 20);
> > > > > + intel_require_memory(1, batch_size, CHECK_RAM);
> > > > > +
> > > > > + handle = gem_create(i915, batch_size);
> > > > > + gem_write(i915, handle, 0, , sizeof(bbe));
> > > > > +
> > > > > + if (!FORCE_PREAD_PWRITE && gem_has_llc(i915))
> > > > > + ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, 
> > > > > PROT_READ);
> > > > > + else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915))
> > > > > + ptr = __gem_mmap__wc(i915, handle, 0, batch_size, 
> > > > > PROT_READ);
> > > > > + else
> > > > > + ptr = NULL;
> > > > > +
> > > > > + execN(i915, handle, batch_size, 0, ptr);
> > > > > +
> > > > > + if (ptr)
> > > > > + munmap(ptr, batch_size);
> > > > > +}
> > > > > +
> > > > > +igt_main
> > > > > +{
> > > > > + int i915 = -1;
> > > > > +
> > > > > + igt_fixture {
> > > > > + i915 = 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Chris Wilson
Quoting Daniel Vetter (2019-02-13 13:02:29)
> On Wed, Feb 13, 2019 at 11:15 AM Chris Wilson  
> wrote:
> > Quoting Daniel Vetter (2019-02-13 10:11:27)
> > > On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> > > > CI complains that the exhaustive test of trying every size up to the
> > > > limit is too slow, so add a simple test that tries to submit one
> > > > extreme batch buffer and check all the relocations land.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
> > > > Signed-off-by: Chris Wilson 
> > > > ---
> > > >  tests/i915/gem_exec_big.c| 70 ++--
> > > >  tests/intel-ci/blacklist.txt |  1 +
> > > >  2 files changed, 60 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c
> > > > index a15672f66..6d7041cf4 100644
> > > > --- a/tests/i915/gem_exec_big.c
> > > > +++ b/tests/i915/gem_exec_big.c
> > > > @@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t 
> > > > reloc_ofs, unsigned flags, c
> > > >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> > > >   gem_exec[0].alignment = 0;
> > > >   gem_exec[0].offset = 0;
> > > > - gem_exec[0].flags = 0;
> > > > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > > >   gem_exec[0].rsvd1 = 0;
> > > >   gem_exec[0].rsvd2 = 0;
> > > >
> > > > @@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, 
> > > > uint64_t batch_size, unsigned flags,
> > > >   gem_exec[0].handle = handle;
> > > >   gem_exec[0].relocation_count = nreloc;
> > > >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> > > > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > > >
> > > >   memset(, 0, sizeof(execbuf));
> > > >   execbuf.buffers_ptr = to_user_pointer(gem_exec);
> > > >   execbuf.buffer_count = 1;
> > > > - execbuf.batch_start_offset = 0;
> > > > - execbuf.batch_len = 8;
> > > >   execbuf.flags = flags;
> > > >
> > > >   /* Avoid hitting slowpaths in the reloc processing which might 
> > > > yield a
> > > > @@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, 
> > > > uint64_t batch_size, unsigned flags,
> > > >  #undef reloc_ofs
> > > >  }
> > > >
> > > > -igt_simple_main
> > > > +static void exhaustive(int fd)
> > > >  {
> > > >   uint32_t batch[2] = {MI_BATCH_BUFFER_END};
> > > >   uint64_t batch_size, max, ggtt_max, reloc_ofs;
> > > > - int fd;
> > > > -
> > > > - fd = drm_open_driver(DRIVER_INTEL);
> > > > - igt_require_gem(fd);
> > > > -
> > > > - use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8;
> > > >
> > > >   max = 3 * gem_aperture_size(fd) / 4;
> > > >   ggtt_max = 3 * gem_global_aperture_size(fd) / 4;
> > > > @@ -258,6 +251,61 @@ igt_simple_main
> > > >   else
> > > >   batch_size *= 2;
> > > >   }
> > > > +}
> > > > +
> > > > +static void single(int i915)
> > > > +{
> > > > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > > > + uint64_t batch_size, limit;
> > > > + uint32_t handle;
> > > > + void *ptr;
> > > > +
> > > > + batch_size = (intel_get_avail_ram_mb() - 4) << 20; /* internal 
> > > > slack */
> > > > + limit = gem_aperture_size(i915) - (256 << 10); /* low pages 
> > > > reserved */
> > > > + if (!gem_uses_full_ppgtt(i915))
> > > > + limit = 3 * limit / 4;
> > > > +
> > > > + batch_size = min(batch_size, limit);
> > > > + batch_size = ALIGN(batch_size, 4096);
> > > > + igt_info("Submitting a %'"PRId64"MiB batch, %saperture size 
> > > > %'"PRId64"MiB\n",
> > > > +  batch_size >> 20,
> > > > +  gem_uses_full_ppgtt(i915) ? "" : "shared ",
> > > > +  gem_aperture_size(i915) >> 20);
> > > > + intel_require_memory(1, batch_size, CHECK_RAM);
> > > > +
> > > > + handle = gem_create(i915, batch_size);
> > > > + gem_write(i915, handle, 0, , sizeof(bbe));
> > > > +
> > > > + if (!FORCE_PREAD_PWRITE && gem_has_llc(i915))
> > > > + ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, 
> > > > PROT_READ);
> > > > + else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915))
> > > > + ptr = __gem_mmap__wc(i915, handle, 0, batch_size, 
> > > > PROT_READ);
> > > > + else
> > > > + ptr = NULL;
> > > > +
> > > > + execN(i915, handle, batch_size, 0, ptr);
> > > > +
> > > > + if (ptr)
> > > > + munmap(ptr, batch_size);
> > > > +}
> > > > +
> > > > +igt_main
> > > > +{
> > > > + int i915 = -1;
> > > > +
> > > > + igt_fixture {
> > > > + i915 = drm_open_driver(DRIVER_INTEL);
> > > > + igt_require_gem(i915);
> > > > +
> > > > + use_64bit_relocs = intel_gen(intel_get_drm_devid(i915)) 
> > > > >= 8;
> > > > + }
> > > > +
> > > > + igt_subtest("single")
> > > > + single(i915);
> > > > +
> > > > + 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Daniel Vetter
On Wed, Feb 13, 2019 at 11:15 AM Chris Wilson  wrote:
> Quoting Daniel Vetter (2019-02-13 10:11:27)
> > On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> > > CI complains that the exhaustive test of trying every size up to the
> > > limit is too slow, so add a simple test that tries to submit one
> > > extreme batch buffer and check all the relocations land.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
> > > Signed-off-by: Chris Wilson 
> > > ---
> > >  tests/i915/gem_exec_big.c| 70 ++--
> > >  tests/intel-ci/blacklist.txt |  1 +
> > >  2 files changed, 60 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c
> > > index a15672f66..6d7041cf4 100644
> > > --- a/tests/i915/gem_exec_big.c
> > > +++ b/tests/i915/gem_exec_big.c
> > > @@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t 
> > > reloc_ofs, unsigned flags, c
> > >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> > >   gem_exec[0].alignment = 0;
> > >   gem_exec[0].offset = 0;
> > > - gem_exec[0].flags = 0;
> > > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > >   gem_exec[0].rsvd1 = 0;
> > >   gem_exec[0].rsvd2 = 0;
> > >
> > > @@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, uint64_t 
> > > batch_size, unsigned flags,
> > >   gem_exec[0].handle = handle;
> > >   gem_exec[0].relocation_count = nreloc;
> > >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> > > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > >
> > >   memset(, 0, sizeof(execbuf));
> > >   execbuf.buffers_ptr = to_user_pointer(gem_exec);
> > >   execbuf.buffer_count = 1;
> > > - execbuf.batch_start_offset = 0;
> > > - execbuf.batch_len = 8;
> > >   execbuf.flags = flags;
> > >
> > >   /* Avoid hitting slowpaths in the reloc processing which might 
> > > yield a
> > > @@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, uint64_t 
> > > batch_size, unsigned flags,
> > >  #undef reloc_ofs
> > >  }
> > >
> > > -igt_simple_main
> > > +static void exhaustive(int fd)
> > >  {
> > >   uint32_t batch[2] = {MI_BATCH_BUFFER_END};
> > >   uint64_t batch_size, max, ggtt_max, reloc_ofs;
> > > - int fd;
> > > -
> > > - fd = drm_open_driver(DRIVER_INTEL);
> > > - igt_require_gem(fd);
> > > -
> > > - use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8;
> > >
> > >   max = 3 * gem_aperture_size(fd) / 4;
> > >   ggtt_max = 3 * gem_global_aperture_size(fd) / 4;
> > > @@ -258,6 +251,61 @@ igt_simple_main
> > >   else
> > >   batch_size *= 2;
> > >   }
> > > +}
> > > +
> > > +static void single(int i915)
> > > +{
> > > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > > + uint64_t batch_size, limit;
> > > + uint32_t handle;
> > > + void *ptr;
> > > +
> > > + batch_size = (intel_get_avail_ram_mb() - 4) << 20; /* internal 
> > > slack */
> > > + limit = gem_aperture_size(i915) - (256 << 10); /* low pages 
> > > reserved */
> > > + if (!gem_uses_full_ppgtt(i915))
> > > + limit = 3 * limit / 4;
> > > +
> > > + batch_size = min(batch_size, limit);
> > > + batch_size = ALIGN(batch_size, 4096);
> > > + igt_info("Submitting a %'"PRId64"MiB batch, %saperture size 
> > > %'"PRId64"MiB\n",
> > > +  batch_size >> 20,
> > > +  gem_uses_full_ppgtt(i915) ? "" : "shared ",
> > > +  gem_aperture_size(i915) >> 20);
> > > + intel_require_memory(1, batch_size, CHECK_RAM);
> > > +
> > > + handle = gem_create(i915, batch_size);
> > > + gem_write(i915, handle, 0, , sizeof(bbe));
> > > +
> > > + if (!FORCE_PREAD_PWRITE && gem_has_llc(i915))
> > > + ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, 
> > > PROT_READ);
> > > + else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915))
> > > + ptr = __gem_mmap__wc(i915, handle, 0, batch_size, 
> > > PROT_READ);
> > > + else
> > > + ptr = NULL;
> > > +
> > > + execN(i915, handle, batch_size, 0, ptr);
> > > +
> > > + if (ptr)
> > > + munmap(ptr, batch_size);
> > > +}
> > > +
> > > +igt_main
> > > +{
> > > + int i915 = -1;
> > > +
> > > + igt_fixture {
> > > + i915 = drm_open_driver(DRIVER_INTEL);
> > > + igt_require_gem(i915);
> > > +
> > > + use_64bit_relocs = intel_gen(intel_get_drm_devid(i915)) >= 
> > > 8;
> > > + }
> > > +
> > > + igt_subtest("single")
> > > + single(i915);
> > > +
> > > + igt_subtest("exhaustive")
> > > + exhaustive(i915);
> >
> > Do we still need this one? CI time isn't an endless resource (as much as
> > we'd want to), neither is our ability to maintain everything. And if all
> > we get is timeouts in CI I think there's better uses for that machine
> > time. 

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Chris Wilson
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson 
---
Continue the tweaking to see how much memory CI requires for java during
the middle of test execution. java, java, java!
---
 tests/i915/gem_exec_big.c| 70 ++--
 tests/intel-ci/blacklist.txt |  1 +
 2 files changed, 60 insertions(+), 11 deletions(-)

diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c
index a15672f66..015f59e29 100644
--- a/tests/i915/gem_exec_big.c
+++ b/tests/i915/gem_exec_big.c
@@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t 
reloc_ofs, unsigned flags, c
gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
gem_exec[0].alignment = 0;
gem_exec[0].offset = 0;
-   gem_exec[0].flags = 0;
+   gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
gem_exec[0].rsvd1 = 0;
gem_exec[0].rsvd2 = 0;
 
@@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, uint64_t 
batch_size, unsigned flags,
gem_exec[0].handle = handle;
gem_exec[0].relocation_count = nreloc;
gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
+   gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
 
memset(, 0, sizeof(execbuf));
execbuf.buffers_ptr = to_user_pointer(gem_exec);
execbuf.buffer_count = 1;
-   execbuf.batch_start_offset = 0;
-   execbuf.batch_len = 8;
execbuf.flags = flags;
 
/* Avoid hitting slowpaths in the reloc processing which might yield a
@@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, uint64_t 
batch_size, unsigned flags,
 #undef reloc_ofs
 }
 
-igt_simple_main
+static void exhaustive(int fd)
 {
uint32_t batch[2] = {MI_BATCH_BUFFER_END};
uint64_t batch_size, max, ggtt_max, reloc_ofs;
-   int fd;
-
-   fd = drm_open_driver(DRIVER_INTEL);
-   igt_require_gem(fd);
-
-   use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8;
 
max = 3 * gem_aperture_size(fd) / 4;
ggtt_max = 3 * gem_global_aperture_size(fd) / 4;
@@ -258,6 +251,61 @@ igt_simple_main
else
batch_size *= 2;
}
+}
+
+static void single(int i915)
+{
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   uint64_t batch_size, limit;
+   uint32_t handle;
+   void *ptr;
+
+   batch_size = (intel_get_avail_ram_mb() - 128) << 20; /* CI slack */
+   limit = gem_aperture_size(i915) - (256 << 10); /* low pages reserved */
+   if (!gem_uses_full_ppgtt(i915))
+   limit = 3 * limit / 4;
+
+   batch_size = min(batch_size, limit);
+   batch_size = ALIGN(batch_size, 4096);
+   igt_info("Submitting a %'"PRId64"MiB batch, %saperture size 
%'"PRId64"MiB\n",
+batch_size >> 20,
+gem_uses_full_ppgtt(i915) ? "" : "shared ",
+gem_aperture_size(i915) >> 20);
+   intel_require_memory(1, batch_size, CHECK_RAM);
+
+   handle = gem_create(i915, batch_size);
+   gem_write(i915, handle, 0, , sizeof(bbe));
+
+   if (!FORCE_PREAD_PWRITE && gem_has_llc(i915))
+   ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, PROT_READ);
+   else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915))
+   ptr = __gem_mmap__wc(i915, handle, 0, batch_size, PROT_READ);
+   else
+   ptr = NULL;
+
+   execN(i915, handle, batch_size, 0, ptr);
+
+   if (ptr)
+   munmap(ptr, batch_size);
+}
+
+igt_main
+{
+   int i915 = -1;
+
+   igt_fixture {
+   i915 = drm_open_driver(DRIVER_INTEL);
+   igt_require_gem(i915);
+
+   use_64bit_relocs = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   }
+
+   igt_subtest("single")
+   single(i915);
+
+   igt_subtest("exhaustive")
+   exhaustive(i915);
 
-   close(fd);
+   igt_fixture
+   close(i915);
 }
diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
index cef0da84a..0e6beeae4 100644
--- a/tests/intel-ci/blacklist.txt
+++ b/tests/intel-ci/blacklist.txt
@@ -28,6 +28,7 @@ igt@gem_ctx_thrash(@.*)?
 igt@gem_evict_alignment(@.*)?
 igt@gem_evict_everything(@.*)?
 igt@gem_exec_alignment@(?!.*single).*
+igt@gem_exec_big@(?!.*single).*
 igt@gem_exec_capture@many-(?!4K-).*
 igt@gem_exec_fence@(?!.*basic).*
 igt@gem_exec_flush@(?!.*basic).*
-- 
2.20.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Patchwork
== Series Details ==

Series: i915/gem_exec_big: Add a single shot test
URL   : https://patchwork.freedesktop.org/series/56595/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5596_full -> IGTPW_2390_full


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56595/revisions/1/mbox/

New tests
-

  New tests have been introduced between CI_DRM_5596_full and IGTPW_2390_full:
Known issues


  Here are the changes found in IGTPW_2390_full that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-snb:  PASS -> INCOMPLETE [fdo#105411]

  * igt@i915_suspend@shrink:
- shard-kbl:  NOTRUN -> DMESG-WARN [fdo#109244]

  * igt@kms_available_modes_crc@available_mode_test_crc:
- shard-kbl:  NOTRUN -> FAIL [fdo#106641]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-kbl:  NOTRUN -> DMESG-WARN [fdo#107956] +2

  * igt@kms_content_protection@legacy:
- shard-kbl:  NOTRUN -> FAIL [fdo#108597]

  * igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-glk:  NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl:  PASS -> FAIL [fdo#103232] +6

  * igt@kms_cursor_crc@cursor-64x64-sliding:
- shard-kbl:  NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-glk:  PASS -> FAIL [fdo#109350]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-apl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-apl:  NOTRUN -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt:
- shard-glk:  PASS -> FAIL [fdo#103167] +2

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite:
- shard-glk:  NOTRUN -> FAIL [fdo#103167]

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-glk:  PASS -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] / [fdo#108590] +3

  * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] +4

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-apl:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-glk:  PASS -> FAIL [fdo#103166]

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-hsw:  PASS -> FAIL [fdo#104894]

  * igt@pm_rps@reset:
- shard-glk:  PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]

  
 Possible fixes 

  * igt@gem_exec_create@forked:
- shard-hsw:  INCOMPLETE [fdo#103540] -> PASS

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk:  FAIL [fdo#108145] -> PASS

  * igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl:  FAIL [fdo#103232] -> PASS +4

  * igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl:  FAIL [fdo#103191] / [fdo#103232] -> PASS

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  FAIL [fdo#105767] -> PASS

  * igt@kms_flip@basic-flip-vs-modeset:
- shard-hsw:  DMESG-WARN [fdo#102614] -> PASS

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-glk:  FAIL [fdo#102887] / [fdo#105363] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-apl:  FAIL [fdo#103167] -> PASS +2

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk:  FAIL [fdo#103167] -> PASS +1

  * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-apl:  FAIL [fdo#108948] -> PASS

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk:  FAIL [fdo#108948] -> PASS
- shard-apl:  INCOMPLETE [fdo#103927] -> PASS

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-glk:  FAIL [fdo#103166] -> PASS +4
- shard-apl:  FAIL [fdo#103166] -> PASS +3

  * igt@kms_setmode@clone-exclusive-crtc:
- shard-glk:  INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS +1

  
 Warnings 

  * igt@gem_busy@extended-parallel-bsd:
- shard-snb:  {SKIP} [fdo#109271] -> INCOMPLETE [fdo#105411]

  * igt@i915_suspend@shrink:
- shard-glk:  INCOMPLETE [fdo#103359] / [fdo#106886] / 
[k.org#198133] -> DMESG-WARN [fdo#109244]

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  

[Intel-gfx] [PULL] drm-intel-fixes

2019-02-13 Thread Jani Nikula

Hi Dave and Daniel, perhaps slightly more than I'd like at this stage,
but didn't really want to drop anything either...

BR,
Jani.

The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9:

  Linux 5.0-rc6 (2019-02-10 14:42:20 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-02-13

for you to fetch changes up to 16eb0f34cdf4cf04cd92762c7a79f98aa51e053f:

  drm/i915/opregion: rvda is relative from opregion base in opregion 2.1+ 
(2019-02-12 15:37:58 +0200)


drm/i915 fixes for v5.0-rc7:
- combo phy programming fix
- opregion version check fix for VBT RVDA lookup
- gem mmap ioctl race fix
- fbdev hpd during suspend fix
- array size bounds check fix in pmu


Aditya Swarup (1):
  drm/i915/cnl: Fix CNL macros for Voltage Swing programming

Clint Taylor (1):
  drm/i915/icl: combo port vswing programming changes per BSPEC

Jani Nikula (2):
  drm/i915/opregion: fix version check
  drm/i915/opregion: rvda is relative from opregion base in opregion 2.1+

Joonas Lahtinen (1):
  drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set

Lyude Paul (1):
  drm/i915: Block fbdev HPD processing during suspend

Tvrtko Ursulin (1):
  drm/i915/pmu: Fix enable count array size and bounds checking

 drivers/gpu/drm/i915/i915_gem.c |  12 +-
 drivers/gpu/drm/i915/i915_pmu.c |  22 ++-
 drivers/gpu/drm/i915/i915_pmu.h |   2 +
 drivers/gpu/drm/i915/i915_reg.h |  18 ++-
 drivers/gpu/drm/i915/intel_ddi.c| 238 
 drivers/gpu/drm/i915/intel_dp.c |   4 +-
 drivers/gpu/drm/i915/intel_drv.h|  10 ++
 drivers/gpu/drm/i915/intel_fbdev.c  |  33 -
 drivers/gpu/drm/i915/intel_opregion.c   |  38 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |   9 +-
 10 files changed, 208 insertions(+), 178 deletions(-)

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

Re: [Intel-gfx] [v15 3/4] drm: Add colorspace info to AVI Infoframe

2019-02-13 Thread Shankar, Uma


>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Wednesday, February 13, 2019 4:34 PM
>To: Shankar, Uma 
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala, 
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject: Re: [v15 3/4] drm: Add colorspace info to AVI Infoframe
>
>On Tue, Feb 12, 2019 at 09:30:50PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Tuesday, February 12, 2019 10:35 PM
>> >To: Shankar, Uma 
>> >Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>> >Syrjala, Ville ; emil.l.veli...@gmail.com;
>> >Lankhorst, Maarten 
>> >Subject: Re: [v15 3/4] drm: Add colorspace info to AVI Infoframe
>> >
>> >On Fri, Feb 08, 2019 at 11:54:55PM +0530, Uma Shankar wrote:
>> >> This adds colorspace information to HDMI AVI infoframe.
>> >> A helper function is added to program the same.
>> >>
>> >> v2: Moved this to drm core instead of i915 driver.
>> >>
>> >> v3: Exported the helper function.
>> >>
>> >> v4: Added separate HDMI specific macro as per CTA spec.
>> >> This is separate from user exposed enum values. This is as per
>> >> Ville's suggestion.
>> >>
>> >> v5: Appended BT709 and SMPTE 170M with YCC information as per
>> >> Ville's review comment to be clear and not to be confused with RGB.
>> >>
>> >> Signed-off-by: Uma Shankar 
>> >> ---
>> >>  drivers/gpu/drm/drm_edid.c  | 57
>> >> +
>> >>  include/drm/drm_connector.h | 20 
>> >>  include/drm/drm_edid.h  |  6 +
>> >>  3 files changed, 83 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_edid.c
>> >> b/drivers/gpu/drm/drm_edid.c index 990b190..5202fea 100644
>> >> --- a/drivers/gpu/drm/drm_edid.c
>> >> +++ b/drivers/gpu/drm/drm_edid.c
>> >> @@ -4925,6 +4925,63 @@ static bool is_hdmi2_sink(struct
>> >> drm_connector
>> >> *connector)
>> >> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
>> >>
>> >>  /**
>> >> + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
>> >> + *   colorspace information
>> >> + * @frame: HDMI AVI infoframe
>> >> + * @conn_state: connector state
>> >> + */
>> >> +void
>> >> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
>> >> +   const struct drm_connector_state *conn_state) 
>> >> {
>> >> + u32 colorimetry_val = conn_state->colorspace &
>> >> + FULL_COLORIMETRY_MASK;
>> >> +
>> >> + switch (colorimetry_val) {
>> >> + case DRM_MODE_COLORIMETRY_NO_DATA:
>> >> + colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
>> >> + break;
>> >> + case HDMI_COLORIMETRY_SMPTE_170M_YCC:
>> >> + colorimetry_val = HDMI_COLORIMETRY_SMPTE_170M_YCC;
>> >> + break;
>> >> + case DRM_MODE_COLORIMETRY_BT709_YCC:
>> >> + colorimetry_val = HDMI_COLORIMETRY_BT709_YCC;
>> >> + break;
>> >> + case DRM_MODE_COLORIMETRY_XVYCC_601:
>> >> + colorimetry_val = HDMI_COLORIMETRY_XVYCC_601;
>> >> + break;
>> >> + case DRM_MODE_COLORIMETRY_XVYCC_709:
>> >> + colorimetry_val = HDMI_COLORIMETRY_XVYCC_709;
>> >> + break;
>> >> + case DRM_MODE_COLORIMETRY_SYCC_601:
>> >> + colorimetry_val = HDMI_COLORIMETRY_SYCC_601;
>> >> + break;
>> >> + case DRM_MODE_COLORIMETRY_OPYCC_601:
>> >> + colorimetry_val = HDMI_COLORIMETRY_OPYCC_601;
>> >> + break;
>> >> + case DRM_MODE_COLORIMETRY_OPRGB:
>> >> + colorimetry_val = HDMI_COLORIMETRY_OPRGB;
>> >> + break;
>> >> + case DRM_MODE_COLORIMETRY_BT2020_RGB:
>> >> + case DRM_MODE_COLORIMETRY_BT2020_YCC:
>> >> + colorimetry_val = HDMI_COLORIMETRY_BT2020_RGB;
>> >> + break;
>> >> + case DRM_MODE_COLORIMETRY_BT2020_CYCC:
>> >> + colorimetry_val = HDMI_COLORIMETRY_BT2020_CYCC;
>> >> + break;
>> >> + default:
>> >> + /* ToDo: DCI-P3 will be handled as part of ACE enabling */
>> >> + colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
>> >> + break;
>> >> + }
>> >
>> >A table would probably be prettier.
>>
>> Ok, I will add that as table.
>>
>> >> +
>> >> + frame->colorimetry = colorimetry_val & NORMAL_COLORIMETRY_MASK;
>> >> + frame->extended_colorimetry = (colorimetry_val >> 2) &
>> >> + EXTENDED_COLORIMETRY_MASK;
>> >> +}
>> >> +EXPORT_SYMBOL(drm_hdmi_avi_infoframe_colorspace);
>> >> +
>> >> +/**
>> >>   * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
>> >>   *quantization range information
>> >>   * @frame: HDMI AVI infoframe
>> >> diff --git a/include/drm/drm_connector.h
>> >> b/include/drm/drm_connector.h index 4d9aa2f..efacf29 100644
>> >> --- a/include/drm/drm_connector.h
>> >> +++ b/include/drm/drm_connector.h
>> >> @@ -288,6 +288,26 @@ enum drm_panel_orientation {
>> >>  

Re: [Intel-gfx] [v15 3/4] drm: Add colorspace info to AVI Infoframe

2019-02-13 Thread Ville Syrjälä
On Tue, Feb 12, 2019 at 09:30:50PM +, Shankar, Uma wrote:
> 
> 
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, February 12, 2019 10:35 PM
> >To: Shankar, Uma 
> >Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
> >Syrjala, Ville
> >; emil.l.veli...@gmail.com; Lankhorst, Maarten
> >
> >Subject: Re: [v15 3/4] drm: Add colorspace info to AVI Infoframe
> >
> >On Fri, Feb 08, 2019 at 11:54:55PM +0530, Uma Shankar wrote:
> >> This adds colorspace information to HDMI AVI infoframe.
> >> A helper function is added to program the same.
> >>
> >> v2: Moved this to drm core instead of i915 driver.
> >>
> >> v3: Exported the helper function.
> >>
> >> v4: Added separate HDMI specific macro as per CTA spec.
> >> This is separate from user exposed enum values. This is as per Ville's
> >> suggestion.
> >>
> >> v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
> >> review comment to be clear and not to be confused with RGB.
> >>
> >> Signed-off-by: Uma Shankar 
> >> ---
> >>  drivers/gpu/drm/drm_edid.c  | 57
> >> +
> >>  include/drm/drm_connector.h | 20 
> >>  include/drm/drm_edid.h  |  6 +
> >>  3 files changed, 83 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 990b190..5202fea 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -4925,6 +4925,63 @@ static bool is_hdmi2_sink(struct drm_connector
> >> *connector)  EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
> >>
> >>  /**
> >> + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
> >> + *   colorspace information
> >> + * @frame: HDMI AVI infoframe
> >> + * @conn_state: connector state
> >> + */
> >> +void
> >> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
> >> +const struct drm_connector_state *conn_state) 
> >> {
> >> +  u32 colorimetry_val = conn_state->colorspace &
> >> +  FULL_COLORIMETRY_MASK;
> >> +
> >> +  switch (colorimetry_val) {
> >> +  case DRM_MODE_COLORIMETRY_NO_DATA:
> >> +  colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
> >> +  break;
> >> +  case HDMI_COLORIMETRY_SMPTE_170M_YCC:
> >> +  colorimetry_val = HDMI_COLORIMETRY_SMPTE_170M_YCC;
> >> +  break;
> >> +  case DRM_MODE_COLORIMETRY_BT709_YCC:
> >> +  colorimetry_val = HDMI_COLORIMETRY_BT709_YCC;
> >> +  break;
> >> +  case DRM_MODE_COLORIMETRY_XVYCC_601:
> >> +  colorimetry_val = HDMI_COLORIMETRY_XVYCC_601;
> >> +  break;
> >> +  case DRM_MODE_COLORIMETRY_XVYCC_709:
> >> +  colorimetry_val = HDMI_COLORIMETRY_XVYCC_709;
> >> +  break;
> >> +  case DRM_MODE_COLORIMETRY_SYCC_601:
> >> +  colorimetry_val = HDMI_COLORIMETRY_SYCC_601;
> >> +  break;
> >> +  case DRM_MODE_COLORIMETRY_OPYCC_601:
> >> +  colorimetry_val = HDMI_COLORIMETRY_OPYCC_601;
> >> +  break;
> >> +  case DRM_MODE_COLORIMETRY_OPRGB:
> >> +  colorimetry_val = HDMI_COLORIMETRY_OPRGB;
> >> +  break;
> >> +  case DRM_MODE_COLORIMETRY_BT2020_RGB:
> >> +  case DRM_MODE_COLORIMETRY_BT2020_YCC:
> >> +  colorimetry_val = HDMI_COLORIMETRY_BT2020_RGB;
> >> +  break;
> >> +  case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> >> +  colorimetry_val = HDMI_COLORIMETRY_BT2020_CYCC;
> >> +  break;
> >> +  default:
> >> +  /* ToDo: DCI-P3 will be handled as part of ACE enabling */
> >> +  colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
> >> +  break;
> >> +  }
> >
> >A table would probably be prettier.
> 
> Ok, I will add that as table.
> 
> >> +
> >> +  frame->colorimetry = colorimetry_val & NORMAL_COLORIMETRY_MASK;
> >> +  frame->extended_colorimetry = (colorimetry_val >> 2) &
> >> +  EXTENDED_COLORIMETRY_MASK;
> >> +}
> >> +EXPORT_SYMBOL(drm_hdmi_avi_infoframe_colorspace);
> >> +
> >> +/**
> >>   * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
> >>   *quantization range information
> >>   * @frame: HDMI AVI infoframe
> >> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> >> index 4d9aa2f..efacf29 100644
> >> --- a/include/drm/drm_connector.h
> >> +++ b/include/drm/drm_connector.h
> >> @@ -288,6 +288,26 @@ enum drm_panel_orientation {
> >>  #define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT16
> >>  #define DRM_MODE_DP_COLORIMETRY_SCRGB 17
> >>
> >> +/* HDMI Colorspace Spec Definitions */
> >> +#define FULL_COLORIMETRY_MASK 0x1FF
> >> +#define NORMAL_COLORIMETRY_MASK   0x3
> >> +#define EXTENDED_COLORIMETRY_MASK 0x7
> >> +#define EXTENDED_ACE_COLORIMETRY_MASK 

Re: [Intel-gfx] [v9 5/5] drm/i915/icl: Add degamma and gamma lut size to gen11 caps

2019-02-13 Thread Maarten Lankhorst
Op 11-02-2019 om 14:50 schreef Uma Shankar:
> Add the degamma and gamma lut sizes to gen11 capability
> structure.
>
> Note: Currently this doesn't account for the extended range gamma
> entries and this will be addressed with new segmented gamma ABI
> in a future patch.
>
> v2: Reorder the patch as per Maarten's suggestion.
>
> v3: Rebase
>
> v4: Updated commit message with a note as per Matt's suggestion.
>
> v5: No Change.
>
> Signed-off-by: Uma Shankar 
> Reviewed-by: Matt Roper 
> Reviewed-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 2a4d25c..c4d6b8d 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -648,7 +648,8 @@
>   }, \
>   GEN(11), \
>   .ddb_size = 2048, \
> - .has_logical_ring_elsq = 1
> + .has_logical_ring_elsq = 1, \
> + .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
>  
>  static const struct intel_device_info intel_icelake_11_info = {
>   GEN11_FEATURES,

Thanks, pushed. :)

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

[Intel-gfx] [PATCH 3/4] drm/i915: Remove access to global seqno in the HWSP

2019-02-13 Thread Chris Wilson
Stop accessing the HWSP to read the global seqno, and stop tracking the
mirror in the engine's execution timeline -- it is unused.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gpu_error.c |  4 --
 drivers/gpu/drm/i915/i915_gpu_error.h |  3 --
 drivers/gpu/drm/i915/i915_request.c   | 27 +
 drivers/gpu/drm/i915/i915_reset.c |  1 -
 drivers/gpu/drm/i915/intel_engine_cs.c| 14 +--
 drivers/gpu/drm/i915/intel_lrc.c  | 21 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  7 +---
 drivers/gpu/drm/i915/intel_ringbuffer.h   | 40 ---
 drivers/gpu/drm/i915/selftests/i915_request.c |  3 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  3 --
 10 files changed, 19 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9a65341fec09..a674c78ca1f8 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -533,8 +533,6 @@ static void error_print_engine(struct 
drm_i915_error_state_buf *m,
   ee->vm_info.pp_dir_base);
}
}
-   err_printf(m, "  seqno: 0x%08x\n", ee->seqno);
-   err_printf(m, "  last_seqno: 0x%08x\n", ee->last_seqno);
err_printf(m, "  ring->head: 0x%08x\n", ee->cpu_ring_head);
err_printf(m, "  ring->tail: 0x%08x\n", ee->cpu_ring_tail);
err_printf(m, "  hangcheck timestamp: %dms (%lu%s)\n",
@@ -1227,8 +1225,6 @@ static void error_record_engine_registers(struct 
i915_gpu_state *error,
 
ee->instpm = I915_READ(RING_INSTPM(engine->mmio_base));
ee->acthd = intel_engine_get_active_head(engine);
-   ee->seqno = intel_engine_get_seqno(engine);
-   ee->last_seqno = intel_engine_last_submit(engine);
ee->start = I915_READ_START(engine);
ee->head = I915_READ_HEAD(engine);
ee->tail = I915_READ_TAIL(engine);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index afa3adb28f02..0bdcd557a9ce 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -94,8 +94,6 @@ struct i915_gpu_state {
u32 cpu_ring_head;
u32 cpu_ring_tail;
 
-   u32 last_seqno;
-
/* Register state */
u32 start;
u32 tail;
@@ -108,7 +106,6 @@ struct i915_gpu_state {
u32 bbstate;
u32 instpm;
u32 instps;
-   u32 seqno;
u64 bbaddr;
u64 acthd;
u32 fault_reg;
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index c2a5c48c7541..761ecb601d8a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -177,12 +177,11 @@ static void free_capture_list(struct i915_request 
*request)
 static void __retire_engine_request(struct intel_engine_cs *engine,
struct i915_request *rq)
 {
-   GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d:%d\n",
+   GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d\n",
  __func__, engine->name,
  rq->fence.context, rq->fence.seqno,
  rq->global_seqno,
- hwsp_seqno(rq),
- intel_engine_get_seqno(engine));
+ hwsp_seqno(rq));
 
GEM_BUG_ON(!i915_request_completed(rq));
 
@@ -241,12 +240,11 @@ static void i915_request_retire(struct i915_request 
*request)
 {
struct i915_active_request *active, *next;
 
-   GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
+   GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
  request->engine->name,
  request->fence.context, request->fence.seqno,
  request->global_seqno,
- hwsp_seqno(request),
- intel_engine_get_seqno(request->engine));
+ hwsp_seqno(request));
 
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
@@ -305,12 +303,11 @@ void i915_request_retire_upto(struct i915_request *rq)
struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
 
-   GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
+   GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
  rq->engine->name,
  rq->fence.context, rq->fence.seqno,
  rq->global_seqno,
- hwsp_seqno(rq),
- intel_engine_get_seqno(rq->engine));
+ hwsp_seqno(rq));
 
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_request_completed(rq));
@@ -354,12 +351,11 @@ void __i915_request_submit(struct i915_request *request)

[Intel-gfx] [PATCH 1/4] drm/i915/pmu: Always sample an active ringbuffer

2019-02-13 Thread Chris Wilson
As we no longer have a precise indication of requests queued to an
engine, make no presumptions and just sample the ring registers to see
if the engine is busy.

v2: Report busy while the ring is idling on a semaphore/event.
v3: Give the struct a name!
v4: Always 0 outside the powerwell; trusting the powerwell is
accurate enough for our sampling pmu.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 60 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 2 files changed, 24 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 13d70b90dd0f..21adad72bd86 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -148,14 +148,6 @@ void i915_pmu_gt_unparked(struct drm_i915_private *i915)
spin_unlock_irq(>pmu.lock);
 }
 
-static bool grab_forcewake(struct drm_i915_private *i915, bool fw)
-{
-   if (!fw)
-   intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
-
-   return true;
-}
-
 static void
 add_sample(struct i915_pmu_sample *sample, u32 val)
 {
@@ -168,49 +160,43 @@ engines_sample(struct drm_i915_private *dev_priv, 
unsigned int period_ns)
struct intel_engine_cs *engine;
enum intel_engine_id id;
intel_wakeref_t wakeref;
-   bool fw = false;
 
if ((dev_priv->pmu.enable & ENGINE_SAMPLE_MASK) == 0)
return;
 
-   if (!dev_priv->gt.awake)
-   return;
-
-   wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
+   wakeref = 0;
+   if (READ_ONCE(dev_priv->gt.awake))
+   wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
if (!wakeref)
return;
 
for_each_engine(engine, dev_priv, id) {
-   u32 current_seqno = intel_engine_get_seqno(engine);
-   u32 last_seqno = intel_engine_last_submit(engine);
+   struct intel_engine_pmu *pmu = >pmu;
+   bool busy;
u32 val;
 
-   val = !i915_seqno_passed(current_seqno, last_seqno);
-
-   if (val)
-   add_sample(>pmu.sample[I915_SAMPLE_BUSY],
-  period_ns);
-
-   if (val && (engine->pmu.enable &
-   (BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
-   fw = grab_forcewake(dev_priv, fw);
-
-   val = I915_READ_FW(RING_CTL(engine->mmio_base));
-   } else {
-   val = 0;
-   }
+   val = I915_READ_FW(RING_CTL(engine->mmio_base));
+   if (val == 0) /* powerwell off => engine idle */
+   continue;
 
if (val & RING_WAIT)
-   add_sample(>pmu.sample[I915_SAMPLE_WAIT],
-  period_ns);
-
+   add_sample(>sample[I915_SAMPLE_WAIT], period_ns);
if (val & RING_WAIT_SEMAPHORE)
-   add_sample(>pmu.sample[I915_SAMPLE_SEMA],
-  period_ns);
-   }
+   add_sample(>sample[I915_SAMPLE_SEMA], period_ns);
 
-   if (fw)
-   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+   /*
+* MI_MODE reports IDLE if the ring is waiting, but we regard
+* this as being busy instead, as the engine is busy with the
+* user request.
+*/
+   busy = val & (RING_WAIT_SEMAPHORE | RING_WAIT);
+   if (!busy) {
+   val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
+   busy = !(val & MODE_IDLE);
+   }
+   if (busy)
+   add_sample(>sample[I915_SAMPLE_BUSY], period_ns);
+   }
 
intel_runtime_pm_put(dev_priv, wakeref);
 }
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 710ffb221775..5d45ad4ecca9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -392,7 +392,7 @@ struct intel_engine_cs {
bool irq_armed;
} breadcrumbs;
 
-   struct {
+   struct intel_engine_pmu {
/**
 * @enable: Bitmask of enable sample events on this engine.
 *
-- 
2.20.1

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

[Intel-gfx] [PATCH 4/4] drm/i915: Remove i915_request.global_seqno

2019-02-13 Thread Chris Wilson
Having weaned the interrupt handling off using a single global execution
queue, we no longer need to emit a global_seqno. Note that we still have
a few assumptions about execution order along engine timelines, but this
removes the most obvious artefact!

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 35 ++---
 drivers/gpu/drm/i915/i915_gpu_error.h |  2 -
 drivers/gpu/drm/i915/i915_request.c   | 31 ++--
 drivers/gpu/drm/i915/i915_request.h   | 32 
 drivers/gpu/drm/i915/i915_trace.h | 25 +++---
 drivers/gpu/drm/i915/intel_engine_cs.c|  5 +-
 drivers/gpu/drm/i915/intel_guc_submission.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c  | 34 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c   | 50 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  2 -
 .../gpu/drm/i915/selftests/intel_hangcheck.c  |  5 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  1 -
 12 files changed, 31 insertions(+), 193 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a674c78ca1f8..8792ad12373d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -380,19 +380,16 @@ static void print_error_buffers(struct 
drm_i915_error_state_buf *m,
err_printf(m, "%s [%d]:\n", name, count);
 
while (count--) {
-   err_printf(m, "%08x_%08x %8u %02x %02x %02x",
+   err_printf(m, "%08x_%08x %8u %02x %02x",
   upper_32_bits(err->gtt_offset),
   lower_32_bits(err->gtt_offset),
   err->size,
   err->read_domains,
-  err->write_domain,
-  err->wseqno);
+  err->write_domain);
err_puts(m, tiling_flag(err->tiling));
err_puts(m, dirty_flag(err->dirty));
err_puts(m, purgeable_flag(err->purgeable));
err_puts(m, err->userptr ? " userptr" : "");
-   err_puts(m, err->engine != -1 ? " " : "");
-   err_puts(m, engine_name(m->i915, err->engine));
err_puts(m, i915_cache_level_str(m->i915, err->cache_level));
 
if (err->name)
@@ -1059,27 +1056,6 @@ i915_error_object_create(struct drm_i915_private *i915,
return dst;
 }
 
-/* The error capture is special as tries to run underneath the normal
- * locking rules - so we use the raw version of the i915_active_request lookup.
- */
-static inline u32
-__active_get_seqno(struct i915_active_request *active)
-{
-   struct i915_request *request;
-
-   request = __i915_active_request_peek(active);
-   return request ? request->global_seqno : 0;
-}
-
-static inline int
-__active_get_engine_id(struct i915_active_request *active)
-{
-   struct i915_request *request;
-
-   request = __i915_active_request_peek(active);
-   return request ? request->engine->id : -1;
-}
-
 static void capture_bo(struct drm_i915_error_buffer *err,
   struct i915_vma *vma)
 {
@@ -1088,9 +1064,6 @@ static void capture_bo(struct drm_i915_error_buffer *err,
err->size = obj->base.size;
err->name = obj->base.name;
 
-   err->wseqno = __active_get_seqno(>frontbuffer_write);
-   err->engine = __active_get_engine_id(>frontbuffer_write);
-
err->gtt_offset = vma->node.start;
err->read_domains = obj->read_domains;
err->write_domain = obj->write_domain;
@@ -1295,10 +1268,10 @@ static void record_request(struct i915_request *request,
struct i915_gem_context *ctx = request->gem_context;
 
erq->flags = request->fence.flags;
-   erq->context = ctx->hw_id;
+   erq->context = request->fence.context;
+   erq->seqno = request->fence.seqno;
erq->sched_attr = request->sched.attr;
erq->ban_score = atomic_read(>ban_score);
-   erq->seqno = request->global_seqno;
erq->jiffies = request->emitted_jiffies;
erq->start = i915_ggtt_offset(request->ring->vma);
erq->head = request->head;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 0bdcd557a9ce..1ca81a720c5b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -167,7 +167,6 @@ struct i915_gpu_state {
struct drm_i915_error_buffer {
u32 size;
u32 name;
-   u32 wseqno;
u64 gtt_offset;
u32 read_domains;
u32 write_domain;
@@ -176,7 +175,6 @@ struct i915_gpu_state {
u32 dirty:1;
u32 purgeable:1;
u32 userptr:1;
-   s32 engine:4;
u32 cache_level:3;
} *active_bo[I915_NUM_ENGINES], *pinned_bo;
u32 

[Intel-gfx] [PATCH 2/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-13 Thread Chris Wilson
To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests will then be completed, we use a primitive random number
generator instead (with a cycle long enough to not matter over an
interval of a few thousand requests between hangcheck samples).

The alternative to using a dedicated seqno on every request is to issue
a heartbeat request and query its progress through the system. Sadly
this requires us to reduce struct_mutex so that we can issue requests
without requiring that bkl.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  7 ++---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  5 ++--
 drivers/gpu/drm/i915/intel_hangcheck.c  |  6 ++---
 drivers/gpu/drm/i915/intel_lrc.c| 15 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 19 -
 6 files changed, 77 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 13bdf326287b..69de9a0c8c38 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1295,7 +1295,7 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
with_intel_runtime_pm(dev_priv, wakeref) {
for_each_engine(engine, dev_priv, id) {
acthd[id] = intel_engine_get_active_head(engine);
-   seqno[id] = intel_engine_get_seqno(engine);
+   seqno[id] = intel_engine_get_hangcheck_seqno(engine);
}
 
intel_engine_get_instdone(dev_priv->engine[RCS], );
@@ -1315,8 +1315,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
for_each_engine(engine, dev_priv, id) {
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
-  engine->hangcheck.seqno, seqno[id],
-  intel_engine_last_submit(engine),
+  engine->hangcheck.last_seqno,
+  seqno[id],
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies -

engine->hangcheck.action_timestamp));
 
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 2547e2e51db8..26cfb24caa5f 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1499,10 +1499,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_terminally_wedged(>i915->gpu_error))
drm_printf(m, "*** WEDGED ***\n");
 
-   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms]\n",
+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x/%x [%d ms]\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
-  engine->hangcheck.seqno,
+  engine->hangcheck.last_seqno,
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp));
drm_printf(m, "\tReset count: %d (global %d)\n",
   i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index a219c796e56d..e04b2560369e 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -133,21 +133,21 @@ static void hangcheck_load_sample(struct intel_engine_cs 
*engine,
  struct hangcheck *hc)
 {
hc->acthd = intel_engine_get_active_head(engine);
-   hc->seqno = intel_engine_get_seqno(engine);
+   hc->seqno = intel_engine_get_hangcheck_seqno(engine);
 }
 
 static void hangcheck_store_sample(struct intel_engine_cs *engine,
   const struct hangcheck *hc)
 {
engine->hangcheck.acthd = hc->acthd;
-   engine->hangcheck.seqno = hc->seqno;
+   engine->hangcheck.last_seqno = hc->seqno;
 }
 
 static enum intel_engine_hangcheck_action
 hangcheck_get_action(struct intel_engine_cs *engine,
 const struct hangcheck *hc)
 {
-   if (engine->hangcheck.seqno != hc->seqno)
+   if (engine->hangcheck.last_seqno != hc->seqno)
return ENGINE_ACTIVE_SEQNO;
 
if (intel_engine_is_idle(engine))
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a62791a30c7e..6541eeb9d360 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -178,6 +178,12 @@ static inline u32 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Chris Wilson
Quoting Daniel Vetter (2019-02-13 10:11:27)
> On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> > CI complains that the exhaustive test of trying every size up to the
> > limit is too slow, so add a simple test that tries to submit one
> > extreme batch buffer and check all the relocations land.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
> > Signed-off-by: Chris Wilson 
> > ---
> >  tests/i915/gem_exec_big.c| 70 ++--
> >  tests/intel-ci/blacklist.txt |  1 +
> >  2 files changed, 60 insertions(+), 11 deletions(-)
> > 
> > diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c
> > index a15672f66..6d7041cf4 100644
> > --- a/tests/i915/gem_exec_big.c
> > +++ b/tests/i915/gem_exec_big.c
> > @@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t 
> > reloc_ofs, unsigned flags, c
> >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> >   gem_exec[0].alignment = 0;
> >   gem_exec[0].offset = 0;
> > - gem_exec[0].flags = 0;
> > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> >   gem_exec[0].rsvd1 = 0;
> >   gem_exec[0].rsvd2 = 0;
> >  
> > @@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, uint64_t 
> > batch_size, unsigned flags,
> >   gem_exec[0].handle = handle;
> >   gem_exec[0].relocation_count = nreloc;
> >   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> >  
> >   memset(, 0, sizeof(execbuf));
> >   execbuf.buffers_ptr = to_user_pointer(gem_exec);
> >   execbuf.buffer_count = 1;
> > - execbuf.batch_start_offset = 0;
> > - execbuf.batch_len = 8;
> >   execbuf.flags = flags;
> >  
> >   /* Avoid hitting slowpaths in the reloc processing which might yield a
> > @@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, uint64_t 
> > batch_size, unsigned flags,
> >  #undef reloc_ofs
> >  }
> >  
> > -igt_simple_main
> > +static void exhaustive(int fd)
> >  {
> >   uint32_t batch[2] = {MI_BATCH_BUFFER_END};
> >   uint64_t batch_size, max, ggtt_max, reloc_ofs;
> > - int fd;
> > -
> > - fd = drm_open_driver(DRIVER_INTEL);
> > - igt_require_gem(fd);
> > -
> > - use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8;
> >  
> >   max = 3 * gem_aperture_size(fd) / 4;
> >   ggtt_max = 3 * gem_global_aperture_size(fd) / 4;
> > @@ -258,6 +251,61 @@ igt_simple_main
> >   else
> >   batch_size *= 2;
> >   }
> > +}
> > +
> > +static void single(int i915)
> > +{
> > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > + uint64_t batch_size, limit;
> > + uint32_t handle;
> > + void *ptr;
> > +
> > + batch_size = (intel_get_avail_ram_mb() - 4) << 20; /* internal slack 
> > */
> > + limit = gem_aperture_size(i915) - (256 << 10); /* low pages reserved 
> > */
> > + if (!gem_uses_full_ppgtt(i915))
> > + limit = 3 * limit / 4;
> > +
> > + batch_size = min(batch_size, limit);
> > + batch_size = ALIGN(batch_size, 4096);
> > + igt_info("Submitting a %'"PRId64"MiB batch, %saperture size 
> > %'"PRId64"MiB\n",
> > +  batch_size >> 20,
> > +  gem_uses_full_ppgtt(i915) ? "" : "shared ",
> > +  gem_aperture_size(i915) >> 20);
> > + intel_require_memory(1, batch_size, CHECK_RAM);
> > +
> > + handle = gem_create(i915, batch_size);
> > + gem_write(i915, handle, 0, , sizeof(bbe));
> > +
> > + if (!FORCE_PREAD_PWRITE && gem_has_llc(i915))
> > + ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, PROT_READ);
> > + else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915))
> > + ptr = __gem_mmap__wc(i915, handle, 0, batch_size, PROT_READ);
> > + else
> > + ptr = NULL;
> > +
> > + execN(i915, handle, batch_size, 0, ptr);
> > +
> > + if (ptr)
> > + munmap(ptr, batch_size);
> > +}
> > +
> > +igt_main
> > +{
> > + int i915 = -1;
> > +
> > + igt_fixture {
> > + i915 = drm_open_driver(DRIVER_INTEL);
> > + igt_require_gem(i915);
> > +
> > + use_64bit_relocs = intel_gen(intel_get_drm_devid(i915)) >= 8;
> > + }
> > +
> > + igt_subtest("single")
> > + single(i915);
> > +
> > + igt_subtest("exhaustive")
> > + exhaustive(i915);
> 
> Do we still need this one? CI time isn't an endless resource (as much as
> we'd want to), neither is our ability to maintain everything. And if all
> we get is timeouts in CI I think there's better uses for that machine
> time. And we do use all the CI machine time, so anytime you take away 10
> minutes, it's 10 minutes of not running some other testcase.

It's not for CI and not run in CI. CI is not the be all and end all of
testing. We still have to manually find test cases for CI to run...
-Chris
___

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Daniel Vetter
On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> CI complains that the exhaustive test of trying every size up to the
> limit is too slow, so add a simple test that tries to submit one
> extreme batch buffer and check all the relocations land.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
> Signed-off-by: Chris Wilson 
> ---
>  tests/i915/gem_exec_big.c| 70 ++--
>  tests/intel-ci/blacklist.txt |  1 +
>  2 files changed, 60 insertions(+), 11 deletions(-)
> 
> diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c
> index a15672f66..6d7041cf4 100644
> --- a/tests/i915/gem_exec_big.c
> +++ b/tests/i915/gem_exec_big.c
> @@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t 
> reloc_ofs, unsigned flags, c
>   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
>   gem_exec[0].alignment = 0;
>   gem_exec[0].offset = 0;
> - gem_exec[0].flags = 0;
> + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
>   gem_exec[0].rsvd1 = 0;
>   gem_exec[0].rsvd2 = 0;
>  
> @@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, uint64_t 
> batch_size, unsigned flags,
>   gem_exec[0].handle = handle;
>   gem_exec[0].relocation_count = nreloc;
>   gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
> + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
>  
>   memset(, 0, sizeof(execbuf));
>   execbuf.buffers_ptr = to_user_pointer(gem_exec);
>   execbuf.buffer_count = 1;
> - execbuf.batch_start_offset = 0;
> - execbuf.batch_len = 8;
>   execbuf.flags = flags;
>  
>   /* Avoid hitting slowpaths in the reloc processing which might yield a
> @@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, uint64_t 
> batch_size, unsigned flags,
>  #undef reloc_ofs
>  }
>  
> -igt_simple_main
> +static void exhaustive(int fd)
>  {
>   uint32_t batch[2] = {MI_BATCH_BUFFER_END};
>   uint64_t batch_size, max, ggtt_max, reloc_ofs;
> - int fd;
> -
> - fd = drm_open_driver(DRIVER_INTEL);
> - igt_require_gem(fd);
> -
> - use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8;
>  
>   max = 3 * gem_aperture_size(fd) / 4;
>   ggtt_max = 3 * gem_global_aperture_size(fd) / 4;
> @@ -258,6 +251,61 @@ igt_simple_main
>   else
>   batch_size *= 2;
>   }
> +}
> +
> +static void single(int i915)
> +{
> + const uint32_t bbe = MI_BATCH_BUFFER_END;
> + uint64_t batch_size, limit;
> + uint32_t handle;
> + void *ptr;
> +
> + batch_size = (intel_get_avail_ram_mb() - 4) << 20; /* internal slack */
> + limit = gem_aperture_size(i915) - (256 << 10); /* low pages reserved */
> + if (!gem_uses_full_ppgtt(i915))
> + limit = 3 * limit / 4;
> +
> + batch_size = min(batch_size, limit);
> + batch_size = ALIGN(batch_size, 4096);
> + igt_info("Submitting a %'"PRId64"MiB batch, %saperture size 
> %'"PRId64"MiB\n",
> +  batch_size >> 20,
> +  gem_uses_full_ppgtt(i915) ? "" : "shared ",
> +  gem_aperture_size(i915) >> 20);
> + intel_require_memory(1, batch_size, CHECK_RAM);
> +
> + handle = gem_create(i915, batch_size);
> + gem_write(i915, handle, 0, , sizeof(bbe));
> +
> + if (!FORCE_PREAD_PWRITE && gem_has_llc(i915))
> + ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, PROT_READ);
> + else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915))
> + ptr = __gem_mmap__wc(i915, handle, 0, batch_size, PROT_READ);
> + else
> + ptr = NULL;
> +
> + execN(i915, handle, batch_size, 0, ptr);
> +
> + if (ptr)
> + munmap(ptr, batch_size);
> +}
> +
> +igt_main
> +{
> + int i915 = -1;
> +
> + igt_fixture {
> + i915 = drm_open_driver(DRIVER_INTEL);
> + igt_require_gem(i915);
> +
> + use_64bit_relocs = intel_gen(intel_get_drm_devid(i915)) >= 8;
> + }
> +
> + igt_subtest("single")
> + single(i915);
> +
> + igt_subtest("exhaustive")
> + exhaustive(i915);

Do we still need this one? CI time isn't an endless resource (as much as
we'd want to), neither is our ability to maintain everything. And if all
we get is timeouts in CI I think there's better uses for that machine
time. And we do use all the CI machine time, so anytime you take away 10
minutes, it's 10 minutes of not running some other testcase.
-Daniel

>  
> - close(fd);
> + igt_fixture
> + close(i915);
>  }
> diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
> index cef0da84a..0e6beeae4 100644
> --- a/tests/intel-ci/blacklist.txt
> +++ b/tests/intel-ci/blacklist.txt
> @@ -28,6 +28,7 @@ igt@gem_ctx_thrash(@.*)?
>  igt@gem_evict_alignment(@.*)?
>  igt@gem_evict_everything(@.*)?
>  igt@gem_exec_alignment@(?!.*single).*
> +igt@gem_exec_big@(?!.*single).*
>  igt@gem_exec_capture@many-(?!4K-).*
> 

[Intel-gfx] [PULL] drm-misc-fixes

2019-02-13 Thread Maarten Lankhorst
Hi Dave, Daniel,

Just a single fix to a license inconsistency in vkms. :)

drm-misc-fixes-2019-02-13:
drm-misc-fixes for v5.0:
- Fix license inconsistency in vkms.
The following changes since commit 6297388e1eddd2f1345cea5892156223995bcf2d:

  drm/omap: dsi: Hack-fix DSI bus flags (2019-02-06 13:39:03 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-02-13

for you to fetch changes up to 7fd56e0260a22c0cfaf9adb94a2427b76e239dd0:

  drm/vkms: Fix license inconsistent (2019-02-10 10:23:06 -0200)


drm-misc-fixes for v5.0:
- Fix license inconsistency in vkms.


Rodrigo Siqueira (1):
  drm/vkms: Fix license inconsistent

 drivers/gpu/drm/vkms/vkms_crc.c| 3 ++-
 drivers/gpu/drm/vkms/vkms_crtc.c   | 8 +---
 drivers/gpu/drm/vkms/vkms_drv.c| 7 +--
 drivers/gpu/drm/vkms/vkms_drv.h| 2 ++
 drivers/gpu/drm/vkms/vkms_gem.c| 8 +---
 drivers/gpu/drm/vkms/vkms_output.c | 8 +---
 drivers/gpu/drm/vkms/vkms_plane.c  | 8 +---
 7 files changed, 9 insertions(+), 35 deletions(-)
___
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: Apply rps waitboosting for dma_fence_wait_timeout()

2019-02-13 Thread Patchwork
== Series Details ==

Series: drm/i915: Apply rps waitboosting for dma_fence_wait_timeout()
URL   : https://patchwork.freedesktop.org/series/56597/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5596 -> Patchwork_12209


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56597/revisions/1/mbox/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_12209:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live_workarounds:
- {fi-icl-u2}:PASS -> INCOMPLETE

  
Known issues


  Here are the changes found in Patchwork_12209 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g:   PASS -> DMESG-WARN [fdo#108965]

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]

  * igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: NOTRUN -> FAIL [fdo#103182]

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS

  * igt@prime_vgem@basic-fence-flip:
- fi-skl-6700k2:  FAIL [fdo#104008] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
  [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
  [fdo#109226]: https://bugs.freedesktop.org/show_bug.cgi?id=109226
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278


Participating hosts (40 -> 39)
--

  Additional (3): fi-gdg-551 fi-apl-guc fi-pnv-d510 
  Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 


Build changes
-

* Linux: CI_DRM_5596 -> Patchwork_12209

  CI_DRM_5596: aaaccba122fe89ef87706ae2642dc3e3b0d256e6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4820: 368237db1149033d8274248489ffec671ea1f7d8 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12209: 80720548eb7b87b4b5511478c64e07f5cd670f85 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

80720548eb7b drm/i915: Apply rps waitboosting for dma_fence_wait_timeout()

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Apply rps waitboosting for dma_fence_wait_timeout()

2019-02-13 Thread Patchwork
== Series Details ==

Series: drm/i915: Apply rps waitboosting for dma_fence_wait_timeout()
URL   : https://patchwork.freedesktop.org/series/56597/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Apply rps waitboosting for dma_fence_wait_timeout()
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3571:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3566:16: warning: expression 
using sizeof(void)

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

[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_sseu: Fix 32-bit build

2019-02-13 Thread Guillaume Tucker
This fixes a compiler warning treated as an error when building for
32-bit architectures since their pointer size does not match the size
of drm_i915_gem_context_param.value which is 64 bits:

  CC   i915/gem_ctx_sseu.o
  i915/gem_ctx_sseu.c: In function ‘test_ggtt_args’:
  i915/gem_ctx_sseu.c:384:9: error: cast to pointer from integer of different 
size [-Werror=int-to-pointer-cast]
munmap((void *)arg.value, 4096);

It was found while building for arm with gcc 6.3.0 and I suspect the
same problem would arise for i386 or other 32-bit architectures.  The
uintptr_t type is by definition an unsigned integer of the same length
as a pointer on a given architecture, so this should fix the problem
for all architectures up to 64 bits.

Signed-off-by: Guillaume Tucker 
---
 tests/i915/gem_ctx_sseu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
index 16609bee61c8..3afa5c152939 100644
--- a/tests/i915/gem_ctx_sseu.c
+++ b/tests/i915/gem_ctx_sseu.c
@@ -381,7 +381,7 @@ test_ggtt_args(int fd)
igt_assert_eq(__gem_context_get_param(fd, ), 0);
igt_assert_eq(__gem_context_set_param(fd, ), 0);
 
-   munmap((void *)arg.value, 4096);
+   munmap((void *)(uintptr_t)arg.value, 4096);
gem_close(fd, bo);
gem_context_destroy(fd, arg.ctx_id);
 }
-- 
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 i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Patchwork
== Series Details ==

Series: i915/gem_exec_big: Add a single shot test
URL   : https://patchwork.freedesktop.org/series/56595/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5596 -> IGTPW_2390


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56595/revisions/1/mbox/

Known issues


  Here are the changes found in IGTPW_2390 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic-flip-a:
- fi-gdg-551: NOTRUN -> FAIL [fdo#103182] +1

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   PASS -> FAIL [fdo#109485]

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS

  * igt@prime_vgem@basic-fence-flip:
- fi-skl-6700k2:  FAIL [fdo#104008] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485


Participating hosts (40 -> 39)
--

  Additional (3): fi-gdg-551 fi-apl-guc fi-pnv-d510 
  Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 


Build changes
-

* IGT: IGT_4820 -> IGTPW_2390

  CI_DRM_5596: aaaccba122fe89ef87706ae2642dc3e3b0d256e6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2390: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2390/
  IGT_4820: 368237db1149033d8274248489ffec671ea1f7d8 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools



== Testlist changes ==

+igt@gem_exec_big@exhaustive
+igt@gem_exec_big@single
-igt@gem_exec_big

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Apply rps waitboosting for dma_fence_wait_timeout()

2019-02-13 Thread Chris Wilson
As time goes by, usage of generic ioctls such as drm_syncobj and
sync_file are on the increase bypassing i915-specific ioctls like
GEM_WAIT. Currently, we only apply waitboosting to our driver ioctls as
we track the file/client and account the waitboosting to them. However,
since commit 7b92c1bd0540 ("drm/i915: Avoid keeping waitboost active for
signaling threads"), we no longer have been applying the client
ratelimiting on waitboosts and so that information has only been used
for debug tracking.

Push the application of waitboosting down to the common
i915_request_wait, and apply it to all foreign fence waits as well.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Eero Tamminen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 19 +-
 drivers/gpu/drm/i915/i915_drv.h  |  7 +--
 drivers/gpu/drm/i915/i915_gem.c  | 86 ++--
 drivers/gpu/drm/i915/i915_request.c  | 21 ++-
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  |  5 +-
 7 files changed, 44 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 13bdf326287b..2aeea977283f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2020,11 +2020,9 @@ static const char *rps_power_to_str(unsigned int power)
 static int i915_rps_boost_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_device *dev = _priv->drm;
struct intel_rps *rps = _priv->gt_pm.rps;
u32 act_freq = rps->cur_freq;
intel_wakeref_t wakeref;
-   struct drm_file *file;
 
with_intel_runtime_pm_if_in_use(dev_priv, wakeref) {
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
@@ -2058,22 +2056,7 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
   intel_gpu_freq(dev_priv, rps->efficient_freq),
   intel_gpu_freq(dev_priv, rps->boost_freq));
 
-   mutex_lock(>filelist_mutex);
-   list_for_each_entry_reverse(file, >filelist, lhead) {
-   struct drm_i915_file_private *file_priv = file->driver_priv;
-   struct task_struct *task;
-
-   rcu_read_lock();
-   task = pid_task(file->pid, PIDTYPE_PID);
-   seq_printf(m, "%s [%d]: %d boosts\n",
-  task ? task->comm : "",
-  task ? task->pid : -1,
-  atomic_read(_priv->rps_client.boosts));
-   rcu_read_unlock();
-   }
-   seq_printf(m, "Kernel (anonymous) boosts: %d\n",
-  atomic_read(>boosts));
-   mutex_unlock(>filelist_mutex);
+   seq_printf(m, "Wait boosts: %d\n", atomic_read(>boosts));
 
if (INTEL_GEN(dev_priv) >= 6 &&
rps->enabled &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 380b994fe5dc..17fe942eaafa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -217,10 +217,6 @@ struct drm_i915_file_private {
} mm;
struct idr context_idr;
 
-   struct intel_rps_client {
-   atomic_t boosts;
-   } rps_client;
-
unsigned int bsd_engine;
 
 /*
@@ -3056,8 +3052,7 @@ void i915_gem_resume(struct drm_i915_private *dev_priv);
 vm_fault_t i915_gem_fault(struct vm_fault *vmf);
 int i915_gem_object_wait(struct drm_i915_gem_object *obj,
 unsigned int flags,
-long timeout,
-struct intel_rps_client *rps);
+long timeout);
 int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
  unsigned int flags,
  const struct i915_sched_attr *attr);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ae1467a74a08..b421bc7a2e26 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -418,8 +418,7 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj)
 static long
 i915_gem_object_wait_fence(struct dma_fence *fence,
   unsigned int flags,
-  long timeout,
-  struct intel_rps_client *rps_client)
+  long timeout)
 {
struct i915_request *rq;
 
@@ -437,27 +436,6 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
if (i915_request_completed(rq))
goto out;
 
-   /*
-* This client is about to stall waiting for the GPU. In many cases
-* this is undesirable and limits the throughput of the system, as
-* many clients cannot continue processing user input/output whilst
-* blocked. RPS autotuning may take tens of milliseconds to respond
-* to 

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_big: Add a single shot test

2019-02-13 Thread Chris Wilson
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson 
---
 tests/i915/gem_exec_big.c| 70 ++--
 tests/intel-ci/blacklist.txt |  1 +
 2 files changed, 60 insertions(+), 11 deletions(-)

diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c
index a15672f66..492a19cb9 100644
--- a/tests/i915/gem_exec_big.c
+++ b/tests/i915/gem_exec_big.c
@@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t 
reloc_ofs, unsigned flags, c
gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
gem_exec[0].alignment = 0;
gem_exec[0].offset = 0;
-   gem_exec[0].flags = 0;
+   gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
gem_exec[0].rsvd1 = 0;
gem_exec[0].rsvd2 = 0;
 
@@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, uint64_t 
batch_size, unsigned flags,
gem_exec[0].handle = handle;
gem_exec[0].relocation_count = nreloc;
gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
+   gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
 
memset(, 0, sizeof(execbuf));
execbuf.buffers_ptr = to_user_pointer(gem_exec);
execbuf.buffer_count = 1;
-   execbuf.batch_start_offset = 0;
-   execbuf.batch_len = 8;
execbuf.flags = flags;
 
/* Avoid hitting slowpaths in the reloc processing which might yield a
@@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, uint64_t 
batch_size, unsigned flags,
 #undef reloc_ofs
 }
 
-igt_simple_main
+static void exhaustive(int fd)
 {
uint32_t batch[2] = {MI_BATCH_BUFFER_END};
uint64_t batch_size, max, ggtt_max, reloc_ofs;
-   int fd;
-
-   fd = drm_open_driver(DRIVER_INTEL);
-   igt_require_gem(fd);
-
-   use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8;
 
max = 3 * gem_aperture_size(fd) / 4;
ggtt_max = 3 * gem_global_aperture_size(fd) / 4;
@@ -258,6 +251,61 @@ igt_simple_main
else
batch_size *= 2;
}
+}
+
+static void single(int i915)
+{
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   uint64_t batch_size, limit;
+   uint32_t handle;
+   void *ptr;
+
+   batch_size = (intel_get_avail_ram_mb() - 64) << 20; /* internal slack */
+   limit = gem_aperture_size(i915) - (256 << 10); /* low pages reserved */
+   if (!gem_uses_full_ppgtt(i915))
+   limit = 3 * limit / 4;
+
+   batch_size = min(batch_size, limit);
+   batch_size = ALIGN(batch_size, 4096);
+   igt_info("Submitting a %'"PRId64"MiB batch, %saperture size 
%'"PRId64"MiB\n",
+batch_size >> 20,
+gem_uses_full_ppgtt(i915) ? "" : "shared ",
+gem_aperture_size(i915) >> 20);
+   intel_require_memory(1, batch_size, CHECK_RAM);
+
+   handle = gem_create(i915, batch_size);
+   gem_write(i915, handle, 0, , sizeof(bbe));
+
+   if (!FORCE_PREAD_PWRITE && gem_has_llc(i915))
+   ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, PROT_READ);
+   else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915))
+   ptr = __gem_mmap__wc(i915, handle, 0, batch_size, PROT_READ);
+   else
+   ptr = NULL;
+
+   execN(i915, handle, batch_size, 0, ptr);
+
+   if (ptr)
+   munmap(ptr, batch_size);
+}
+
+igt_main
+{
+   int i915 = -1;
+
+   igt_fixture {
+   i915 = drm_open_driver(DRIVER_INTEL);
+   igt_require_gem(i915);
+
+   use_64bit_relocs = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   }
+
+   igt_subtest("single")
+   single(i915);
+
+   igt_subtest("exhaustive")
+   exhaustive(i915);
 
-   close(fd);
+   igt_fixture
+   close(i915);
 }
diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
index cef0da84a..0e6beeae4 100644
--- a/tests/intel-ci/blacklist.txt
+++ b/tests/intel-ci/blacklist.txt
@@ -28,6 +28,7 @@ igt@gem_ctx_thrash(@.*)?
 igt@gem_evict_alignment(@.*)?
 igt@gem_evict_everything(@.*)?
 igt@gem_exec_alignment@(?!.*single).*
+igt@gem_exec_big@(?!.*single).*
 igt@gem_exec_capture@many-(?!4K-).*
 igt@gem_exec_fence@(?!.*basic).*
 igt@gem_exec_flush@(?!.*basic).*
-- 
2.20.1

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

Re: [Intel-gfx] [PULL] topic/component-typed

2019-02-13 Thread Joonas Lahtinen
Quoting Rodrigo Vivi (2019-02-12 01:51:18)
> On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote:
> > Hi all,
> > 
> > Here's the typed component topic branch.
> > 
> > drm-intel maintainers: Please pull, I need this for the mei hdcp work from 
> > Ram.
> 
> I'm about to handle dinq to Joonas since I did latest pull-request for 5.1
> last week.
> Also since this might impact Joonas on a later backmerge I believe he
> is the best position to get this right now.
> 
> Joonas?

Yeah, I'll handle it. Daniel said he'll need a patch or two more to land
for the i915 portion, so there will be a PR for me including those, too.

Regards, Joonas

> 
> > 
> > drm-misc maintainers: Please pull, there's a drm doc patch follow-up
> > that I want to stuff into drm-misc-next.
> > 
> > Greg: The drm side missed our feature cutoff, so will only land in 5.2.
> > Probably good if you pull this into drivers-core so it lands a bit
> > quicker. You will also get a topic pull later on with the MEI bits
> > for char-misc tree, which needs to be based on top of this tree here.
> > 
> > Takashi: Since the drm side only lands in 5.2 might be good if you
> > pull this in too to avoid conflicts.
> > 
> > Cheers, Daniel
> > 
> > topic/component-typed-2019-02-11:
> > typed componented support + i915/snd-hda changes
> > 
> > This is needed by the new MEI-HDCP support in i915, so will need to go
> > in through drm and drivers-misc trees at least.
> > 
> > Cheers, Daniel
> > 
> > The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:
> > 
> >   Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)
> > 
> > are available in the Git repository at:
> > 
> >   git://anongit.freedesktop.org/drm/drm-intel
> > tags/topic/component-typed-2019-02-11
> > 
> > for you to fetch changes up to 8857c7d065e900a0b3829c97634c99501b606541:
> > 
> >   i915/snd_hdac: I915 subcomponent for the snd_hdac (2019-02-08 16:58:59 
> > +0100)
> > 
> > 
> > typed componented support + i915/snd-hda changes
> > 
> > This is needed by the new MEI-HDCP support in i915, so will need to go
> > in through drm and drivers-misc trees at least.
> > 
> > 
> > Daniel Vetter (3):
> >   component: Add documentation
> >   components: multiple components for a device
> >   i915/snd_hdac: I915 subcomponent for the snd_hdac
> > 
> >  Documentation/driver-api/component.rst   |  17 +++
> >  Documentation/driver-api/device_link.rst |   3 +
> >  Documentation/driver-api/index.rst   |   1 +
> >  drivers/base/component.c | 206 
> > +--
> >  drivers/gpu/drm/i915/intel_audio.c   |   4 +-
> >  include/drm/i915_component.h |   4 +
> >  include/linux/component.h|  76 
> >  include/sound/hda_component.h|   5 +-
> >  sound/hda/hdac_component.c   |   4 +-
> >  sound/hda/hdac_i915.c|   6 +-
> >  10 files changed, 308 insertions(+), 18 deletions(-)
> >  create mode 100644 Documentation/driver-api/component.rst
> > 
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for Add Colorspace connector property interface (rev15)

2019-02-13 Thread Patchwork
== Series Details ==

Series: Add Colorspace connector property interface (rev15)
URL   : https://patchwork.freedesktop.org/series/47132/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5596_full -> Patchwork_12208_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12208_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@reset-stress:
- shard-snb:  PASS -> FAIL [fdo#107799]

  * igt@i915_suspend@fence-restore-untiled:
- shard-kbl:  NOTRUN -> DMESG-WARN [fdo#103313]

  * igt@kms_available_modes_crc@available_mode_test_crc:
- shard-kbl:  NOTRUN -> FAIL [fdo#106641]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-kbl:  NOTRUN -> DMESG-WARN [fdo#107956] +7

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-glk:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_color@pipe-c-ctm-max:
- shard-apl:  PASS -> FAIL [fdo#108147]

  * igt@kms_content_protection@atomic:
- shard-kbl:  NOTRUN -> FAIL [fdo#108597] +1

  * igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-apl:  NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +4

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk:  PASS -> FAIL [fdo#104873]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-kbl:  NOTRUN -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-apl:  NOTRUN -> FAIL [fdo#103167]

  * igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-apl:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-glk:  PASS -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] +7

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] / [fdo#108590] +5

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-kbl:  NOTRUN -> FAIL [fdo#103166] +1

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  NOTRUN -> INCOMPLETE [fdo#103665]

  * igt@kms_setmode@basic:
- shard-kbl:  NOTRUN -> FAIL [fdo#99912]

  * igt@kms_sysfs_edid_timing:
- shard-kbl:  NOTRUN -> FAIL [fdo#100047]

  
 Possible fixes 

  * igt@gem_exec_create@forked:
- shard-hsw:  INCOMPLETE [fdo#103540] -> PASS

  * igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl:  FAIL [fdo#103232] -> PASS

  * igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl:  FAIL [fdo#103191] / [fdo#103232] -> PASS

  * igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl:  FAIL [fdo#109350] -> PASS

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  FAIL [fdo#105767] -> PASS

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  FAIL [fdo#104873] -> PASS

  * igt@kms_flip@basic-flip-vs-modeset:
- shard-hsw:  DMESG-WARN [fdo#102614] -> PASS

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-glk:  FAIL [fdo#102887] / [fdo#105363] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-apl:  FAIL [fdo#103167] -> PASS

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-apl:  INCOMPLETE [fdo#103927] -> PASS

  * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-glk:  FAIL [fdo#108145] -> PASS

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-apl:  FAIL [fdo#103166] -> PASS +2

  * igt@kms_setmode@clone-exclusive-crtc:
- shard-glk:  INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS +1

  
 Warnings 

  * igt@i915_suspend@shrink:
- shard-glk:  INCOMPLETE [fdo#103359] / [fdo#106886] / 
[k.org#198133] -> DMESG-WARN [fdo#109244]

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: