Re: [Intel-gfx] [PATCH 4/9] drm/i915/tdr: Add support for per engine reset recovery

[Michel Thierry]

On 19/12/16 01:51, Chris Wilson wrote:

On Sun, Dec 18, 2016 at 09:02:33PM -0800, Michel Thierry wrote:



On 12/16/2016 12:45 PM, Chris Wilson wrote:

On Fri, Dec 16, 2016 at 12:20:05PM -0800, Michel Thierry wrote:

From: Arun Siluvery 

This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. This is only supported

>from Gen8 onwards.


Hangchecker determines which engines are hung and invokes error handler to
recover from it. Error handler schedules recovery for each of those engines
that are hung. The recovery procedure is as follows,
- identifies the request that caused the hang and it is dropped
- force engine to idle: this is done by issuing a reset request
- reset and re-init engine
- restart submissions to the engine

If engine reset fails then we fall back to heavy weight full gpu reset
which resets all engines and reinitiazes complete state of HW and SW.

v2: Rebase.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
drivers/gpu/drm/i915/i915_drv.c | 56 +++--
drivers/gpu/drm/i915/i915_drv.h |  3 ++
drivers/gpu/drm/i915/i915_gem.c |  2 +-
drivers/gpu/drm/i915/intel_lrc.c| 12 
drivers/gpu/drm/i915/intel_lrc.h|  1 +
drivers/gpu/drm/i915/intel_uncore.c | 41 ---
6 files changed, 108 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e5688edd62cd..a034793bc246 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1830,18 +1830,70 @@ void i915_reset(struct drm_i915_private *dev_priv)
 *
 * Reset a specific GPU engine. Useful if a hang is detected.
 * Returns zero on successful reset or otherwise an error code.
+ *
+ * Procedure is fairly simple:
+ *  - identifies the request that caused the hang and it is dropped
+ *  - force engine to idle: this is done by issuing a reset request
+ *  - reset engine
+ *  - restart submissions to the engine
 */
int i915_reset_engine(struct intel_engine_cs *engine)


What's the serialisation between potential callers of
i915_reset_engine()?



I haven't seen simultaneous calls happening yet, would a
reset_engine-specific mutex be enough?


That is what it more or less boils down to. But first, do we ensure we
don't declare a second hang on this engine before the first reset is
complete? Then we only a barrier between a single engine reset and a
full reset.


{
int ret;
struct drm_i915_private *dev_priv = engine->i915;

-   /* FIXME: replace me with engine reset sequence */
-   ret = -ENODEV;
+   /*
+* We need to first idle the engine by issuing a reset request,
+* then perform soft reset and re-initialize hw state, for all of
+* this GT power need to be awake so ensure it does throughout the
+* process
+*/
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+   /*
+* the request that caused the hang is stuck on elsp, identify the
+* active request and drop it, adjust head to skip the offending
+* request to resume executing remaining requests in the queue.
+*/
+   i915_gem_reset_engine(engine);


Must freeze the engine and irqs first, before calling
i915_gem_reset_engine() (i.e. something like disable_engines_irq,
cancelling tasklet)


Will do.


Eeek note that the current i915_gem_reset_engine() is lacking a
spinlock.



The new mutex (for i915_reset_engine) should cover this.


No. We need to protect these lists from concurrent manipulation in the
fences. The spinlock protection there needs to be extended here, being
covered by struct_mutex is no longer sufficient protection for the
current code.


I think you already addressed the last point in "drm/i915: Prevent 
timeline updates whilst performing reset" 
(00c25e3f40083a6d5f955baccd287ee49258), right?


But looking at these (and the interaction with possible waiters), do you 
think it is still achievable to reset a engine without grabbing the 
struct_mutex? Then both i915_reset (chip) and i915_reset_engine can use 
the "reset_in_progress".


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

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Pandiyan, Dhinakaran]

On Wed, 2017-01-04 at 11:42 +0100, Peter Frühberger wrote:
> Forgot to CC the list, sorry.
> 
> On Wed, Jan 4, 2017 at 11:42 AM, Peter Frühberger 
> wrote:
> Hi Jani,
> thanks for your reply
> 
> On Wed, Jan 4, 2017 at 10:34 AM, Jani Nikula
>  wrote:
> On Wed, 04 Jan 2017, Peter Frühberger
>  wrote:
> > Hi
> >
> > On Sun, Nov 6, 2016 at 1:23 AM, Pandiyan, Dhinakaran
> <
> > dhinakaran.pandi...@intel.com> wrote:
> >
> >> On Sat, 2016-11-05 at 21:40 +0200, Jani Nikula
> wrote:
> >> > On Fri, 04 Nov 2016, "Pandiyan, Dhinakaran" <
> >> dhinakaran.pandi...@intel.com> wrote:
> >> > > On Fri, 2016-11-04 at 17:48 +0200, Jani Nikula
> wrote:
> >> > >> On Wed, 26 Oct 2016, Dhinakaran Pandiyan <
> >> dhinakaran.pandi...@intel.com> wrote:
> >> > >> > Enabling DP audio stall fix is necessary to
> play audio over DP
> >> HBR2. So,
> >> > >> > let's set this bit right before enabling the
> audio codec. Playing
> >> audio
> >> > >> > without setting this bit results in pipe
> FIFO underruns.
> >> > >> >
> >> > >> > This workaround is applicable only for audio
> sample rates up to
> >> 96kHz. For
> >> > >> > frequencies above 96kHz, this is
> insufficient and cdclk should be
> >> increased
> >> > >> > to at least 432 MHz, just like BDW. Since,
> the audio driver does not
> >> > >> > support sample rates > 48 kHz, we are safe
> with this fix for now.
> >> > >>
> >> > >> Do we still need this patch now that these two
> have been pushed?
> >> > >>
> >> > >> b30ce9e0552a drm/i915/dp: BDW cdclk fix for DP
> audio
> >> > >> 9c7540241885 drm/i915/dp: Extend BDW DP audio
> workaround to GEN9
> >> platforms
> >> > >>
> >> > >> BR,
> >> > >> Jani.
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > > No, we are good afaik. This patch would have
> helped us to make use of a
> >> > > lower cdclk (337.5 MHz), with constraints on
> audio bit rate. Operating
> >> > > at 432 MHz, like we do now, rules out the need
> for this patch.
> >> >
> >> > Hmm, what about 5.4 Gbps link with 1 or 2 lanes?
> >> >
> >> > BR,
> >> > Jani.
> >> >
> >>
> >> Good point, I think it will depend on the audio
> sampling rate. But, I
> >> have to figure out a way to play high sampling rate
> audio (> 96 KHz) and
> >> test 5.4 Gbps with 1 or 2 lanes.
> >>
> >> The other option is to play safe and apply this
> patch with even lesser
> >> restrictions, say link rate >= 2.7 Gbps.
> >>
> >>
> >> -DK
> >>
> >
> > as we are currently talking about high samplerates
> in this context. I
> > wanted to post a perhaps related issue. On my Apollo
> Lake (J4205) I have
> > two outputs. One DVI and one HDMI 2.0 via internal
> DP. Via DVI the
> > following works without issues, via DP it fails. As
> the original commit
> > mentions HBR, I think there is still something
> missing. We submit TrueHD,
> > DTS-HD via 192 khz and 16 bit format while setting
> AES0=2
> >
> > You can easily reproduce with (you obviously need a
> DTS-HD, TrueHD capable
> > AVR attached to your HDMI 2.0 (DP) out):
> 
+Libin


> Just to clarify, is the DP -> HDMI2.0 converter
> internal to the machine?
> LSPCON related messages in the dmesg with
> drm.debug=14? Do you have a DP
> or an HDMI physical connector in the chassis?
> 
> 
> The chip used is: https://media.digikey.com/pdf/Data%
> 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Extending DC9 support for GEN9_LP.

[Patchwork]

== Series Details ==

Series: drm/i915: Extending DC9 support for GEN9_LP.
URL   : https://patchwork.freedesktop.org/series/17568/
State : warning

== Summary ==

Series 17568v1 drm/i915: Extending DC9 support for GEN9_LP.
https://patchwork.freedesktop.org/api/1.0/series/17568/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-bxt-j4205)

fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:82   pass:69   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:246  pass:214  dwarn:0   dfail:0   fail:0   skip:32 

8e6dfeed0f95b5f85430271a46d2f817a6df1d21 drm-tip: 2017y-01m-05d-16h-48m-32s UTC 
integration manifest
d89c0f4 drm/i915: Extending DC9 support for GEN9_LP.

== Logs ==

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

Re: [Intel-gfx] [PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep

[Jim Bride]

On Tue, Jan 03, 2017 at 10:27:51PM +0530, vathsala nagaraju wrote:
> Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
> to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
> should report value 8 , if system enters deep sleep state.
> 
> Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
> flickering is observed on psr2 panel.
> 
> v2: (Ilia Mirkin)
> - Remove duplicate bit definition 25:27
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 10 +++---
>  drivers/gpu/drm/i915/intel_dp.c  |  1 -
>  drivers/gpu/drm/i915/intel_psr.c | 29 -
>  3 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5ca506a..272a283 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3597,9 +3597,12 @@ enum {
>  #define   EDP_PSR_PERF_CNT_MASK  0xff
>  
>  #define EDP_PSR_DEBUG_CTL_MMIO(dev_priv->psr_mmio_base + 0x60)
> -#define   EDP_PSR_DEBUG_MASK_LPSP(1<<27)
> -#define   EDP_PSR_DEBUG_MASK_MEMUP   (1<<26)
> -#define   EDP_PSR_DEBUG_MASK_HPD (1<<25)
> +#define   EDP_PSR_DEBUG_MASK_MAX_SLEEP (1<<28)
> +#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
> +#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
> +#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
> +#define   EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1<<16)
> +#define   EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1<<15)
>  
>  #define EDP_PSR2_CTL _MMIO(0x6f900)
>  #define   EDP_PSR2_ENABLE(1<<31)
> @@ -3614,6 +3617,7 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
> +#define   EDP_FRAMES_BEFORE_SU_ENTRY   (1<<4)
>  
>  #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
>  #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9b313a3..0a10858 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3655,7 +3655,6 @@ void intel_dp_set_idle_link_train(struct intel_dp 
> *intel_dp)
>   dev_priv->psr.alpm =
>   intel_dp_get_alpm_status(intel_dp);
>   }
> -
>   }
>  
>   /* Read the eDP Display control capabilities registers */
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2e75ef6..19cd4d7 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -339,7 +339,9 @@ static void hsw_enable_source_psr2(struct intel_dp 
> *intel_dp)
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE |
> + EDP_SU_TRACK_ENABLE |
> + EDP_FRAMES_BEFORE_SU_ENTRY;
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> @@ -512,18 +514,27 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>   dev_priv->psr.psr2_support = false;
>   else
>   skl_psr_setup_su_vsc(intel_dp);
> + I915_WRITE(EDP_PSR_DEBUG_CTL,
> +EDP_PSR_DEBUG_MASK_MEMUP |
> +EDP_PSR_DEBUG_MASK_HPD |
> +EDP_PSR_DEBUG_MASK_LPSP |
> +EDP_PSR_DEBUG_MASK_MAX_SLEEP |
> +EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
>   } else {
>   /* set up vsc header for psr1 */
>   hsw_psr_setup_vsc(intel_dp);
> + /*
> +  * Per Spec: Avoid continuous PSR exit by masking MEMUP
> +  * and HPD. also mask LPSP to avoid dependency on other
> +  * drivers that might block runtime_pm besides
> +  * preventing  other hw tracking issues now we can rely
> +  * on frontbuffer tracking.
> +  */
> + I915_WRITE(EDP_PSR_DEBUG_CTL,
> +EDP_PSR_DEBUG_MASK_MEMUP |
> +EDP_PSR_DEBUG_MASK_HPD |
> +EDP_PSR_DEBUG_MASK_LPSP);
>   }
> - /*
> -  * Per Spec: Avoid continuous PSR exit by masking 

Re: [Intel-gfx] [PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[Vivi, Rodrigo]

On Fri, 2017-01-06 at 00:55 +0530, vathsala nagaraju wrote:
> Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
> psr1 should be disabled.When psr2 is exited , bit 31 of reg
> PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
> (psr1 control register)is set to 0.
> Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
> instead of PSR2_STATUS register, which has wrong data, resulting
> in blankscreen.
> hsw_enable_source is split into hsw_enable_source_psr1 and
> hsw_enable_source_psr2 for easier code review and maintenance,
> as suggested by rodrigo and jim.
> 
> v2: (Vivi Rodrigo)
> - Rename hsw_enable_source_psr* to intel_enable_source_psr*
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |   3 +
>  drivers/gpu/drm/i915/intel_psr.c | 124 
> +--
>  2 files changed, 97 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa..7830e6e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3615,6 +3615,9 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
>  
> +#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
> +#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +
>  /* VGA port control */
>  #define ADPA _MMIO(0x61100)
>  #define PCH_ADPA_MMIO(0xe1100)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3aa649..d5e8bcc 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
>  VLV_EDP_PSR_ACTIVE_ENTRY);
>  }
>  
> -static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +static void intel_enable_source_psr1(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> -
>   uint32_t max_sleep_time = 0x1f;
>   /*
>* Let's respect VBT in case VBT asks a higher idle_frame value.
> @@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   val |= EDP_PSR_TP1_TP2_SEL;
>  
>   I915_WRITE(EDP_PSR_CTL, val);
> +}
>  
> - if (!dev_priv->psr.psr2_support)
> - return;
> +static void intel_enable_source_psr2(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /*
> +  * Let's respect VBT in case VBT asks a higher idle_frame value.
> +  * Let's use 6 as the minimum to cover all known cases including
> +  * the off-by-one issue that HW has in some cases. Also there are
> +  * cases where sink should be able to train
> +  * with the 5 or 6 idle patterns.
> +  */
> + uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> + uint32_t val = EDP_PSR_ENABLE;
> +
> + val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> @@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   I915_WRITE(EDP_PSR2_CTL, val);
>  }
>  
> +
> +static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /* psr1 and psr2 are mutually exclusive.*/
> + if (dev_priv->psr.psr2_support)
> + intel_enable_source_psr2(intel_dp);
> + else
> + intel_enable_source_psr1(intel_dp);
> +}
> +
>  static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
> - WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> + if (dev_priv->psr.psr2_support)
> + WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
> + 

[Intel-gfx] [PATCH] drm/i915: Extending DC9 support for GEN9_LP.

[Animesh Manna]

All gen9-lp platform has support for DC9 (lowest power state of display
engine). Modified the condition check for enabling/disabling DC9.

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_drv.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4d22b4b..2dffd95 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1484,7 +1484,7 @@ static int i915_drm_suspend_late(struct drm_device *dev, 
bool hibernation)
intel_power_domains_suspend(dev_priv);
 
ret = 0;
-   if (IS_BROXTON(dev_priv))
+   if (IS_GEN9_LP(dev_priv))
bxt_enable_dc9(dev_priv);
else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
hsw_enable_pc8(dev_priv);
@@ -1692,7 +1692,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
 
intel_uncore_early_sanitize(dev_priv, true);
 
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
if (!dev_priv->suspended_to_idle)
gen9_sanitize_dc_state(dev_priv);
bxt_disable_dc9(dev_priv);
@@ -2326,7 +2326,7 @@ static int intel_runtime_suspend(struct device *kdev)
intel_runtime_pm_disable_interrupts(dev_priv);
 
ret = 0;
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
bxt_display_core_uninit(dev_priv);
bxt_enable_dc9(dev_priv);
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
@@ -2411,7 +2411,7 @@ static int intel_runtime_resume(struct device *kdev)
if (IS_GEN6(dev_priv))
intel_init_pch_refclk(dev_priv);
 
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
bxt_disable_dc9(dev_priv);
bxt_display_core_init(dev_priv, true);
if (dev_priv->csr.dmc_payload &&
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 05/10] drm/i915/psr: enable ALPM for psr2

[Jim Bride]

On Mon, Jan 02, 2017 at 05:00:58PM +0530, vathsala nagaraju wrote:
> As per edp1.4 spec , alpm is required for psr2 operation as it's
> used for all psr2  main link power down management and alpm enable
> bit must be set for psr2 operation.
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: vathsala nagaraju 
> Signed-off-by: Patil Deepti 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_dp.c  | 10 ++
>  drivers/gpu/drm/i915/intel_psr.c |  6 +-
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 36dc835..0742b81 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1166,6 +1166,7 @@ struct i915_psr {
>   bool link_standby;
>   bool y_cord_support;
>   bool colorimetry_support;
> + bool alpm;
>  };
>  
>  enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index da577c9..9b313a3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3060,6 +3060,14 @@ static bool intel_dp_get_colorimetry_status(struct 
> intel_dp *intel_dp)
>   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
>  }
>  
> +bool intel_dp_get_alpm_status(struct intel_dp *intel_dp)
> +{
> + uint8_t alpm_caps = 0;
> +
> + drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP, _caps);
> + return alpm_caps & DP_ALPM_CAP;
> +}
> +
>  /* These are source-specific values. */
>  uint8_t
>  intel_dp_voltage_max(struct intel_dp *intel_dp)
> @@ -3644,6 +3652,8 @@ void intel_dp_set_idle_link_train(struct intel_dp 
> *intel_dp)
>   intel_dp_get_y_cord_status(intel_dp);
>   dev_priv->psr.colorimetry_support =
>   intel_dp_get_colorimetry_status(intel_dp);
> + dev_priv->psr.alpm =
> + intel_dp_get_alpm_status(intel_dp);
>   }
>  
>   }
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 93eb0f0..494e4b2 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -209,7 +209,11 @@ static void hsw_psr_enable_sink(struct intel_dp 
> *intel_dp)
>   drm_dp_dpcd_writeb(_dp->aux,
>   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
>   DP_AUX_FRAME_SYNC_ENABLE);
> -
> + /* Enable ALPM at sink for psr2 */
> + if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
> + drm_dp_dpcd_writeb(_dp->aux,
> + DP_RECEIVER_ALPM_CONFIG,
> + DP_ALPM_ENABLE);
>   if (dev_priv->psr.link_standby)
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG,
>  DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
> -- 
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[Jim Bride]

On Fri, Jan 06, 2017 at 12:55:59AM +0530, vathsala nagaraju wrote:
> Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
> psr1 should be disabled.When psr2 is exited , bit 31 of reg
> PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
> (psr1 control register)is set to 0.
> Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
> instead of PSR2_STATUS register, which has wrong data, resulting
> in blankscreen.
> hsw_enable_source is split into hsw_enable_source_psr1 and
> hsw_enable_source_psr2 for easier code review and maintenance,
> as suggested by rodrigo and jim.
> 
> v2: (Vivi Rodrigo)
> - Rename hsw_enable_source_psr* to intel_enable_source_psr*
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 

The new naming is much better!

Reviewed-by: Jim Bride 


> ---
>  drivers/gpu/drm/i915/i915_reg.h  |   3 +
>  drivers/gpu/drm/i915/intel_psr.c | 124 
> +--
>  2 files changed, 97 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa..7830e6e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3615,6 +3615,9 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
>  
> +#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
> +#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +
>  /* VGA port control */
>  #define ADPA _MMIO(0x61100)
>  #define PCH_ADPA_MMIO(0xe1100)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3aa649..d5e8bcc 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
>  VLV_EDP_PSR_ACTIVE_ENTRY);
>  }
>  
> -static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +static void intel_enable_source_psr1(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> -
>   uint32_t max_sleep_time = 0x1f;
>   /*
>* Let's respect VBT in case VBT asks a higher idle_frame value.
> @@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   val |= EDP_PSR_TP1_TP2_SEL;
>  
>   I915_WRITE(EDP_PSR_CTL, val);
> +}
>  
> - if (!dev_priv->psr.psr2_support)
> - return;
> +static void intel_enable_source_psr2(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /*
> +  * Let's respect VBT in case VBT asks a higher idle_frame value.
> +  * Let's use 6 as the minimum to cover all known cases including
> +  * the off-by-one issue that HW has in some cases. Also there are
> +  * cases where sink should be able to train
> +  * with the 5 or 6 idle patterns.
> +  */
> + uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> + uint32_t val = EDP_PSR_ENABLE;
> +
> + val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> @@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   I915_WRITE(EDP_PSR2_CTL, val);
>  }
>  
> +
> +static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /* psr1 and psr2 are mutually exclusive.*/
> + if (dev_priv->psr.psr2_support)
> + intel_enable_source_psr2(intel_dp);
> + else
> + intel_enable_source_psr1(intel_dp);
> +}
> +
>  static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
> - WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> + if 

[Intel-gfx] ✓ Fi.CI.BAT: success for 4.10-rc2 oops in DRM connector code

[Patchwork]

== Series Details ==

Series: 4.10-rc2 oops in DRM connector code
URL   : https://patchwork.freedesktop.org/series/17563/
State : success

== Summary ==

Series 17563v1 4.10-rc2 oops in DRM connector code
https://patchwork.freedesktop.org/api/1.0/series/17563/revisions/1/mbox/


fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:82   pass:69   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:246  pass:214  dwarn:0   dfail:0   fail:0   skip:32 

8e6dfeed0f95b5f85430271a46d2f817a6df1d21 drm-tip: 2017y-01m-05d-16h-48m-32s UTC 
integration manifest
0d2c9b1 4.10-rc2 oops in DRM connector code

== Logs ==

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

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

[Dave Airlie]

On 6 January 2017 at 04:29, Linus Torvalds
 wrote:
> On Thu, Jan 5, 2017 at 3:19 AM, Jani Nikula  wrote:
>>
>> Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,
>
> I'm going to ignore this on the assumption that Dave is around. But if
> nothing happens for a few days, ping me again and I'll pull it
> directly. Ok?

Ack from me for direct pull, I'm only on email/irc until
Monday/Tuesday next week,
then off again until LCA, then LCA.

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

[Intel-gfx] [PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[vathsala nagaraju]

Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
psr1 should be disabled.When psr2 is exited , bit 31 of reg
PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
(psr1 control register)is set to 0.
Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
instead of PSR2_STATUS register, which has wrong data, resulting
in blankscreen.
hsw_enable_source is split into hsw_enable_source_psr1 and
hsw_enable_source_psr2 for easier code review and maintenance,
as suggested by rodrigo and jim.

v2: (Vivi Rodrigo)
- Rename hsw_enable_source_psr* to intel_enable_source_psr*

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Vathsala Nagaraju 
Signed-off-by: Patil Deepti 
---
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_psr.c | 124 +--
 2 files changed, 97 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa..7830e6e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3615,6 +3615,9 @@ enum {
 #define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
 #define   EDP_PSR2_IDLE_MASK   0xf
 
+#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
+#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
+
 /* VGA port control */
 #define ADPA   _MMIO(0x61100)
 #define PCH_ADPA_MMIO(0xe1100)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c3aa649..d5e8bcc 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
   VLV_EDP_PSR_ACTIVE_ENTRY);
 }
 
-static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+static void intel_enable_source_psr1(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-
uint32_t max_sleep_time = 0x1f;
/*
 * Let's respect VBT in case VBT asks a higher idle_frame value.
@@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
val |= EDP_PSR_TP1_TP2_SEL;
 
I915_WRITE(EDP_PSR_CTL, val);
+}
 
-   if (!dev_priv->psr.psr2_support)
-   return;
+static void intel_enable_source_psr2(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   /*
+* Let's respect VBT in case VBT asks a higher idle_frame value.
+* Let's use 6 as the minimum to cover all known cases including
+* the off-by-one issue that HW has in some cases. Also there are
+* cases where sink should be able to train
+* with the 5 or 6 idle patterns.
+*/
+   uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
+   uint32_t val = EDP_PSR_ENABLE;
+
+   val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
 
/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
-   val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
 
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
I915_WRITE(EDP_PSR2_CTL, val);
 }
 
+
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   /* psr1 and psr2 are mutually exclusive.*/
+   if (dev_priv->psr.psr2_support)
+   intel_enable_source_psr2(intel_dp);
+   else
+   intel_enable_source_psr1(intel_dp);
+}
+
 static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
-   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
+   if (dev_priv->psr.psr2_support)
+   WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
+   else
+   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
WARN_ON(dev_priv->psr.active);
lockdep_assert_held(_priv->psr.lock);
 
@@ -462,8 +494,6 @@ void 

[Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

My Thinkpad x260 doesn't like to be unplugged from its dock.  I don't
think this is a new bug.  It's happening on my distro's 4.4 kernel
as well.

The actual oops is in device_del().  It appears to have been passed a
null 'struct device *'.

There appears to have been a race _around_ here fixed in 1f7717552e.
I've looked for and tried to find the locking that prevents
drm_connector_unregister() from being called twice concurrently.  I'm
unable to find anything.

drm_dp_destroy_connector_work() has some locking that looks useful:

mutex_lock(>destroy_connector_lock)

but it's released before the offending call:

mgr->cbs->destroy_connector(mgr, port->connector);

which actually calls intel_dp_destroy_mst_connector().  I have no idea
if it's correct (and haven't even run it with lockdep), but the attached
patch does seem to fix my oopses.

Any ideas?

> Jan  5 10:22:32 ray kernel: [  537.087042] BUG: unable to handle kernel NULL 
> pointer dereference at 009e
> Jan  5 10:22:32 ray kernel: [  537.087954] IP: device_del+0x19/0x330
> Jan  5 10:22:32 ray kernel: [  537.088860] PGD 0
> Jan  5 10:22:32 ray kernel: [  537.088860]
> Jan  5 10:22:32 ray kernel: [  537.090578] Oops:  [#1] SMP
> Jan  5 10:22:32 ray kernel: [  537.091406] Modules linked in: ctr ccm 
> ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
> nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
> nf_reject_ipv4 xt_CHECKSUM iptable_mangle xt_tcpudp bridge stp llc 
> iptable_filter ip_tables ebtable_nat ebtables x_tables cmac rfcomm bnep 
> dm_crypt arc4 iwlmvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic iwlwifi intel_rapl snd_hda_intel iosf_mbi 
> hid_logitech_hidpp snd_seq_midi cfg80211 x86_pkg_temp_thermal snd_hda_codec 
> snd_seq_midi_event snd_hwdep btusb snd_rawmidi snd_hda_core btrtl coretemp 
> snd_seq snd_pcm btbcm btintel joydev bluetooth ghash_clmulni_intel snd_timer 
> shpchp thinkpad_acpi snd_seq_device nvram wmi snd soundcore mac_hid 
> aesni_intel aes_x86_64 crypto_simd cryptd glue_helper kvm_intel
> Jan  5 10:22:32 ray kernel: [  537.095222]  kvm irqbypass hid_generic 
> hid_logitech_dj usbhid hid
> Jan  5 10:22:32 ray kernel: [  537.096272] CPU: 2 PID: 23 Comm: kworker/2:0 
> Tainted: GW   4.10.0-rc2 #47
> Jan  5 10:22:32 ray kernel: [  537.097263] Hardware name: LENOVO 
> 20F5S7V800/20F5S7V800, BIOS R02ET50W (1.23 ) 09/20/2016
> Jan  5 10:22:32 ray kernel: [  537.098291] Workqueue: events 
> drm_dp_destroy_connector_work
> Jan  5 10:22:32 ray kernel: [  537.099328] task: 88040f2f1e00 task.stack: 
> c9000198c000
> Jan  5 10:22:32 ray kernel: [  537.100335] RIP: 0010:device_del+0x19/0x330
> Jan  5 10:22:32 ray kernel: [  537.101340] RSP: 0018:c9000198fd58 EFLAGS: 
> 00010282
> Jan  5 10:22:32 ray kernel: [  537.102361] RAX:  RBX: 
> fffe RCX: 88040c5191b0
> Jan  5 10:22:32 ray kernel: [  537.103418] RDX: 81cb6246 RSI: 
> 0001 RDI: fffe
> Jan  5 10:22:32 ray kernel: [  537.104473] RBP: c9000198fd90 R08: 
>  R09: 880421517780
> Jan  5 10:22:32 ray kernel: [  537.105574] R10: 007d0ce17c93 R11: 
> 0001 R12: fffe
> Jan  5 10:22:32 ray kernel: [  537.106636] R13: 88040ed36bd8 R14: 
> 88040ed36788 R15: 88040c728810
> Jan  5 10:22:32 ray kernel: [  537.107728] FS:  () 
> GS:88042150() knlGS:
> Jan  5 10:22:32 ray kernel: [  537.108812] CS:  0010 DS:  ES:  CR0: 
> 80050033
> Jan  5 10:22:32 ray kernel: [  537.109937] CR2: 009e CR3: 
> 000384894000 CR4: 003406e0
> Jan  5 10:22:32 ray kernel: [  537.111038] DR0:  DR1: 
>  DR2: 
> Jan  5 10:22:32 ray kernel: [  537.112142] DR3:  DR6: 
> fffe0ff0 DR7: 0400
> Jan  5 10:22:32 ray kernel: [  537.113223] Call Trace:
> Jan  5 10:22:32 ray kernel: [  537.114293]  device_unregister+0x12/0x30
> Jan  5 10:22:32 ray kernel: [  537.115354]  
> drm_sysfs_connector_remove+0x3b/0x50
> Jan  5 10:22:32 ray kernel: [  537.116391]  
> drm_connector_unregister.part.8+0x27/0x40
> Jan  5 10:22:32 ray kernel: [  537.117433]  drm_connector_unregister+0x14/0x20
> Jan  5 10:22:32 ray kernel: [  537.118478]  
> intel_dp_destroy_mst_connector+0x1a/0x80
> Jan  5 10:22:32 ray kernel: [  537.119513]  
> drm_dp_destroy_connector_work+0xa9/0x150
> Jan  5 10:22:32 ray kernel: [  537.120539]  process_one_work+0x14b/0x430
> Jan  5 10:22:32 ray kernel: [  537.121568]  worker_thread+0x12b/0x4a0
> Jan  5 10:22:32 ray kernel: [  537.122581]  kthread+0x10c/0x140
> Jan  5 10:22:32 ray kernel: [  537.123583]  ? process_one_work+0x430/0x430
> Jan  5 10:22:32 ray kernel: [  537.124584]  ? kthread_create_on_node+0x40/0x40
> Jan  5 10:22:32 ray kernel: [  537.125574]  ret_from_fork+0x27/0x40
> Jan  5 10:22:32 ray 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only skip requests once a context is banned (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Only skip requests once a context is banned (rev2)
URL   : https://patchwork.freedesktop.org/series/17404/
State : success

== Summary ==

Series 17404v2 drm/i915: Only skip requests once a context is banned
https://patchwork.freedesktop.org/api/1.0/series/17404/revisions/2/mbox/


fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:82   pass:69   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:246  pass:214  dwarn:0   dfail:0   fail:0   skip:32 

8e6dfeed0f95b5f85430271a46d2f817a6df1d21 drm-tip: 2017y-01m-05d-16h-48m-32s UTC 
integration manifest
2a14921 drm/i915: Only skip requests once a context is banned

== Logs ==

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

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

[Linus Torvalds]

On Thu, Jan 5, 2017 at 3:19 AM, Jani Nikula  wrote:
>
> Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,

I'm going to ignore this on the assumption that Dave is around. But if
nothing happens for a few days, ping me again and I'll pull it
directly. Ok?

  Linus
___
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: Move a few more utility macros to i915_utils.h

[Patchwork]

== Series Details ==

Series: drm/i915: Move a few more utility macros to i915_utils.h
URL   : https://patchwork.freedesktop.org/series/17557/
State : success

== Summary ==

Series 17557v1 drm/i915: Move a few more utility macros to i915_utils.h
https://patchwork.freedesktop.org/api/1.0/series/17557/revisions/1/mbox/


fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:82   pass:69   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:246  pass:214  dwarn:0   dfail:0   fail:0   skip:32 

8e6dfeed0f95b5f85430271a46d2f817a6df1d21 drm-tip: 2017y-01m-05d-16h-48m-32s UTC 
integration manifest
36d3606 drm/i915: Move a few more utility macros to i915_utils.h

== Logs ==

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

Re: [Intel-gfx] [PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[Rodrigo Vivi]

On Mon, Jan 02, 2017 at 05:00:56PM +0530, vathsala nagaraju wrote:
> Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
> psr1 should be disabled.When psr2 is exited , bit 31 of reg
> PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
> (psr1 control register)is set to 0.
> Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
> instead of PSR2_STATUS register, which has wrong data, resulting
> in blankscreen.
> hsw_enable_source is split into hsw_enable_source_psr1 and
> hsw_enable_source_psr2 for easier code review and maintenance,
> as suggested by rodrigo and jim.
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |   3 +
>  drivers/gpu/drm/i915/intel_psr.c | 124 
> +--
>  2 files changed, 97 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa..7830e6e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3615,6 +3615,9 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
>  
> +#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
> +#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +
>  /* VGA port control */
>  #define ADPA _MMIO(0x61100)
>  #define PCH_ADPA_MMIO(0xe1100)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3aa649..ff2ecfd 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
>  VLV_EDP_PSR_ACTIVE_ENTRY);
>  }
>  
> -static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +static void hsw_enable_source_psr1(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> -
>   uint32_t max_sleep_time = 0x1f;
>   /*
>* Let's respect VBT in case VBT asks a higher idle_frame value.
> @@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   val |= EDP_PSR_TP1_TP2_SEL;
>  
>   I915_WRITE(EDP_PSR_CTL, val);
> +}
>  
> - if (!dev_priv->psr.psr2_support)
> - return;
> +static void hsw_enable_source_psr2(struct intel_dp *intel_dp)

hm... I believe
skl_enable_source_psr2 is more appropriated because psr2 was introduced on skl
and not on hsw as this might lead people to think...
although when we call this we check for psr2 presence and not platform itself.

maybe just let hsw_ on the main one
hsw_psr_enable_source

 and for these 2 new functions just use

intel_enable_source_psr1
intel_enable_source_psr2

> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /*
> +  * Let's respect VBT in case VBT asks a higher idle_frame value.
> +  * Let's use 6 as the minimum to cover all known cases including
> +  * the off-by-one issue that HW has in some cases. Also there are
> +  * cases where sink should be able to train
> +  * with the 5 or 6 idle patterns.
> +  */
> + uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> + uint32_t val = EDP_PSR_ENABLE;
> +
> + val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> @@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   I915_WRITE(EDP_PSR2_CTL, val);
>  }
>  
> +
> +static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /* psr1 and psr2 are mutually exclusive.*/
> + if (dev_priv->psr.psr2_support)
> + hsw_enable_source_psr2(intel_dp);
> + else
> + hsw_enable_source_psr1(intel_dp);
> +}
> +
>  static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
>  

Re: [Intel-gfx] [PATCH 04/10] drm/i915/psr: disable aux_frame_sync on psr2 exit

[Rodrigo Vivi]

makes sense


Reviewed-by: Rodrigo Vivi 


On Mon, Jan 02, 2017 at 05:00:57PM +0530, vathsala nagaraju wrote:
> Screen freeze observed if AUX_FRAME_SYNC is not disabled
> on psr2 exit.AUX_FRAME_SYNC needed for psr2 is enabled during
> psr2 entry. It must be disabled on psr2 exit.
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index ff2ecfd..93eb0f0 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -589,6 +589,11 @@ static void hsw_psr_disable(struct intel_dp *intel_dp)
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
>   if (dev_priv->psr.active) {
> + if (dev_priv->psr.aux_frame_sync)
> + drm_dp_dpcd_writeb(_dp->aux,
> + DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> + 0);
> +
>   if (dev_priv->psr.psr2_support)
>   I915_WRITE(EDP_PSR2_CTL,
>   I915_READ(EDP_PSR2_CTL) &
> @@ -729,6 +734,10 @@ static void intel_psr_exit(struct drm_i915_private 
> *dev_priv)
>   return;
>  
>   if (HAS_DDI(dev_priv)) {
> + if (dev_priv->psr.aux_frame_sync)
> + drm_dp_dpcd_writeb(_dp->aux,
> + DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> + 0);
>   if (dev_priv->psr.psr2_support) {
>   val = I915_READ(EDP_PSR2_CTL);
>   WARN_ON(!(val & EDP_PSR2_ENABLE));
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2

[Rodrigo Vivi]

Please don't forget about the bit 11 for KBL. In a separated patch.

This patch is correct and count with my rv-b, but I believe the best place for 
this is 
on intel_psr_enable, right after setup_vsc.

On Mon, Jan 02, 2017 at 05:00:59PM +0530, vathsala nagaraju wrote:
> As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15
> must be programmed.
> Enable bit 12 for programmable header packet.
> Enable bit 15 for Y cordinate support.
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: vathsala nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 7 +++
>  drivers/gpu/drm/i915/intel_psr.c | 7 +++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7830e6e..5ca506a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6449,6 +6449,13 @@ enum {
>  #define  BDW_DPRS_MASK_VBLANK_SRD(1 << 0)
>  #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A, 
> _CHICKEN_PIPESL_1_B)
>  
> +#define CHICKEN_TRANS_A 0x420c0
> +#define CHICKEN_TRANS_B 0x420c4
> +#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
> CHICKEN_TRANS_B)
> +#define TRANS_EDP  3
> +#define CHICKEN_TRANS_BIT12(1<<12)
> +#define CHICKEN_TRANS_BIT15(1<<15)
> +
>  #define DISP_ARB_CTL _MMIO(0x45000)
>  #define  DISP_FBC_MEMORY_WAKE(1<<31)
>  #define  DISP_TILE_SURFACE_SWIZZLING (1<<13)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 494e4b2..2e75ef6 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -332,6 +332,7 @@ static void hsw_enable_source_psr2(struct intel_dp 
> *intel_dp)
>*/
>   uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
>   uint32_t val = EDP_PSR_ENABLE;
> + uint32_t chicken_trans = 0;
>  
>   val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
> @@ -349,6 +350,12 @@ static void hsw_enable_source_psr2(struct intel_dp 
> *intel_dp)
>   else
>   val |= EDP_PSR2_TP2_TIME_50;
>  
> + /* Set CHICKEN_TRANS_BIT15 if Y coordinate is supported */
> + if (dev_priv->psr.y_cord_support)
> + chicken_trans = CHICKEN_TRANS_BIT15;
> + /* Set CHICKEN_TRANS_BIT12 for programable header */
> + chicken_trans = chicken_trans | CHICKEN_TRANS_BIT12;
> + I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken_trans);
>   I915_WRITE(EDP_PSR2_CTL, val);
>  }
>  
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels

[Rodrigo Vivi]

On Mon, Jan 02, 2017 at 05:01:01PM +0530, vathsala nagaraju wrote:
> Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
> is implemented,this restriction is removed so that psr2
> can work on panels without y cordinate support.
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 19cd4d7..ca3ef3e 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -495,6 +495,15 @@ void intel_psr_enable(struct intel_dp *intel_dp)

I believe the better place for this code is on the match_conditions function...

>   return;
>   }
>  
> + /*
> +  * FIXME:enable psr2 only for y-cordinate psr2 panels
> +  * After gtc implementation , remove this restriction.
> +  */
> + if (!dev_priv->psr.y_cord_support &&  dev_priv->psr.psr2_support) {
> + DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y 
> coordinate\n");
> + return;
> + }
> +
>   mutex_lock(_priv->psr.lock);
>   if (dev_priv->psr.enabled) {
>   DRM_DEBUG_KMS("PSR already in use\n");
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/10] drm/i915/psr: report live PSR2 State

[Rodrigo Vivi]

I like this live status!

On Mon, Jan 02, 2017 at 05:01:02PM +0530, vathsala nagaraju wrote:
> Reports  live state of PSR2 form PSR2_STATUS register.
> bit field 31:28 gives the live state of PSR2.
> It can be used to check if system is in deep sleep,
> selective update or selective update standby.
> During video play back, we can use this to check
> if system is entering SU mode or not.
> when system is in idle state, DEEP_SLEEP(8) must be entered.
> When video playback is happening, system must be in
> SLEEP(3 / selective update) or SU_STANDBY( 6 / selective update standby)
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 24 
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 9d7b5a8..8b0e3f9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2606,6 +2606,30 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>  
>   seq_printf(m, "Performance_Counter: %u\n", psrperf);
>   }
> + if (dev_priv->psr.psr2_support) {
> + static const char * const live_status[] = {
> + "IDLE",
> + "CAPTURE",
> + "CAPTURE_Fs",

Fs? all others are fully capital

> + "SLEEP",
> + "BUFON_FW",
> + "ML_UP",
> + "SU_STANDBY",
> + "FAST_SLEEP",
> + "DEEP_SLEEP",
> + "BUF_ON",
> + "TG_ON" };
> + u8 pos = (I915_READ(EDP_PSR2_STATUS_CTL) &
> + EDP_PSR2_STATUS_STATE_MASK) >>
> + EDP_PSR2_STATUS_STATE_SHIFT;
> +
> + seq_printf(m, "PSR2_STATUS_EDP: %x\n",
> + I915_READ(EDP_PSR2_STATUS_CTL));
> +
> + if (pos <= EDP_PSR2_STATUS_TG_ON)

I like this protection...

> + seq_printf(m, "PSR2 live state %s\n",
> + live_status[pos]);
> + }
>   mutex_unlock(_priv->psr.lock);
>  
>   intel_runtime_pm_put(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0cbe564..03a14d9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3624,6 +3624,8 @@ enum {
>  
>  #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
>  #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +#define EDP_PSR2_STATUS_STATE_SHIFT28
> +#define EDP_PSR2_STATUS_TG_ON  0xa

... but I don't like how this TG_ON is defined,
because following the general style
EDP_PSR2_STATUS_TG_ON should be (0xa<<28)
so it might confuse people...

maybe just remove this and use the protection with size of live_status?


>  
>  /* VGA port control */
>  #define ADPA _MMIO(0x61100)
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Implement .get_format_info() hook for CCS

[Ben Widawsky]

On 17-01-05 16:24:56, Tvrtko Ursulin wrote:


On 04/01/2017 18:42, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts of the main surface are compressed and which are not. The location
of CCS is provided by userspace as just another plane with its own offset.

By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.

Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs. Yf as well. If
desired, we could potentially return a unique pointer for each
pixel_format+tiling+ccs combination, in which case we immediately be
able to tell if any of that stuff changed by just comparing the
pointers. But that does sound a bit wasteful space wise.

v2: Drop the 'dev' argument from the hook
v3: Include the description of the CCS surface layout

Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Reviewed-by: Ben Widawsky 
Signed-off-by: Ville Syrjälä 
---
drivers/gpu/drm/i915/intel_display.c | 36 ++
include/uapi/drm/drm_fourcc.h| 49 
2 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c4662b2e9613..38de9df0ec60 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2478,6 +2478,41 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t 
fb_modifier)
}
}

+static const struct drm_format_info ccs_formats[] = {
+   { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+  int num_formats, u32 format)
+{
+   int i;
+
+   for (i = 0; i < num_formats; i++) {
+   if (formats[i].format == format)
+   return [i];
+   }
+
+   return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
+{
+   switch (cmd->modifier[0]) {
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+   default:
+   return NULL;
+   }
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
   struct drm_framebuffer *fb)
@@ -16083,6 +16118,7 @@ static void intel_atomic_state_free(struct 
drm_atomic_state *state)

static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+   .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7fabcde..4581e3d41e5c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -230,6 +230,55 @@ extern "C" {
#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)

/*
+ * Intel color control surface (CCS) for render compression
+ *
+ * The framebuffer format must be one of the 8:8:8:8 RGB formats,
+ * the main surface will be plane index 0 and will be Y/Yf-tiled,
+ * the CCS will be plane index 1.
+ *
+ * Each byte of CCS contains 4 pairs of bits, with each pair of bits
+ * matching an area of 8x4 pixels of the main surface. Which would seem
+ * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
+ * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
+ * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
+ * ---
+ * | 01 | 23 |
+ *  --
+ * | 45 | 67 |
+ * ---
+ *
+ * Actually only the lower bit of the pair seems to have any effect.
+ * No idea why. 0 in the lower bit would seem to mean not compressed,
+ * and 1 is compressed.  The interpreation of the main surface data
+ * when the block is 

Re: [Intel-gfx] [PATCH 10/10] drm/i915/psr: EDP_PSR_PERF_CNT not valid for psr2

[Rodrigo Vivi]

On Mon, Jan 02, 2017 at 05:01:03PM +0530, vathsala nagaraju wrote:
> PSR1 and PSR2 enable sequence are mutually exclusive.
> Register SRD_PERF_COUNT increments while system is in psr1.
> This register is not valid for psr2.while in psr2,SRD_PERF_COUNT
> is always 0.
> Reporting psr perfcount from SRD_PERF_COUNT is not valid for psr2 case.
> Also, if dc6 is disabled via kernel parameter i915.enable_dc=0,
> EDP_PSR_PERF_CNT can be reported for SKL+ platforms for debug
> purpose.
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 8b0e3f9..4136cec 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2539,6 +2539,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
> *data)
>   u32 stat[3];
>   enum pipe pipe;
>   bool enabled = false;
> + bool dc6_enabled = false;
>  
>   if (!HAS_PSR(dev_priv)) {
>   seq_puts(m, "PSR not supported\n");
> @@ -2598,11 +2599,20 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>  
>   /*
>* VLV/CHV PSR has no kind of performance counter
> +  * EDP_PSR_PERF_CNT is not valid for psr2.
>* SKL+ Perf counter is reset to 0 everytime DC state is entered
> +  * if we want to read EDP_PSR_PERF_CNT for debug purpose on SKL+,
> +  * disable dc state in kernel parameter i915.enable_dc=0.
>*/
> - if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> +
> + dc6_enabled = ((I915_READ(DC_STATE_EN) &
> + DC_STATE_EN_UPTO_DC5_DC6_MASK) ==
> + DC_STATE_EN_UPTO_DC6);

I don't like this approach because if here on this line there is no
guarantee anymore that DC state is not enabled.
Ideally DC state is enabled most of the time so let's just avoid
the perf counter 0 that just confuses people.

> +
> + if ((!dev_priv->psr.psr2_support && !dc6_enabled) ||
> +  IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
>   psrperf = I915_READ(EDP_PSR_PERF_CNT) &
> - EDP_PSR_PERF_CNT_MASK;
> +   EDP_PSR_PERF_CNT_MASK;
>  
>   seq_printf(m, "Performance_Counter: %u\n", psrperf);
>   }
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Move a few more utility macros to i915_utils.h

[Tvrtko Ursulin]

On 05/01/2017 16:41, Chris Wilson wrote:

Now that we have split out a header file for simple macros (that maybe
we can promote into a core header), move a few macros across from
i915_drv.h

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fb6d93450927..4fb91f5c4cf1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4085,24 +4085,4 @@ int remap_io_mapping(struct vm_area_struct *vma,
 unsigned long addr, unsigned long pfn, unsigned long size,
 struct io_mapping *iomap);

-#define ptr_mask_bits(ptr) ({  \
-   unsigned long __v = (unsigned long)(ptr);   \
-   (typeof(ptr))(__v & PAGE_MASK); \
-})
-
-#define ptr_unpack_bits(ptr, bits) ({  \
-   unsigned long __v = (unsigned long)(ptr);   \
-   (bits) = __v & ~PAGE_MASK;  \
-   (typeof(ptr))(__v & PAGE_MASK); \
-})
-
-#define ptr_pack_bits(ptr, bits)   \
-   ((typeof(ptr))((unsigned long)(ptr) | (bits)))
-
-#define fetch_and_zero(ptr) ({ \
-   typeof(*ptr) __T = *(ptr);  \
-   *(ptr) = (typeof(*ptr))0;   \
-   __T;\
-})
-
 #endif
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 9983ef30bac8..34020873e1f6 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -41,4 +41,24 @@
 #define overflows_type(x, T) \
(sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))

+#define ptr_mask_bits(ptr) ({  \
+   unsigned long __v = (unsigned long)(ptr);   \
+   (typeof(ptr))(__v & PAGE_MASK); \
+})
+
+#define ptr_unpack_bits(ptr, bits) ({  \
+   unsigned long __v = (unsigned long)(ptr);   \
+   (bits) = __v & ~PAGE_MASK;  \
+   (typeof(ptr))(__v & PAGE_MASK); \
+})
+
+#define ptr_pack_bits(ptr, bits)   \
+   ((typeof(ptr))((unsigned long)(ptr) | (bits)))
+
+#define fetch_and_zero(ptr) ({ \
+   typeof(*ptr) __T = *(ptr);  \
+   *(ptr) = (typeof(*ptr))0;   \
+   __T;\
+})
+
 #endif /* !__I915_UTILS_H */



You had my r-b for this one as well.

Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH] drm/i915: Only skip requests once a context is banned

[Chris Wilson]

If we skip before banning, we have an inconsistent interface between
execbuf still queueing valid request but those requests already queued
being cancelled. If we only cancel the pending requests once we stop
accepting new requests, the user interface is more consistent.

Reported-by: Tvrtko Ursulin 
Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc:  # v4.9+
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 70ddff3570bb..e60467271898 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2734,7 +2734,7 @@ void i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
 static void i915_gem_reset_engine(struct intel_engine_cs *engine)
 {
struct drm_i915_gem_request *request;
-   struct i915_gem_context *incomplete_ctx;
+   struct i915_gem_context *hung_ctx;
struct intel_timeline *timeline;
unsigned long flags;
bool ring_hung;
@@ -2746,6 +2746,8 @@ static void i915_gem_reset_engine(struct intel_engine_cs 
*engine)
if (!request)
return;
 
+   hung_ctx = request->ctx;
+
ring_hung = engine->hangcheck.stalled;
if (engine->hangcheck.seqno != intel_engine_get_seqno(engine)) {
DRM_DEBUG_DRIVER("%s pardoned, was guilty? %s\n",
@@ -2755,9 +2757,9 @@ static void i915_gem_reset_engine(struct intel_engine_cs 
*engine)
}
 
if (ring_hung)
-   i915_gem_context_mark_guilty(request->ctx);
+   i915_gem_context_mark_guilty(hung_ctx);
else
-   i915_gem_context_mark_innocent(request->ctx);
+   i915_gem_context_mark_innocent(hung_ctx);
 
if (!ring_hung)
return;
@@ -2768,6 +2770,10 @@ static void i915_gem_reset_engine(struct intel_engine_cs 
*engine)
/* Setup the CS to resume from the breadcrumb of the hung request */
engine->reset_hw(engine, request);
 
+   /* If this context is now banned, skip all of its pending requests. */
+   if (!i915_gem_context_is_banned(hung_ctx))
+   return;
+
/* Users of the default context do not rely on logical state
 * preserved between batches. They have to emit full state on
 * every batch and so it is safe to execute queued requests following
@@ -2776,17 +2782,16 @@ static void i915_gem_reset_engine(struct 
intel_engine_cs *engine)
 * Other contexts preserve state, now corrupt. We want to skip all
 * queued requests that reference the corrupt context.
 */
-   incomplete_ctx = request->ctx;
-   if (i915_gem_context_is_default(incomplete_ctx))
+   if (i915_gem_context_is_default(hung_ctx))
return;
 
-   timeline = i915_gem_context_lookup_timeline(incomplete_ctx, engine);
+   timeline = i915_gem_context_lookup_timeline(hung_ctx, engine);
 
spin_lock_irqsave(>timeline->lock, flags);
spin_lock(>lock);
 
list_for_each_entry_continue(request, >timeline->requests, link)
-   if (request->ctx == incomplete_ctx)
+   if (request->ctx == hung_ctx)
reset_request(request);
 
list_for_each_entry(request, >requests, link)
-- 
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: warning for drm/i915: initialize ret in i915_gem_evict_something (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: initialize ret in i915_gem_evict_something (rev2)
URL   : https://patchwork.freedesktop.org/series/17552/
State : warning

== Summary ==

Series 17552v2 drm/i915: initialize ret in i915_gem_evict_something
https://patchwork.freedesktop.org/api/1.0/series/17552/revisions/2/mbox/

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

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:1   skip:14 
fi-bsw-n3050 total:246  pass:206  dwarn:0   dfail:0   fail:1   skip:39 
fi-bxt-j4205 total:246  pass:223  dwarn:0   dfail:0   fail:1   skip:22 
fi-bxt-t5700 total:82   pass:69   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:246  pass:218  dwarn:0   dfail:0   fail:1   skip:27 
fi-byt-n2820 total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-hsw-4770  total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-hsw-4770r total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-ivb-3520m total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-ivb-3770  total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-kbl-7500u total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:221  dwarn:3   dfail:0   fail:1   skip:21 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-snb-2520m total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-snb-2600  total:246  pass:213  dwarn:0   dfail:0   fail:1   skip:32 

6a304f1f2e7446fe71bf7845c34dcdc73436c547 drm-tip: 2017y-01m-05d-11h-52m-09s UTC 
integration manifest
b45bcf3 drm/i915: Clear ret before unbinding in i915_gem_evict_something()

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Clear ret before unbinding in i915_gem_evict_something()

[Chris Wilson]

On Thu, Jan 05, 2017 at 04:36:06PM +, Matthew Auld wrote:
> On 5 January 2017 at 16:33, Chris Wilson  wrote:
> > On Thu, Jan 05, 2017 at 03:59:40PM +, Chris Wilson wrote:
> >> Missed when rebasing patches, I failed to set ret to zero before
> >> starting the unbind loop (which depends upon ret being zero).
> >>
> >> Reported-by: Matthew Auld 
> >> Fixes: 9332f3b1b99a ("drm/i915: Combine loops within 
> >> i915_gem_evict_something")
> >> Signed-off-by: Chris Wilson 
> >> Cc: Matthew Auld 
> > Cc:  # v4.9+
> Reviewed-by: Matthew Auld 

Thanks for spotting my mistake, pushed before it starts to cause
problems in the wild.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Move a few more utility macros to i915_utils.h

[Matthew Auld]

On 5 January 2017 at 16:41, Chris Wilson  wrote:
> Now that we have split out a header file for simple macros (that maybe
> we can promote into a core header), move a few macros across from
> i915_drv.h
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Move a few more utility macros to i915_utils.h

[Chris Wilson]

Now that we have split out a header file for simple macros (that maybe
we can promote into a core header), move a few macros across from
i915_drv.h

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fb6d93450927..4fb91f5c4cf1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4085,24 +4085,4 @@ int remap_io_mapping(struct vm_area_struct *vma,
 unsigned long addr, unsigned long pfn, unsigned long size,
 struct io_mapping *iomap);
 
-#define ptr_mask_bits(ptr) ({  \
-   unsigned long __v = (unsigned long)(ptr);   \
-   (typeof(ptr))(__v & PAGE_MASK); \
-})
-
-#define ptr_unpack_bits(ptr, bits) ({  \
-   unsigned long __v = (unsigned long)(ptr);   \
-   (bits) = __v & ~PAGE_MASK;  \
-   (typeof(ptr))(__v & PAGE_MASK); \
-})
-
-#define ptr_pack_bits(ptr, bits)   \
-   ((typeof(ptr))((unsigned long)(ptr) | (bits)))
-
-#define fetch_and_zero(ptr) ({ \
-   typeof(*ptr) __T = *(ptr);  \
-   *(ptr) = (typeof(*ptr))0;   \
-   __T;\
-})
-
 #endif
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 9983ef30bac8..34020873e1f6 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -41,4 +41,24 @@
 #define overflows_type(x, T) \
(sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))
 
+#define ptr_mask_bits(ptr) ({  \
+   unsigned long __v = (unsigned long)(ptr);   \
+   (typeof(ptr))(__v & PAGE_MASK); \
+})
+
+#define ptr_unpack_bits(ptr, bits) ({  \
+   unsigned long __v = (unsigned long)(ptr);   \
+   (bits) = __v & ~PAGE_MASK;  \
+   (typeof(ptr))(__v & PAGE_MASK); \
+})
+
+#define ptr_pack_bits(ptr, bits)   \
+   ((typeof(ptr))((unsigned long)(ptr) | (bits)))
+
+#define fetch_and_zero(ptr) ({ \
+   typeof(*ptr) __T = *(ptr);  \
+   *(ptr) = (typeof(*ptr))0;   \
+   __T;\
+})
+
 #endif /* !__I915_UTILS_H */
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Clear ret before unbinding in i915_gem_evict_something()

[Matthew Auld]

On 5 January 2017 at 16:33, Chris Wilson  wrote:
> On Thu, Jan 05, 2017 at 03:59:40PM +, Chris Wilson wrote:
>> Missed when rebasing patches, I failed to set ret to zero before
>> starting the unbind loop (which depends upon ret being zero).
>>
>> Reported-by: Matthew Auld 
>> Fixes: 9332f3b1b99a ("drm/i915: Combine loops within 
>> i915_gem_evict_something")
>> Signed-off-by: Chris Wilson 
>> Cc: Matthew Auld 
> Cc:  # v4.9+
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Implement .get_format_info() hook for CCS

[Tvrtko Ursulin]

On 04/01/2017 18:42, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts of the main surface are compressed and which are not. The location
of CCS is provided by userspace as just another plane with its own offset.

By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.

Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs. Yf as well. If
desired, we could potentially return a unique pointer for each
pixel_format+tiling+ccs combination, in which case we immediately be
able to tell if any of that stuff changed by just comparing the
pointers. But that does sound a bit wasteful space wise.

v2: Drop the 'dev' argument from the hook
v3: Include the description of the CCS surface layout

Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Reviewed-by: Ben Widawsky 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 36 ++
 include/uapi/drm/drm_fourcc.h| 49 
 2 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c4662b2e9613..38de9df0ec60 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2478,6 +2478,41 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t 
fb_modifier)
}
 }

+static const struct drm_format_info ccs_formats[] = {
+   { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+  int num_formats, u32 format)
+{
+   int i;
+
+   for (i = 0; i < num_formats; i++) {
+   if (formats[i].format == format)
+   return [i];
+   }
+
+   return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
+{
+   switch (cmd->modifier[0]) {
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+   default:
+   return NULL;
+   }
+}
+
 static int
 intel_fill_fb_info(struct drm_i915_private *dev_priv,
   struct drm_framebuffer *fb)
@@ -16083,6 +16118,7 @@ static void intel_atomic_state_free(struct 
drm_atomic_state *state)

 static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+   .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7fabcde..4581e3d41e5c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -230,6 +230,55 @@ extern "C" {
 #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)

 /*
+ * Intel color control surface (CCS) for render compression
+ *
+ * The framebuffer format must be one of the 8:8:8:8 RGB formats,
+ * the main surface will be plane index 0 and will be Y/Yf-tiled,
+ * the CCS will be plane index 1.
+ *
+ * Each byte of CCS contains 4 pairs of bits, with each pair of bits
+ * matching an area of 8x4 pixels of the main surface. Which would seem
+ * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
+ * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
+ * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
+ * ---
+ * | 01 | 23 |
+ *  --
+ * | 45 | 67 |
+ * ---
+ *
+ * Actually only the lower bit of the pair seems to have any effect.
+ * No idea why. 0 in the lower bit would seem to mean not compressed,
+ * and 1 is compressed.  The interpreation of the main surface data
+ * when the block is marked compressed is unknown as of now.

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Assert all timeline requests are gone before fini

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/5] drm/i915: Assert all timeline requests 
are gone before fini
URL   : https://patchwork.freedesktop.org/series/17556/
State : success

== Summary ==

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

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
dmesg-warn -> PASS   (fi-snb-2520m)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:1   skip:14 
fi-bsw-n3050 total:246  pass:206  dwarn:0   dfail:0   fail:1   skip:39 
fi-bxt-j4205 total:246  pass:223  dwarn:0   dfail:0   fail:1   skip:22 
fi-bxt-t5700 total:82   pass:69   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:246  pass:218  dwarn:0   dfail:0   fail:1   skip:27 
fi-byt-n2820 total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-hsw-4770  total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-hsw-4770r total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-ivb-3520m total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-ivb-3770  total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-kbl-7500u total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:221  dwarn:3   dfail:0   fail:1   skip:21 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-snb-2520m total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-snb-2600  total:246  pass:213  dwarn:0   dfail:0   fail:1   skip:32 

6a304f1f2e7446fe71bf7845c34dcdc73436c547 drm-tip: 2017y-01m-05d-11h-52m-09s UTC 
integration manifest
27795ba drm/i915/guc: Exclude the upper end of the Global GTT for the GuC
a6cc0d9 drm/i915: Move a few utility macros into a separate header
254e24a drm/i915/execlists: Reorder execlists register enabling
ce0843f drm/i915: Assert that we do create the deferred context
18d68ad drm/i915: Assert all timeline requests are gone before fini

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Clear ret before unbinding in i915_gem_evict_something()

[Chris Wilson]

Missed when rebasing patches, I failed to set ret to zero before
starting the unbind loop (which depends upon ret being zero).

Reported-by: Matthew Auld 
Fixes: 9332f3b1b99a ("drm/i915: Combine loops within i915_gem_evict_something")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_evict.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 50129ec1caab..026ebc5a452a 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -209,6 +209,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
}
 
/* Unbinding will emit any required flushes */
+   ret = 0;
while (!list_empty(_list)) {
vma = list_first_entry(_list,
   struct i915_vma,
-- 
2.11.0

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: SKL+ render decompression support (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: SKL+ render decompression support (rev2)
URL   : https://patchwork.freedesktop.org/series/17507/
State : failure

== Summary ==

Series 17507v2 drm/i915: SKL+ render decompression support
https://patchwork.freedesktop.org/api/1.0/series/17507/revisions/2/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
dmesg-warn -> PASS   (fi-snb-2520m)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> INCOMPLETE (fi-skl-6700k)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:1   skip:14 
fi-bsw-n3050 total:246  pass:206  dwarn:0   dfail:0   fail:1   skip:39 
fi-bxt-j4205 total:246  pass:223  dwarn:0   dfail:0   fail:1   skip:22 
fi-bxt-t5700 total:82   pass:69   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:246  pass:218  dwarn:0   dfail:0   fail:1   skip:27 
fi-byt-n2820 total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-hsw-4770  total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-hsw-4770r total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-ivb-3520m total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-ivb-3770  total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-kbl-7500u total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:211  pass:187  dwarn:3   dfail:0   fail:1   skip:19 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-snb-2520m total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-snb-2600  total:246  pass:213  dwarn:0   dfail:0   fail:1   skip:32 

6a304f1f2e7446fe71bf7845c34dcdc73436c547 drm-tip: 2017y-01m-05d-11h-52m-09s UTC 
integration manifest
2989e4e drm/i915: Add render decompression support
701d909 drm/i915: Implement .get_format_info() hook for CCS
2909de8 drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages
7b784ce drm/i915: Pass the correct plane index to _intel_compute_tile_offset()
4130c11 drm/i915: Fix Yf tile width
0784dcc drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane
cd53d3c drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()
0d03743 drm/i915: Plumb drm_framebuffer into more places
6494b83 drm: Add mode_config .get_format_info() hook

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3438/
___
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: initialize ret in i915_gem_evict_something

[Patchwork]

== Series Details ==

Series: drm/i915: initialize ret in i915_gem_evict_something
URL   : https://patchwork.freedesktop.org/series/17552/
State : success

== Summary ==

Series 17552v1 drm/i915: initialize ret in i915_gem_evict_something
https://patchwork.freedesktop.org/api/1.0/series/17552/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
dmesg-warn -> PASS   (fi-snb-2520m)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:1   skip:14 
fi-bsw-n3050 total:246  pass:206  dwarn:0   dfail:0   fail:1   skip:39 
fi-bxt-j4205 total:246  pass:223  dwarn:0   dfail:0   fail:1   skip:22 
fi-bxt-t5700 total:82   pass:69   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:246  pass:218  dwarn:0   dfail:0   fail:1   skip:27 
fi-byt-n2820 total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-hsw-4770  total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-hsw-4770r total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-ivb-3520m total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-kbl-7500u total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:221  dwarn:3   dfail:0   fail:1   skip:21 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-snb-2520m total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-snb-2600  total:246  pass:213  dwarn:0   dfail:0   fail:1   skip:32 

6a304f1f2e7446fe71bf7845c34dcdc73436c547 drm-tip: 2017y-01m-05d-11h-52m-09s UTC 
integration manifest
7d234c9 drm/i915: initialize ret in i915_gem_evict_something

== Logs ==

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

[Intel-gfx] [CI 3/5] drm/i915/execlists: Reorder execlists register enabling

[Chris Wilson]

Empirically we restart following a GPU reset more successfully if we call
lrc_init_hws() (which contains a posting read) last. (The failure mode
that was observed was that breadcrumb writes into the HWS from the
recovered requests went astray leading to the context-switch maintaining
forward progress, but the requests not being retired/completed.)

For clarity, lrc_init_hws() is inlined (and the unused function then
removed).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 51ecb395551b..a9eefb171170 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1335,15 +1335,6 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
return ret;
 }
 
-static void lrc_init_hws(struct intel_engine_cs *engine)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-
-   I915_WRITE(RING_HWS_PGA(engine->mmio_base),
-  engine->status_page.ggtt_offset);
-   POSTING_READ(RING_HWS_PGA(engine->mmio_base));
-}
-
 static int gen8_init_common_ring(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
@@ -1353,20 +1344,19 @@ static int gen8_init_common_ring(struct intel_engine_cs 
*engine)
if (ret)
return ret;
 
-   lrc_init_hws(engine);
-
intel_engine_reset_breadcrumbs(engine);
+   intel_engine_init_hangcheck(engine);
 
I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x);
-
I915_WRITE(RING_MODE_GEN7(engine),
   _MASKED_BIT_DISABLE(GFX_REPLAY_MODE) |
   _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+   I915_WRITE(RING_HWS_PGA(engine->mmio_base),
+  engine->status_page.ggtt_offset);
+   POSTING_READ(RING_HWS_PGA(engine->mmio_base));
 
DRM_DEBUG_DRIVER("Execlists enabled for %s\n", engine->name);
 
-   intel_engine_init_hangcheck(engine);
-
/* After a GPU reset, we may have requests to replay */
if (!execlists_elsp_idle(engine)) {
engine->execlist_port[0].count = 0;
-- 
2.11.0

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

[Intel-gfx] [CI 5/5] drm/i915/guc: Exclude the upper end of the Global GTT for the GuC

[Chris Wilson]

The GuC uses a special mapping for the upper end of the Global GTT,
similar to the way it uses a special mapping for the lower end, so
exclude it from our drm_mm to prevent us using it.

v2: Rename to reflect that it is unmappable similar to the region at the
bottom of the GGTT, and couple it into the assertion that we don't feed
unmappable addresses to the GuC.

Signed-off-by: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 10 ++
 drivers/gpu/drm/i915/i915_guc_reg.h |  3 +++
 drivers/gpu/drm/i915/intel_uc.h |  1 +
 3 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6af9311f72f5..bc2b4421cbd6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3176,6 +3176,16 @@ int i915_ggtt_probe_hw(struct drm_i915_private *dev_priv)
if (ret)
return ret;
 
+   /* Trim the GGTT to fit the GuC mappable upper range (when enabled).
+* This is easier than doing range restriction on the fly, as we
+* currently don't have any bits spare to pass in this upper
+* restriction!
+*/
+   if (HAS_GUC(dev_priv) && i915.enable_guc_loading) {
+   ggtt->base.total = min_t(u64, ggtt->base.total, GUC_GGTT_TOP);
+   ggtt->mappable_end = min(ggtt->mappable_end, ggtt->base.total);
+   }
+
if ((ggtt->base.total - 1) >> 32) {
DRM_ERROR("We never expected a Global GTT with more than 32bits"
  " of address space! Found %lldM!\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 5e638fc37208..6a0adafe0523 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -73,6 +73,9 @@
 #define   GUC_WOPCM_TOP  (0x80 << 12)  /* 512KB */
 #define   BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12)  /* 64KB  */
 
+/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
+#define GUC_GGTT_TOP   0xFEE0
+
 #define GEN8_GT_PM_CONFIG  _MMIO(0x138140)
 #define GEN9LP_GT_PM_CONFIG_MMIO(0x138140)
 #define GEN9_GT_PM_CONFIG  _MMIO(0x13816c)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 3b1e39b0f3ab..9490a8e049c3 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -203,6 +203,7 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
 {
u32 offset = i915_ggtt_offset(vma);
GEM_BUG_ON(offset < GUC_WOPCM_TOP);
+   GEM_BUG_ON(range_overflows_t(u64, offset, vma->size, GUC_GGTT_TOP));
return offset;
 }
 
-- 
2.11.0

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

[Intel-gfx] [CI 4/5] drm/i915: Move a few utility macros into a separate header

[Chris Wilson]

In order to defeat some circular dependencies between headers to allow use
of e.g. range_overflows() in a header, move the simple independent macros
into their own header.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   | 13 +---
 drivers/gpu/drm/i915/i915_gem.c   |  4 
 drivers/gpu/drm/i915/i915_utils.h | 44 +++
 3 files changed, 45 insertions(+), 16 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_utils.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b436621d038..abc8d737cd68 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -52,6 +52,7 @@
 
 #include "i915_params.h"
 #include "i915_reg.h"
+#include "i915_utils.h"
 
 #include "intel_bios.h"
 #include "intel_dpll_mgr.h"
@@ -219,18 +220,6 @@ static inline const char *enableddisabled(bool v)
return v ? "enabled" : "disabled";
 }
 
-#define range_overflows(start, size, max) ({ \
-   typeof(start) start__ = (start); \
-   typeof(size) size__ = (size); \
-   typeof(max) max__ = (max); \
-   (void)(__ == __); \
-   (void)(__ == __); \
-   start__ > max__ || size__ > max__ - start__; \
-})
-
-#define range_overflows_t(type, start, size, max) \
-   range_overflows((type)(start), (type)(size), (type)(max))
-
 enum pipe {
INVALID_PIPE = -1,
PIPE_A = 0,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 37107448a42b..70ddff3570bb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4004,10 +4004,6 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
.put_pages = i915_gem_object_put_pages_gtt,
 };
 
-/* Note we don't consider signbits :| */
-#define overflows_type(x, T) \
-   (sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))
-
 struct drm_i915_gem_object *
 i915_gem_object_create(struct drm_i915_private *dev_priv, u64 size)
 {
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
new file mode 100644
index ..9983ef30bac8
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -0,0 +1,44 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __I915_UTILS_H
+#define __I915_UTILS_H
+
+#define range_overflows(start, size, max) ({ \
+   typeof(start) start__ = (start); \
+   typeof(size) size__ = (size); \
+   typeof(max) max__ = (max); \
+   (void)(__ == __); \
+   (void)(__ == __); \
+   start__ > max__ || size__ > max__ - start__; \
+})
+
+#define range_overflows_t(type, start, size, max) \
+   range_overflows((type)(start), (type)(size), (type)(max))
+
+/* Note we don't consider signbits :| */
+#define overflows_type(x, T) \
+   (sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))
+
+#endif /* !__I915_UTILS_H */
-- 
2.11.0

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

[Intel-gfx] [CI 1/5] drm/i915: Assert all timeline requests are gone before fini

[Chris Wilson]

During i915_gem_timeline_fini(), assert that all the timeline's request
are completed and removed from the timeline.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_timeline.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.c 
b/drivers/gpu/drm/i915/i915_gem_timeline.c
index bf8a471b61e6..b596ca7ee058 100644
--- a/drivers/gpu/drm/i915/i915_gem_timeline.c
+++ b/drivers/gpu/drm/i915/i915_gem_timeline.c
@@ -81,10 +81,18 @@ int i915_gem_timeline_init__global(struct drm_i915_private 
*i915)
, "_timeline->lock");
 }
 
-void i915_gem_timeline_fini(struct i915_gem_timeline *tl)
+void i915_gem_timeline_fini(struct i915_gem_timeline *timeline)
 {
-   lockdep_assert_held(>i915->drm.struct_mutex);
+   int i;
 
-   list_del(>link);
-   kfree(tl->name);
+   lockdep_assert_held(>i915->drm.struct_mutex);
+
+   for (i = 0; i < ARRAY_SIZE(timeline->engine); i++) {
+   struct intel_timeline *tl = >engine[i];
+
+   GEM_BUG_ON(!list_empty(>requests));
+   }
+
+   list_del(>link);
+   kfree(timeline->name);
 }
-- 
2.11.0

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

[Intel-gfx] [CI 2/5] drm/i915: Assert that we do create the deferred context

[Chris Wilson]

In order to convince static analyzers that the allocation function
returns an error or sets ce->state, assert that it is set afterwards.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 227978820320..51ecb395551b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -781,6 +781,7 @@ static int execlists_context_pin(struct intel_engine_cs 
*engine,
if (ret)
goto err;
}
+   GEM_BUG_ON(!ce->state);
 
flags = PIN_GLOBAL;
if (ctx->ggtt_offset_bias)
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915: initialize ret in i915_gem_evict_something

[Matthew Auld]

On 5 January 2017 at 15:13, Chris Wilson  wrote:
> On Thu, Jan 05, 2017 at 02:41:31PM +, Matthew Auld wrote:
>> If we find a suitable victim node on our first pass, then ret
>> will be uninitialized which could lead to some funny business later.
>>
>> Fixes: 9332f3b1b99a ("drm/i915: Combine loops within 
>> i915_gem_evict_something")
>> Cc: Chris Wilson 
>> Signed-off-by: Matthew Auld 
>> ---
>>  drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
>> b/drivers/gpu/drm/i915/i915_gem_evict.c
>> index 50129ec1caab..19716548c455 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
>> @@ -109,7 +109,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
>>   }, **phase;
>>   struct i915_vma *vma, *next;
>>   struct drm_mm_node *node;
>> - int ret;
>> + int ret = 0;
>
> Please don't randomly initialise locals. It is meant to be initialised
> just prior to the unbind loop. It appears that my patches are
> out-of-order. :|
Oh, then I misread the intention of the code, sorry.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support

[ville . syrjala]

From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
location of CCS is provided by userspace as just another plane with its
own offset.

Add the required stuff to validate the user provided AUX plane metadata
and convert the user provided linear offset into something the hardware
can consume.

Due to hardware limitations we require that the main surface and
the AUX surface (CCS) be part of the same bo. The hardware also
makes life hard by not allowing you to provide separate x/y offsets
for the main and AUX surfaces (excpet with NV12), so finding suitable
offsets for both requires a bit of work. Assuming we still want keep
playing tricks with the offsets. I've just gone with a dumb "search
backward for suitable offsets" approach, which is far from optimal,
but it works.

Also not all planes will be capable of scanning out compressed surfaces,
and eg. 90/270 degree rotation is not supported in combination with
decompression either.

This patch may contain work from at least the following people:
* Vandana Kannan 
* Daniel Vetter 
* Ben Widawsky 

v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)

Cc: Paulo Zanoni 
Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  23 
 drivers/gpu/drm/i915/intel_display.c | 234 ---
 drivers/gpu/drm/i915/intel_pm.c  |  29 -
 drivers/gpu/drm/i915/intel_sprite.c  |   5 +
 4 files changed, 274 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa77afa..6849ba93f1d9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6209,6 +6209,28 @@ enum {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
 
+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A   0x701c4
+#define PLANE_AUX_OFFSET_2_A   0x702c4
+#define PLANE_AUX_OFFSET_1_B   0x711c4
+#define PLANE_AUX_OFFSET_2_B   0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
@@ -6433,6 +6455,7 @@ enum {
 # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
 
 #define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
 #define  DPA_MASK_VBLANK_SRD   (1 << 15)
 #define  FORCE_ARB_IDLE_PLANES (1 << 14)
 #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 38de9df0ec60..2236abebd8bc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer 
*fb, int plane)
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Yf_TILED:
/*
 * Bspec seems to suggest that the Yf tile width would
@@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct 

Re: [Intel-gfx] [PATCH] drm/i915: initialize ret in i915_gem_evict_something

[Chris Wilson]

On Thu, Jan 05, 2017 at 02:41:31PM +, Matthew Auld wrote:
> If we find a suitable victim node on our first pass, then ret
> will be uninitialized which could lead to some funny business later.
> 
> Fixes: 9332f3b1b99a ("drm/i915: Combine loops within 
> i915_gem_evict_something")
> Cc: Chris Wilson 
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 50129ec1caab..19716548c455 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -109,7 +109,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
>   }, **phase;
>   struct i915_vma *vma, *next;
>   struct drm_mm_node *node;
> - int ret;
> + int ret = 0;

Please don't randomly initialise locals. It is meant to be initialised
just prior to the unbind loop. It appears that my patches are
out-of-order. :|
-Chris

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

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add render decompression support

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 05:14:04PM -0200, Paulo Zanoni wrote:
> Em Qua, 2017-01-04 às 20:42 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä 
> > 
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display
> > engine
> > the location of the color control surfae (CCS) which describes
> > which parts of the main surface are compressed and which are not. The
> > location of CCS is provided by userspace as just another plane with
> > its
> > own offset.
> > 
> > Add the required stuff to validate the user provided AUX plane
> > metadata
> > and convert the user provided linear offset into something the
> > hardware
> > can consume.
> > 
> > Due to hardware limitations we require that the main surface and
> > the AUX surface (CCS) be part of the same bo. The hardware also
> > makes life hard by not allowing you to provide separate x/y offsets
> > for the main and AUX surfaces (excpet with NV12), so finding suitable
> > offsets for both requires a bit of work. Assuming we still want keep
> > playing tricks with the offsets. I've just gone with a dumb "search
> > backward for suitable offsets" approach, which is far from optimal,
> > but it works.
> > 
> > Also not all planes will be capable of scanning out compressed
> > surfaces,
> > and eg. 90/270 degree rotation is not supported in combination with
> > decompression either.
> > 
> > This patch may contain work from at least the following people:
> > * Vandana Kannan 
> > * Daniel Vetter 
> > * Ben Widawsky 
> 
> As I mentioned to Ben in the other email, there are some points of
> BSpec that say "if render decompression is enabled, to this", which we
> largely ignored so far. I hope they are all marked as workarounds. From
> a quick look, it looks like we need at least Display WAs #0390, #0531
> and #1125, and maybe some other non-display WAs (please take a look at
> the BSpec list). I'll assume they were not implemented yet since I
> don't see WA comments on the patches. I think we need them, otherwise
> we may introduce more SKL flickering problems.

I went through the list and those three do seem like the likely things
we want. I'll post a revised patch with those included.

> 
> Thanks,
> Paulo
> 
> > 
> > Cc: Vandana Kannan 
> > Cc: Daniel Vetter 
> > Cc: Ben Widawsky 
> > Cc: Jason Ekstrand 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  22 
> >  drivers/gpu/drm/i915/intel_display.c | 219
> > +--
> >  drivers/gpu/drm/i915/intel_pm.c  |   8 +-
> >  drivers/gpu/drm/i915/intel_sprite.c  |   5 +
> >  4 files changed, 240 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 00970aa77afa..05e18e742776 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6209,6 +6209,28 @@ enum {
> >     _ID(id, _PS_ECC_STAT_1A,
> > _PS_ECC_STAT_2A),   \
> >     _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> >  
> > +#define PLANE_AUX_DIST_1_A 0x701c0
> > +#define PLANE_AUX_DIST_2_A 0x702c0
> > +#define PLANE_AUX_DIST_1_B 0x711c0
> > +#define PLANE_AUX_DIST_2_B 0x712c0
> > +#define _PLANE_AUX_DIST_1(pipe) \
> > +   _PIPE(pipe, PLANE_AUX_DIST_1_A,
> > PLANE_AUX_DIST_1_B)
> > +#define _PLANE_AUX_DIST_2(pipe) \
> > +   _PIPE(pipe, PLANE_AUX_DIST_2_A,
> > PLANE_AUX_DIST_2_B)
> > +#define PLANE_AUX_DIST(pipe, plane) \
> > +   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
> > _PLANE_AUX_DIST_2(pipe))
> > +
> > +#define PLANE_AUX_OFFSET_1_A   0x701c4
> > +#define PLANE_AUX_OFFSET_2_A   0x702c4
> > +#define PLANE_AUX_OFFSET_1_B   0x711c4
> > +#define PLANE_AUX_OFFSET_2_B   0x712c4
> > +#define _PLANE_AUX_OFFSET_1(pipe)   \
> > +   _PIPE(pipe, PLANE_AUX_OFFSET_1_A,
> > PLANE_AUX_OFFSET_1_B)
> > +#define _PLANE_AUX_OFFSET_2(pipe)   \
> > +   _PIPE(pipe, PLANE_AUX_OFFSET_2_A,
> > PLANE_AUX_OFFSET_2_B)
> > +#define PLANE_AUX_OFFSET(pipe, plane)   \
> > +   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe),
> > _PLANE_AUX_OFFSET_2(pipe))
> > +
> >  /* legacy palette */
> >  #define _LGC_PALETTE_A   0x4a000
> >  #define _LGC_PALETTE_B   0x4a800
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 38de9df0ec60..b547332eeda1 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct
> > drm_framebuffer *fb, int plane)
> >     return 

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add render decompression support

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 08:25:23PM -0800, Ben Widawsky wrote:
> On 17-01-04 20:42:32, Ville Syrjälä wrote:
> >From: Ville Syrjälä 
> >
> >SKL+ display engine can scan out certain kinds of compressed surfaces
> >produced by the render engine. This involved telling the display engine
> >the location of the color control surfae (CCS) which describes
> >which parts of the main surface are compressed and which are not. The
> >location of CCS is provided by userspace as just another plane with its
> >own offset.
> >
> >Add the required stuff to validate the user provided AUX plane metadata
> >and convert the user provided linear offset into something the hardware
> >can consume.
> >
> >Due to hardware limitations we require that the main surface and
> >the AUX surface (CCS) be part of the same bo. The hardware also
> >makes life hard by not allowing you to provide separate x/y offsets
> >for the main and AUX surfaces (excpet with NV12), so finding suitable
> >offsets for both requires a bit of work. Assuming we still want keep
> >playing tricks with the offsets. I've just gone with a dumb "search
> >backward for suitable offsets" approach, which is far from optimal,
> >but it works.
> >
> >Also not all planes will be capable of scanning out compressed surfaces,
> >and eg. 90/270 degree rotation is not supported in combination with
> >decompression either.
> >
> >This patch may contain work from at least the following people:
> >* Vandana Kannan 
> >* Daniel Vetter 
> >* Ben Widawsky 
> >
> >Cc: Vandana Kannan 
> >Cc: Daniel Vetter 
> >Cc: Ben Widawsky 
> >Cc: Jason Ekstrand 
> >Signed-off-by: Ville Syrjälä 
> >---
> > drivers/gpu/drm/i915/i915_reg.h  |  22 
> > drivers/gpu/drm/i915/intel_display.c | 219 
> > +--
> > drivers/gpu/drm/i915/intel_pm.c  |   8 +-
> > drivers/gpu/drm/i915/intel_sprite.c  |   5 +
> > 4 files changed, 240 insertions(+), 14 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >b/drivers/gpu/drm/i915/i915_reg.h
> >index 00970aa77afa..05e18e742776 100644
> >--- a/drivers/gpu/drm/i915/i915_reg.h
> >+++ b/drivers/gpu/drm/i915/i915_reg.h
> >@@ -6209,6 +6209,28 @@ enum {
> > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
> > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> >
> >+#define PLANE_AUX_DIST_1_A  0x701c0
> >+#define PLANE_AUX_DIST_2_A  0x702c0
> >+#define PLANE_AUX_DIST_1_B  0x711c0
> >+#define PLANE_AUX_DIST_2_B  0x712c0
> >+#define _PLANE_AUX_DIST_1(pipe) \
> >+_PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
> >+#define _PLANE_AUX_DIST_2(pipe) \
> >+_PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
> >+#define PLANE_AUX_DIST(pipe, plane) \
> >+_MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
> >+
> >+#define PLANE_AUX_OFFSET_1_A0x701c4
> >+#define PLANE_AUX_OFFSET_2_A0x702c4
> >+#define PLANE_AUX_OFFSET_1_B0x711c4
> >+#define PLANE_AUX_OFFSET_2_B0x712c4
> >+#define _PLANE_AUX_OFFSET_1(pipe)   \
> >+_PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
> >+#define _PLANE_AUX_OFFSET_2(pipe)   \
> >+_PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
> >+#define PLANE_AUX_OFFSET(pipe, plane)   \
> >+_MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
> >+
> > /* legacy palette */
> > #define _LGC_PALETTE_A   0x4a000
> > #define _LGC_PALETTE_B   0x4a800
> >diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >b/drivers/gpu/drm/i915/intel_display.c
> >index 38de9df0ec60..b547332eeda1 100644
> >--- a/drivers/gpu/drm/i915/intel_display.c
> >+++ b/drivers/gpu/drm/i915/intel_display.c
> >@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer 
> >*fb, int plane)
> > return 128;
> > else
> > return 512;
> >+case I915_FORMAT_MOD_Y_TILED_CCS:
> >+if (plane == 1)
> >+return 64;
> >+/* fall through */
> > case I915_FORMAT_MOD_Y_TILED:
> > if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
> > return 128;
> > else
> > return 512;
> >+case I915_FORMAT_MOD_Yf_TILED_CCS:
> >+if (plane == 1)
> >+return 64;
> >+/* fall through */
> > case I915_FORMAT_MOD_Yf_TILED:
> > /*
> >  * Bspec seems to suggest that the Yf tile width would
> >@@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct 
> >drm_framebuffer *fb,
> > struct drm_i915_private *dev_priv = to_i915(fb->dev);
> 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

[Lyude Paul]

On Thu, 2017-01-05 at 09:52 +0100, Daniel Vetter wrote:
> On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
> > No matter what we do here, the question remains what to do with
> > Chamelium. Changing the color range is really a workaround for
> > Chamelium, not a fix. Using CEA range is perfectly fine per DP
> > spec.
> 
Of course, I had just figured this was actually a bug, but I guess not
:). I'll just make sure RGB Broadcast is set in the igt tests then

> Can we just set a non-CEA mode/edid for chamelium, problem solved? We
> want
> to do that anyway for HDMI, where you really have to do the limited
> range
> dance to make stuff display correctly.
> -Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: initialize ret in i915_gem_evict_something

[Matthew Auld]

If we find a suitable victim node on our first pass, then ret
will be uninitialized which could lead to some funny business later.

Fixes: 9332f3b1b99a ("drm/i915: Combine loops within i915_gem_evict_something")
Cc: Chris Wilson 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 50129ec1caab..19716548c455 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -109,7 +109,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
}, **phase;
struct i915_vma *vma, *next;
struct drm_mm_node *node;
-   int ret;
+   int ret = 0;
 
lockdep_assert_held(>i915->drm.struct_mutex);
trace_i915_gem_evict(vm, min_size, alignment, flags);
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

[Michal Wajdeczko]

On Wed, Jan 04, 2017 at 06:55:54AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
> 
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: rebased on top of drm-intel-nightly.
> v4: changed wait_for_automic to wait_for
> v5: rebased.
> v7: rebased.
> v8: rebased.
> v9: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
> and place the prototype in intel_guc.h,correct the comments.
> v10: rebased.
> v11: rebased.
> v12: rebased on top of drm-tip
> v13: rebased. Moved intel_guc_auth_huc from i915_guc_submission.c
> to intel_uc.c.Update dev to dev_priv in intel_guc_auth_huc().
> Renamed HOST2GUC_ACTION_AUTHENTICATE_HUC TO INTEL_GUC_ACTION_
> AUTHENTICATE_HUC
> v14: rebased.
> v15: rebased. Add newline on DRM_ERRORs that already dont have one.
> v16: rebased. Replace wait_for with intel_wait_for_register() since
> the latter employs sleep optimisations for quick responses- as pointed
> out by Chris Wilson.
> 
> Cc: Chris Wilson 
> Cc: Arkadiusz Hiler 
> Cc: Michal Wajdeczko 

Typo in my email ;(

> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> ---
>  drivers/gpu/drm/i915/intel_guc_fwif.h   |  1 +
>  drivers/gpu/drm/i915/intel_guc_loader.c |  2 +
>  drivers/gpu/drm/i915/intel_uc.c | 70 
> -
>  drivers/gpu/drm/i915/intel_uc.h |  1 +
>  4 files changed, 72 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index ed1ab40..ce4e05e 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -506,6 +506,7 @@ enum intel_guc_action {
>   INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
>   INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
>   INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x0E000,
> + INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,

Can we keep actions in order of their code values?


>   INTEL_GUC_ACTION_LIMIT
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index ed57ab3..0508054 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -529,6 +529,8 @@ int intel_guc_setup(struct drm_i915_private *dev_priv)
>   intel_uc_fw_status_repr(guc_fw->fetch_status),
>   intel_uc_fw_status_repr(guc_fw->load_status));
>  
> + intel_guc_auth_huc(dev_priv);
> +
>   if (i915.enable_guc_submission) {
>   if (i915.guc_log_level >= 0)
>   gen9_enable_guc_interrupts(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
> index c6be352..d1a4d79 100644
> --- a/drivers/gpu/drm/i915/intel_uc.c
> +++ b/drivers/gpu/drm/i915/intel_uc.c
> @@ -46,7 +46,7 @@ static bool intel_guc_recv(struct intel_guc *guc, u32 
> *status)
>  int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
>  {
>   struct drm_i915_private *dev_priv = guc_to_i915(guc);
> - u32 status;
> + u32 status = 0;
>   int i;
>   int ret;
>  
> @@ -71,7 +71,11 @@ int intel_guc_send(struct intel_guc *guc, const u32 
> *action, u32 len)
>* up to that length of time, then switch to a slower sleep-wait loop.
>* No inte_guc_send command should ever take longer than 10ms.
>*/
> - ret = wait_for_us(intel_guc_recv(guc, ), 10);
> + ret = intel_wait_for_register(dev_priv,
> + HUC_STATUS2,
> + HUC_FW_VERIFIED,
> + HUC_FW_VERIFIED,
> + 50);
>   if (ret)
>   ret = wait_for(intel_guc_recv(guc, ), 10);
>   if (status != INTEL_GUC_STATUS_SUCCESS) {
> @@ -140,3 +144,65 @@ int intel_guc_log_control(struct intel_guc *guc, u32 
> control_val)
>  
>   return intel_guc_send(guc, action, ARRAY_SIZE(action));
>  }
> +
> +/**
> + * intel_guc_auth_huc() - authenticate ucode
> + * @dev_priv: the drm_i915_device
> + *
> + * Triggers a HuC fw authentication request to the GuC via intel_guc_action_
> + * authenticate_huc interface.
> + * interface.
> + */
> +void intel_guc_auth_huc(struct drm_i915_private *dev_priv)
> +{
> + struct intel_guc *guc = _priv->guc;
> + struct intel_huc *huc = _priv->huc;
> + struct i915_vma *vma;
> + int ret;
> + u32 data[2];
> +
> + /* Bypass the case where there is no HuC firmware */
> + if (huc->fw.fetch_status == INTEL_UC_FIRMWARE_NONE ||
> + huc->fw.load_status == INTEL_UC_FIRMWARE_NONE)

To 

Re: [Intel-gfx] [PATCH v6] drm: add fourcc codes for 16bit R and RG

[Christian König]

Am 05.01.2017 um 12:37 schrieb Ville Syrjälä:

On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:

From: Rainer Hochecker 

This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.

Signed-off-by: Rainer Hochecker 

Reviewed-by: Ville Syrjälä 


Good to see some work landing on that part, patch is Acked-by: Christian 
König .





---
  include/uapi/drm/drm_fourcc.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..d230e58 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
  /* 8 bpp Red */
  #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
  
+/* 16 bpp Red */

+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R 
little endian */
+
  /* 16 bpp RG */
  #define DRM_FORMAT_RG88   fourcc_code('R', 'G', '8', '8') /* 
[15:0] R:G 8:8 little endian */
  #define DRM_FORMAT_GR88   fourcc_code('G', 'R', '8', '8') /* 
[15:0] G:R 8:8 little endian */
  
+/* 32 bpp RG */

+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 little endian */
+
  /* 8 bpp RGB */
  #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
3:3:2 */
  #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
2:3:3 */
--
2.9.3



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

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

[Arkadiusz Hiler]

On Wed, Jan 04, 2017 at 06:55:48AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> Rename some of the GuC fw loading code to make them more general. We
> will utilise them for HuC loading as well.
>  s/intel_guc_fw/intel_uc_fw/g
>  s/GUC_FIRMWARE/UC_FIRMWARE/g
> 
> Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
> such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
> same purpose.
> 
> v2: rebased on top of nightly.
> reapplied the search/replace as upstream code as changed.
> v3: rebased again on drm-nightly.
> v4: removed G from messages in shared fw fetch function.
> v5: rebased.
> v7: rebased.
> v8: rebased.
> v9: rebased.
> v10: rebased.
> v11: rebased.
> v12: rebased on top of drm-tip
> v13: rebased.Updated dev to dev_priv in intel_guc_setup(), guc_fw_getch()
> and intel_guc_init().
> v14: rebased. Remove uint32_t fw_type to patch 2. Add INTEL_ prefix for
> fields in enum intel_uc_fw_status. Remove uc_dev field since its never
> used.Rename uc_fw to just fw and guc_fw to fw to avoid redundency.
> v15: rebased. Remove sections of code that were commented and no longer
> required.
> v16: rebased. Remove uc_fw_ prefix from path and obj fields
> in intel_uc_fw struct as suggested by Michal.
> 
> Cc: Michal Wajdeczko 
> Cc: Arkadiusz Hiler 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 

Reviewed-by: Arkadiusz Hiler 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
>  drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
>  drivers/gpu/drm/i915/intel_guc_loader.c| 156 
> ++---
>  drivers/gpu/drm/i915/intel_uc.h|  36 +++
>  4 files changed, 104 insertions(+), 104 deletions(-)

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

Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

[Arkadiusz Hiler]

On Wed, Jan 04, 2017 at 06:55:54AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
> 
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: rebased on top of drm-intel-nightly.
> v4: changed wait_for_automic to wait_for
> v5: rebased.
> v7: rebased.
> v8: rebased.
> v9: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
> and place the prototype in intel_guc.h,correct the comments.
> v10: rebased.
> v11: rebased.
> v12: rebased on top of drm-tip
> v13: rebased. Moved intel_guc_auth_huc from i915_guc_submission.c
> to intel_uc.c.Update dev to dev_priv in intel_guc_auth_huc().
> Renamed HOST2GUC_ACTION_AUTHENTICATE_HUC TO INTEL_GUC_ACTION_
> AUTHENTICATE_HUC
> v14: rebased.
> v15: rebased. Add newline on DRM_ERRORs that already dont have one.
> v16: rebased. Replace wait_for with intel_wait_for_register() since
> the latter employs sleep optimisations for quick responses- as pointed
> out by Chris Wilson.
> 
> Cc: Chris Wilson 
> Cc: Arkadiusz Hiler 
> Cc: Michal Wajdeczko 

Typo in Michal's address.

> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 

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

Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

[Arkadiusz Hiler]

On Wed, Jan 04, 2017 at 06:55:54AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
> 
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: rebased on top of drm-intel-nightly.
> v4: changed wait_for_automic to wait_for
> v5: rebased.
> v7: rebased.
> v8: rebased.
> v9: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
> and place the prototype in intel_guc.h,correct the comments.
> v10: rebased.
> v11: rebased.
> v12: rebased on top of drm-tip
> v13: rebased. Moved intel_guc_auth_huc from i915_guc_submission.c
> to intel_uc.c.Update dev to dev_priv in intel_guc_auth_huc().
> Renamed HOST2GUC_ACTION_AUTHENTICATE_HUC TO INTEL_GUC_ACTION_
> AUTHENTICATE_HUC
> v14: rebased.
> v15: rebased. Add newline on DRM_ERRORs that already dont have one.
> v16: rebased. Replace wait_for with intel_wait_for_register() since
> the latter employs sleep optimisations for quick responses- as pointed
> out by Chris Wilson.
> 
> Cc: Chris Wilson 
> Cc: Arkadiusz Hiler 
> Cc: Michal Wajdeczko 
> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> ---
>  drivers/gpu/drm/i915/intel_guc_fwif.h   |  1 +
>  drivers/gpu/drm/i915/intel_guc_loader.c |  2 +
>  drivers/gpu/drm/i915/intel_uc.c | 70 
> -
>  drivers/gpu/drm/i915/intel_uc.h |  1 +
>  4 files changed, 72 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index ed1ab40..ce4e05e 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -506,6 +506,7 @@ enum intel_guc_action {
>   INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
>   INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
>   INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x0E000,
> + INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
>   INTEL_GUC_ACTION_LIMIT
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index ed57ab3..0508054 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -529,6 +529,8 @@ int intel_guc_setup(struct drm_i915_private *dev_priv)
>   intel_uc_fw_status_repr(guc_fw->fetch_status),
>   intel_uc_fw_status_repr(guc_fw->load_status));
>  
> + intel_guc_auth_huc(dev_priv);
> +
>   if (i915.enable_guc_submission) {
>   if (i915.guc_log_level >= 0)
>   gen9_enable_guc_interrupts(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
> index c6be352..d1a4d79 100644
> --- a/drivers/gpu/drm/i915/intel_uc.c
> +++ b/drivers/gpu/drm/i915/intel_uc.c
> @@ -46,7 +46,7 @@ static bool intel_guc_recv(struct intel_guc *guc, u32 
> *status)
>  int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
>  {
>   struct drm_i915_private *dev_priv = guc_to_i915(guc);
> - u32 status;
> + u32 status = 0;
>   int i;
>   int ret;
>  
> @@ -71,7 +71,11 @@ int intel_guc_send(struct intel_guc *guc, const u32 
> *action, u32 len)
>* up to that length of time, then switch to a slower sleep-wait loop.
>* No inte_guc_send command should ever take longer than 10ms.
>*/
> - ret = wait_for_us(intel_guc_recv(guc, ), 10);
> + ret = intel_wait_for_register(dev_priv,
> + HUC_STATUS2,
> + HUC_FW_VERIFIED,
> + HUC_FW_VERIFIED,
> + 50);

Why do all suddenly intel_guc_send() starts caring about HUC?

I think you've misplaced the check, missed that you were in the wrong
place and "fixed" status not being set properly by initializing it with
the 0.

>   if (ret)
>   ret = wait_for(intel_guc_recv(guc, ), 10);
>   if (status != INTEL_GUC_STATUS_SUCCESS) {
> @@ -140,3 +144,65 @@ int intel_guc_log_control(struct intel_guc *guc, u32 
> control_val)
>  
>   return intel_guc_send(guc, action, ARRAY_SIZE(action));
>  }
> +
> +/**
> + * intel_guc_auth_huc() - authenticate ucode
> + * @dev_priv: the drm_i915_device
> + *
> + * Triggers a HuC fw authentication request to the GuC via intel_guc_action_
> + * authenticate_huc interface.
> + * interface.
> + */
> +void intel_guc_auth_huc(struct drm_i915_private *dev_priv)
> +{
> + struct intel_guc *guc = _priv->guc;
> + struct intel_huc *huc = _priv->huc;
> + struct i915_vma *vma;
> + int ret;
> + u32 data[2];
> +
> + /* Bypass the case where there is no HuC 

Re: [Intel-gfx] [PATCH v6] drm: add fourcc codes for 16bit R and RG

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
> From: Rainer Hochecker 
> 
> This adds fourcc codes for 16bit planes required for DRM buffer
> export to mesa.
> 
> Signed-off-by: Rainer Hochecker 

Reviewed-by: Ville Syrjälä 

> ---
>  include/uapi/drm/drm_fourcc.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index a5890bf..d230e58 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -41,10 +41,17 @@ extern "C" {
>  /* 8 bpp Red */
>  #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /* 
> [7:0] R */
>  
> +/* 16 bpp Red */
> +#define DRM_FORMAT_R16   fourcc_code('R', '1', '6', ' ') /* 
> [15:0] R little endian */
> +
>  /* 16 bpp RG */
>  #define DRM_FORMAT_RG88  fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 little endian */
>  #define DRM_FORMAT_GR88  fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 little endian */
>  
> +/* 32 bpp RG */
> +#define DRM_FORMAT_RG1616fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
> 16:16 little endian */
> +#define DRM_FORMAT_GR1616fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
> 16:16 little endian */
> +
>  /* 8 bpp RGB */
>  #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
> 3:3:2 */
>  #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
> 2:3:3 */
> -- 
> 2.9.3

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

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

[Jani Nikula]

Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,

Here's a bunch of drm/i915 fixes for v4.10-rc3. It includes GVT-g fixes,
which apparently have a conflict with Alex's (Cc'd) upcoming vfio
changes [1]. So heads up.

My new year's resolution is to start using signed tags for pulls. If
that feels like a déjà vu, it's ((new year's) resolution), not (new
(year's resolution)).

BR,
Jani.

[1] http://lkml.kernel.org/r/20170103104239.67dd9...@canb.auug.org.au


The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-01-05

for you to fetch changes up to 2471eb5fb6e1433e28426ece235e3730348019ec:

  drm/i915: Prevent timeline updates whilst performing reset (2017-01-03 
11:41:57 +0200)


Chris Wilson (3):
  drm/i915: Don't clflush before release phys object
  drm/i915: Silence allocation failure during sg_trim()
  drm/i915: Prevent timeline updates whilst performing reset

Jani Nikula (1):
  Merge tag 'gvt-fixes-2016-12-26' of https://github.com/01org/gvt-linux 
into drm-intel-fixes

Jike Song (4):
  drm/i915/gvt/kvmgt: dereference the pointer within lock
  drm/i915/gvt/kvmgt: check returned slot for gfn
  drm/i915/gvt/kvmgt: prevent double-release of vgpu
  drm/i915/gvt/kvmgt: trival: code cleanup

Min He (2):
  drm/i915/gvt: fix an error in opregion handling
  drm/i915/gvt: fix an issue in emulating cfg space PCI_COMMAND

Pei Zhang (1):
  drm/i915/gvt: fix typo in cfg_space range check

Ping Gao (1):
  drm/i915/gvt: reset the GGTT entry when vGPU created

Ville Syrjälä (5):
  drm/i915: Force VDD off on the new power seqeuencer before starting to 
use it
  drm/i915: Move the min_pixclk[] handling to the end of readout
  drm/i915: Initialize overlay->last_flip properly
  drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff
  drm/i915: Fix oops in overlay due to frontbuffer tracking

 drivers/gpu/drm/i915/gvt/cfg_space.c|  4 +--
 drivers/gpu/drm/i915/gvt/gtt.c  | 55 +
 drivers/gpu/drm/i915/gvt/gtt.h  |  4 +++
 drivers/gpu/drm/i915/gvt/gvt.h  |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c| 46 +--
 drivers/gpu/drm/i915/gvt/opregion.c |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 22 +
 drivers/gpu/drm/i915/i915_gem_request.h | 19 
 drivers/gpu/drm/i915/intel_display.c| 32 +--
 drivers/gpu/drm/i915/intel_dp.c | 41 +++-
 drivers/gpu/drm/i915/intel_overlay.c|  9 --
 11 files changed, 190 insertions(+), 45 deletions(-)

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

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi Jani,

On Thu, 05 Jan 2017 12:24:13 +0200 Jani Nikula  
wrote:
>
> Daniel reverted it in drm-misc.

OK, thanks.

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

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Jani Nikula]

On Thu, 05 Jan 2017, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/usb/Kconfig:39:error: recursive dependency detected!
> drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
> drivers/input/mouse/Kconfig:187:symbol MOUSE_APPLETOUCH depends on 
> INPUT
> drivers/input/Kconfig:8:symbol INPUT is selected by VT
> drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
> drivers/video/fbdev/Kconfig:678:symbol FB_STI depends on FB
> drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER depends on 
> DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:66: symbol DRM_KMS_HELPER is selected by 
> DRM_NOUVEAU
> drivers/gpu/drm/nouveau/Kconfig:1:  symbol DRM_NOUVEAU depends on 
> LEDS_CLASS
> drivers/leds/Kconfig:16:symbol LEDS_CLASS is selected by 
> OMAP_DEBUG_LEDS
> arch/arm/plat-omap/Kconfig:19:  symbol OMAP_DEBUG_LEDS depends on NEW_LEDS
> drivers/leds/Kconfig:8: symbol NEW_LEDS is selected by ATH9K_HTC
> drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on 
> USB
>
> Caused by commit
>
>   a5ad0fd8524e ("drm: nouveau: fix build when LEDS_CLASS=m")
>
> I have reverted that commit for today (just because I had to to make
> sure that was the problem).

Daniel reverted it in drm-misc.

BR,
Jani.

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

[Daniel Stone]

Hi,

On 5 January 2017 at 08:52, Daniel Vetter  wrote:
> On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
>> No matter what we do here, the question remains what to do with
>> Chamelium. Changing the color range is really a workaround for
>> Chamelium, not a fix. Using CEA range is perfectly fine per DP spec.
>
> Can we just set a non-CEA mode/edid for chamelium, problem solved? We want
> to do that anyway for HDMI, where you really have to do the limited range
> dance to make stuff display correctly.

Or, if you set the 'Broadcast RGB' connector property to 'Full',
you'll never hit the color_range_auto branch in the first place ...

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

Re: [Intel-gfx] [PATCH] drm/i915: Header cleanup for intel_display

[Chris Wilson]

On Thu, Jan 05, 2017 at 09:12:17AM +0200, Mika Kahola wrote:
> Remove reference to drm/drm_edid.h and drm/drmP.h as these are no longer
> required.
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ab72858..c4e1bfa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -31,8 +31,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include "intel_drv.h"
>  #include "intel_frontbuffer.h"
>  #include 

But you could bring order to this mess whilst you are here...

+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
-#include 
-#include "intel_drv.h"
-#include "intel_frontbuffer.h"
-#include 
-#include "i915_drv.h"
-#include "intel_dsi.h"
-#include "i915_trace.h"
+
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
+
+#include "i915_drv.h"
+#include "i915_trace.h"
+#include "intel_drv.h"
+#include "intel_dsi.h"
+#include "intel_frontbuffer.h"

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

Re: [Intel-gfx] [PATCH igt 4/6] kms_frontbuffer_tracking: refactor sink CRC reliability handling

[Petri Latvala]

After this patch we got some failures in CI for anything not connected
to eDP. sink_crc.supported now defaults to true, so perhaps...


diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index b91f08b..b84721f 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -1399,6 +1399,7 @@ static void setup_sink_crc(void)
c = get_connector(prim_mode_params.connector_id);
if (c->connector_type != DRM_MODE_CONNECTOR_eDP) {
igt_info("Sink CRC not supported: primary screen is not eDP\n");
+   sink_crc.supported = false;
return;
}


Paulo?


--
Petri Latvala



On Thu, Dec 22, 2016 at 06:42:06PM -0200, Paulo Zanoni wrote:
> What I'm currently seeing is that sometimes the first check during
> setup_sink_crc() returns valid sink CRC, but then the subsequent
> checks return ETIMEDOUT. In these cases, we keep getting flooded by
> messages saying that our sink CRC is unreliable and that the results
> differ. This is annoying for the FBC tests where sink CRC is not
> mandatory.
> 
> Since this case shows it's useless to try to check for sink CRC
> reliability before the actual tests, refactor the code in a way that
> if at any point we detect that sink CRC is unreliable we'll mark it as
> such and stop flooding the logs. For the tests where it's mandatory
> we'll still keep the same SKIP behavior.
> 
> This refactor also allows us to just call get_sink_crc() in the
> setup_sink_crc() function instead of having to reimplement the same
> logic.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  tests/kms_frontbuffer_tracking.c | 39 ++-
>  1 file changed, 18 insertions(+), 21 deletions(-)
> 
> diff --git a/tests/kms_frontbuffer_tracking.c 
> b/tests/kms_frontbuffer_tracking.c
> index 4a46942..8aa6362 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -203,9 +203,11 @@ struct both_crcs *wanted_crc;
>  struct {
>   int fd;
>   bool supported;
> + bool reliable;
>  } sink_crc = {
>   .fd = -1,
> - .supported = false,
> + .supported = true,
> + .reliable = true,
>  };
>  
>  /* The goal of this structure is to easily allow us to deal with cases where 
> we
> @@ -943,11 +945,17 @@ static void get_sink_crc(sink_crc_t *crc, bool 
> mandatory)
>   rc = read(sink_crc.fd, crc->data, SINK_CRC_SIZE);
>   errno_ = errno;
>  
> - if (rc == -1 && errno_ == ETIMEDOUT) {
> + if (rc == -1 && errno_ == ENOTTY) {
> + igt_info("Sink CRC not supported: panel doesn't support it\n");
> + sink_crc.supported = false;
> + } else if (rc == -1 && errno_ == ETIMEDOUT) {
> + if (sink_crc.reliable) {
> + igt_info("Sink CRC is unreliable on this machine.\n");
> + sink_crc.reliable = false;
> + }
> +
>   if (mandatory)
> - igt_skip("Sink CRC is unreliable on this machine. Try 
> running this test again individually\n");
> - else
> - igt_info("Sink CRC is unreliable on this machine. Try 
> running this test again individually\n");
> + igt_skip("Sink CRC is unreliable on this machine.\n");
>   } else {
>   igt_assert(rc == SINK_CRC_SIZE);
>   }
> @@ -1396,9 +1404,7 @@ static void teardown_modeset(void)
>  
>  static void setup_sink_crc(void)
>  {
> - ssize_t rc;
>   sink_crc_t crc;
> - int errno_;
>   drmModeConnectorPtr c;
>  
>   c = get_connector(prim_mode_params.connector_id);
> @@ -1418,17 +1424,8 @@ static void setup_sink_crc(void)
>   sink_crc.fd = igt_debugfs_open("i915_sink_crc_eDP1", O_RDONLY);
>   igt_assert_lte(0, sink_crc.fd);
>  
> - rc = read(sink_crc.fd, crc.data, SINK_CRC_SIZE);
> - errno_ = errno;
> - if (rc == -1 && errno_ == ENOTTY)
> - igt_info("Sink CRC not supported: panel doesn't support it\n");
> - if (rc == -1 && errno_ == ETIMEDOUT)
> - igt_info("Sink CRC not reliable on this panel: skipping it\n");
> - else if (rc == SINK_CRC_SIZE)
> - sink_crc.supported = true;
> - else
> - igt_info("Unexpected sink CRC error, rc=:%zd errno:%d %s\n",
> -  rc, errno_, strerror(errno_));
> + /* Do a first read to try to detect if it's supported. */
> + get_sink_crc(, false);
>  }
>  
>  static void setup_crcs(void)
> @@ -1677,9 +1674,9 @@ static int adjust_assertion_flags(const struct 
> test_mode *t, int flags)
>   igt_assert_crc_equal(_.pipe, _crc->pipe);\
>   if (mandatory_sink_crc) \
>   assert_sink_crc_equal(_.sink, _crc->sink);   \
> - else\
> - if (!sink_crc_equal(_.sink, _crc->sink)) \
> - 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

[Peter Frühberger]

Hi,

On Thu, Jan 5, 2017 at 9:52 AM, Daniel Vetter  wrote:

> On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
> > No matter what we do here, the question remains what to do with
> > Chamelium. Changing the color range is really a workaround for
> > Chamelium, not a fix. Using CEA range is perfectly fine per DP spec.
>
> Can we just set a non-CEA mode/edid for chamelium, problem solved? We want
> to do that anyway for HDMI, where you really have to do the limited range
> dance to make stuff display correctly.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

I shortly want to emphasize on this:
https://lists.freedesktop.org/archives/intel-gfx/2015-November/081516.html

No matter what you sync with the Port - userspace must have a chance to
know what happens with its DATA. It is a huge problem when the driver
clamps by itself assuming everything it gets would be full range. Or when
the Output device clamps and does not scale, then you loose, e.g. 0 ..16
and 235.. 255. On the other hand such scenarios make userspace scale data -
especially video data - twice. One time to full range and later down in the
driver when using CEA mode, e.g. Limited 16:235.

Please keep that in mind. It's problematic already nowadays when a 1:1
output without color altering is high importance.

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

Re: [Intel-gfx] [PATCH igt] lib: Always unbind the fbcon around igt

[Daniel Vetter]

On Wed, Jan 04, 2017 at 11:44:29AM +, Chris Wilson wrote:
> The fbcon imposes unpredictable latencies on tests - each drmIoctl has
> been observed to trigger two 650us calls to console_unlock() as it
> flushes printk buffer for the DRM_DEBUG around the ioctl. This makes
> tests such as gem_wait fail as they expect the ioctl to be spent on the
> operation under test not clogged up by the console.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=99130
> Signed-off-by: Chris Wilson 

Makes sense. Reviewed-by: Daniel Vetter 

> ---
>  lib/igt_core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index a18a728c..403b9423 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -67,6 +67,7 @@
>  
>  #include "igt_core.h"
>  #include "igt_aux.h"
> +#include "igt_sysfs.h"
>  
>  #ifdef HAVE_LIBGEN_H
>  #include/* for basename() on Solaris */
> @@ -512,6 +513,7 @@ static void common_exit_handler(int sig)
>  {
>   if (!igt_only_list_subtests()) {
>   low_mem_killer_disable(false);
> + kick_fbcon(true);
>   }
>  
>   /* When not killed by a signal check that igt_exit() has been properly
> @@ -731,6 +733,7 @@ out:
>   exit(ret == -1 ? 0 : IGT_EXIT_INVALID);
>  
>   if (!list_subtests) {
> + kick_fbcon(false);
>   kmsg(KERN_INFO "[IGT] %s: executing\n", command_str);
>   print_version();
>  
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

[Daniel Vetter]

On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
> No matter what we do here, the question remains what to do with
> Chamelium. Changing the color range is really a workaround for
> Chamelium, not a fix. Using CEA range is perfectly fine per DP spec.

Can we just set a non-CEA mode/edid for chamelium, problem solved? We want
to do that anyway for HDMI, where you really have to do the limited range
dance to make stuff display correctly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/9] drm: Add mode_config .get_format_info() hook

[Daniel Vetter]

On Wed, Jan 04, 2017 at 07:15:34PM -0800, Ben Widawsky wrote:
> On 17-01-04 20:42:24, Ville Syrjälä wrote:
> > From: Ville Syrjälä 
> > 
> > Allow drivers to return a custom drm_format_info structure for special
> > fb layouts. We'll use this for the compression control surface in i915.
> > 
> > v2: Fix drm_get_format_info() kernel doc (Laurent)
> >Don't pass 'dev' to the new hook (Laurent)
> > 
> > Cc: Laurent Pinchart 
> > Cc: Ben Widawsky 
> > Signed-off-by: Ville Syrjälä 

Ok if I still merge this throught drm-misc? Looks like the next few
patches don't need this yet, and the CCS stuff probably needs a bit more
wrangling for all the pieces to be fully ready.

> > +*
> > +* RETURNS:
> > +*
> > +* The format information specific to the given fb metadata, or
> > +* NULL if none is found.
> > +*/
> > +   const struct drm_format_info *(*get_format_info)(const struct 
> > drm_mode_fb_cmd2 *mode_cmd);
> > +
> > +   /**
> >  * @output_poll_changed:
> >  *
> >  * Callback used by helpers to inform the driver of output configuration
> 
> Looks like msm and omap could use this too, and then if you allowed mode_cmd
> to be NULL, you could potentially deprecate drm_format_info. Just a thought.

Hm, what do you mean here with deprecating drm_format_info and a NULL
mode_cmd? I don't follow at all ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

[Jani Nikula]

On Thu, 05 Jan 2017, Lyude  wrote:
> Until now, it seems we've been erroneously enabling limited color ranges
> for the vast majority of DisplayPort monitors. I noticed this after
> writing a frame dump comparison test for the Chamelium and noticing that
> every i915 device I had was failing, while amdgpu machines were fine:
>
> https://people.freedesktop.org/~lyudess/archive/01-03-2017/
>
> It looks like this is because the DisplayPort spec tells us to use
> limited color ranges whenever we detect a CEA mode in use. However, from
> the looks of it there's another rather confusing part of the spec that
> got missed: source devices are allowed to use the full range of values
> for pixels -even- if the sink device declares that it's using a CEA
> mode. It's up to the sink device to limit the pixel range to the CEA
> ranges if it needs.

DP 1.2a 5.1.1.1 Video Colorimetry

* When a Source device is transmitting an RGB stream with a video timing
  format called out in CEA-861C Section 5 (except 640 x 480p) as using
  CEA range RGB, it should use CEA range RGB.

* When a Source device is transmitting a RGB stream with a video timing
  format called out in CEA-861C Section 5 as using CEA range RGB, it
  must use the CEA range RGB.

* However, a Source device may transmit all code values from zero to the
  maximum even when it declares the CEA range in the Main Stream
  Attributes. It is the responsibility of the Sink device to limit the
  pixel value range as needed.

The spec has a conflict about SHOULD and MUST. Nevertheless, using CEA
range is at least recommended. When using CEA range, the CEA range MUST
be declared in Main Stream Attributes for CEA modes, but full range of
values MAY be transmitted.

DP 1.4 5.1.1.1 Video Colorimetry

* When a Source device is transmitting an RGB stream with a video timing
  format called out in CEA-861-F, Section 5 (except 640x480p) as using
  CEA range RGB, it should use CEA range RGB.

* When a Source device is transmitting an RGB stream with a video timing
  format called out in CEA-861-F, the device may provide RGB in the VESA
  range.

* The Sink device shall have the responsibility of limiting the pixel
  value range, as needed.

The conflict has been resolved, using CEA range is now
recommended. However, the source MAY also use VESA range. I take it that
means the source could also declare VESA range in Main Stream
Attributes.

---

I am not sure if we'd be able to declare CEA range in Main Stream
Attributes but transmit VESA range anyway. Feels kind of silly anyway,
and IIUC would only be according to DP 1.2a. It boils down to CEA range
vs. VESA range.

> I'm really surprised that this bug would have been around as long as it looks
> like it has been without anyone noticing it, so I figured I'd just send a 
> patch
> to the mailing list so you guys can point out whether or not this is really 
> the
> correct thing to do.

We've had the same discussion several times over with HDMI for sure, but
I think also with DP. The conclusion has always been that no matter
which range we choose as the default, it's going to be wrong for some
displays. And when it turns into a contest of who complains the loudest,
it's a no brainer to go by spec. It's never been less than recommended
to go with CEA range for CEA modes, regardless of the conflict in DP
1.2a.

No matter what we do here, the question remains what to do with
Chamelium. Changing the color range is really a workaround for
Chamelium, not a fix. Using CEA range is perfectly fine per DP spec.


BR,
Jani.

>
>  drivers/gpu/drm/i915/intel_dp.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index d9bc19b..6642abd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1649,12 +1649,15 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>  found:
>   if (intel_dp->color_range_auto) {
>   /*
> +  * We are required to use the limited CEA RGB range when a CEA
> +  * mode is declared in the EDID. However, limiting the pixel
> +  * value range is up to the sink, not the source. So, just
> +  * don't enable limited color ranges.
>* See:
>* CEA-861-E - 5.1 Default Encoding Parameters
>* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
>*/
> - pipe_config->limited_color_range =
> - bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
> + pipe_config->limited_color_range = false;
>   } else {
>   pipe_config->limited_color_range =
>   intel_dp->limited_color_range;

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

[Daniel Vetter]

On Thu, Jan 05, 2017 at 03:54:54AM +, Pandiyan, Dhinakaran wrote:
> On Wed, 2017-01-04 at 19:20 +, Pandiyan, Dhinakaran wrote:
> > On Wed, 2017-01-04 at 10:33 +0100, Daniel Vetter wrote:
> > > On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote:
> > > > Link bandwidth is shared between multiple display streams in DP MST
> > > > configurations. The DP MST topology manager structure maintains the 
> > > > shared
> > > > link bandwidth for a primary link directly connected to the GPU. For 
> > > > atomic
> > > > modesetting drivers, checking if there is sufficient link bandwidth for 
> > > > a
> > > > mode needs to be done during the atomic_check phase to avoid failed
> > > > modesets. Let's encsapsulate the available link bw information in a 
> > > > state
> > > > structure so that bw can be allocated and released atomically for each 
> > > > of
> > > > the ports sharing the primary link.
> > > > 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > 
> > > Overall issue with the patch is that dp helpers now have 2 places where
> > > available_slots is stored: One for atomic drivers in ->state, and the
> > > legacy one. I think it'd be good to rework the legacy codepaths (i.e.
> > > drm_dp_find_vcpi_slots) to use mgr->state->avail_slots, and remove
> > > mgr->avail_slots entirely.
> > 
> > PATCH 2/6 does that. mgr->avail_slots is not updated in the legacy code
> > path, so the check turns out to be against mgr->total_slots. So, I did
> > just that, albeit explicitly. 

Ah right, I missed that.

> > > > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > > > index fd2d971..7ac5ed6 100644
> > > > --- a/include/drm/drm_atomic.h
> > > > +++ b/include/drm/drm_atomic.h
> > > > @@ -153,6 +153,11 @@ struct __drm_connnectors_state {
> > > > struct drm_connector_state *state;
> > > >  };
> > > >  
> > > > +struct __drm_dp_mst_topology_state {
> > > > +   struct drm_dp_mst_topology_mgr *ptr;
> > > > +   struct drm_dp_mst_topology_state *state;
> > > 
> > > One way to fix that control inversion I mentioned above is to use void*
> > > pionters here, and then have callbacks for atomic_destroy and swap_state
> > > on top. A bit more shuffling, but we could then use that for other driver
> > > private objects.
> > > 
> > > Other option is to stuff it into intel_atomic_state.
> 
> Hmm... I think I understand what you are saying. The core atomic
> functions like swap_state should not be able alter the topology
> manager's current state?
> 
> Did you mean something like this - https://paste.ubuntu.com/23743485/ ?

Not quite yet, here's what I had in mind as a sketch:

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 2e28fdca9c3d..6ce704b1e900 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -154,6 +154,17 @@ struct __drm_connnectors_state {
struct drm_connector_state *state;
 };
 
+struct drm_private_state_funcs {
+   void (*swap)(void *obj, void *state);
+   void (*destroy_state)(void *state);
+};
+
+struct __drm_private_obj_state {
+   struct obj *ptr;
+   struct obj_state *state;
+   struct drm_private_state_funcs *funcs;
+}
+
 /**
  * struct drm_atomic_state - the global state object for atomic updates
  * @ref: count of all references to this state (will not be freed until zero)
@@ -178,6 +189,8 @@ struct drm_atomic_state {
struct __drm_crtcs_state *crtcs;
int num_connector;
struct __drm_connnectors_state *connectors;
+   int num_private_objs;
+   struct __drm_private_obj_state *private_objs;
 
struct drm_modeset_acquire_ctx *acquire_ctx;
 
@@ -414,6 +427,19 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
 (__i)++)   \
for_each_if (plane_state)
 
+/* The magic here is that if obj and obj_state have the right type, then this
+ * will automatically cast to the right type. Since we allow any kind of 
private
+ * object mixed into the same array, runtime type casting is done using the
+ * funcs pointer.
+ */
+#define for_each_private_obj(__state, obj, obj_state, __i, funcs)
+   for ((__i) = 0; \
+(__i) < (__state)->num_private_objs && 
\
+((obj) = (__state)->private_objs[__i].ptr, \
+(obj_state) = (__state)->private_objs[__i].state, 1);  \
+(__i)++)   \
+   for_each_if ((__state)->private_objs[__i].funcs == (funcs))
+
 /**
  * drm_atomic_crtc_needs_modeset - compute combined modeset need
  * @state: _crtc_state for the CRTC

I didn't sketch helper functions for looking up/inserting objects, and ofc
we'd need the boilerplat for cleanup/swap, but I hope that part is clear.

If we add a duplicate_state callback to