Re: [Intel-gfx] [PATCH] drm/i915: Move vgpu balloon info into i915_virtual_gpu struct

2018-04-02 Thread Zhenyu Wang
On 2018.04.02 16:37:55 +0800, Xiong Zhang wrote:
> vgpu ballon info consists of four drm_mm_node which is used to reserve
> ggtt space, then linux guest won't use these reserved ggtt space.
> 
> Each vgpu has its own ballon info, so move ballon info into
> i915_virtual_gpu structure.
> 
> Signed-off-by: Xiong Zhang 
> ---

Acked-by: Zhenyu Wang 

>  drivers/gpu/drm/i915/i915_drv.h  | 14 
>  drivers/gpu/drm/i915/i915_vgpu.c | 47 
> 
>  2 files changed, 37 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 800230b..2adc73d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1301,6 +1301,20 @@ struct i915_workarounds {
>  struct i915_virtual_gpu {
>   bool active;
>   u32 caps;
> +
> + struct balloon_info {
> + /*
> +  * There are up to 2 regions per mappable/unmappable graphic
> +  * memory that might be ballooned. Here, index 0/1 is for
> +  * mappable graphic memory, 2/3 for unmappable graphic memory.
> +  */
> +#define VGPU_MAPPABLE_BALLOON_LOW 0
> +#define VGPU_MAPPABLE_BALLOON_HIGH1
> +#define VGPU_UNMAPPABLE_BALLOON_LOW   2
> +#define VGPU_UNMAPPABLE_BALLOON_HIGH  3
> +#define VGPU_MAX_BALLOON_NUM  4
> + struct drm_mm_node space[VGPU_MAX_BALLOON_NUM];
> + } bl_info;
>  };
>  
>  /* used in computing the new watermarks state */
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 7545686..79d3df4 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -86,17 +86,6 @@ bool intel_vgpu_has_full_48bit_ppgtt(struct 
> drm_i915_private *dev_priv)
>   return dev_priv->vgpu.caps & VGT_CAPS_FULL_48BIT_PPGTT;
>  }
>  
> -struct _balloon_info_ {
> - /*
> -  * There are up to 2 regions per mappable/unmappable graphic
> -  * memory that might be ballooned. Here, index 0/1 is for mappable
> -  * graphic memory, 2/3 for unmappable graphic memory.
> -  */
> - struct drm_mm_node space[4];
> -};
> -
> -static struct _balloon_info_ bl_info;
> -
>  static void vgt_deballoon_space(struct i915_ggtt *ggtt,
>   struct drm_mm_node *node)
>  {
> @@ -128,8 +117,9 @@ void intel_vgt_deballoon(struct drm_i915_private 
> *dev_priv)
>  
>   DRM_DEBUG("VGT deballoon.\n");
>  
> - for (i = 0; i < 4; i++)
> - vgt_deballoon_space(_priv->ggtt, _info.space[i]);
> + for (i = 0; i < VGPU_MAX_BALLOON_NUM; i++)
> + vgt_deballoon_space(_priv->ggtt,
> + _priv->vgpu.bl_info.space[i]);
>  }
>  
>  static int vgt_balloon_space(struct i915_ggtt *ggtt,
> @@ -200,6 +190,7 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
>  int intel_vgt_balloon(struct drm_i915_private *dev_priv)
>  {
>   struct i915_ggtt *ggtt = _priv->ggtt;
> + struct balloon_info *bl_info;
>   unsigned long ggtt_end = ggtt->base.total;
>  
>   unsigned long mappable_base, mappable_size, mappable_end;
> @@ -230,34 +221,39 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
>   return -EINVAL;
>   }
>  
> + bl_info = _priv->vgpu.bl_info;
>   /* Unmappable graphic memory ballooning */
>   if (unmappable_base > ggtt->mappable_end) {
> - ret = vgt_balloon_space(ggtt, _info.space[2],
> - ggtt->mappable_end, unmappable_base);
> + ret = vgt_balloon_space(ggtt,
> + _info->space[VGPU_UNMAPPABLE_BALLOON_LOW],
> + ggtt->mappable_end, unmappable_base);
>  
>   if (ret)
>   goto err;
>   }
>  
>   if (unmappable_end < ggtt_end) {
> - ret = vgt_balloon_space(ggtt, _info.space[3],
> - unmappable_end, ggtt_end);
> + ret = vgt_balloon_space(ggtt,
> + _info->space[VGPU_UNMAPPABLE_BALLOON_HIGH],
> + unmappable_end, ggtt_end);
>   if (ret)
>   goto err_upon_mappable;
>   }
>  
>   /* Mappable graphic memory ballooning */
>   if (mappable_base) {
> - ret = vgt_balloon_space(ggtt, _info.space[0],
> - 0, mappable_base);
> + ret = vgt_balloon_space(ggtt,
> + _info->space[VGPU_MAPPABLE_BALLOON_LOW],
> + 0, mappable_base);
>  
>   if (ret)
>   goto err_upon_unmappable;
>   }
>  
>   if (mappable_end < ggtt->mappable_end) {
> - ret = vgt_balloon_space(ggtt, _info.space[1],
> - mappable_end, ggtt->mappable_end);
> + ret = vgt_balloon_space(ggtt,
> +   

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

2018-04-02 Thread Laura Abbott

On 04/02/2018 02:26 PM, Lyude Paul wrote:

While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to continue handling aux
transactions even when none of the sinks are turned on since it's
possible for us to have a single atomic commit which results in
disabling each downstream sink, followed by subsequently re-enabling
each sink.

If we don't do this, we'll end up stalling any pending ESI interrupts
from the sink for up to 1ms. Unfortunately, dropping ESIs during this
timespan makes it so that link fallback retraining for MST (which I will
be submitting to the ML shortly) fails due to the channel EQ failure
interrupts potentially getting dropped. Additionally, when performing a
modeset that brings the hub status's link status from bad -> good having
ESIs disabled for that long causes us to miss the hub's response to us
trying to start link training as well.

Since any sink with MST is going to support DisplayPort 1.2 anyway, save
us the hassle of trying to wait until the sink comes back up and just
never shut the aux block down.

Changes since v2:
  - Fix patch name, no functional changes

Signed-off-by: Lyude Paul 
Cc: Laura Abbott 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")


Still able to boot docked and lid closed so

Tested-by: Laura Abbott 


---
  drivers/gpu/drm/i915/intel_dp.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..0479c377981b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode)
return;
  
  	if (mode != DRM_MODE_DPMS_ON) {

+   unsigned char data = intel_dp->is_mst ?
+   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
+
if (downstream_hpd_needs_d0(intel_dp))
return;
  
-		ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,

-DP_SET_POWER_D3);
+   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
  



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


Re: [Intel-gfx] [PATCH 5/8] drm/i915/guc: Use GuC FW size and HW restrictions to determine WOPCM partition

2018-04-02 Thread Yaodong Li

On 03/26/2018 03:04 AM, Michał Winiarski wrote:

On Fri, Mar 23, 2018 at 01:00:35PM -0700, Yaodong Li wrote:

On 03/23/2018 05:34 AM, Michał Winiarski wrote:

We need GuC to load HuC, but it's also possible for GuC to operate on
its own. We don't know what the size of HuC FW may be, so, not wanting
to make any platform-specific hardcoded guesses, we assume that its size
is 0... Which is a very bad approximation.
This has a very unfortunate consequence - once we've booted with GuC and
no HuC, we'll never be able to load HuC (unless we reboot, since the
registers are locked).
Rather than using unknown values in our computations - let's partition
based on GuC size.

we can do this based on known GuC and HuC sizes without
any assumption on FW sizes :)
please also refer to: https://patchwork.freedesktop.org/series/40541/

You need to have HuC FW present in the filesystem do do that though.
(IIUC we still get 0 if it's not there)

Yes. we cannot make any assumption to the status of the FW files as well.
so I think we should expect a system reboot for any FW updates.

We have one HW restriction where we're using HuC size (GuC size needs to
be roughly similar to HuC size - which may be unknown at this point),
luckily, another HW restriction makes it very unlikely to run in any
sort of issues in this case.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Jackie Li 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
---
   drivers/gpu/drm/i915/intel_wopcm.c | 60 
+-
   1 file changed, 34 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 52841d340002..295d302e97b9 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -167,7 +167,22 @@ static int check_ctx_rsvd_fits(struct intel_wopcm *wopcm, 
u32 ctx_rsvd)
return 0;
   }
-static int wopcm_check_hw_restrictions(struct intel_wopcm *wopcm)
+static inline void
+__guc_region_grow(struct intel_wopcm *wopcm, u32 size)
+{
+   /*
+* We're growing guc region in the direction of lower addresses.
+* We need to use multiples of base alignment, because it has more
+* strict alignment rules.
+*/
+   size = DIV_ROUND_UP(size, 2);

A bit confused here. Don't we just want to push the base downward for
*size* bytes?

Starting from the following:

 +--+
 |--|
 ||||
 ||||
 ||  GuC   ||
 ||  region||
 ||||
 ||||
 ||||
 ||||
 +--+
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 +--+

We want to grow the whole region by size bytes. Pushing the base downward gives
us this:

 +--+
 |  Empty   |
 |  space   |
 +--+
 ||||
 ||||
 ||  GuC   ||
 ||  region||
 ||||
 ||||
 ||||
 ||||
 +--+
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 +--+

Which leaves less space for HuC (and we're also leaving a bunch of unused space
in our partitioning).

If we modify both base and size to end up with this:

 +--+
 |--|
 ||||
 ||||
 ||  GuC   ||
 ||  region||
 ||||
 ||||
 ||||
 ||||
 ||||
 +--+
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 +--+

We're still satisfying the HW restriciton, but we're not wasting any space from
the top (and also we're leaving more space for HuC).


+   size = ALIGN(size, GUC_WOPCM_OFFSET_ALIGNMENT);

Hmm, I think we only need align it to 4K boundary.

No - because we're modifying both base (16K alignment) and size (4K
alignment).

Got it:-) Thanks!



+
+   wopcm->guc.base -= size;
+   wopcm->guc.size += size;
+}
+
+static void wopcm_adjust_for_hw_restrictions(struct intel_wopcm *wopcm)
   {
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
u32 huc_fw_size = intel_uc_fw_get_upload_size(>huc.fw);
@@ -177,22 +192,18 @@ static int wopcm_check_hw_restrictions(struct intel_wopcm 
*wopcm)
size = gen9_size_for_dword_gap_restriction(wopcm->guc.base,

[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC, HuC Loading Support for Cannonlake. (rev2)

2018-04-02 Thread Patchwork
== Series Details ==

Series: GuC, HuC Loading Support for Cannonlake. (rev2)
URL   : https://patchwork.freedesktop.org/series/41031/
State : failure

== Summary ==

Series 41031v2 GuC, HuC Loading Support for Cannonlake.
https://patchwork.freedesktop.org/api/1.0/series/41031/revisions/2/mbox/

 Possible new issues:

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-cnl-y3)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-cnl-y3)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-cnl-y3)
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-snb-2600)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-cnl-y3)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-cnl-y3)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-bdw-5557u)
   

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values

2018-04-02 Thread Yaodong Li

On 03/26/2018 12:15 AM, Joonas Lahtinen wrote:

Quoting Yaodong Li (2018-03-23 19:33:15)

As I said, I agree that we would likely solve the enable_guc=1 then
enable_guc=3 case with these changes which I think this the the only benefit
that we can get from the starting from the top way.
But my point is just like the from the bottom way, you are ignoring the
HuC FW size. e.g. you will need to grow the guc wopcm size for the hw
restrictions.
The problem is currently we do have this restriction on huc fw size v.s.
guc wopcm
size. In you solution, you are actually counting on the assumption that
guc fw size should be large enough so that we can ignore the huc fw size
and expect it still works when we set enable_huc=3. and my answer to
this is yes it will work for the cases that guc fw size is large enough, but
still risky to fail in case of guc fw size < huc_fw_size + 16K. and that
comes
to my point:
why not make life easier and accurate - If we decide to support dynamically
switching on/off huc fw loading and the fact we can get actual FW sizes,
why not drop all these assumptions and fix it in a way that we won't be
bothered by any FW side changes? :)

Is not the GuC vs. HuC FW size limitation going to be fixed for upcoming
platforms?

My gut instinct would be to partition based only on the enabled FW sizes,
whichever it be. Then just require a reboot if after that partitioning,
changing the parameter causes the FW not to fit.

That's my thought too. I think it makes sense to reboot the system for
any FW updates, especially when we have these write-once registers.

I believe the main reason we wanted to support enable_guc=1 (GuC FW only)
then enable_guc=3 (GuC + HuC FW) without a system reboot is to facilitate
the debugging.

Regards,
-Jackie

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


Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/debugfs: Print sink PSR status

2018-04-02 Thread Rodrigo Vivi
On Mon, Apr 02, 2018 at 03:38:26PM -0700, Pandiyan, Dhinakaran wrote:
> On Mon, 2018-04-02 at 13:51 -0700, José Roberto de Souza wrote:
> > IGT tests could be improved with sink status, knowing for sure that
> > hardware have activate or exit PSR.
> > 
> > Reviewed-by: Dhinakaran Pandiyan 
> 
> 
> Please don't merge this patch yet. While the patch itself is correct,
> testing it brings up an interesting problem.
> 
> Printing the sink_status() leads to power_get(aux_domain) which wakes up
> the display engine from DC5/6. This results in a HW triggered PSR exit,
> effectively altering the state that we are trying to read. I would like
> to understand the problem fully before merging the patch.

ack

> 
> 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 29 +
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 1dba2c451255..c9ac946b62c9 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
> > return "unknown";
> >  }
> >  
> > +static const char *psr_sink_status(u8 val)
> > +{
> > +   static const char * const sink_status[] = {
> > +   "inactive",
> > +   "transition to active, capture and display",
> > +   "active, display from RFB",
> > +   "active, capture and display on sink device timings",
> > +   "transition to inactive, capture and display, timing re-sync",
> > +   "reserved",
> > +   "reserved",
> > +   "sink internal error"
> > +   };
> > +
> > +   val &= DP_PSR_SINK_STATE_MASK;
> > +   if (val < ARRAY_SIZE(sink_status))
> > +   return sink_status[val];
> > +
> > +   return "unknown";
> > +}
> > +
> >  static int i915_edp_psr_status(struct seq_file *m, void *data)
> >  {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> >psr2, psr2_live_status(psr2));
> > }
> > +
> > +   if (dev_priv->psr.enabled) {
> > +   struct drm_dp_aux *aux = _priv->psr.enabled->aux;
> > +   u8 val;
> > +
> > +   if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, ) == 1)
> > +   seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val,
> > +  psr_sink_status(val));
> > +   }
> > mutex_unlock(_priv->psr.lock);
> >  
> > intel_runtime_pm_put(dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 3/3] HAX enable guc, huc for CI

2018-04-02 Thread Anusha Srivatsa
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c963603..1d23c41 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, 2) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
2.7.4

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


[Intel-gfx] [PATCH 1/3] linux-firmware/guc/cnl: Load GuC on Cannonlake

2018-04-02 Thread Anusha Srivatsa
GuC is now available for Cannonlake.
Load GuC v11.102 on Cannonlake.

Cc: Tomi Sarvela 
Cc: Jani Saarinen 
Cc: Rodrigo vivi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index a9e6fcc..6c59649d1 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -39,6 +39,9 @@
 #define KBL_FW_MAJOR 9
 #define KBL_FW_MINOR 39
 
+#define CNL_FW_MAJOR 11
+#define CNL_FW_MINOR 102
+
 #define GUC_FW_PATH(platform, major, minor) \
"i915/" __stringify(platform) "_guc_ver" __stringify(major) "_" 
__stringify(minor) ".bin"
 
@@ -51,6 +54,9 @@ MODULE_FIRMWARE(I915_BXT_GUC_UCODE);
 #define I915_KBL_GUC_UCODE GUC_FW_PATH(kbl, KBL_FW_MAJOR, KBL_FW_MINOR)
 MODULE_FIRMWARE(I915_KBL_GUC_UCODE);
 
+#define I915_CNL_GUC_UCODE GUC_FW_PATH(cnl, CNL_FW_MAJOR, CNL_FW_MINOR)
+MODULE_FIRMWARE(I915_CNL_GUC_UCODE);
+
 static void guc_fw_select(struct intel_uc_fw *guc_fw)
 {
struct intel_guc *guc = container_of(guc_fw, struct intel_guc, fw);
@@ -77,6 +83,10 @@ static void guc_fw_select(struct intel_uc_fw *guc_fw)
guc_fw->path = I915_KBL_GUC_UCODE;
guc_fw->major_ver_wanted = KBL_FW_MAJOR;
guc_fw->minor_ver_wanted = KBL_FW_MINOR;
+   } else if (IS_CANNONLAKE(dev_priv)) {
+   guc_fw->path = I915_CNL_GUC_UCODE;
+   guc_fw->major_ver_wanted = CNL_FW_MAJOR;
+   guc_fw->minor_ver_wanted = CNL_FW_MINOR;
} else {
DRM_WARN("%s: No firmware known for this platform!\n",
 intel_uc_fw_type_repr(guc_fw->type));
-- 
2.7.4

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


[Intel-gfx] [PATCH 2/3] linux-firmware/huc/cnl: Load HuC on Cannonlake

2018-04-02 Thread Anusha Srivatsa
Huc is available now for cannonlake.
Load v9.01.2719 on Cannonlake.

Cc: Tomi Sarvela 
Cc: Jani Saarinen 
Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_huc_fw.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c 
b/drivers/gpu/drm/i915/intel_huc_fw.c
index f93d238..107b9cf 100644
--- a/drivers/gpu/drm/i915/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/intel_huc_fw.c
@@ -34,6 +34,10 @@
 #define KBL_HUC_FW_MINOR 00
 #define KBL_BLD_NUM 1810
 
+#define CNL_HUC_FW_MAJOR 9
+#define CNL_HUC_FW_MINOR 01
+#define CNL_BLD_NUM 2719
+
 #define HUC_FW_PATH(platform, major, minor, bld_num) \
"i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
__stringify(minor) "_" __stringify(bld_num) ".bin"
@@ -50,6 +54,10 @@ MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
KBL_HUC_FW_MINOR, KBL_BLD_NUM)
 MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
 
+#define I915_CNL_HUC_UCODE HUC_FW_PATH(cnl, CNL_HUC_FW_MAJOR, \
+   CNL_HUC_FW_MINOR, CNL_BLD_NUM)
+MODULE_FIRMWARE(I915_CNL_HUC_UCODE);
+
 static void huc_fw_select(struct intel_uc_fw *huc_fw)
 {
struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
@@ -76,6 +84,10 @@ static void huc_fw_select(struct intel_uc_fw *huc_fw)
huc_fw->path = I915_KBL_HUC_UCODE;
huc_fw->major_ver_wanted = KBL_HUC_FW_MAJOR;
huc_fw->minor_ver_wanted = KBL_HUC_FW_MINOR;
+   } else if (IS_CANNONLAKE(dev_priv)) {
+   huc_fw->path = I915_CNL_HUC_UCODE;
+   huc_fw->major_ver_wanted = CNL_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = CNL_HUC_FW_MINOR;
} else {
DRM_WARN("%s: No firmware known for this platform!\n",
 intel_uc_fw_type_repr(huc_fw->type));
-- 
2.7.4

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


[Intel-gfx] [PATCH 0/3] GuC, HuC Loading Support for Cannonlake.

2018-04-02 Thread Anusha Srivatsa
Load the latest version of GuC and HuC.

Pull Request:
The following changes since commit a3be6d433f843d71edaa0f9a291297589d571ce4:

  Merge https://github.com/Netronome/linux-firmware into netro (2018-03-30 
10:10:27 -0400)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware master

for you to fetch changes up to 3e3bbec105af9141755db8eac768ac829cc9cfff:

  linux-firmware/i915: HuC firmware for Cannonlake v9.01.2719 (2018-03-30 
10:38:34 -0700)


Anusha Srivatsa (7):
  linux-firmware/i915: GuC firmware for Cannonlake v11.102
  linux-firmware/i915: HuC firmware for Cannonlake v9.01.2678
  Revert "linux-firmware/i915: HuC firmware for Cannonlake v9.01.2678"
  Revert "linux-firmware/i915: GuC firmware for Cannonlake v11.102"
  Merge remote-tracking branch 'official/master' into drm-firmware
  linux-firmware/i915: GuC firmware for Cannonlake v11.102
  linux-firmware/i915: HuC firmware for Cannonlake v9.01.2719

 WHENCE|   7 +++
 i915/cnl_guc_ver11_102.bin| Bin 0 -> 215936 bytes
 i915/cnl_huc_ver9_01_2719.bin | Bin 0 -> 430528 bytes
 3 files changed, 7 insertions(+)
 create mode 100644 i915/cnl_guc_ver11_102.bin
 create mode 100644 i915/cnl_huc_ver9_01_2719.bin


Anusha Srivatsa (3):
  linux-firmware/guc/cnl: Load GuC on Cannonlake
  linux-firmware/huc/cnl: Load HuC on Cannonlake
  HAX enable guc, huc for CI

 drivers/gpu/drm/i915/i915_params.h  |  2 +-
 drivers/gpu/drm/i915/intel_guc_fw.c | 10 ++
 drivers/gpu/drm/i915/intel_huc_fw.c | 12 
 3 files changed, 23 insertions(+), 1 deletion(-)

-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v5 04/10] drm/dp_mst: Remove all evil duplicate state pointers

2018-04-02 Thread Pandiyan, Dhinakaran
On Mon, 2018-04-02 at 18:47 -0400, Lyude Paul wrote:
> There's no reason to track the atomic state three times. Unfortunately,
> this is currently what we're doing, and even worse is that there is only
> one actually correct state pointer: the one in mst_state->base.state.
> mgr->state never seems to be used, along with the one in
> mst_state->state.
> 

Looks like the redundancy got introduced when struct drm_private_state
was added.

Reviewed-by: Dhinakaran Pandiyan 

> This confused me for over 4 hours until I realized there was no magic
> behind these pointers. So, let's save everyone else from the trouble.
> 
> Signed-off-by: Lyude Paul .
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Lyude Paul 
> ---
>  include/drm/drm_dp_mst_helper.h | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 41a8f08da05d..035963fbcd9d 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -409,7 +409,6 @@ struct drm_dp_payload {
>  struct drm_dp_mst_topology_state {
>   struct drm_private_state base;
>   int avail_slots;
> - struct drm_atomic_state *state;
>   struct drm_dp_mst_topology_mgr *mgr;
>  };
>  
> @@ -497,11 +496,6 @@ struct drm_dp_mst_topology_mgr {
>*/
>   int pbn_div;
>  
> - /**
> -  * @state: State information for topology manager
> -  */
> - struct drm_dp_mst_topology_state *state;
> -
>   /**
>* @funcs: Atomic helper callbacks
>*/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

2018-04-02 Thread Souza, Jose
On Mon, 2018-04-02 at 22:16 +, Souza, Jose wrote:
> On Mon, 2018-04-02 at 11:42 -0700, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> > > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza
> > > wrote:
> > > > When PSR/PSR2 is enabled hardware can do aux ch transactions by
> > > > it
> > > > self.
> > > > Spec requires that PSR is inactive before do any aux ch
> > > > transaction
> > > > in HSW and BDW, for skl+ there is a aux ch mutex but the use is
> > > > not
> > > > recommended.
> > > > So exiting PSR/PSR2 and waiting the transition to inactive to
> > > > prevent
> > > > any concurrent access between hardware and software in aux ch
> > > > registers.
> > > > 
> > > > VLV and CHV hardware don't do any aux as software is
> > > > responsible
> > > > to
> > > > do all the buffer tracking and it sends the wake up aux ch
> > > > message
> > > > to sink.
> > > > 
> > > 
> > > ahh cool... I get back what I said on some previous patch.
> > > I like where it is going, but...
> > > 
> > > > BSpec: 7530, 799 and 7532
> > > > 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c  | 38
> > > > ++
> > > >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> > > >  drivers/gpu/drm/i915/intel_psr.c |  8 
> > > >  3 files changed, 48 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 62f82c4298ac..fedee4e7ed24 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -1062,6 +1062,41 @@ static uint32_t
> > > > skl_get_aux_send_ctl(struct intel_dp *intel_dp,
> > > >DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> > > >  }
> > > >  
> > > > +/**
> > > > + * intel_dp_aux_ch_get - Get total control of aux ch registers
> > > > + *
> > > > + * By exiting or disabling any hardware feature that can also
> > > > use the aux ch
> > > > + * registers at the same time as driver, this function will
> > > > give
> > > > total control
> > > > + * of aux ch registers to driver.
> > > > + */
> > > > +static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
> > > > +{
> > > > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > > > +   return;
> > > > +
> > > > +   intel_psr_activate_block_get(intel_dp);
> > > > +   intel_psr_exit(intel_dp, true);
> > > 
> > > decision on exit and activate should be inside the block_get and
> > > block_put,
> > > based on current state of the counters.
> > > 
> > 
> > I haven't read the patches yet, but you could use the kref
> > infrastructure for 
> > reference counting.
> 
> Cool I will use it, thanks.

To use kref I would need to do something like this in intel_psr_init():

kref_init(_priv->psr.activate_block_kref);
/* kref_init() initialize the reference as 1, so calling kref_put() to
 * keep it as 0 but this will cause the release callback to be executed
 * but it will not be fully executed as PSR is not enabled yet.
 */
kref_put(_priv->psr.activate_block_kref,
intel_psr_activate_block_release);

That is okay? keep it?

> 
> > 
> > > > +}
> > > > +
> > > > +/**
> > > > + * intel_dp_aux_ch_put - Release aux ch registers control
> > > > + *
> > > > + * It is the intel_dp_aux_ch_get() counterpart.
> > > > + */
> > > > +static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
> > > > +{
> > > > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > > > +   return;
> > > > +
> > > > +   intel_psr_activate_block_put(intel_dp);
> > > > +   /* Usually more than just one aux ch transaction is
> > > > executed when
> > > > +* handling some event, activating PSR right way would
> > > > cause several
> > > > +* msecs of delay waiting PSR to exit for each aux ch
> > > > transaction, so
> > > > +* here asking it to be scheduled.
> > > > +*/
> > > > +   intel_psr_activate(intel_dp, true);
> > > > +}
> > > > +
> > > >  static int
> > > >  intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > > >   const uint8_t *send, int send_bytes,
> > > > @@ -1101,6 +1136,8 @@ intel_dp_aux_xfer(struct intel_dp
> > > > *intel_dp,
> > > >  
> > > > intel_dp_check_edp(intel_dp);
> > > >  
> > > > +   intel_dp_aux_ch_get(intel_dp);
> > > > +
> > > > /* Try to wait for any previous AUX channel activity
> > > > */
> > > > for (try = 0; try < 3; try++) {
> > > > status = I915_READ_NOTRACE(ch_ctl);
> > > > @@ -1223,6 +1260,7 @@ intel_dp_aux_xfer(struct intel_dp
> > > > *intel_dp,
> > > >  
> > > > ret = recv_bytes;
> > > >  out:
> > > > +   intel_dp_aux_ch_put(intel_dp);
> > > > pm_qos_update_request(_priv->pm_qos,
> > > > PM_QOS_DEFAULT_VALUE);
> > > >  
> > > > 

[Intel-gfx] [PATCH v5 10/10] drm/i915: Implement proper fallback training for MST

2018-04-02 Thread Lyude Paul
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.

MST retraining is somewhat different then SST retraining. While it's
possible during the normal link retraining sequence for a hub to indicate
bad link status, it's also possible for a hub to only indicate this
status through ESI messages and it's possible for this to happen after
the initial link training succeeds. This can lead to a pattern that
looks like this:

- Train MST link
- Training completes successfully
- MST hub sets Channel EQ failed bit in ESI
- Retraining starts
- Retraining completes successfully
- MST hub sets Channel EQ failed bit in ESI again
- Rinse and repeat

In these situations, we need to be able to actually trigger fallback
link training from the ESI handler as well, along with using the ESI
handler during retraining to figure out whether or not our retraining
actually succeeded.

This gets a bit more complicated since we have to ensure that we don't
block the ESI handler at all while doing retraining. If we do, due to
DisplayPort's general issues with being sensitive to IRQ latency most
MST hubs will just stop responding to us if their interrupts aren't
handled in a timely manner.

So: move retraining into it's own seperate handler. Running in a
seperate handler allows us to avoid stalling the ESI during link
retraining, and we can have the ESI signal that the channel EQ bit was
cleared through a simple completion struct. Additionally, we take care
to stick as much of this into the SST retraining path as possible since
sharing is caring.

V4:
 - Move all MST retraining work into hotplug_work
 - Grab the correct power wells when retraining.
 - Loop through MST encoders in intel_dp_get_crtc_mask(), quicker/easier
   than connectors

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ddi.c  |  10 +-
 drivers/gpu/drm/i915/intel_dp.c   | 355 --
 drivers/gpu/drm/i915/intel_dp_link_training.c |   6 +-
 drivers/gpu/drm/i915/intel_dp_mst.c   |  30 ++-
 drivers/gpu/drm/i915/intel_drv.h  |   7 +
 5 files changed, 315 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85..80f47b7c11fd 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3059,9 +3059,17 @@ static bool intel_ddi_hotplug(struct intel_encoder 
*encoder,
break;
}
 
+   if (ret == -EINVAL)
+   ret = intel_dp_handle_train_failure(
+   enc_to_intel_dp(>base));
+
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
-   WARN(ret, "Acquiring modeset locks failed with %i\n", ret);
+
+   if (ret == -EIO)
+   changed = true;
+   else
+   WARN(ret, "Acquiring modeset locks failed with %i\n", ret);
 
return changed;
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0aaeb3294799..a2754c1cbb2a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -45,6 +45,8 @@
 
 #define DP_DPRX_ESI_LEN 14
 
+#define DP_MST_RETRAIN_TIMEOUT (msecs_to_jiffies(100))
+
 /* Compliance test status bits  */
 #define INTEL_DP_RESOLUTION_SHIFT_MASK 0
 #define INTEL_DP_RESOLUTION_PREFERRED  (1 << INTEL_DP_RESOLUTION_SHIFT_MASK)
@@ -2762,6 +2764,7 @@ static void intel_disable_dp(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
 
intel_dp->link_trained = false;
+   intel_dp->link_is_bad = false;
 
if (old_crtc_state->has_audio)
intel_audio_codec_disable(encoder,
@@ -4207,8 +4210,133 @@ static void intel_dp_handle_test_request(struct 
intel_dp *intel_dp)
DRM_DEBUG_KMS("Could not write test response to sink\n");
 }
 
+/* Get a mask of the CRTCs that are running on the given intel_dp struct. For
+ * MST, this returns a crtc mask containing all of the CRTCs driving
+ * downstream sinks, for SST it just returns a mask of the attached
+ * connector's CRTC.
+ */
+int
+intel_dp_get_crtc_mask(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev;
+   struct drm_connector *connector;
+   struct drm_crtc *crtc;
+   int crtc_mask = 0;
+
+   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+
+   if (intel_dp->is_mst) {
+   struct intel_dp_mst_encoder *mst_enc;
+   struct intel_connector *intel_connector;
+   struct drm_connector_state *conn_state;
+   int i;
+
+   for (i = 0; i < 

[Intel-gfx] [PATCH v5 08/10] drm/i915: Make intel_dp_mst_atomic_check() idempotent

2018-04-02 Thread Lyude Paul
The current way of handling changing VCPI allocations doesn't make a
whole ton of sense. Since drm_atomic_helper_check_modeset() can be
called multiple times which means that intel_dp_mst_atomic_check() can
also be called multiple times. However, since we make the silly mistake
of trying to free VCPI slots based off the /new/ atomic state instead of
the old atomic state, we'll end up potentially double freeing the vcpi
slots for the ports.

This also has another unintended consequence that came back up while
implementing MST fallback retraining: if a modeset is forced on a
connector that's already part of the state, but it's atomic_check() has
already been run once and doesn't get run again, we'll end up not
freeing the VCPI allocations on the connector at all.

The easiest way to solve this is to be clever and, with the exception of
connectors that are being disabled and thus will never have
compute_config() ran on them, move vcpi freeing out of the atomic check
and into compute_config().

Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 78 +++--
 1 file changed, 57 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index d3040dd06859..7e97b4ee534e 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -30,6 +30,38 @@
 #include 
 #include 
 
+static int
+intel_dp_mst_atomic_release_vcpi_slots(struct drm_atomic_state *state,
+  struct drm_crtc_state *crtc_state,
+  struct drm_connector_state *conn_state)
+{
+   struct drm_crtc_state *new_crtc_state;
+   struct intel_crtc_state *intel_crtc_state =
+   to_intel_crtc_state(crtc_state);
+   struct drm_encoder *encoder;
+   struct drm_dp_mst_topology_mgr *mgr;
+   int slots, ret;
+
+   slots = intel_crtc_state->dp_m_n.tu;
+   if (slots <= 0)
+   return 0;
+
+   encoder = conn_state->best_encoder;
+   mgr = _to_mst(encoder)->primary->dp.mst_mgr;
+
+   ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots);
+   if (ret) {
+   DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n",
+ slots, ret);
+   } else {
+   new_crtc_state = drm_atomic_get_crtc_state(state,
+  crtc_state->crtc);
+   to_intel_crtc_state(new_crtc_state)->dp_m_n.tu = 0;
+   }
+
+   return ret;
+}
+
 static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
@@ -41,11 +73,15 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
+   struct drm_connector_state *old_conn_state =
+   drm_atomic_get_old_connector_state(state, >base);
+   struct drm_crtc *old_crtc;
struct intel_dp_mst_topology_state *mst_state;
int bpp;
int slots;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int mst_pbn;
+   int ret;
bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
   DP_DPCD_QUIRK_LIMITED_M_N);
 
@@ -78,6 +114,17 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
 
+   /* Free any VCPI allocations on this connector from the previous
+* state */
+   old_crtc = old_conn_state->crtc;
+   if (old_crtc) {
+   ret = intel_dp_mst_atomic_release_vcpi_slots(
+   state, drm_atomic_get_old_crtc_state(state, old_crtc),
+   old_conn_state);
+   if (ret)
+   return ret;
+   }
+
slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr,
  connector->port, mst_pbn);
if (slots < 0) {
@@ -107,31 +154,20 @@ static int intel_dp_mst_atomic_check(struct drm_connector 
*connector,
 {
struct drm_atomic_state *state = new_conn_state->state;
struct drm_connector_state *old_conn_state;
-   struct drm_crtc *old_crtc;
-   struct drm_crtc_state *crtc_state;
-   int slots, ret = 0;
+   int ret = 0;
 
old_conn_state = drm_atomic_get_old_connector_state(state, connector);
-   old_crtc = old_conn_state->crtc;
-   if (!old_crtc)
-   return ret;
 
-   crtc_state = 

[Intel-gfx] [PATCH v5 09/10] drm/dp_mst: Add MST fallback retraining helpers

2018-04-02 Thread Lyude Paul
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps that must be taken in order to properly retrain the
entire topology under a lower link rate. Since the VCPI allocations for
each mstb is determined based off the link rate for the top of the
topology, we also have to recalculate all of the VCPI allocations for
the downstream ports as well to ensure that we still have enough link
bandwidth to drive each mstb.

Additionally, since we have multiple downstream connectors per port,
setting the link status of the parent mstb's port to bad isn't enough:
all of the downstream mstb ports have to have their link status set to
bad.

This basically follows the same paradigm that our DP link status logic
in DRM does, in that we simply tell userspace that all of the mstb ports
need retraining and additionally applying the new lower bandwidth
constraints to all of the atomic commits on the topology that follow.
Additionally; we add helpers that handle automatically checking whether
or not a new atomic commit would perform the modesets required to
retrain a link and if so, additionally handles updating the link status
of each connector on the MST topology.

V4:
 - clarify slightly confusing message in
   drm_dp_mst_topology_mgr_lower_link_rate()
 - Fix argument naming
 - Squash this with the other retrain helper, because now they're
   intertwined with one another
 - Track which connectors with CRTCs need modesets in order to retrain a
   topology in the topology's atomic state. This lets us greatly simplify
   the helpers, along with alleviating drivers of the responsibility of
   figuring out when to call the retrain helpers during atomic checks. It
   also ensures that we can keep zombie connectors that a retrain is
   dependent on alive until the topology either disappears, or they are
   disabled. We needed to do most of this anyway, since our original
   helpers didn't take into account that we need to invoke retraining
   when the link status prop changes, regardless of whether or not a
   modeset has been initiated yet.
 - Handle situation we completely forgot about: adding new connectors to
   an MST topology that needs fallback retraining (solution: new
   connectors on a topology inherit the link status of the rest of the
   topology)
 - Also make sure to handle connectors that are orphaned due to their
   MST topology disappearing. Solution: remove from topology state,
   reset link status to good
 - Write more docs on the retraining procedure.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 438 +-
 include/drm/drm_dp_mst_helper.h   |  20 ++
 2 files changed, 453 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b55fd545d6a3..aca05b10bf18 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1199,6 +1199,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
*mstb,
 
if (created && !port->input) {
char proppath[255];
+   struct drm_dp_mst_topology_state *state;
 
build_mst_prop_path(mstb, port->port_num, proppath, 
sizeof(proppath));
port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr, 
port, proppath);
@@ -1217,6 +1218,11 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
*mstb,
port->cached_edid = drm_get_edid(port->connector, 
>aux.ddc);
drm_mode_connector_set_tile_property(port->connector);
}
+   state = to_dp_mst_topology_state(port->mgr->base.state);
+   if (!list_empty(>bad_ports)) {
+   port->connector->state->link_status =
+   DRM_LINK_STATUS_BAD;
+   }
(*mstb->mgr->cbs->register_connector)(port->connector);
}
 
@@ -2076,7 +2082,7 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
 {
switch (dp_link_bw) {
default:
-   DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count: 
%d)\n",
+   DRM_DEBUG_KMS("invalid link bandwidth: %x (link count: %d)\n",
  dp_link_bw, dp_link_count);
return false;
 
@@ -2096,11 +2102,408 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
return true;
 }
 
+static int drm_dp_set_mstb_link_status(struct drm_dp_mst_topology_mgr *mgr,
+  struct drm_dp_mst_branch *mstb,
+  enum drm_link_status status)
+{
+   

[Intel-gfx] [PATCH v5 06/10] drm/dp_mst: Add reset_state callback to topology mgr

2018-04-02 Thread Lyude Paul
This gives drivers subclassing drm_dp_mst_topology_state the ability to
prepare their topology states for a new hub to be connected whenever
it's detected that the currently connected topology has been
disconnected from the system. We'll need this in order to correctly
track RX capabilities in i915 from the topology's atomic state.

Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 11 +++
 include/drm/drm_dp_mst_helper.h   |  3 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 8a72eed0ae05..b55fd545d6a3 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2096,6 +2096,16 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
return true;
 }
 
+static void drm_dp_mst_topology_reset_state(struct drm_dp_mst_topology_mgr 
*mgr)
+{
+   struct drm_dp_mst_topology_state *state =
+   to_dp_mst_topology_state(mgr->base.state);
+
+
+   if (mgr->cbs->reset_state)
+   mgr->cbs->reset_state(state);
+}
+
 /**
  * drm_dp_mst_topology_mgr_set_mst() - Set the MST state for a topology manager
  * @mgr: manager to set state for
@@ -2171,6 +2181,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
mgr->payload_mask = 0;
set_bit(0, >payload_mask);
mgr->vcpi_mask = 0;
+   drm_dp_mst_topology_reset_state(mgr);
}
 
 out_unlock:
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index b42922987470..fd856c371a6e 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -381,6 +381,7 @@ struct drm_dp_sideband_msg_tx {
 
 /* sideband msg handler */
 struct drm_dp_mst_topology_mgr;
+struct drm_dp_mst_topology_state;
 struct drm_dp_mst_topology_cbs {
/* create a connector for a port */
struct drm_connector *(*add_connector)(struct drm_dp_mst_topology_mgr 
*mgr, struct drm_dp_mst_port *port, const char *path);
@@ -388,7 +389,7 @@ struct drm_dp_mst_topology_cbs {
void (*destroy_connector)(struct drm_dp_mst_topology_mgr *mgr,
  struct drm_connector *connector);
void (*hotplug)(struct drm_dp_mst_topology_mgr *mgr);
-
+   void (*reset_state)(struct drm_dp_mst_topology_state *state);
 };
 
 #define DP_MAX_PAYLOAD (sizeof(unsigned long) * 8)
-- 
2.14.3

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


[Intel-gfx] [PATCH v5 07/10] drm/i915: Only use one link bw config for MST topologies

2018-04-02 Thread Lyude Paul
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if the sink changes it's RX caps after we've already set up
an MST link and we attempt to add or remove another sink from the
topology, we could put ourselves into an invalid state where we've tried
to configure different sinks on the same MST topology with different
link rates. We could also run into this situation if a sink reports a
higher link rate after suspend, usually from us having trained it with a
fallback bw configuration before suspending.

So: keep the link rate consistent by subclassing
drm_dp_mst_topology_state, and tracking it there. For the time being, we
only allow the link rate to change when the entire topology has been
disconnected.

V4:
 - Track link rate/lane count in the atomic topology state instead of in
   intel_dp.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 77 +
 drivers/gpu/drm/i915/intel_drv.h|  7 
 2 files changed, 68 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index e308962cde05..d3040dd06859 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -41,8 +41,9 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
+   struct intel_dp_mst_topology_state *mst_state;
int bpp;
-   int lane_count, slots;
+   int slots;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
@@ -55,18 +56,22 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
DRM_DEBUG_KMS("Setting pipe bpp to %d\n",
  bpp);
}
+
+   mst_state = to_intel_dp_mst_topology_state(
+   drm_atomic_dp_mst_get_topology_state(state, _dp->mst_mgr));
/*
 * for MST we always configure max link bw - the spec doesn't
 * seem to suggest we should do otherwise.
 */
-   lane_count = intel_dp_max_lane_count(intel_dp);
-
-   pipe_config->lane_count = lane_count;
+   if (!mst_state->link_rate || !mst_state->lane_count) {
+   mst_state->link_rate = intel_dp_max_link_rate(intel_dp);
+   mst_state->lane_count = intel_dp_max_lane_count(intel_dp);
+   }
 
+   pipe_config->lane_count = mst_state->lane_count;
+   pipe_config->port_clock = mst_state->link_rate;
pipe_config->pipe_bpp = bpp;
 
-   pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
-
if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
 
@@ -80,7 +85,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
return false;
}
 
-   intel_link_compute_m_n(bpp, lane_count,
+   intel_link_compute_m_n(bpp, mst_state->lane_count,
   adjusted_mode->crtc_clock,
   pipe_config->port_clock,
   _config->dp_m_n,
@@ -524,11 +529,55 @@ static void intel_dp_mst_hotplug(struct 
drm_dp_mst_topology_mgr *mgr)
drm_kms_helper_hotplug_event(dev);
 }
 
+static void intel_mst_reset_state(struct drm_dp_mst_topology_state *state)
+{
+   struct intel_dp_mst_topology_state *intel_mst_state =
+   to_intel_dp_mst_topology_state(state);
+
+   intel_mst_state->link_rate = 0;
+   intel_mst_state->lane_count = 0;
+}
+
 static const struct drm_dp_mst_topology_cbs mst_cbs = {
.add_connector = intel_dp_add_mst_connector,
.register_connector = intel_dp_register_mst_connector,
.destroy_connector = intel_dp_destroy_mst_connector,
.hotplug = intel_dp_mst_hotplug,
+   .reset_state = intel_mst_reset_state,
+};
+
+static struct drm_private_state *
+intel_dp_mst_duplicate_state(struct drm_private_obj *obj)
+{
+   struct intel_dp_mst_topology_state *state;
+
+   state = kmemdup(obj->state, sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return NULL;
+
+   __drm_atomic_dp_mst_duplicate_topology_state(
+   to_dp_mst_topology_mgr(obj), >base);
+
+   return >base.base;
+}
+
+static void
+intel_dp_mst_destroy_state(struct drm_private_obj *obj,
+  struct drm_private_state *state)
+{
+   struct drm_dp_mst_topology_state 

[Intel-gfx] [PATCH v5 01/10] drm/atomic: Print debug message on atomic check failure

2018-04-02 Thread Lyude Paul
Does what it says on the label, it's a little confusing debugging atomic
check failures otherwise.

Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_atomic.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..972a7e9634ab 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1705,8 +1705,11 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
if (config->funcs->atomic_check)
ret = config->funcs->atomic_check(state->dev, state);
 
-   if (ret)
+   if (ret) {
+   DRM_DEBUG_ATOMIC("atomic driver check for %p failed: %d\n",
+state, ret);
return ret;
+   }
 
if (!state->allow_modeset) {
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
-- 
2.14.3

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


[Intel-gfx] [PATCH v5 05/10] drm/dp_mst: Make drm_dp_mst_topology_state subclassable

2018-04-02 Thread Lyude Paul
This is useful for drivers (which will probably be all of them soon)
which need to track state that is exclusive to the topology, and not a
specific connector on said topology. This includes things such as the
link rate and lane count that are shared by all of the connectors on the
topology.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 14 +++-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 35 +++-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h|  4 +-
 drivers/gpu/drm/drm_dp_mst_topology.c  | 94 +-
 drivers/gpu/drm/i915/intel_dp_mst.c| 13 ++-
 drivers/gpu/drm/nouveau/nv50_display.c | 15 +++-
 drivers/gpu/drm/radeon/radeon_dp_mst.c | 13 ++-
 include/drm/drm_dp_mst_helper.h|  8 ++
 8 files changed, 165 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e42a28e3adc5..2c3660c36732 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3626,9 +3626,17 @@ static int amdgpu_dm_connector_init(struct 
amdgpu_display_manager *dm,
 
drm_connector_register(>base);
 
-   if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
-   || connector_type == DRM_MODE_CONNECTOR_eDP)
-   amdgpu_dm_initialize_dp_connector(dm, aconnector);
+   if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+   connector_type == DRM_MODE_CONNECTOR_eDP) {
+   res = amdgpu_dm_initialize_dp_connector(dm, aconnector);
+   if (res) {
+   drm_connector_unregister(>base);
+   drm_connector_cleanup(>base);
+   aconnector->connector_id = -1;
+
+   goto out_free;
+   }
+   }
 
 #if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||\
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 8291d74f26bc..a3a43b1b30df 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -475,22 +475,49 @@ static const struct drm_dp_mst_topology_cbs dm_mst_cbs = {
.register_connector = dm_dp_mst_register_connector
 };
 
-void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
-  struct amdgpu_dm_connector *aconnector)
+static const struct drm_private_state_funcs dm_mst_state_funcs = {
+   .atomic_duplicate_state = drm_atomic_dp_mst_duplicate_topology_state,
+   .atomic_destroy_state = drm_atomic_dp_mst_destroy_topology_state,
+};
+
+int amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
+ struct amdgpu_dm_connector *aconnector)
 {
+   struct drm_dp_mst_topology_state *state =
+   kzalloc(sizeof(*state), GFP_KERNEL);
+   int ret = 0;
+
+   if (!state)
+   return -ENOMEM;
+
aconnector->dm_dp_aux.aux.name = "dmdc";
aconnector->dm_dp_aux.aux.dev = dm->adev->dev;
aconnector->dm_dp_aux.aux.transfer = dm_dp_aux_transfer;
aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
 
-   drm_dp_aux_register(>dm_dp_aux.aux);
+   ret = drm_dp_aux_register(>dm_dp_aux.aux);
+   if (ret)
+   goto err_aux;
+
aconnector->mst_mgr.cbs = _mst_cbs;
-   drm_dp_mst_topology_mgr_init(
+   aconnector->mst_mgr.funcs = _mst_state_funcs;
+   ret = drm_dp_mst_topology_mgr_init(
>mst_mgr,
+   state,
dm->adev->ddev,
>dm_dp_aux.aux,
16,
4,
aconnector->connector_id);
+   if (ret)
+   goto err_mst;
+
+   return 0;
+
+err_mst:
+   drm_dp_aux_unregister(>dm_dp_aux.aux);
+err_aux:
+   kfree(state);
+   return ret;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
index 8cf51da26657..d28fb456d2d5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
@@ -29,8 +29,8 @@
 struct amdgpu_display_manager;
 struct amdgpu_dm_connector;
 
-void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
-  struct amdgpu_dm_connector *aconnector);
+int amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
+ struct amdgpu_dm_connector *aconnector);
 void 

[Intel-gfx] [PATCH v5 02/10] drm/i915: Move DP modeset retry work into intel_dp

2018-04-02 Thread Lyude Paul
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're dealing with an MST device, along with being able to easily
trace the intel_dp struct back to it's respective connector (if there is
any). So, move the modeset_retry_work function out of the
intel_connector struct and into intel_dp.

Signed-off-by: Lyude Paul 
Reviewed-by: Manasi Navare 
Cc: Manasi Navare 
Cc: Ville Syrjälä 

V2:
 - Remove accidental duplicate modeset_retry_work in intel_connector
V3:
 - Also check against eDP in intel_hpd_poll_fini() - mdnavare
V4:
 - Don't bother looping over connectors for canceling modeset rety work,
   just encoders.
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/intel_display.c  | 14 +++---
 drivers/gpu/drm/i915/intel_dp.c   | 10 --
 drivers/gpu/drm/i915/intel_dp_link_training.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  6 +++---
 4 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3acd75753a31..6357d8d8e36f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15406,20 +15406,28 @@ void intel_connector_unregister(struct drm_connector 
*connector)
 
 static void intel_hpd_poll_fini(struct drm_device *dev)
 {
-   struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+   struct intel_connector *connector;
+   struct intel_encoder *encoder;
+   struct intel_dp *intel_dp;
 
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(dev, _iter);
for_each_intel_connector_iter(connector, _iter) {
-   if (connector->modeset_retry_work.func)
-   cancel_work_sync(>modeset_retry_work);
if (connector->hdcp_shim) {
cancel_delayed_work_sync(>hdcp_check_work);
cancel_work_sync(>hdcp_prop_work);
}
}
drm_connector_list_iter_end(_iter);
+
+   for_each_intel_encoder(dev, encoder) {
+   if (encoder->type == INTEL_OUTPUT_DP ||
+   encoder->type == INTEL_OUTPUT_EDP) {
+   intel_dp = enc_to_intel_dp(>base);
+   cancel_work_sync(_dp->modeset_retry_work);
+   }
+   }
 }
 
 void intel_modeset_cleanup(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0479c377981b..0aaeb3294799 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6251,12 +6251,10 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
 
 static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
 {
-   struct intel_connector *intel_connector;
-   struct drm_connector *connector;
+   struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
+modeset_retry_work);
+   struct drm_connector *connector = _dp->attached_connector->base;
 
-   intel_connector = container_of(work, typeof(*intel_connector),
-  modeset_retry_work);
-   connector = _connector->base;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
  connector->name);
 
@@ -6285,7 +6283,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
int type;
 
/* Initialize the work for modeset in case of link train failure */
-   INIT_WORK(_connector->modeset_retry_work,
+   INIT_WORK(_dp->modeset_retry_work,
  intel_dp_modeset_retry_work_fn);
 
if (WARN(intel_dig_port->max_lanes < 1,
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..2cfa58ce1f95 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
 
intel_dp->link_rate,
 
intel_dp->lane_count))
/* Schedule a Hotplug Uevent to userspace to start 
modeset */
-   schedule_work(_connector->modeset_retry_work);
+   schedule_work(_dp->modeset_retry_work);
} else {
DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate 
= %d, lane count = %d",
  

[Intel-gfx] [PATCH v5 03/10] drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state()

2018-04-02 Thread Lyude Paul
Since these functions are dealing with an atomic state that needs to be
modified during atomic check and commit, change the naming on this
function to drm_atomic_dp_mst_get_topology_state() since we're the only
one using the function, and it's more consistent with the naming
scheme used in drm_atomic.c/drm_atomic_helper.c.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
 include/drm/drm_dp_mst_helper.h   |  5 +++--
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6fac4129e6a2..ba67f1782a04 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2622,7 +2622,7 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state 
*state,
struct drm_dp_mst_topology_state *topology_state;
int req_slots;
 
-   topology_state = drm_atomic_get_mst_topology_state(state, mgr);
+   topology_state = drm_atomic_dp_mst_get_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
 
@@ -2662,7 +2662,7 @@ int drm_dp_atomic_release_vcpi_slots(struct 
drm_atomic_state *state,
 {
struct drm_dp_mst_topology_state *topology_state;
 
-   topology_state = drm_atomic_get_mst_topology_state(state, mgr);
+   topology_state = drm_atomic_dp_mst_get_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
 
@@ -3129,7 +3129,7 @@ static const struct drm_private_state_funcs 
mst_state_funcs = {
 };
 
 /**
- * drm_atomic_get_mst_topology_state: get MST topology state
+ * drm_atomic_dp_mst_get_topology_state: get MST topology state
  *
  * @state: global atomic state
  * @mgr: MST topology manager, also the private object in this case
@@ -3143,15 +3143,16 @@ static const struct drm_private_state_funcs 
mst_state_funcs = {
  *
  * The MST topology state or error pointer.
  */
-struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
drm_atomic_state *state,
-   struct 
drm_dp_mst_topology_mgr *mgr)
+struct drm_dp_mst_topology_state *
+drm_atomic_dp_mst_get_topology_state(struct drm_atomic_state *state,
+struct drm_dp_mst_topology_mgr *mgr)
 {
struct drm_device *dev = mgr->dev;
 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
return to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state, 
>base));
 }
-EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
+EXPORT_SYMBOL(drm_atomic_dp_mst_get_topology_state);
 
 /**
  * drm_dp_mst_topology_mgr_init - initialise a topology manager
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 7f78d26a0766..41a8f08da05d 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -623,8 +623,9 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
 
 void drm_dp_mst_topology_mgr_suspend(struct drm_dp_mst_topology_mgr *mgr);
 int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr);
-struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
drm_atomic_state *state,
-   struct 
drm_dp_mst_topology_mgr *mgr);
+
+struct drm_dp_mst_topology_state *drm_atomic_dp_mst_get_topology_state(struct 
drm_atomic_state *state,
+  struct 
drm_dp_mst_topology_mgr *mgr);
 int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
  struct drm_dp_mst_topology_mgr *mgr,
  struct drm_dp_mst_port *port, int pbn);
-- 
2.14.3

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


[Intel-gfx] [PATCH v5 00/10] Implement proper MST fallback retraining in i915

2018-04-02 Thread Lyude Paul
Latest version of https://patchwork.freedesktop.org/series/39642/ ,
hopefully patchwork understands this and doesn't break anything!

Lots of changes.

Lyude Paul (10):
  drm/atomic: Print debug message on atomic check failure
  drm/i915: Move DP modeset retry work into intel_dp
  drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state()
  drm/dp_mst: Remove all evil duplicate state pointers
  drm/dp_mst: Make drm_dp_mst_topology_state subclassable
  drm/dp_mst: Add reset_state callback to topology mgr
  drm/i915: Only use one link bw config for MST topologies
  drm/i915: Make intel_dp_mst_atomic_check() idempotent
  drm/dp_mst: Add MST fallback retraining helpers
  drm/i915: Implement proper fallback training for MST

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  14 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  35 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h|   4 +-
 drivers/gpu/drm/drm_atomic.c   |   5 +-
 drivers/gpu/drm/drm_dp_mst_topology.c  | 548 -
 drivers/gpu/drm/i915/intel_ddi.c   |  10 +-
 drivers/gpu/drm/i915/intel_display.c   |  14 +-
 drivers/gpu/drm/i915/intel_dp.c| 361 ++
 drivers/gpu/drm/i915/intel_dp_link_training.c  |   6 +-
 drivers/gpu/drm/i915/intel_dp_mst.c| 180 +--
 drivers/gpu/drm/i915/intel_drv.h   |  20 +-
 drivers/gpu/drm/nouveau/nv50_display.c |  15 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c |  13 +-
 include/drm/drm_dp_mst_helper.h|  42 +-
 14 files changed, 1088 insertions(+), 179 deletions(-)

-- 
2.14.3

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


[Intel-gfx] [PATCH v5 04/10] drm/dp_mst: Remove all evil duplicate state pointers

2018-04-02 Thread Lyude Paul
There's no reason to track the atomic state three times. Unfortunately,
this is currently what we're doing, and even worse is that there is only
one actually correct state pointer: the one in mst_state->base.state.
mgr->state never seems to be used, along with the one in
mst_state->state.

This confused me for over 4 hours until I realized there was no magic
behind these pointers. So, let's save everyone else from the trouble.

Signed-off-by: Lyude Paul .
Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Lyude Paul 
---
 include/drm/drm_dp_mst_helper.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 41a8f08da05d..035963fbcd9d 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -409,7 +409,6 @@ struct drm_dp_payload {
 struct drm_dp_mst_topology_state {
struct drm_private_state base;
int avail_slots;
-   struct drm_atomic_state *state;
struct drm_dp_mst_topology_mgr *mgr;
 };
 
@@ -497,11 +496,6 @@ struct drm_dp_mst_topology_mgr {
 */
int pbn_div;
 
-   /**
-* @state: State information for topology manager
-*/
-   struct drm_dp_mst_topology_state *state;
-
/**
 * @funcs: Atomic helper callbacks
 */
-- 
2.14.3

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


Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/debugfs: Print sink PSR status

2018-04-02 Thread Pandiyan, Dhinakaran
On Mon, 2018-04-02 at 13:51 -0700, José Roberto de Souza wrote:
> IGT tests could be improved with sink status, knowing for sure that
> hardware have activate or exit PSR.
> 
> Reviewed-by: Dhinakaran Pandiyan 


Please don't merge this patch yet. While the patch itself is correct,
testing it brings up an interesting problem.

Printing the sink_status() leads to power_get(aux_domain) which wakes up
the display engine from DC5/6. This results in a HW triggered PSR exit,
effectively altering the state that we are trying to read. I would like
to understand the problem fully before merging the patch.


> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1dba2c451255..c9ac946b62c9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
>   return "unknown";
>  }
>  
> +static const char *psr_sink_status(u8 val)
> +{
> + static const char * const sink_status[] = {
> + "inactive",
> + "transition to active, capture and display",
> + "active, display from RFB",
> + "active, capture and display on sink device timings",
> + "transition to inactive, capture and display, timing re-sync",
> + "reserved",
> + "reserved",
> + "sink internal error"
> + };
> +
> + val &= DP_PSR_SINK_STATE_MASK;
> + if (val < ARRAY_SIZE(sink_status))
> + return sink_status[val];
> +
> + return "unknown";
> +}
> +
>  static int i915_edp_psr_status(struct seq_file *m, void *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
>  psr2, psr2_live_status(psr2));
>   }
> +
> + if (dev_priv->psr.enabled) {
> + struct drm_dp_aux *aux = _priv->psr.enabled->aux;
> + u8 val;
> +
> + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, ) == 1)
> + seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val,
> +psr_sink_status(val));
> + }
>   mutex_unlock(_priv->psr.lock);
>  
>   intel_runtime_pm_put(dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] i915/dp_mst: Keep AUX block running when disabling DPMS

2018-04-02 Thread Pandiyan, Dhinakaran



On Mon, 2018-04-02 at 17:21 -0400, Lyude Paul wrote:
> While enabling/disabling DPMS before link training with MST hubs is
> perfectly valid; unfortunately disabling DPMS results in some devices
> disabling their AUX CH block as well. For SST this isn't as much of a
> problem, but for MST we need to be able to continue handling aux
> transactions even when none of the sinks are turned on since it's
> possible for us to have a single atomic commit which results in
> disabling each downstream sink, followed by subsequently re-enabling
> each sink.
> 
> If we don't do this, we'll end up stalling any pending ESI interrupts
> from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> timespan makes it so that link fallback retraining for MST (which I will
> be submitting to the ML shortly) fails due to the channel EQ failure
> interrupts potentially getting dropped. Additionally, when performing a
> modeset that brings the hub status's link status from bad -> good having
> ESIs disabled for that long causes us to miss the hub's response to us
> trying to start link training as well.
> 
> Since any sink with MST is going to support DisplayPort 1.2 anyway, save
> us the hassle of trying to wait until the sink comes back up and just
> never shut the aux block down.
> 
> Signed-off-by: Lyude Paul 
> Cc: Laura Abbott 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Cc: sta...@vger.kernel.org
> Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST 
> hub.")

We've come a full circle on this one :)

1) Originally, we had disable_ddi() setting the branch power state to
D3.
2) Then "Use MST sideband message transactions for dpms control" removed
that as a bug fix for some devices. The sideband solution was chosen
over the D3_AUX_ON approach this patch takes.
3) Next, "Write to SET_POWER dpcd to enable MST hub" effectively took us
back to the original state due to a regression.
4) Now, we are calling (3) a regression and implementing D3_AUX_ON.


I guess, this combination should work for most devices. But, we should
test this on a few different MST hubs before going ahead.

-DK


> ---
>  drivers/gpu/drm/i915/intel_dp.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4298ac..0479c377981b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, 
> int mode)
>   return;
>  
>   if (mode != DRM_MODE_DPMS_ON) {
> + unsigned char data = intel_dp->is_mst ?
> + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> +
>   if (downstream_hpd_needs_d0(intel_dp))
>   return;
>  
> - ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> -  DP_SET_POWER_D3);
> + ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
>   } else {
>   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

2018-04-02 Thread Souza, Jose
On Mon, 2018-04-02 at 11:42 -0700, Pandiyan, Dhinakaran wrote:
> 
> 
> On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza
> > wrote:
> > > When PSR/PSR2 is enabled hardware can do aux ch transactions by
> > > it
> > > self.
> > > Spec requires that PSR is inactive before do any aux ch
> > > transaction
> > > in HSW and BDW, for skl+ there is a aux ch mutex but the use is
> > > not
> > > recommended.
> > > So exiting PSR/PSR2 and waiting the transition to inactive to
> > > prevent
> > > any concurrent access between hardware and software in aux ch
> > > registers.
> > > 
> > > VLV and CHV hardware don't do any aux as software is responsible
> > > to
> > > do all the buffer tracking and it sends the wake up aux ch
> > > message
> > > to sink.
> > > 
> > 
> > ahh cool... I get back what I said on some previous patch.
> > I like where it is going, but...
> > 
> > > BSpec: 7530, 799 and 7532
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c  | 38
> > > ++
> > >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> > >  drivers/gpu/drm/i915/intel_psr.c |  8 
> > >  3 files changed, 48 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 62f82c4298ac..fedee4e7ed24 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -1062,6 +1062,41 @@ static uint32_t
> > > skl_get_aux_send_ctl(struct intel_dp *intel_dp,
> > >  DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> > >  }
> > >  
> > > +/**
> > > + * intel_dp_aux_ch_get - Get total control of aux ch registers
> > > + *
> > > + * By exiting or disabling any hardware feature that can also
> > > use the aux ch
> > > + * registers at the same time as driver, this function will give
> > > total control
> > > + * of aux ch registers to driver.
> > > + */
> > > +static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
> > > +{
> > > + if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > > + return;
> > > +
> > > + intel_psr_activate_block_get(intel_dp);
> > > + intel_psr_exit(intel_dp, true);
> > 
> > decision on exit and activate should be inside the block_get and
> > block_put,
> > based on current state of the counters.
> > 
> 
> I haven't read the patches yet, but you could use the kref
> infrastructure for 
> reference counting.

Cool I will use it, thanks.

> 
> > > +}
> > > +
> > > +/**
> > > + * intel_dp_aux_ch_put - Release aux ch registers control
> > > + *
> > > + * It is the intel_dp_aux_ch_get() counterpart.
> > > + */
> > > +static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
> > > +{
> > > + if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > > + return;
> > > +
> > > + intel_psr_activate_block_put(intel_dp);
> > > + /* Usually more than just one aux ch transaction is
> > > executed when
> > > +  * handling some event, activating PSR right way would
> > > cause several
> > > +  * msecs of delay waiting PSR to exit for each aux ch
> > > transaction, so
> > > +  * here asking it to be scheduled.
> > > +  */
> > > + intel_psr_activate(intel_dp, true);
> > > +}
> > > +
> > >  static int
> > >  intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > > const uint8_t *send, int send_bytes,
> > > @@ -1101,6 +1136,8 @@ intel_dp_aux_xfer(struct intel_dp
> > > *intel_dp,
> > >  
> > >   intel_dp_check_edp(intel_dp);
> > >  
> > > + intel_dp_aux_ch_get(intel_dp);
> > > +
> > >   /* Try to wait for any previous AUX channel activity */
> > >   for (try = 0; try < 3; try++) {
> > >   status = I915_READ_NOTRACE(ch_ctl);
> > > @@ -1223,6 +1260,7 @@ intel_dp_aux_xfer(struct intel_dp
> > > *intel_dp,
> > >  
> > >   ret = recv_bytes;
> > >  out:
> > > + intel_dp_aux_ch_put(intel_dp);
> > >   pm_qos_update_request(_priv->pm_qos,
> > > PM_QOS_DEFAULT_VALUE);
> > >  
> > >   if (vdd)
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 020b96324135..177478f0b032 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1139,6 +1139,8 @@ struct intel_dp {
> > >  
> > >   /* Displayport compliance testing */
> > >   struct intel_dp_compliance compliance;
> > > +
> > > + bool exit_psr_on_aux_ch_xfer;
> > >  };
> > >  
> > >  struct intel_lspcon {
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 8702dbafb42d..f88f12246a23 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -665,6 +665,13 @@ void intel_psr_enable(struct intel_dp
> > > *intel_dp,
> > > msecs_to_jiffies(intel_dp-
> > > >panel_power_cycle_delay * 5));
> > >   }
> > > 

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

2018-04-02 Thread Souza, Jose
On Mon, 2018-04-02 at 12:00 -0700, Pandiyan, Dhinakaran wrote:
> 
> 
> On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza
> > wrote:
> > > When PSR/PSR2 is enabled hardware can do aux ch transactions by
> > > it
> > > self.
> > > Spec requires that PSR is inactive before do any aux ch
> > > transaction
> > > in HSW and BDW, for skl+ there is a aux ch mutex but the use is
> > > not
> > > recommended.
> > > So exiting PSR/PSR2 and waiting the transition to inactive to
> > > prevent
> > > any concurrent access between hardware and software in aux ch
> > > registers.
> 
> Wouldn't the debugfs interface that you added to read sink PSR status
> always show PSR as disabled? Or do you intend to set
> intel_dp->exit_psr_on_aux_ch_xfer = true? 

Yeah it will always be disabled, unless when the hack in 'drm/i915:
Keep IGT PSR and frontbuffer tests functional' is set, Rodrigo asked to
remove the debugfs file that was controlling the state of the hack and
enable/disable it around CRC read so I could do that for the whole
i915_edp_psr_status too.

> 
> 
> > > 
> > > VLV and CHV hardware don't do any aux as software is responsible
> > > to
> > > do all the buffer tracking and it sends the wake up aux ch
> > > message
> > > to sink.
> > > 
> > 
> > ahh cool... I get back what I said on some previous patch.
> > I like where it is going, but...
> > 
> > > BSpec: 7530, 799 and 7532
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c  | 38
> > > ++
> > >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> > >  drivers/gpu/drm/i915/intel_psr.c |  8 
> > >  3 files changed, 48 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 62f82c4298ac..fedee4e7ed24 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -1062,6 +1062,41 @@ static uint32_t
> > > skl_get_aux_send_ctl(struct intel_dp *intel_dp,
> > >  DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> > >  }
> > >  
> > > +/**
> > > + * intel_dp_aux_ch_get - Get total control of aux ch registers
> > > + *
> > > + * By exiting or disabling any hardware feature that can also
> > > use the aux ch
> > > + * registers at the same time as driver, this function will give
> > > total control
> > > + * of aux ch registers to driver.
> > > + */
> > > +static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
> > > +{
> > > + if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > > + return;
> > > +
> > > + intel_psr_activate_block_get(intel_dp);
> > > + intel_psr_exit(intel_dp, true);
> > 
> > decision on exit and activate should be inside the block_get and
> > block_put,
> > based on current state of the counters.
> > 
> > > +}
> > > +
> > > +/**
> > > + * intel_dp_aux_ch_put - Release aux ch registers control
> > > + *
> > > + * It is the intel_dp_aux_ch_get() counterpart.
> > > + */
> > > +static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
> > > +{
> > > + if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > > + return;
> > > +
> > > + intel_psr_activate_block_put(intel_dp);
> > > + /* Usually more than just one aux ch transaction is
> > > executed when
> > > +  * handling some event, activating PSR right way would
> > > cause several
> > > +  * msecs of delay waiting PSR to exit for each aux ch
> > > transaction, so
> > > +  * here asking it to be scheduled.
> > > +  */
> > > + intel_psr_activate(intel_dp, true);
> > > +}
> > > +
> > >  static int
> > >  intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > > const uint8_t *send, int send_bytes,
> > > @@ -1101,6 +1136,8 @@ intel_dp_aux_xfer(struct intel_dp
> > > *intel_dp,
> > >  
> > >   intel_dp_check_edp(intel_dp);
> > >  
> > > + intel_dp_aux_ch_get(intel_dp);
> > > +
> > >   /* Try to wait for any previous AUX channel activity */
> > >   for (try = 0; try < 3; try++) {
> > >   status = I915_READ_NOTRACE(ch_ctl);
> > > @@ -1223,6 +1260,7 @@ intel_dp_aux_xfer(struct intel_dp
> > > *intel_dp,
> > >  
> > >   ret = recv_bytes;
> > >  out:
> > > + intel_dp_aux_ch_put(intel_dp);
> > >   pm_qos_update_request(_priv->pm_qos,
> > > PM_QOS_DEFAULT_VALUE);
> > >  
> > >   if (vdd)
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 020b96324135..177478f0b032 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1139,6 +1139,8 @@ struct intel_dp {
> > >  
> > >   /* Displayport compliance testing */
> > >   struct intel_dp_compliance compliance;
> > > +
> > > + bool exit_psr_on_aux_ch_xfer;
> > >  };
> > >  
> > >  struct intel_lspcon {
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > 

Re: [Intel-gfx] [PATCH 06/11] drm/i915/psr: Add intel_psr_activate_block_get()/put()

2018-04-02 Thread Souza, Jose
On Mon, 2018-04-02 at 11:20 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:31PM -0700, José Roberto de Souza
> wrote:
> > intel_psr_activate_block_get() should be called when by some reason
> > PSR should not be activated for some time, it will increment
> > counter
> > and it should the decremented by intel_psr_activate_block_put()
> > when PSR can be activated again.
> > intel_psr_activate_block_put() will not actually activate PSR,
> > users
> > of this function should also call intel_psr_activate().
> 
> Ohh cool! you made the counter.
> probably we will need to change things from mutex to spin locker.
> But also the blocker functions here could already introduce the
> function
> calls to really block and release psr.

Oh so drop the 'drm/i915/psr: Export intel_psr_activate/exit()' and
call PSR exit and activate from intel_psr_activate_block_get()/put()?

I dind't understand why you want to change struct mutex lock; to
spinlock_t?

> 
> > 
> > Signed-off-by: José Roberto de Souza 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c | 54
> > 
> >  3 files changed, 57 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 99af9169d792..41ebb144594e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -609,6 +609,7 @@ struct i915_psr {
> > bool has_hw_tracking;
> > bool psr2_enabled;
> > u8 sink_sync_latency;
> > +   unsigned int activate_block_count;
> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 70026b772721..020b96324135 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1893,6 +1893,8 @@ void intel_psr_compute_config(struct intel_dp
> > *intel_dp,
> >   struct intel_crtc_state
> > *crtc_state);
> >  void intel_psr_exit(struct intel_dp *intel_dp, bool wait_idle);
> >  void intel_psr_activate(struct intel_dp *intel_dp, bool schedule);
> > +void intel_psr_activate_block_get(struct intel_dp *intel_dp);
> > +void intel_psr_activate_block_put(struct intel_dp *intel_dp);
> >  
> >  /* intel_runtime_pm.c */
> >  int intel_power_domains_init(struct drm_i915_private *);
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 906a12ea934d..8702dbafb42d 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -558,6 +558,8 @@ static void __intel_psr_activate(struct
> > intel_dp *intel_dp)
> >  
> > WARN_ON(dev_priv->psr.active);
> > lockdep_assert_held(_priv->psr.lock);
> > +   if (dev_priv->psr.activate_block_count)
> > +   return;
> >  
> > dev_priv->psr.activate(intel_dp);
> > dev_priv->psr.active = true;
> > @@ -1188,3 +1190,55 @@ void intel_psr_activate(struct intel_dp
> > *intel_dp, bool schedule)
> >  out:
> > mutex_unlock(_priv->psr.lock);
> >  }
> > +
> > +/**
> > + * intel_psr_activate_block_get - Block further attempts to
> > activate PSR
> > + * @intel_dp: DisplayPort that have PSR enabled
> > + *
> > + * It have a internal reference count, so each
> > intel_psr_activate_block_get()
> > + * should have a intel_psr_activate_block_put() counterpart.
> > + */
> > +void intel_psr_activate_block_get(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);
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return;
> > +
> > +   mutex_lock(_priv->psr.lock);
> > +   if (dev_priv->psr.enabled != intel_dp)
> > +   goto out;
> > +
> > +   dev_priv->psr.activate_block_count++;
> > +out:
> > +   mutex_unlock(_priv->psr.lock);
> > +}
> > +
> > +
> > +/**
> > + * intel_psr_activate_block_put - Unblock further attempts to
> > activate PSR
> > + * @intel_dp: DisplayPort that have PSR enabled
> > + *
> > + * Decrease the reference counter incremented by
> > intel_psr_activate_block_get()
> > + * when zero it allows PSR be activate. To actually activate PSR
> > when reference
> > + * counter is zero intel_psr_activate() should be called.
> > + */
> > +void intel_psr_activate_block_put(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);
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return;
> > +
> > +   mutex_lock(_priv->psr.lock);
> > + 

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status

2018-04-02 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status
URL   : https://patchwork.freedesktop.org/series/41022/
State : warning

== Summary ==

 Possible new issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-top-edge:
pass   -> SKIP   (shard-snb)
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
dmesg-warn -> PASS   (shard-snb)

 Known issues:

Test gem_softpin:
Subgroup noreloc-s3:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
dmesg-fail -> PASS   (shard-apl) fdo#104727
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-c-planes:
pass   -> INCOMPLETE (shard-hsw) fdo#103375

fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#104727 https://bugs.freedesktop.org/show_bug.cgi?id=104727
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:3495 pass:1831 dwarn:1   dfail:0   fail:7   skip:1655 
time:12912s
shard-hswtotal:3493 pass:1780 dwarn:1   dfail:0   fail:1   skip:1709 
time:10871s
shard-snbtotal:3495 pass:1373 dwarn:1   dfail:0   fail:3   skip:2118 
time:6990s
Blacklisted hosts:
shard-kbltotal:3495 pass:1958 dwarn:1   dfail:1   fail:7   skip:1528 
time:9294s

== Logs ==

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


[Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

2018-04-02 Thread Lyude Paul
While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to continue handling aux
transactions even when none of the sinks are turned on since it's
possible for us to have a single atomic commit which results in
disabling each downstream sink, followed by subsequently re-enabling
each sink.

If we don't do this, we'll end up stalling any pending ESI interrupts
from the sink for up to 1ms. Unfortunately, dropping ESIs during this
timespan makes it so that link fallback retraining for MST (which I will
be submitting to the ML shortly) fails due to the channel EQ failure
interrupts potentially getting dropped. Additionally, when performing a
modeset that brings the hub status's link status from bad -> good having
ESIs disabled for that long causes us to miss the hub's response to us
trying to start link training as well.

Since any sink with MST is going to support DisplayPort 1.2 anyway, save
us the hassle of trying to wait until the sink comes back up and just
never shut the aux block down.

Changes since v2:
 - Fix patch name, no functional changes

Signed-off-by: Lyude Paul 
Cc: Laura Abbott 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
 drivers/gpu/drm/i915/intel_dp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..0479c377981b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode)
return;
 
if (mode != DRM_MODE_DPMS_ON) {
+   unsigned char data = intel_dp->is_mst ?
+   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
+
if (downstream_hpd_needs_d0(intel_dp))
return;
 
-   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
-DP_SET_POWER_D3);
+   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
 
-- 
2.14.3

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


[Intel-gfx] [PATCH] i915/dp_mst: Keep AUX block running when disabling DPMS

2018-04-02 Thread Lyude Paul
While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to continue handling aux
transactions even when none of the sinks are turned on since it's
possible for us to have a single atomic commit which results in
disabling each downstream sink, followed by subsequently re-enabling
each sink.

If we don't do this, we'll end up stalling any pending ESI interrupts
from the sink for up to 1ms. Unfortunately, dropping ESIs during this
timespan makes it so that link fallback retraining for MST (which I will
be submitting to the ML shortly) fails due to the channel EQ failure
interrupts potentially getting dropped. Additionally, when performing a
modeset that brings the hub status's link status from bad -> good having
ESIs disabled for that long causes us to miss the hub's response to us
trying to start link training as well.

Since any sink with MST is going to support DisplayPort 1.2 anyway, save
us the hassle of trying to wait until the sink comes back up and just
never shut the aux block down.

Signed-off-by: Lyude Paul 
Cc: Laura Abbott 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
 drivers/gpu/drm/i915/intel_dp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..0479c377981b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode)
return;
 
if (mode != DRM_MODE_DPMS_ON) {
+   unsigned char data = intel_dp->is_mst ?
+   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
+
if (downstream_hpd_needs_d0(intel_dp))
return;
 
-   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
-DP_SET_POWER_D3);
+   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
 
-- 
2.14.3

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status

2018-04-02 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status
URL   : https://patchwork.freedesktop.org/series/41022/
State : success

== Summary ==

Series 41022v1 series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR 
status
https://patchwork.freedesktop.org/api/1.0/series/41022/revisions/1/mbox/

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:378s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:541s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:296s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:518s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:521s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:509s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:510s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:422s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:320s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:467s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:470s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:670s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:502s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:513s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:430s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:443s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:597s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:255  dwarn:3   dfail:0   fail:1   skip:26  
time:527s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s

c46052cde6a50c5459e00791ffc4d5aa1ec58a9e drm-tip: 2018y-03m-30d-18h-56m-26s UTC 
integration manifest
4c3d5eaa3722 drm/i915/psr/cnl: Set y-coordinate as valid in SDP
b029e056dae9 drm/i915/debugfs: Print sink PSR status

== Logs ==

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


Re: [Intel-gfx] [PATCH 03/11] drm/i915/psr: Share code between disable and exit

2018-04-02 Thread Souza, Jose
On Mon, 2018-04-02 at 11:11 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:28PM -0700, José Roberto de Souza
> wrote:
> > The disable and exit sequence are very similar with a lot common
> > code between both, so here sharing the code.
> 
> I don't believe that we should do this.
> Disable as is has some extra wait/timeouts that could slow things
> down.
> 
> Or at least not do this while we don't have a proper robuts test in
> place
> and to test also performance impacts...

When the disabling argument is false it don't have the disable
wait/timeouts, I kept the same behavior to both just sharing the common
part.

> 
> > 
> > Signed-off-by: José Roberto de Souza 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
> >  drivers/gpu/drm/i915/intel_psr.c | 84 ++
> > --
> >  2 files changed, 38 insertions(+), 48 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index a8d300280a2c..cb72ee27422f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -617,7 +617,7 @@ struct i915_psr {
> > void (*enable_sink)(struct intel_dp *);
> > void (*activate)(struct intel_dp *);
> > void (*setup_vsc)(struct intel_dp *, const struct
> > intel_crtc_state *);
> > -   void (*exit)(struct intel_dp *intel_dp);
> > +   void (*exit)(struct intel_dp *intel_dp, bool disabling);
> >  };
> >  
> >  enum intel_pch {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index bcaac9e69f8c..d3451afeb8bb 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -672,23 +672,9 @@ static void vlv_psr_disable(struct intel_dp
> > *intel_dp,
> > struct drm_device *dev = intel_dig_port->base.base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> > >base.crtc);
> > -   uint32_t val;
> >  
> > if (dev_priv->psr.active) {
> > -   /* Put VLV PSR back to PSR_state 0 (disabled). */
> > -   if (intel_wait_for_register(dev_priv,
> > -   VLV_PSRSTAT(crtc-
> > >pipe),
> > -   VLV_EDP_PSR_IN_TRANS,
> > -   0,
> > -   1))
> > -   WARN(1, "PSR transition took longer than
> > expected\n");
> > -
> > -   val = I915_READ(VLV_PSRCTL(crtc->pipe));
> > -   val &= ~VLV_EDP_PSR_ACTIVE_ENTRY;
> > -   val &= ~VLV_EDP_PSR_ENABLE;
> > -   val &= ~VLV_EDP_PSR_MODE_MASK;
> > -   I915_WRITE(VLV_PSRCTL(crtc->pipe), val);
> > -
> > +   dev_priv->psr.exit(intel_dp, true);
> > dev_priv->psr.active = false;
> > } else {
> > WARN_ON(vlv_is_psr_active_on_pipe(dev, crtc-
> > >pipe));
> > @@ -703,31 +689,7 @@ static void hsw_psr_disable(struct intel_dp
> > *intel_dp,
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >  
> > if (dev_priv->psr.active) {
> > -   i915_reg_t psr_status;
> > -   u32 psr_status_mask;
> > -
> > -   if (dev_priv->psr.psr2_enabled) {
> > -   psr_status = EDP_PSR2_STATUS;
> > -   psr_status_mask =
> > EDP_PSR2_STATUS_STATE_MASK;
> > -
> > -   I915_WRITE(EDP_PSR2_CTL,
> > -  I915_READ(EDP_PSR2_CTL) &
> > -  ~(EDP_PSR2_ENABLE |
> > EDP_SU_TRACK_ENABLE));
> > -
> > -   } else {
> > -   psr_status = EDP_PSR_STATUS;
> > -   psr_status_mask =
> > EDP_PSR_STATUS_STATE_MASK;
> > -
> > -   I915_WRITE(EDP_PSR_CTL,
> > -  I915_READ(EDP_PSR_CTL) &
> > ~EDP_PSR_ENABLE);
> > -   }
> > -
> > -   /* Wait till PSR is idle */
> > -   if (intel_wait_for_register(dev_priv,
> > -   psr_status,
> > psr_status_mask, 0,
> > -   2000))
> > -   DRM_ERROR("Timed out waiting for PSR Idle
> > State\n");
> > -
> > +   dev_priv->psr.exit(intel_dp, true);
> > dev_priv->psr.active = false;
> > } else {
> > if (dev_priv->psr.psr2_enabled)
> > @@ -838,25 +800,41 @@ static void intel_psr_work(struct work_struct
> > *work)
> > mutex_unlock(_priv->psr.lock);
> >  }
> >  
> > -static void hsw_psr_exit(struct intel_dp *intel_dp)
> > +static void hsw_psr_exit(struct intel_dp *intel_dp, bool
> > disabling)
> >  {
> > 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);
> > +   i915_reg_t 

[Intel-gfx] [PATCH v2 1/2] drm/i915/debugfs: Print sink PSR status

2018-04-02 Thread José Roberto de Souza
IGT tests could be improved with sink status, knowing for sure that
hardware have activate or exit PSR.

Reviewed-by: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1dba2c451255..c9ac946b62c9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
return "unknown";
 }
 
+static const char *psr_sink_status(u8 val)
+{
+   static const char * const sink_status[] = {
+   "inactive",
+   "transition to active, capture and display",
+   "active, display from RFB",
+   "active, capture and display on sink device timings",
+   "transition to inactive, capture and display, timing re-sync",
+   "reserved",
+   "reserved",
+   "sink internal error"
+   };
+
+   val &= DP_PSR_SINK_STATE_MASK;
+   if (val < ARRAY_SIZE(sink_status))
+   return sink_status[val];
+
+   return "unknown";
+}
+
 static int i915_edp_psr_status(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
   psr2, psr2_live_status(psr2));
}
+
+   if (dev_priv->psr.enabled) {
+   struct drm_dp_aux *aux = _priv->psr.enabled->aux;
+   u8 val;
+
+   if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, ) == 1)
+   seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val,
+  psr_sink_status(val));
+   }
mutex_unlock(_priv->psr.lock);
 
intel_runtime_pm_put(dev_priv);
-- 
2.16.3

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


[Intel-gfx] [PATCH v2 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

2018-04-02 Thread José Roberto de Souza
This was my bad, spec says that the name of this bit is
'Y-coordinate valid' but the values for it is:
0: Include Y-coordinate valid eDP1.4a
1: Do not include Y-coordinate valid eDP 1.4
So not setting it.

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

Changelog:
v2: Not renaming EDP_Y_COORDINATE_VALID

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

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2d53f7398a6d..f12111438bcf 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -400,9 +400,8 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
-   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
-   val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
-   }
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+   val |= EDP_Y_COORDINATE_ENABLE;
 
val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
 
-- 
2.16.3

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


Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

2018-04-02 Thread Pandiyan, Dhinakaran



On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote:
> > When PSR/PSR2 is enabled hardware can do aux ch transactions by it
> > self.
> > Spec requires that PSR is inactive before do any aux ch transaction
> > in HSW and BDW, for skl+ there is a aux ch mutex but the use is not
> > recommended.
> > So exiting PSR/PSR2 and waiting the transition to inactive to prevent
> > any concurrent access between hardware and software in aux ch
> > registers.

Wouldn't the debugfs interface that you added to read sink PSR status
always show PSR as disabled? Or do you intend to set
intel_dp->exit_psr_on_aux_ch_xfer = true? 


> > 
> > VLV and CHV hardware don't do any aux as software is responsible to
> > do all the buffer tracking and it sends the wake up aux ch message
> > to sink.
> >
> 
> ahh cool... I get back what I said on some previous patch.
> I like where it is going, but...
> 
> > BSpec: 7530, 799 and 7532
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 38 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c |  8 
> >  3 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 62f82c4298ac..fedee4e7ed24 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1062,6 +1062,41 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
> > *intel_dp,
> >DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> >  }
> >  
> > +/**
> > + * intel_dp_aux_ch_get - Get total control of aux ch registers
> > + *
> > + * By exiting or disabling any hardware feature that can also use the aux 
> > ch
> > + * registers at the same time as driver, this function will give total 
> > control
> > + * of aux ch registers to driver.
> > + */
> > +static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
> > +{
> > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > +   return;
> > +
> > +   intel_psr_activate_block_get(intel_dp);
> > +   intel_psr_exit(intel_dp, true);
> 
> decision on exit and activate should be inside the block_get and block_put,
> based on current state of the counters.
> 
> > +}
> > +
> > +/**
> > + * intel_dp_aux_ch_put - Release aux ch registers control
> > + *
> > + * It is the intel_dp_aux_ch_get() counterpart.
> > + */
> > +static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
> > +{
> > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > +   return;
> > +
> > +   intel_psr_activate_block_put(intel_dp);
> > +   /* Usually more than just one aux ch transaction is executed when
> > +* handling some event, activating PSR right way would cause several
> > +* msecs of delay waiting PSR to exit for each aux ch transaction, so
> > +* here asking it to be scheduled.
> > +*/
> > +   intel_psr_activate(intel_dp, true);
> > +}
> > +
> >  static int
> >  intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >   const uint8_t *send, int send_bytes,
> > @@ -1101,6 +1136,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >  
> > intel_dp_check_edp(intel_dp);
> >  
> > +   intel_dp_aux_ch_get(intel_dp);
> > +
> > /* Try to wait for any previous AUX channel activity */
> > for (try = 0; try < 3; try++) {
> > status = I915_READ_NOTRACE(ch_ctl);
> > @@ -1223,6 +1260,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >  
> > ret = recv_bytes;
> >  out:
> > +   intel_dp_aux_ch_put(intel_dp);
> > pm_qos_update_request(_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
> >  
> > if (vdd)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 020b96324135..177478f0b032 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1139,6 +1139,8 @@ struct intel_dp {
> >  
> > /* Displayport compliance testing */
> > struct intel_dp_compliance compliance;
> > +
> > +   bool exit_psr_on_aux_ch_xfer;
> >  };
> >  
> >  struct intel_lspcon {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 8702dbafb42d..f88f12246a23 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -665,6 +665,13 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> >   
> > msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
> > }
> >  
> > +   /* From all platforms that supports PSR/PSR2 this 2 is the ones that
> > +* don't have restrictions about use of the aux ch while PSR/PSR2 is
> > +* enabled.
> > +*/
> > +   if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> > +   intel_dp->exit_psr_on_aux_ch_xfer = 

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

2018-04-02 Thread Pandiyan, Dhinakaran



On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote:
> > When PSR/PSR2 is enabled hardware can do aux ch transactions by it
> > self.
> > Spec requires that PSR is inactive before do any aux ch transaction
> > in HSW and BDW, for skl+ there is a aux ch mutex but the use is not
> > recommended.
> > So exiting PSR/PSR2 and waiting the transition to inactive to prevent
> > any concurrent access between hardware and software in aux ch
> > registers.
> > 
> > VLV and CHV hardware don't do any aux as software is responsible to
> > do all the buffer tracking and it sends the wake up aux ch message
> > to sink.
> >
> 
> ahh cool... I get back what I said on some previous patch.
> I like where it is going, but...
> 
> > BSpec: 7530, 799 and 7532
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 38 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c |  8 
> >  3 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 62f82c4298ac..fedee4e7ed24 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1062,6 +1062,41 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
> > *intel_dp,
> >DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> >  }
> >  
> > +/**
> > + * intel_dp_aux_ch_get - Get total control of aux ch registers
> > + *
> > + * By exiting or disabling any hardware feature that can also use the aux 
> > ch
> > + * registers at the same time as driver, this function will give total 
> > control
> > + * of aux ch registers to driver.
> > + */
> > +static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
> > +{
> > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > +   return;
> > +
> > +   intel_psr_activate_block_get(intel_dp);
> > +   intel_psr_exit(intel_dp, true);
> 
> decision on exit and activate should be inside the block_get and block_put,
> based on current state of the counters.
> 

I haven't read the patches yet, but you could use the kref infrastructure for 
reference counting.

> > +}
> > +
> > +/**
> > + * intel_dp_aux_ch_put - Release aux ch registers control
> > + *
> > + * It is the intel_dp_aux_ch_get() counterpart.
> > + */
> > +static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
> > +{
> > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > +   return;
> > +
> > +   intel_psr_activate_block_put(intel_dp);
> > +   /* Usually more than just one aux ch transaction is executed when
> > +* handling some event, activating PSR right way would cause several
> > +* msecs of delay waiting PSR to exit for each aux ch transaction, so
> > +* here asking it to be scheduled.
> > +*/
> > +   intel_psr_activate(intel_dp, true);
> > +}
> > +
> >  static int
> >  intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >   const uint8_t *send, int send_bytes,
> > @@ -1101,6 +1136,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >  
> > intel_dp_check_edp(intel_dp);
> >  
> > +   intel_dp_aux_ch_get(intel_dp);
> > +
> > /* Try to wait for any previous AUX channel activity */
> > for (try = 0; try < 3; try++) {
> > status = I915_READ_NOTRACE(ch_ctl);
> > @@ -1223,6 +1260,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >  
> > ret = recv_bytes;
> >  out:
> > +   intel_dp_aux_ch_put(intel_dp);
> > pm_qos_update_request(_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
> >  
> > if (vdd)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 020b96324135..177478f0b032 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1139,6 +1139,8 @@ struct intel_dp {
> >  
> > /* Displayport compliance testing */
> > struct intel_dp_compliance compliance;
> > +
> > +   bool exit_psr_on_aux_ch_xfer;
> >  };
> >  
> >  struct intel_lspcon {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 8702dbafb42d..f88f12246a23 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -665,6 +665,13 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> >   
> > msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
> > }
> >  
> > +   /* From all platforms that supports PSR/PSR2 this 2 is the ones that
> > +* don't have restrictions about use of the aux ch while PSR/PSR2 is
> > +* enabled.
> > +*/
> > +   if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> > +   intel_dp->exit_psr_on_aux_ch_xfer = true;
> > +
> >  unlock:
> > mutex_unlock(_priv->psr.lock);
> >  }
> 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

2018-04-02 Thread Rodrigo Vivi
On Mon, Apr 02, 2018 at 10:42:23AM -0700, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Sat, 2018-03-31 at 00:17 +, Souza, Jose wrote:
> > On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote:
> > > On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> > > > This was my bad, spec says that the name of this bit is
> > > > 'Y-coordinate valid' but the values for it is:
> > > > 0: Include Y-coordinate valid eDP1.4a
> > > > 1: Do not include Y-coordinate valid eDP 1.4
> > > > So renaming the bit and not setting it.
> > > > 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_reg.h  | 2 +-
> > > >  drivers/gpu/drm/i915/intel_psr.c | 5 ++---
> > > >  2 files changed, 3 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 176dca6554f4..19429cb1f3a7 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -4058,7 +4058,7 @@ enum {
> > > >  #define EDP_PSR2_CTL   _MMIO(0x6f900)
> > > >  #define   EDP_PSR2_ENABLE  (1<<31)
> > > >  #define   EDP_SU_TRACK_ENABLE  (1<<30)
> > > > -#define   EDP_Y_COORDINATE_VALID   (1<<26) /* GLK and CNL+ */
> > > > +#define   EDP_Y_COORDINATE_INVALID (1<<26) /* GLK and CNL+
> > > > */
> > > 
> > > INVALID isn't the same as asking the source to not send the y-
> > > coordinate
> > > valid bit. Sorry to be pedantic, please leave the definition as it
> > > is.
> > 
> > I agree with you, if it don't need to send the y-coordinate is
> > better just not set EDP_Y_COORDINATE_ENABLE but leave the bit
> > definition name as it is, is prone to others do the same error as I
> > did.
> > 
> 
> I'll let Rodrigo take a call on this one.

I agree with DK.

Please use the spec name, i.e. "BitField: Y-coordinate valid"

"invalid" will actually bring even more confusion.

> 
> -DK
> 
> > > 
> > > Reviewed-by: Dhinakaran Pandiyan  if
> > > you
> > > remove this hunk.
> > > 
> > > >  #define   EDP_Y_COORDINATE_ENABLE  (1<<25) /* GLK and CNL+
> > > > */
> > > >  #define   EDP_MAX_SU_DISABLE_TIME(t)   ((t)<<20)
> > > >  #define   EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 2d53f7398a6d..f12111438bcf 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -400,9 +400,8 @@ static void hsw_activate_psr2(struct intel_dp
> > > > *intel_dp)
> > > >  * mesh at all with our frontbuffer tracking. And the hw
> > > > alone isn't
> > > >  * good enough. */
> > > > val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > > > -   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > > > {
> > > > -   val |= EDP_Y_COORDINATE_VALID |
> > > > EDP_Y_COORDINATE_ENABLE;
> > > > -   }
> > > > +   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > > > +   val |= EDP_Y_COORDINATE_ENABLE;
> > > >  
> > > > val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv-
> > > > >psr.sink_sync_latency + 1);
> > > >  
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 09/11] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink

2018-04-02 Thread Rodrigo Vivi
On Fri, Mar 30, 2018 at 03:23:34PM -0700, José Roberto de Souza wrote:
> eDP spec states that sink device will do a short pulse in HPD
> line when there is a PSR/PSR2 error that needs to be handled by
> source, this is handling the first and most simples error:
> DP_PSR_SINK_INTERNAL_ERROR.
> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 31 +++
>  3 files changed, 34 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c655f6c08a02..fc8b86bc0120 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4518,6 +4518,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>   if (intel_dp_needs_link_retrain(intel_dp))
>   return false;
>  
> + intel_psr_hpd_short_pulse_handle(intel_dp);
> +
>   if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
>   DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
>   /* Send a Hotplug Uevent to userspace to start modeset */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 177478f0b032..d4c7e1e0fb86 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1897,6 +1897,7 @@ void intel_psr_exit(struct intel_dp *intel_dp, bool 
> wait_idle);
>  void intel_psr_activate(struct intel_dp *intel_dp, bool schedule);
>  void intel_psr_activate_block_get(struct intel_dp *intel_dp);
>  void intel_psr_activate_block_put(struct intel_dp *intel_dp);
> +void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp);
>  
>  /* intel_runtime_pm.c */
>  int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index f88f12246a23..85d201fce287 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -1250,3 +1250,34 @@ void intel_psr_activate_block_put(struct intel_dp 
> *intel_dp)
>  out:
>   mutex_unlock(_priv->psr.lock);
>  }
> +
> +void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct i915_psr *psr = _priv->psr;
> + uint8_t val;
> +
> + if (!HAS_PSR(dev_priv))
> + return;
> +
> + mutex_lock(>lock);
> + if (psr->enabled != intel_dp)
> + goto out;
> +
> + if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, ) != 1) {
> + DRM_DEBUG_KMS("PSR_STATUS read failed\n");
> + goto dpcd_read_error;
> + }
> +
> + if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR)
> + __intel_psr_exit(dev_priv);

shouldn't we add a debug msg here?

> +
> + /* TODO: handle other PSR/PSR2 errors */
> +dpcd_read_error:
> + if (!dev_priv->psr.busy_frontbuffer_bits)
> + __intel_psr_activate(intel_dp);
> +out:
> + mutex_unlock(>lock);
> +}
> -- 
> 2.16.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 08/11] drm/i915: Keep IGT PSR and frontbuffer tests functional

2018-04-02 Thread Rodrigo Vivi
On Fri, Mar 30, 2018 at 03:23:33PM -0700, José Roberto de Souza wrote:
> 'drm/i915/dp: Exit PSR before do a aux channel transaction' cause all
> IGT PSR and frontbuffer tracking tests to not be userful.
> Those tests depend in reading the calculated CRC value of the
> frontbuffer in sink and doing a aux transaction now causes the PSR
> to exit.
> So any bug in software and hardware buffer tracking will be masked by
> this forced PSR exit.
> 
> This is a dirty workaround that makes those tests functional again
> at the risk of causing concurrent access in the aux ch registers
> while running_igt_psr_tests is set.
> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_dp.c | 18 ++
>  3 files changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1dba2c451255..519f67598d44 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4732,6 +4732,27 @@ static int i915_drrs_ctl_set(void *data, u64 val)
>  
>  DEFINE_SIMPLE_ATTRIBUTE(i915_drrs_ctl_fops, NULL, i915_drrs_ctl_set, 
> "%llu\n");
>  
> +static int i915_running_igt_psr_tests_get(void *data, u64 *val)
> +{
> + struct drm_i915_private *dev_priv = data;
> +
> + *val = dev_priv->running_igt_psr_tests;
> + return 0;
> +}
> +
> +static int i915_running_igt_psr_tests_set(void *data, u64 val)
> +{
> + struct drm_i915_private *dev_priv = data;
> +
> + dev_priv->running_igt_psr_tests = !!val;
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_running_igt_psr_tests_fops,
> + i915_running_igt_psr_tests_get,
> + i915_running_igt_psr_tests_set,
> + "%llu\n");
> +
>  static const struct drm_info_list i915_debugfs_list[] = {
>   {"i915_capabilities", i915_capabilities, 0},
>   {"i915_gem_objects", i915_gem_object_info, 0},
> @@ -4812,7 +4833,8 @@ static const struct i915_debugfs_files {
>   {"i915_guc_log_relay", _guc_log_relay_fops},
>   {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
>   {"i915_ipc_status", _ipc_status_fops},
> - {"i915_drrs_ctl", _drrs_ctl_fops}
> + {"i915_drrs_ctl", _drrs_ctl_fops},
> + {"i915_running_igt_psr_tests", _running_igt_psr_tests_fops}

we don't need new ops. All we want is to block the exit when running
sink_crc tests, so add the blocker wa there...

>  };
>  
>  int i915_debugfs_register(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 41ebb144594e..9e0a5e29f48e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2110,6 +2110,8 @@ struct drm_i915_private {
>  
>   struct i915_pmu pmu;
>  
> + bool running_igt_psr_tests;
> +
>   /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fedee4e7ed24..c655f6c08a02 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1071,8 +1071,20 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
> *intel_dp,
>   */
>  static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
>  {
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> +
>   if (!intel_dp->exit_psr_on_aux_ch_xfer)
>   return;
> + /*
> +  * HACK: This is a workaround to keep IGT PSR and frontbuffer tracking
> +  * tests functional, otherwise when IGT request the CRC of the
> +  * frontbuffer to sink it would cause this function to complete execute
> +  * and exit PSR.
> +  */
> + if (dev_priv->running_igt_psr_tests)
> + return;
>  
>   intel_psr_activate_block_get(intel_dp);
>   intel_psr_exit(intel_dp, true);
> @@ -1085,8 +1097,14 @@ static void intel_dp_aux_ch_get(struct intel_dp 
> *intel_dp)
>   */
>  static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
>  {
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> +
>   if (!intel_dp->exit_psr_on_aux_ch_xfer)
>   return;
> + if (dev_priv->running_igt_psr_tests)
> + return;
>  
>   intel_psr_activate_block_put(intel_dp);
>   /* Usually more than just one aux ch transaction is executed when
> -- 
> 2.16.3
> 

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

2018-04-02 Thread Rodrigo Vivi
On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote:
> When PSR/PSR2 is enabled hardware can do aux ch transactions by it
> self.
> Spec requires that PSR is inactive before do any aux ch transaction
> in HSW and BDW, for skl+ there is a aux ch mutex but the use is not
> recommended.
> So exiting PSR/PSR2 and waiting the transition to inactive to prevent
> any concurrent access between hardware and software in aux ch
> registers.
> 
> VLV and CHV hardware don't do any aux as software is responsible to
> do all the buffer tracking and it sends the wake up aux ch message
> to sink.
>

ahh cool... I get back what I said on some previous patch.
I like where it is going, but...

> BSpec: 7530, 799 and 7532
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 38 ++
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_psr.c |  8 
>  3 files changed, 48 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4298ac..fedee4e7ed24 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1062,6 +1062,41 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
> *intel_dp,
>  DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
>  }
>  
> +/**
> + * intel_dp_aux_ch_get - Get total control of aux ch registers
> + *
> + * By exiting or disabling any hardware feature that can also use the aux ch
> + * registers at the same time as driver, this function will give total 
> control
> + * of aux ch registers to driver.
> + */
> +static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
> +{
> + if (!intel_dp->exit_psr_on_aux_ch_xfer)
> + return;
> +
> + intel_psr_activate_block_get(intel_dp);
> + intel_psr_exit(intel_dp, true);

decision on exit and activate should be inside the block_get and block_put,
based on current state of the counters.

> +}
> +
> +/**
> + * intel_dp_aux_ch_put - Release aux ch registers control
> + *
> + * It is the intel_dp_aux_ch_get() counterpart.
> + */
> +static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
> +{
> + if (!intel_dp->exit_psr_on_aux_ch_xfer)
> + return;
> +
> + intel_psr_activate_block_put(intel_dp);
> + /* Usually more than just one aux ch transaction is executed when
> +  * handling some event, activating PSR right way would cause several
> +  * msecs of delay waiting PSR to exit for each aux ch transaction, so
> +  * here asking it to be scheduled.
> +  */
> + intel_psr_activate(intel_dp, true);
> +}
> +
>  static int
>  intel_dp_aux_xfer(struct intel_dp *intel_dp,
> const uint8_t *send, int send_bytes,
> @@ -1101,6 +1136,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>  
>   intel_dp_check_edp(intel_dp);
>  
> + intel_dp_aux_ch_get(intel_dp);
> +
>   /* Try to wait for any previous AUX channel activity */
>   for (try = 0; try < 3; try++) {
>   status = I915_READ_NOTRACE(ch_ctl);
> @@ -1223,6 +1260,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>  
>   ret = recv_bytes;
>  out:
> + intel_dp_aux_ch_put(intel_dp);
>   pm_qos_update_request(_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
>  
>   if (vdd)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 020b96324135..177478f0b032 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1139,6 +1139,8 @@ struct intel_dp {
>  
>   /* Displayport compliance testing */
>   struct intel_dp_compliance compliance;
> +
> + bool exit_psr_on_aux_ch_xfer;
>  };
>  
>  struct intel_lspcon {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 8702dbafb42d..f88f12246a23 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -665,6 +665,13 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> 
> msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
>   }
>  
> + /* From all platforms that supports PSR/PSR2 this 2 is the ones that
> +  * don't have restrictions about use of the aux ch while PSR/PSR2 is
> +  * enabled.
> +  */
> + if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> + intel_dp->exit_psr_on_aux_ch_xfer = true;
> +
>  unlock:
>   mutex_unlock(_priv->psr.lock);
>  }
> @@ -732,6 +739,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
>  
>   dev_priv->psr.disable_source(intel_dp);
>  
> + intel_dp->exit_psr_on_aux_ch_xfer = false;
>   /* Disable PSR on Sink */
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
>  
> -- 
> 2.16.3
> 
___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 06/11] drm/i915/psr: Add intel_psr_activate_block_get()/put()

2018-04-02 Thread Rodrigo Vivi
On Fri, Mar 30, 2018 at 03:23:31PM -0700, José Roberto de Souza wrote:
> intel_psr_activate_block_get() should be called when by some reason
> PSR should not be activated for some time, it will increment counter
> and it should the decremented by intel_psr_activate_block_put()
> when PSR can be activated again.
> intel_psr_activate_block_put() will not actually activate PSR, users
> of this function should also call intel_psr_activate().

Ohh cool! you made the counter.
probably we will need to change things from mutex to spin locker.
But also the blocker functions here could already introduce the function
calls to really block and release psr.

> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_psr.c | 54 
> 
>  3 files changed, 57 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 99af9169d792..41ebb144594e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -609,6 +609,7 @@ struct i915_psr {
>   bool has_hw_tracking;
>   bool psr2_enabled;
>   u8 sink_sync_latency;
> + unsigned int activate_block_count;
>  
>   void (*enable_source)(struct intel_dp *,
> const struct intel_crtc_state *);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 70026b772721..020b96324135 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1893,6 +1893,8 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
> struct intel_crtc_state *crtc_state);
>  void intel_psr_exit(struct intel_dp *intel_dp, bool wait_idle);
>  void intel_psr_activate(struct intel_dp *intel_dp, bool schedule);
> +void intel_psr_activate_block_get(struct intel_dp *intel_dp);
> +void intel_psr_activate_block_put(struct intel_dp *intel_dp);
>  
>  /* intel_runtime_pm.c */
>  int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 906a12ea934d..8702dbafb42d 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -558,6 +558,8 @@ static void __intel_psr_activate(struct intel_dp 
> *intel_dp)
>  
>   WARN_ON(dev_priv->psr.active);
>   lockdep_assert_held(_priv->psr.lock);
> + if (dev_priv->psr.activate_block_count)
> + return;
>  
>   dev_priv->psr.activate(intel_dp);
>   dev_priv->psr.active = true;
> @@ -1188,3 +1190,55 @@ void intel_psr_activate(struct intel_dp *intel_dp, 
> bool schedule)
>  out:
>   mutex_unlock(_priv->psr.lock);
>  }
> +
> +/**
> + * intel_psr_activate_block_get - Block further attempts to activate PSR
> + * @intel_dp: DisplayPort that have PSR enabled
> + *
> + * It have a internal reference count, so each intel_psr_activate_block_get()
> + * should have a intel_psr_activate_block_put() counterpart.
> + */
> +void intel_psr_activate_block_get(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);
> +
> + if (!CAN_PSR(dev_priv))
> + return;
> +
> + mutex_lock(_priv->psr.lock);
> + if (dev_priv->psr.enabled != intel_dp)
> + goto out;
> +
> + dev_priv->psr.activate_block_count++;
> +out:
> + mutex_unlock(_priv->psr.lock);
> +}
> +
> +
> +/**
> + * intel_psr_activate_block_put - Unblock further attempts to activate PSR
> + * @intel_dp: DisplayPort that have PSR enabled
> + *
> + * Decrease the reference counter incremented by 
> intel_psr_activate_block_get()
> + * when zero it allows PSR be activate. To actually activate PSR when 
> reference
> + * counter is zero intel_psr_activate() should be called.
> + */
> +void intel_psr_activate_block_put(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);
> +
> + if (!CAN_PSR(dev_priv))
> + return;
> +
> + mutex_lock(_priv->psr.lock);
> + if (dev_priv->psr.enabled != intel_dp)
> + goto out;
> +
> + dev_priv->psr.activate_block_count--;
> +out:
> + mutex_unlock(_priv->psr.lock);
> +}
> -- 
> 2.16.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 05/11] drm/i915/psr: Export intel_psr_activate/exit()

2018-04-02 Thread Rodrigo Vivi
On Fri, Mar 30, 2018 at 03:23:30PM -0700, José Roberto de Souza wrote:
> Export this functions so other modules can activate and exit PSR.

"module" is not a right word here.

But I also don't like the approach. In the past we had the use spread
on our driver and it was confusing and hard to deal with more corner
cases. frontbuffer tracking was created to fix that.

I understand where you are going because we need to disable it on aux
transactions, etc. But I don't believe the right way is to exporting
active/exit.

But to create one unified infrastructure to block and release psr
with atomic counters.

> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  2 +
>  drivers/gpu/drm/i915/intel_psr.c | 94 
> +---
>  2 files changed, 89 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index d1452fd2a58d..70026b772721 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1891,6 +1891,8 @@ void intel_psr_single_frame_update(struct 
> drm_i915_private *dev_priv,
>  unsigned frontbuffer_bits);
>  void intel_psr_compute_config(struct intel_dp *intel_dp,
> struct intel_crtc_state *crtc_state);
> +void intel_psr_exit(struct intel_dp *intel_dp, bool wait_idle);
> +void intel_psr_activate(struct intel_dp *intel_dp, bool schedule);
>  
>  /* intel_runtime_pm.c */
>  int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c4720b0152c3..906a12ea934d 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -56,6 +56,8 @@
>  #include "intel_drv.h"
>  #include "i915_drv.h"
>  
> +#define ACTIVATE_WORK_MSEC_DELAY 100
> +
>  static inline enum intel_display_power_domain
>  psr_aux_domain(struct intel_dp *intel_dp)
>  {
> @@ -548,7 +550,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>   DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
>  }
>  
> -static void intel_psr_activate(struct intel_dp *intel_dp)
> +static void __intel_psr_activate(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = intel_dig_port->base.base.dev;
> @@ -645,7 +647,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   dev_priv->psr.enabled = intel_dp;
>  
>   if (INTEL_GEN(dev_priv) >= 9) {
> - intel_psr_activate(intel_dp);
> + __intel_psr_activate(intel_dp);
>   } else {
>   /*
>* FIXME: Activation should happen immediately since this
> @@ -794,7 +796,7 @@ static void intel_psr_work(struct work_struct *work)
>   if (dev_priv->psr.busy_frontbuffer_bits)
>   goto unlock;
>  
> - intel_psr_activate(intel_dp);
> + __intel_psr_activate(intel_dp);
>  unlock:
>   mutex_unlock(_priv->psr.lock);
>  }
> @@ -880,7 +882,7 @@ static void vlv_psr_exit(struct intel_dp *intel_dp, bool 
> disabling)
>  DP_SET_POWER_D0);
>  }
>  
> -static void intel_psr_exit(struct drm_i915_private *dev_priv)
> +static void __intel_psr_exit(struct drm_i915_private *dev_priv)
>  {
>   struct intel_dp *intel_dp = dev_priv->psr.enabled;
>  
> @@ -977,7 +979,7 @@ void intel_psr_invalidate(struct drm_i915_private 
> *dev_priv,
>   dev_priv->psr.busy_frontbuffer_bits |= frontbuffer_bits;
>  
>   if (frontbuffer_bits)
> - intel_psr_exit(dev_priv);
> + __intel_psr_exit(dev_priv);
>  
>   mutex_unlock(_priv->psr.lock);
>  }
> @@ -1023,7 +1025,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>   if (frontbuffer_bits) {
>   if (dev_priv->psr.psr2_enabled ||
>   IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> - intel_psr_exit(dev_priv);
> + __intel_psr_exit(dev_priv);
>   } else {
>   /*
>* Display WA #0884: all
> @@ -1041,7 +1043,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>   if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
>   if (!work_busy(_priv->psr.work.work))
>   schedule_delayed_work(_priv->psr.work,
> -   msecs_to_jiffies(100));
> +   
> msecs_to_jiffies(ACTIVATE_WORK_MSEC_DELAY));
>   mutex_unlock(_priv->psr.lock);
>  }
>  
> @@ -1108,3 +1110,81 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
>   dev_priv->psr.exit = hsw_psr_exit;
>   }
>  }
> +
> +/**
> + * intel_psr_exit - Exit PSR
> + * 

Re: [Intel-gfx] [PATCH 04/11] drm/i915/psr: Remove intel_crtc_state parameter from disable()

2018-04-02 Thread Rodrigo Vivi
On Fri, Mar 30, 2018 at 03:23:29PM -0700, José Roberto de Souza wrote:
> It is not necessary as is possible to get the pipe information
> from intel_dp.
> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
Cc: Lucas

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  3 +--
>  drivers/gpu/drm/i915/intel_psr.c | 13 ++---
>  2 files changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index cb72ee27422f..99af9169d792 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -612,8 +612,7 @@ struct i915_psr {
>  
>   void (*enable_source)(struct intel_dp *,
> const struct intel_crtc_state *);
> - void (*disable_source)(struct intel_dp *,
> -const struct intel_crtc_state *);
> + void (*disable_source)(struct intel_dp *intel_dp);
>   void (*enable_sink)(struct intel_dp *);
>   void (*activate)(struct intel_dp *);
>   void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index d3451afeb8bb..c4720b0152c3 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -665,24 +665,23 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   mutex_unlock(_priv->psr.lock);
>  }
>  
> -static void vlv_psr_disable(struct intel_dp *intel_dp,
> - const struct intel_crtc_state *old_crtc_state)
> +static void vlv_psr_disable(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> + struct drm_crtc *crtc = intel_dig_port->base.base.crtc;

Lucas, is this the one you noticed we are using wrongly?

> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
>  
>   if (dev_priv->psr.active) {
>   dev_priv->psr.exit(intel_dp, true);
>   dev_priv->psr.active = false;
>   } else {
> - WARN_ON(vlv_is_psr_active_on_pipe(dev, crtc->pipe));
> + WARN_ON(vlv_is_psr_active_on_pipe(dev, pipe));
>   }
>  }
>  
> -static void hsw_psr_disable(struct intel_dp *intel_dp,
> - const struct intel_crtc_state *old_crtc_state)
> +static void hsw_psr_disable(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = intel_dig_port->base.base.dev;
> @@ -727,7 +726,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
>   return;
>   }
>  
> - dev_priv->psr.disable_source(intel_dp, old_crtc_state);
> + dev_priv->psr.disable_source(intel_dp);
>  
>   /* Disable PSR on Sink */
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
> -- 
> 2.16.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 03/11] drm/i915/psr: Share code between disable and exit

2018-04-02 Thread Rodrigo Vivi
On Fri, Mar 30, 2018 at 03:23:28PM -0700, José Roberto de Souza wrote:
> The disable and exit sequence are very similar with a lot common
> code between both, so here sharing the code.

I don't believe that we should do this.
Disable as is has some extra wait/timeouts that could slow things down.

Or at least not do this while we don't have a proper robuts test in place
and to test also performance impacts...

> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
>  drivers/gpu/drm/i915/intel_psr.c | 84 
> ++--
>  2 files changed, 38 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a8d300280a2c..cb72ee27422f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -617,7 +617,7 @@ struct i915_psr {
>   void (*enable_sink)(struct intel_dp *);
>   void (*activate)(struct intel_dp *);
>   void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
> - void (*exit)(struct intel_dp *intel_dp);
> + void (*exit)(struct intel_dp *intel_dp, bool disabling);
>  };
>  
>  enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index bcaac9e69f8c..d3451afeb8bb 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -672,23 +672,9 @@ static void vlv_psr_disable(struct intel_dp *intel_dp,
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> - uint32_t val;
>  
>   if (dev_priv->psr.active) {
> - /* Put VLV PSR back to PSR_state 0 (disabled). */
> - if (intel_wait_for_register(dev_priv,
> - VLV_PSRSTAT(crtc->pipe),
> - VLV_EDP_PSR_IN_TRANS,
> - 0,
> - 1))
> - WARN(1, "PSR transition took longer than expected\n");
> -
> - val = I915_READ(VLV_PSRCTL(crtc->pipe));
> - val &= ~VLV_EDP_PSR_ACTIVE_ENTRY;
> - val &= ~VLV_EDP_PSR_ENABLE;
> - val &= ~VLV_EDP_PSR_MODE_MASK;
> - I915_WRITE(VLV_PSRCTL(crtc->pipe), val);
> -
> + dev_priv->psr.exit(intel_dp, true);
>   dev_priv->psr.active = false;
>   } else {
>   WARN_ON(vlv_is_psr_active_on_pipe(dev, crtc->pipe));
> @@ -703,31 +689,7 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
>   if (dev_priv->psr.active) {
> - i915_reg_t psr_status;
> - u32 psr_status_mask;
> -
> - if (dev_priv->psr.psr2_enabled) {
> - psr_status = EDP_PSR2_STATUS;
> - psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> -
> - I915_WRITE(EDP_PSR2_CTL,
> -I915_READ(EDP_PSR2_CTL) &
> -~(EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE));
> -
> - } else {
> - psr_status = EDP_PSR_STATUS;
> - psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
> -
> - I915_WRITE(EDP_PSR_CTL,
> -I915_READ(EDP_PSR_CTL) & ~EDP_PSR_ENABLE);
> - }
> -
> - /* Wait till PSR is idle */
> - if (intel_wait_for_register(dev_priv,
> - psr_status, psr_status_mask, 0,
> - 2000))
> - DRM_ERROR("Timed out waiting for PSR Idle State\n");
> -
> + dev_priv->psr.exit(intel_dp, true);
>   dev_priv->psr.active = false;
>   } else {
>   if (dev_priv->psr.psr2_enabled)
> @@ -838,25 +800,41 @@ static void intel_psr_work(struct work_struct *work)
>   mutex_unlock(_priv->psr.lock);
>  }
>  
> -static void hsw_psr_exit(struct intel_dp *intel_dp)
> +static void hsw_psr_exit(struct intel_dp *intel_dp, bool disabling)
>  {
>   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);
> + i915_reg_t psr_status;
> + u32 psr_status_mask;
>   u32 val;
>  
>   if (dev_priv->psr.psr2_enabled) {
> + psr_status = EDP_PSR2_STATUS;
> + psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> +
>   val = I915_READ(EDP_PSR2_CTL);
> - WARN_ON(!(val & EDP_PSR2_ENABLE));
> - I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
> +   

Re: [Intel-gfx] [PATCH 02/11] drm/i915/psr: Move PSR exit specific code to hardware specific function

2018-04-02 Thread Rodrigo Vivi
On Fri, Mar 30, 2018 at 03:23:27PM -0700, José Roberto de Souza wrote:
> To proper execute PSR exit it was using 'if (HAS_DDI(dev_priv))' to
> differentiate between VLV/CHV and HSW+ hardware, so here moving each
> hardware handling to his own function.
> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 94 
> +++-
>  2 files changed, 56 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5373b171bb96..a8d300280a2c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -617,6 +617,7 @@ struct i915_psr {
>   void (*enable_sink)(struct intel_dp *);
>   void (*activate)(struct intel_dp *);
>   void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
> + void (*exit)(struct intel_dp *intel_dp);
>  };
>  
>  enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index fc7c36efd401..bcaac9e69f8c 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -838,53 +838,67 @@ static void intel_psr_work(struct work_struct *work)
>   mutex_unlock(_priv->psr.lock);
>  }
>  
> -static void intel_psr_exit(struct drm_i915_private *dev_priv)
> +static void hsw_psr_exit(struct intel_dp *intel_dp)
>  {
> - struct intel_dp *intel_dp = dev_priv->psr.enabled;
> - struct drm_crtc *crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
> + 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);
> + u32 val;
> +
> + if (dev_priv->psr.psr2_enabled) {
> + val = I915_READ(EDP_PSR2_CTL);
> + WARN_ON(!(val & EDP_PSR2_ENABLE));
> + I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
> + } else {
> + val = I915_READ(EDP_PSR_CTL);
> + WARN_ON(!(val & EDP_PSR_ENABLE));
> + I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE);
> + }
> +}
> +
> +static void vlv_psr_exit(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);
> + struct drm_crtc *crtc = dig_port->base.base.crtc;
>   enum pipe pipe = to_intel_crtc(crtc)->pipe;
>   u32 val;
>  
> - if (!dev_priv->psr.active)
> - return;
> + val = I915_READ(VLV_PSRCTL(pipe));
>  
> - if (HAS_DDI(dev_priv)) {
> - if (dev_priv->psr.psr2_enabled) {
> - val = I915_READ(EDP_PSR2_CTL);
> - WARN_ON(!(val & EDP_PSR2_ENABLE));
> - I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
> - } else {
> - val = I915_READ(EDP_PSR_CTL);
> - WARN_ON(!(val & EDP_PSR_ENABLE));
> - I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE);
> - }
> - } else {
> - val = I915_READ(VLV_PSRCTL(pipe));
> + /*
> +  * Here we do the transition drirectly from
> +  * PSR_state 3 (active - no Remote Frame Buffer (RFB) update) to
> +  * PSR_state 5 (exit).
> +  * PSR State 4 (active with single frame update) can be skipped.
> +  * On PSR_state 5 (exit) Hardware is responsible to transition
> +  * back to PSR_state 1 (inactive).
> +  * Now we are at Same state after vlv_psr_enable_source.
> +  */
> + val &= ~VLV_EDP_PSR_ACTIVE_ENTRY;
> + I915_WRITE(VLV_PSRCTL(pipe), val);
>  
> - /*
> -  * Here we do the transition drirectly from
> -  * PSR_state 3 (active - no Remote Frame Buffer (RFB) update) to
> -  * PSR_state 5 (exit).
> -  * PSR State 4 (active with single frame update) can be skipped.
> -  * On PSR_state 5 (exit) Hardware is responsible to transition
> -  * back to PSR_state 1 (inactive).
> -  * Now we are at Same state after vlv_psr_enable_source.
> -  */
> - val &= ~VLV_EDP_PSR_ACTIVE_ENTRY;
> - I915_WRITE(VLV_PSRCTL(pipe), val);
> + /*
> +  * Send AUX wake up - Spec says after transitioning to PSR
> +  * active we have to send AUX wake up by writing 01h in DPCD
> +  * 600h of sink device.
> +  * XXX: This might slow down the transition, but without this
> +  * HW doesn't complete the transition to PSR_state 1 and we
> +  * never get the screen updated.
> +  */
> + drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> +

Re: [Intel-gfx] [PATCH 01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

2018-04-02 Thread Rodrigo Vivi
On Fri, Mar 30, 2018 at 03:23:26PM -0700, José Roberto de Souza wrote:
> It was reading some random register in VLV and CHV.
> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 

I'm sure that my patch [1] will conflict with this series.

[1] https://patchwork.freedesktop.org/series/39650/

But the approach here is right and I couldn't get back there
yet and address latest DK's requests. So:

Reviewed-by: Rodrigo Vivi 


> ---
>  drivers/gpu/drm/i915/intel_psr.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2d53f7398a6d..fc7c36efd401 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -424,6 +424,11 @@ static void hsw_psr_activate(struct intel_dp *intel_dp)
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
> + if (dev_priv->psr.psr2_enabled)
> + WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
> + else
> + WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> +
>   /* On HSW+ after we enable PSR on source it will activate it
>* as soon as it match configure idle_frame count. So
>* we just actually enable it here on activation time.
> @@ -549,10 +554,6 @@ 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);
>  
> - if (dev_priv->psr.psr2_enabled)
> - 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);
>  
> -- 
> 2.16.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

2018-04-02 Thread Pandiyan, Dhinakaran



On Sat, 2018-03-31 at 00:17 +, Souza, Jose wrote:
> On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote:
> > On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> > > This was my bad, spec says that the name of this bit is
> > > 'Y-coordinate valid' but the values for it is:
> > > 0: Include Y-coordinate valid eDP1.4a
> > > 1: Do not include Y-coordinate valid eDP 1.4
> > > So renaming the bit and not setting it.
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h  | 2 +-
> > >  drivers/gpu/drm/i915/intel_psr.c | 5 ++---
> > >  2 files changed, 3 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 176dca6554f4..19429cb1f3a7 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -4058,7 +4058,7 @@ enum {
> > >  #define EDP_PSR2_CTL _MMIO(0x6f900)
> > >  #define   EDP_PSR2_ENABLE(1<<31)
> > >  #define   EDP_SU_TRACK_ENABLE(1<<30)
> > > -#define   EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> > > +#define   EDP_Y_COORDINATE_INVALID   (1<<26) /* GLK and CNL+
> > > */
> > 
> > INVALID isn't the same as asking the source to not send the y-
> > coordinate
> > valid bit. Sorry to be pedantic, please leave the definition as it
> > is.
> 
> I agree with you, if it don't need to send the y-coordinate is
> better just not set EDP_Y_COORDINATE_ENABLE but leave the bit
> definition name as it is, is prone to others do the same error as I
> did.
> 

I'll let Rodrigo take a call on this one.

-DK

> > 
> > Reviewed-by: Dhinakaran Pandiyan  if
> > you
> > remove this hunk.
> > 
> > >  #define   EDP_Y_COORDINATE_ENABLE(1<<25) /* GLK and CNL+
> > > */
> > >  #define   EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
> > >  #define   EDP_MAX_SU_DISABLE_TIME_MASK   (0x1f<<20)
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 2d53f7398a6d..f12111438bcf 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -400,9 +400,8 @@ static void hsw_activate_psr2(struct intel_dp
> > > *intel_dp)
> > >* mesh at all with our frontbuffer tracking. And the hw
> > > alone isn't
> > >* good enough. */
> > >   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > > - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > > {
> > > - val |= EDP_Y_COORDINATE_VALID |
> > > EDP_Y_COORDINATE_ENABLE;
> > > - }
> > > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > > + val |= EDP_Y_COORDINATE_ENABLE;
> > >  
> > >   val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv-
> > > >psr.sink_sync_latency + 1);
> > >  
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Track begin/end of execlists submission sequences

2018-04-02 Thread Francisco Jerez
Chris Wilson  writes:

> We would like to start doing some bookkeeping at the beginning, between
> contexts and at the end of execlists submission. We already mark the
> beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication
> when the HW is idle. This give us a pair of sequence points we can then
> expand on for further bookkeeping.
>
> v2: Refactor guc submission to share the same begin/end.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Francisco Jerez 
> Reviewed-by: Francisco Jerez  #v1

Thanks, v2 is also:

Reviewed-by: Francisco Jerez 

> ---
>  drivers/gpu/drm/i915/intel_guc_submission.c | 17 ++
>  drivers/gpu/drm/i915/intel_lrc.c| 50 
> ++---
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 15 -
>  3 files changed, 63 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
> b/drivers/gpu/drm/i915/intel_guc_submission.c
> index 207cda062626..749f27916a02 100644
> --- a/drivers/gpu/drm/i915/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/intel_guc_submission.c
> @@ -728,7 +728,7 @@ static void guc_dequeue(struct intel_engine_cs *engine)
>   execlists->first = rb;
>   if (submit) {
>   port_assign(port, last);
> - execlists_set_active(execlists, EXECLISTS_ACTIVE_USER);
> + execlists_user_begin(execlists, execlists->port);
>   guc_submit(engine);
>   }
>  
> @@ -748,17 +748,20 @@ static void guc_submission_tasklet(unsigned long data)
>   struct execlist_port *port = execlists->port;
>   struct i915_request *rq;
>  
> - rq = port_request([0]);
> + rq = port_request(port);
>   while (rq && i915_request_completed(rq)) {
>   trace_i915_request_out(rq);
>   i915_request_put(rq);
>  
> - execlists_port_complete(execlists, port);
> -
> - rq = port_request([0]);
> + port = execlists_port_complete(execlists, port);
> + if (port_isset(port)) {
> + execlists_user_begin(execlists, port);
> + rq = port_request(port);
> + } else {
> + execlists_user_end(execlists);
> + rq = NULL;
> + }
>   }
> - if (!rq)
> - execlists_clear_active(execlists, EXECLISTS_ACTIVE_USER);
>  
>   if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) &&
>   intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) ==
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index f60b61bf8b3b..4d08875422b6 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -374,6 +374,19 @@ execlists_context_status_change(struct i915_request *rq, 
> unsigned long status)
>  status, rq);
>  }
>  
> +inline void
> +execlists_user_begin(struct intel_engine_execlists *execlists,
> +  const struct execlist_port *port)
> +{
> + execlists_set_active_once(execlists, EXECLISTS_ACTIVE_USER);
> +}
> +
> +inline void
> +execlists_user_end(struct intel_engine_execlists *execlists)
> +{
> + execlists_clear_active(execlists, EXECLISTS_ACTIVE_USER);
> +}
> +
>  static inline void
>  execlists_context_schedule_in(struct i915_request *rq)
>  {
> @@ -711,7 +724,7 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
>   spin_unlock_irq(>timeline->lock);
>  
>   if (submit) {
> - execlists_set_active(execlists, EXECLISTS_ACTIVE_USER);
> + execlists_user_begin(execlists, execlists->port);
>   execlists_submit_ports(engine);
>   }
>  
> @@ -742,7 +755,7 @@ execlists_cancel_port_requests(struct 
> intel_engine_execlists * const execlists)
>   port++;
>   }
>  
> - execlists_clear_active(execlists, EXECLISTS_ACTIVE_USER);
> + execlists_user_end(execlists);
>  }
>  
>  static void clear_gtiir(struct intel_engine_cs *engine)
> @@ -873,7 +886,7 @@ static void execlists_submission_tasklet(unsigned long 
> data)
>  {
>   struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
>   struct intel_engine_execlists * const execlists = >execlists;
> - struct execlist_port * const port = execlists->port;
> + struct execlist_port *port = execlists->port;
>   struct drm_i915_private *dev_priv = engine->i915;
>   bool fw = false;
>  
> @@ -1012,10 +1025,28 @@ static void execlists_submission_tasklet(unsigned 
> long data)
>  
>   GEM_BUG_ON(count == 0);
>   if (--count == 0) {
> + /*
> +  * On the final event corresponding to the
> +  * submission of this 

Re: [Intel-gfx] [PATCH] drm/i915: Store preemption capability in engine->flags

2018-04-02 Thread Daniele Ceraolo Spurio



On 31/03/18 03:42, Chris Wilson wrote:

Let's avoid having to delve down the pointer chain to see if the i915
device has support for preemption and store that on the engine, which
made the decision in the first place!

Signed-off-by: Chris Wilson 
Cc: Tomasz Lis 
Cc: Daniele Ceraolo Spurio 
Cc: Michał Winiarski 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_lrc.c|  7 +--
  drivers/gpu/drm/i915/intel_ringbuffer.h | 13 +++--
  2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f60b61bf8b3b..48073987214f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -183,7 +183,8 @@ static inline bool need_preempt(const struct 
intel_engine_cs *engine,
const struct i915_request *last,
int prio)
  {
-   return engine->i915->preempt_context && prio > max(rq_prio(last), 0);
+   return (intel_engine_has_preemption(engine) &&
+   prio > max(rq_prio(last), 0));


This is re-coded in guc_dequeue so we could either use 
intel_engine_has_preemption() over there as well or move
need_preempt() to a common header and call it from there. Apart from 
this the patch LGTM.


Daniele


  }
  
  /**

@@ -2089,11 +2090,13 @@ static void execlists_set_default_submission(struct 
intel_engine_cs *engine)
engine->unpark = NULL;
  
  	engine->flags |= I915_ENGINE_SUPPORTS_STATS;

+   if (engine->i915->preempt_context)
+   engine->flags |= I915_ENGINE_HAS_PREEMPTION;
  
  	engine->i915->caps.scheduler =

I915_SCHEDULER_CAP_ENABLED |
I915_SCHEDULER_CAP_PRIORITY;
-   if (engine->i915->preempt_context)
+   if (intel_engine_has_preemption(engine))
engine->i915->caps.scheduler |= I915_SCHEDULER_CAP_PREEMPTION;
  }
  
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h

index a02c7b3b9d55..1079254e6b89 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -562,6 +562,7 @@ struct intel_engine_cs {
  
  #define I915_ENGINE_NEEDS_CMD_PARSER BIT(0)

  #define I915_ENGINE_SUPPORTS_STATS   BIT(1)
+#define I915_ENGINE_HAS_PREEMPTION   BIT(2)
unsigned int flags;
  
  	/*

@@ -621,16 +622,24 @@ struct intel_engine_cs {
} stats;
  };
  
-static inline bool intel_engine_needs_cmd_parser(struct intel_engine_cs *engine)

+static inline bool
+intel_engine_needs_cmd_parser(const struct intel_engine_cs *engine)
  {
return engine->flags & I915_ENGINE_NEEDS_CMD_PARSER;
  }
  
-static inline bool intel_engine_supports_stats(struct intel_engine_cs *engine)

+static inline bool
+intel_engine_supports_stats(const struct intel_engine_cs *engine)
  {
return engine->flags & I915_ENGINE_SUPPORTS_STATS;
  }
  
+static inline bool

+intel_engine_has_preemption(const struct intel_engine_cs *engine)
+{
+   return engine->flags & I915_ENGINE_HAS_PREEMPTION;
+}
+
  static inline void
  execlists_set_active(struct intel_engine_execlists *execlists,
 unsigned int bit)


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


Re: [Intel-gfx] [PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

2018-04-02 Thread Steven Rostedt
On Fri, 30 Mar 2018 16:01:31 +0100
Chris Wilson  wrote:

> Across suspend, we may see a very large drift in timestamps if the sched
> clock is unstable, prompting the global trace's ringbuffer code to warn
> and suggest switching to the global clock. Preempt this request by
> detecting when the sched clock is unstable (determined during
> late_initcall) and automatically switching the default clock over to
> trace_global_clock.
> 
> This should prevent requiring user interaction to resolve warnings such
> as:
> 
> Delta way too big! 18446743856563626466 ts=18446744054496180323 write 
> stamp = 197932553857
> If you just came from a suspend/resume,
> please switch to the trace global clock:
> echo global > /sys/kernel/debug/tracing/trace_clock
> 
> Signed-off-by: Chris Wilson 
> Cc: Steven Rostedt (VMware) 
> ---
> v2: Tell the user what's happening and what they can do to correct it.
>

Thanks, I pulled them in. I'll start testing them before I post to git.

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


Re: [Intel-gfx] [PATCH v4 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

2018-04-02 Thread Sean Paul
On Mon, Apr 02, 2018 at 05:20:22PM +0530, Ramalingam C wrote:
> As per DP spec when R0 mismatch is detected, HDCP source supported
> re-read the R0 atleast twice.
> 
> And For HDMI and DP minimum wait required for the R0 availability is
> 100mSec. So this patch changes the wait time to 100mSec but retries
> twice with the time interval of 100mSec for each attempt.
> 
> This patch is needed for DP HDCP1.4 CTS Test: 1A-06.
> 
> v2:
>   No Change
> v3:
>   Comment on R0 retry is moved closer to the code[Seanpaul]
> v4:
>   Removing unwanted noise introduced in v3.
> 
> Signed-off-by: Ramalingam C 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 14ca5d3057a7..f2cf2e3acd3c 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -506,15 +506,26 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>*/
>   wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
>  
> - ri.reg = 0;
> - ret = shim->read_ri_prime(intel_dig_port, ri.shim);
> - if (ret)
> - return ret;
> - I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
> + tries = 3;
>  
> - /* Wait for Ri prime match */
> - if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
> -  (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
> + /*
> +  * DP HDCP Spec mandates the two more reattempt to read R0, incase
> +  * of R0 mismatch.
> +  */
> + for (i = 0; i < tries; i++) {
> + ri.reg = 0;
> + ret = shim->read_ri_prime(intel_dig_port, ri.shim);
> + if (ret)
> + return ret;
> + I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
> +
> + /* Wait for Ri prime match */
> + if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
> + (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
> + break;
> + }
> +
> + if (i == tries) {
>   DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
> I915_READ(PORT_HDCP_STATUS(port)));
>   return -ETIMEDOUT;
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Read Vprime thrice incase of mismatch

2018-04-02 Thread Sean Paul
On Mon, Apr 02, 2018 at 03:40:32PM +0530, Ramalingam C wrote:
> In case of V prime mismatch, DP HDCP spec mandates the re-read of
> Vprime atleast twice.
> 
> This patch needed for DP HDCP1.4 CTS Test: 1B-05.
> 
> v2:
>   Moved the V' validation into a function for retry. [Sean Paul]
> v3:
>   Removed Inline keyword and DRM_DEBUG_KMS are used [Sean Paul]
> 
> Signed-off-by: Ramalingam C 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 112 
> --
>  1 file changed, 70 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 838c8cd0f543..e0bc03eee941 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -142,53 +142,17 @@ bool intel_hdcp_is_ksv_valid(u8 *ksv)
>   return true;
>  }
>  
> -/* Implements Part 2 of the HDCP authorization procedure */
>  static
> -int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> -const struct intel_hdcp_shim *shim)
> +int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
> + const struct intel_hdcp_shim *shim,
> + u8 *ksv_fifo, u8 num_downstream, u8 *bstatus)
>  {
>   struct drm_i915_private *dev_priv;
>   u32 vprime, sha_text, sha_leftovers, rep_ctl;
> - u8 bstatus[2], num_downstream, *ksv_fifo;
>   int ret, i, j, sha_idx;
>  
>   dev_priv = intel_dig_port->base.base.dev->dev_private;
>  
> - ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
> - if (ret) {
> - DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
> - return ret;
> - }
> -
> - ret = shim->read_bstatus(intel_dig_port, bstatus);
> - if (ret)
> - return ret;
> -
> - if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
> - DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
> - DRM_ERROR("Max Topology Limit Exceeded\n");
> - return -EPERM;
> - }
> -
> - /*
> -  * When repeater reports 0 device count, HDCP1.4 spec allows disabling
> -  * the HDCP encryption. That implies that repeater can't have its own
> -  * display. As there is no consumption of encrypted content in the
> -  * repeater with 0 downstream devices, we are failing the
> -  * authentication.
> -  */
> - num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
> - if (num_downstream == 0)
> - return -EINVAL;
> -
> - ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
> - if (!ksv_fifo)
> - return -ENOMEM;
> -
> - ret = shim->read_ksv_fifo(intel_dig_port, num_downstream, ksv_fifo);
> - if (ret)
> - return ret;
> -
>   /* Process V' values from the receiver */
>   for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
>   ret = shim->read_v_prime_part(intel_dig_port, i, );
> @@ -353,7 +317,8 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   return ret;
>   sha_idx += sizeof(sha_text);
>   } else {
> - DRM_ERROR("Invalid number of leftovers %d\n", sha_leftovers);
> + DRM_DEBUG_KMS("Invalid number of leftovers %d\n",
> +   sha_leftovers);
>   return -EINVAL;
>   }
>  
> @@ -381,14 +346,77 @@ int intel_hdcp_auth_downstream(struct 
> intel_digital_port *intel_dig_port,
>   if (intel_wait_for_register(dev_priv, HDCP_REP_CTL,
>   HDCP_SHA1_COMPLETE,
>   HDCP_SHA1_COMPLETE, 1)) {
> - DRM_ERROR("Timed out waiting for SHA1 complete\n");
> + DRM_DEBUG_KMS("Timed out waiting for SHA1 complete\n");
>   return -ETIMEDOUT;
>   }
>   if (!(I915_READ(HDCP_REP_CTL) & HDCP_SHA1_V_MATCH)) {
> - DRM_ERROR("SHA-1 mismatch, HDCP failed\n");
> + DRM_DEBUG_KMS("SHA-1 mismatch, HDCP failed\n");
>   return -ENXIO;
>   }
>  
> + return 0;
> +}
> +
> +/* Implements Part 2 of the HDCP authorization procedure */
> +static
> +int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> +const struct intel_hdcp_shim *shim)
> +{
> + u8 bstatus[2], num_downstream, *ksv_fifo;
> + int ret, i, tries = 3;
> +
> + ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
> + if (ret) {
> + DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
> + return ret;
> + }
> +
> + ret = shim->read_bstatus(intel_dig_port, bstatus);
> + if (ret)
> + return ret;
> +
> + if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
> + DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
> + DRM_ERROR("Max Topology Limit Exceeded\n");
> +

[Intel-gfx] ✗ Fi.CI.IGT: failure for HDCP1.4 fixes (rev5)

2018-04-02 Thread Patchwork
== Series Details ==

Series: HDCP1.4 fixes (rev5)
URL   : https://patchwork.freedesktop.org/series/38978/
State : failure

== Summary ==

 Possible new issues:

Test drv_module_reload:
Subgroup basic-no-display:
pass   -> INCOMPLETE (shard-snb)
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
dmesg-warn -> PASS   (shard-snb)

 Known issues:

Test gem_softpin:
Subgroup noreloc-s3:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
dmesg-fail -> PASS   (shard-apl) fdo#104727
Test kms_rotation_crc:
Subgroup primary-rotation-90:
pass   -> FAIL   (shard-apl) fdo#103925

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

shard-apltotal:3495 pass:1830 dwarn:1   dfail:0   fail:8   skip:1655 
time:12842s
shard-hswtotal:3495 pass:1780 dwarn:1   dfail:0   fail:4   skip:1709 
time:11477s
shard-snbtotal:3399 pass:1331 dwarn:1   dfail:0   fail:3   skip:2063 
time:6920s
Blacklisted hosts:
shard-kbltotal:3495 pass:1948 dwarn:12  dfail:1   fail:6   skip:1528 
time:9208s

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP1.4 fixes (rev5)

2018-04-02 Thread Patchwork
== Series Details ==

Series: HDCP1.4 fixes (rev5)
URL   : https://patchwork.freedesktop.org/series/38978/
State : success

== Summary ==

Series 38978v5 HDCP1.4 fixes
https://patchwork.freedesktop.org/api/1.0/series/38978/revisions/5/mbox/

 Known issues:

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

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:433s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:452s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:387s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:535s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:295s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:511s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:518s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:506s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:587s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:422s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:317s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:429s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:479s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:657s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:502s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:508s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:434s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:453s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:399s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:531s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:486s

c46052cde6a50c5459e00791ffc4d5aa1ec58a9e drm-tip: 2018y-03m-30d-18h-56m-26s UTC 
integration manifest
c90312327145 drm/i915: Fix reading downstream dev count
376de82ef8ea drm/i915: Check hdcp key loadability
7f0a75907ccf drm/i915: Read Vprime thrice incase of mismatch
1386dd18899d drm/i915: Read HDCP R0 thrice in case of mismatch

== Logs ==

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


[Intel-gfx] [PATCH v4 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

2018-04-02 Thread Ramalingam C
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.

And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.

This patch is needed for DP HDCP1.4 CTS Test: 1A-06.

v2:
  No Change
v3:
  Comment on R0 retry is moved closer to the code[Seanpaul]
v4:
  Removing unwanted noise introduced in v3.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 14ca5d3057a7..f2cf2e3acd3c 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -506,15 +506,26 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
 */
wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
 
-   ri.reg = 0;
-   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
-   if (ret)
-   return ret;
-   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+   tries = 3;
 
-   /* Wait for Ri prime match */
-   if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
-(HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
+   /*
+* DP HDCP Spec mandates the two more reattempt to read R0, incase
+* of R0 mismatch.
+*/
+   for (i = 0; i < tries; i++) {
+   ri.reg = 0;
+   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
+   if (ret)
+   return ret;
+   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+
+   /* Wait for Ri prime match */
+   if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
+   (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
+   break;
+   }
+
+   if (i == tries) {
DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
  I915_READ(PORT_HDCP_STATUS(port)));
return -ETIMEDOUT;
-- 
2.7.4

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


[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP1.4 fixes (rev4)

2018-04-02 Thread Patchwork
== Series Details ==

Series: HDCP1.4 fixes (rev4)
URL   : https://patchwork.freedesktop.org/series/38978/
State : success

== Summary ==

 Possible new issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
dmesg-warn -> PASS   (shard-snb)

 Known issues:

Test gem_softpin:
Subgroup noreloc-s3:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
dmesg-fail -> PASS   (shard-apl) fdo#104727

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

shard-apltotal:3495 pass:1831 dwarn:1   dfail:0   fail:7   skip:1655 
time:12874s
shard-hswtotal:3495 pass:1779 dwarn:1   dfail:0   fail:5   skip:1709 
time:11518s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:7034s
Blacklisted hosts:
shard-kbltotal:3477 pass:1937 dwarn:1   dfail:0   fail:10  skip:1528 
time:9033s

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for Add NV12 support (rev7)

2018-04-02 Thread Patchwork
== Series Details ==

Series: Add NV12 support (rev7)
URL   : https://patchwork.freedesktop.org/series/39670/
State : failure

== Summary ==

 Possible new issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
dmesg-warn -> PASS   (shard-snb)
Test kms_plane_scaling:
Subgroup pipe-a-scaler-with-clipping-clamping:
pass   -> FAIL   (shard-apl)
Subgroup pipe-a-scaler-with-pixel-format:
pass   -> FAIL   (shard-apl)
Subgroup pipe-a-scaler-with-rotation:
pass   -> FAIL   (shard-apl)
Subgroup pipe-b-scaler-with-clipping-clamping:
pass   -> FAIL   (shard-apl)
Subgroup pipe-b-scaler-with-pixel-format:
pass   -> FAIL   (shard-apl)
Subgroup pipe-b-scaler-with-rotation:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_softpin:
Subgroup noreloc-s3:
incomplete -> PASS   (shard-hsw) fdo#103540 +1
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup 2x-plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
dmesg-fail -> PASS   (shard-apl) fdo#104727

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

shard-apltotal:3495 pass:1825 dwarn:1   dfail:0   fail:13  skip:1655 
time:12839s
shard-hswtotal:3430 pass:1749 dwarn:1   dfail:0   fail:3   skip:1675 
time:11177s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:7042s
Blacklisted hosts:
shard-kbltotal:3495 pass:1951 dwarn:1   dfail:0   fail:15  skip:1528 
time:9270s

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP1.4 fixes (rev4)

2018-04-02 Thread Patchwork
== Series Details ==

Series: HDCP1.4 fixes (rev4)
URL   : https://patchwork.freedesktop.org/series/38978/
State : success

== Summary ==

Series 38978v4 HDCP1.4 fixes
https://patchwork.freedesktop.org/api/1.0/series/38978/revisions/4/mbox/

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:388s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:545s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:296s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:513s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:523s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:514s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:510s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:582s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:430s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:316s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:426s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:473s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:659s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:426s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:562s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:520s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:487s

c46052cde6a50c5459e00791ffc4d5aa1ec58a9e drm-tip: 2018y-03m-30d-18h-56m-26s UTC 
integration manifest
1a818c8dc867 drm/i915: Fix reading downstream dev count
d18c7aafdc2b drm/i915: Check hdcp key loadability
a80c7a7aa64c drm/i915: Read Vprime thrice incase of mismatch
0b223e11bf19 drm/i915: Read HDCP R0 thrice in case of mismatch

== Logs ==

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


[Intel-gfx] [PATCH v3 0/4] HDCP1.4 fixes

2018-04-02 Thread Ramalingam C
First two patches needed for below DP HDCP compliance tests
1A-06 and 1B-05

Third patch fixes the HDCP1.4 Key loadability check. where as fourth
one fixes the downstream device count read.

Fix for HDMI HDCP1.4 CTS tests: 1A-04 and 1A-07a are functional.
But the change from v2, as thinking to put through more regressive
testing before upstreaming.

Ramalingam C (4):
  drm/i915: Read HDCP R0 thrice in case of mismatch
  drm/i915: Read Vprime thrice incase of mismatch
  drm/i915: Check hdcp key loadability
  drm/i915: Fix reading downstream dev count

 drivers/gpu/drm/i915/intel_hdcp.c | 182 +++---
 include/drm/drm_hdcp.h|   2 +-
 2 files changed, 130 insertions(+), 54 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH v3 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

2018-04-02 Thread Ramalingam C
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.

And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.

This patch is needed for DP HDCP1.4 CTS Test: 1A-06.

v2:
  No Change
v3:
  Comment on R0 retry is moved closer to the code[Seanpaul]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 14ca5d3057a7..838c8cd0f543 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -498,7 +498,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
/*
 * Wait for R0' to become available. The spec says 100ms from Aksv, but
 * some monitors can take longer than this. We'll set the timeout at
-* 300ms just to be sure.
+-* 300ms just to be sure.
 *
 * On DP, there's an R0_READY bit available but no such bit
 * exists on HDMI. Since the upper-bound is the same, we'll just do
@@ -506,15 +506,26 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
 */
wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
 
-   ri.reg = 0;
-   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
-   if (ret)
-   return ret;
-   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+   tries = 3;
 
-   /* Wait for Ri prime match */
-   if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
-(HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
+   /*
+* DP HDCP Spec mandates the two more reattempt to read R0, incase
+* of R0 mismatch.
+*/
+   for (i = 0; i < tries; i++) {
+   ri.reg = 0;
+   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
+   if (ret)
+   return ret;
+   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+
+   /* Wait for Ri prime match */
+   if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
+   (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
+   break;
+   }
+
+   if (i == tries) {
DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
  I915_READ(PORT_HDCP_STATUS(port)));
return -ETIMEDOUT;
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 4/4] drm/i915: Fix reading downstream dev count

2018-04-02 Thread Ramalingam C
In both HDMI and DP, device count is represented by 6:0 bits of a
register(BInfo/Bstatus)

So macro for bitmasking the device_count is fixed(0x3F->0x7F).

v3:
  Retained the Rb-ed

Signed-off-by: Ramalingam C 
cc: Sean Paul 
Reviewed-by: Sean Paul 
---
 include/drm/drm_hdcp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 562fa7df2637..98e63d870139 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -19,7 +19,7 @@
 #define DRM_HDCP_RI_LEN2
 #define DRM_HDCP_V_PRIME_PART_LEN  4
 #define DRM_HDCP_V_PRIME_NUM_PARTS 5
-#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
+#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
 #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x)   (x & BIT(3))
 #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)(x & BIT(7))
 
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 2/4] drm/i915: Read Vprime thrice incase of mismatch

2018-04-02 Thread Ramalingam C
In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.

This patch needed for DP HDCP1.4 CTS Test: 1B-05.

v2:
  Moved the V' validation into a function for retry. [Sean Paul]
v3:
  Removed Inline keyword and DRM_DEBUG_KMS are used [Sean Paul]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 112 --
 1 file changed, 70 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 838c8cd0f543..e0bc03eee941 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -142,53 +142,17 @@ bool intel_hdcp_is_ksv_valid(u8 *ksv)
return true;
 }
 
-/* Implements Part 2 of the HDCP authorization procedure */
 static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
+   const struct intel_hdcp_shim *shim,
+   u8 *ksv_fifo, u8 num_downstream, u8 *bstatus)
 {
struct drm_i915_private *dev_priv;
u32 vprime, sha_text, sha_leftovers, rep_ctl;
-   u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, j, sha_idx;
 
dev_priv = intel_dig_port->base.base.dev->dev_private;
 
-   ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
-   if (ret) {
-   DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
-   return ret;
-   }
-
-   ret = shim->read_bstatus(intel_dig_port, bstatus);
-   if (ret)
-   return ret;
-
-   if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
-   DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
-   DRM_ERROR("Max Topology Limit Exceeded\n");
-   return -EPERM;
-   }
-
-   /*
-* When repeater reports 0 device count, HDCP1.4 spec allows disabling
-* the HDCP encryption. That implies that repeater can't have its own
-* display. As there is no consumption of encrypted content in the
-* repeater with 0 downstream devices, we are failing the
-* authentication.
-*/
-   num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
-   if (num_downstream == 0)
-   return -EINVAL;
-
-   ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
-   if (!ksv_fifo)
-   return -ENOMEM;
-
-   ret = shim->read_ksv_fifo(intel_dig_port, num_downstream, ksv_fifo);
-   if (ret)
-   return ret;
-
/* Process V' values from the receiver */
for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
ret = shim->read_v_prime_part(intel_dig_port, i, );
@@ -353,7 +317,8 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
return ret;
sha_idx += sizeof(sha_text);
} else {
-   DRM_ERROR("Invalid number of leftovers %d\n", sha_leftovers);
+   DRM_DEBUG_KMS("Invalid number of leftovers %d\n",
+ sha_leftovers);
return -EINVAL;
}
 
@@ -381,14 +346,77 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
if (intel_wait_for_register(dev_priv, HDCP_REP_CTL,
HDCP_SHA1_COMPLETE,
HDCP_SHA1_COMPLETE, 1)) {
-   DRM_ERROR("Timed out waiting for SHA1 complete\n");
+   DRM_DEBUG_KMS("Timed out waiting for SHA1 complete\n");
return -ETIMEDOUT;
}
if (!(I915_READ(HDCP_REP_CTL) & HDCP_SHA1_V_MATCH)) {
-   DRM_ERROR("SHA-1 mismatch, HDCP failed\n");
+   DRM_DEBUG_KMS("SHA-1 mismatch, HDCP failed\n");
return -ENXIO;
}
 
+   return 0;
+}
+
+/* Implements Part 2 of the HDCP authorization procedure */
+static
+int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
+  const struct intel_hdcp_shim *shim)
+{
+   u8 bstatus[2], num_downstream, *ksv_fifo;
+   int ret, i, tries = 3;
+
+   ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
+   if (ret) {
+   DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
+   return ret;
+   }
+
+   ret = shim->read_bstatus(intel_dig_port, bstatus);
+   if (ret)
+   return ret;
+
+   if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
+   DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
+   DRM_ERROR("Max Topology Limit Exceeded\n");
+   return -EPERM;
+   }
+
+   /*
+* When repeater reports 0 device count, HDCP1.4 spec allows disabling
+* the HDCP encryption. That implies that repeater can't have its own
+* 

[Intel-gfx] [PATCH v3 3/4] drm/i915: Check hdcp key loadability

2018-04-02 Thread Ramalingam C
HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.

This patch enables the hdcp initialization for HSW, BDW, and BXT.

v2:
  Choose the PW# based on the platform.
v3:
  No Changes.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 41 +--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index e0bc03eee941..94b7b5158169 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -37,6 +37,43 @@ static int intel_hdcp_poll_ksv_fifo(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
+static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)
+{
+   struct i915_power_domains *power_domains = _priv->power_domains;
+   struct i915_power_well *power_well;
+   enum i915_power_well_id id;
+   bool enabled = false;
+
+   /*
+* On HSW and BDW, Display HW loads the Key as soon as Display resumes.
+* On all BXT+, SW can load the keys only when the PW#1 is turned on.
+*/
+   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   id = HSW_DISP_PW_GLOBAL;
+   else
+   id = SKL_DISP_PW_1;
+
+   mutex_lock(_domains->lock);
+
+   /* PG1 (power well #1) needs to be enabled */
+   for_each_power_well(dev_priv, power_well) {
+   if (power_well->id == id) {
+   enabled = power_well->ops->is_enabled(dev_priv,
+ power_well);
+   break;
+   }
+   }
+   mutex_unlock(_domains->lock);
+
+   /*
+* Another req for hdcp key loadability is enabled state of pll for
+* cdclk. Without active crtc we wont land here. So we are assuming that
+* cdclk is already on.
+*/
+
+   return enabled;
+}
+
 static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
 {
I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
@@ -619,8 +656,8 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
  connector->base.name, connector->base.base.id);
 
-   if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
-   DRM_ERROR("PG1 is disabled, cannot load keys\n");
+   if (!hdcp_key_loadable(dev_priv)) {
+   DRM_ERROR("HDCP key Load is not possible\n");
return -ENXIO;
}
 
-- 
2.7.4

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Add NV12 support (rev7)

2018-04-02 Thread Patchwork
== Series Details ==

Series: Add NV12 support (rev7)
URL   : https://patchwork.freedesktop.org/series/39670/
State : success

== Summary ==

Series 39670v7 Add NV12 support
https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/7/mbox/

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:535s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:295s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:519s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:506s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:588s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:422s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:317s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:549s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:474s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:656s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:440s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:506s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:429s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:594s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:255  dwarn:4   dfail:0   fail:0   skip:26  
time:528s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:486s

c46052cde6a50c5459e00791ffc4d5aa1ec58a9e drm-tip: 2018y-03m-30d-18h-56m-26s UTC 
integration manifest
b1b23aa710c9 drm/i915: Set src size restrictions for NV12
2a6f6cd9bf0a drm/i915: Add NV12 support to intel_framebuffer_init
837c86649a3f drm/i915: Add NV12 as supported format for sprite plane
4585567b4b39 drm/i915: Add NV12 as supported format for primary plane
09621b20dba4 drm/i915: Upscale scaler max scale for NV12
b07ed5e02a2f drm/i915: Update format_is_yuv() to include NV12
69aabaf21998 drm/i915: Set scaler mode for NV12
0ab2b5a2cfdf drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
21067380dced drm/i915: Display WA 827
f906d62dcfc8 drm/i915/skl: split skl_compute_ddb function
887161fdb42a drm/i915/skl+: nv12 workaround disable WM level 1-7
3bd8a18d51f6 drm/i915/skl+: make sure higher latency level has higher wm value
5c8d3c51f18f drm/i915/skl+: pass skl_wm_level struct to wm compute func
bacb78f9fe3d drm/i915/skl+: NV12 related changes for WM
12f80e1cff7f drm/i915/skl+: support verification of DDB HW state for NV12
a296d167a4a6 drm/i915/skl+: add NV12 in skl_format_to_fourcc
aba1b53bed73 drm/i915/skl+: refactor WM calculation for NV12
b485c8e3c47f drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add NV12 support (rev7)

2018-04-02 Thread Patchwork
== Series Details ==

Series: Add NV12 support (rev7)
URL   : https://patchwork.freedesktop.org/series/39670/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b485c8e3c47f drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
aba1b53bed73 drm/i915/skl+: refactor WM calculation for NV12
a296d167a4a6 drm/i915/skl+: add NV12 in skl_format_to_fourcc
12f80e1cff7f drm/i915/skl+: support verification of DDB HW state for NV12
bacb78f9fe3d drm/i915/skl+: NV12 related changes for WM
5c8d3c51f18f drm/i915/skl+: pass skl_wm_level struct to wm compute func
3bd8a18d51f6 drm/i915/skl+: make sure higher latency level has higher wm value
887161fdb42a drm/i915/skl+: nv12 workaround disable WM level 1-7
f906d62dcfc8 drm/i915/skl: split skl_compute_ddb function
21067380dced drm/i915: Display WA 827
0ab2b5a2cfdf drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
69aabaf21998 drm/i915: Set scaler mode for NV12
b07ed5e02a2f drm/i915: Update format_is_yuv() to include NV12
09621b20dba4 drm/i915: Upscale scaler max scale for NV12
4585567b4b39 drm/i915: Add NV12 as supported format for primary plane
837c86649a3f drm/i915: Add NV12 as supported format for sprite plane
2a6f6cd9bf0a drm/i915: Add NV12 support to intel_framebuffer_init
b1b23aa710c9 drm/i915: Set src size restrictions for NV12
-:42: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#42: FILE: drivers/gpu/drm/i915/intel_sprite.c:259:
+   if (fb->format->format == DRM_FORMAT_NV12 &&
+   ((src_h % 4) != 0 || (src_w % 4) != 0)) {

-:62: CHECK:SPACING: spaces preferred around that '|' (ctx:VxV)
#62: FILE: drivers/gpu/drm/i915/intel_sprite.c:306:
+ ((crtc_w + 1) << 16)|(crtc_h + 1));
  ^

total: 0 errors, 0 warnings, 2 checks, 51 lines checked

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


Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of 4 for NV12

2018-04-02 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Thursday, March 29, 2018 2:19 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of
> 4 for NV12
> 
> Op 29-03-18 om 10:06 schreef Vidya Srinivas:
> > As per display WA 1106, to avoid corruption issues
> > NV12 plane height needs to be multiplier of 4 Hence we modify the fb
> > src and destination height and width to be multiples of 4. Without
> > this, pipe fifo underruns were seen on APL and KBL.
> >
> > Credits-to: Maarten Lankhorst 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h| 2 ++
> >  drivers/gpu/drm/i915/intel_sprite.c | 8 
> >  2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9c58da0..a1f718d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -159,6 +159,8 @@
> >  #define INTEL_I2C_BUS_DVO 1
> >  #define INTEL_I2C_BUS_SDVO 2
> >
> > +#define MULT4(x) ((x + 3) & ~0x03)
> > +
> >  /* these are outputs from the chip - integrated only
> > external chips are via DVO or SDVO output */  enum
> > intel_output_type { diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 538d938..9f466c6 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -261,6 +261,14 @@ skl_update_plane(struct intel_plane *plane,
> > crtc_w--;
> > crtc_h--;
> >
> > +   if (fb->format->format == DRM_FORMAT_NV12) {
> > +   src_w = MULT4(src_w);
> > +   src_h = MULT4(src_h);
> > +   crtc_w = MULT4(crtc_w);
> > +   crtc_h = MULT4(crtc_h);
> > +   DRM_ERROR("%d %d %d %d\n", src_w, src_h, crtc_w,
> crtc_h);
> > +   }
> > +
> > spin_lock_irqsave(_priv->uncore.lock, irqflags);
> >
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> 
> Nearly there!
> 
> Do we have limitations for width too? But I think we shouldn't ever adjust
> src for any format.
> This means that we should probably get rid of the drm_rect_adjust_size call
> in intel_check_sprite_plane.
> 
> If any limitations of NV12 are hit, we should reject with -EINVAL instead so
> userspace can decide what to do.
> The best place to put those checks is probably in skl_update_scaler, where
> they will be checked by the primary plane too.
> 
> This will mean the tests fail, but that can be fixed by selecting 16 as
> width/height for NV12 in IGT. If you change it to 16 you can put my r-b on it.
> 
> Also I think we should put the same limitations for width and height being a
> multiple in intel_framebuffer_init.
> 
> And on a final note for patch ordering, put the workaround and gen10 patch
> before enabling nv12 support.

Thank you. I have added the restriction in intel_framebuffer_init and have
re-ordered the series. Have also floated the i-g-t patch with 16x16 buffer
and I have included your r-b. Kindly have a check. Currently since we have 17x17
the restriction hits and kernel message fb dimensions are not right is seen for
tests. If the 16x16 i-g-t patch gets merged, we can get the results. On my side,
I have tested with many buffers (mult of 4) and no underruns are seen.
https://patchwork.freedesktop.org/series/39670/ (rev 7)
> 
> ~Maarten

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


[Intel-gfx] [PATCH v19 14/18] drm/i915: Upscale scaler max scale for NV12

2018-04-02 Thread Vidya Srinivas
From: Chandra Konduru 

This patch updates scaler max limit support for NV12

v2: Rebased (me)

v3: Rebased (me)

v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v5: Addressed review comments from Ville and rebased
- calculation of max_scale to be made
less convoluted by splitting it up a bit
- Indentation errors to be fixed in the series

v6: Rebased (me)
Fixed review comments from Paauwe, Bob J
Previous version, where a split of calculation
was done, was wrong. Fixed that issue here.

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Rebased (me)

v11: Addressed review comments from Shashank Sharma
Alignment issues fixed.
When call to skl_update_scaler is made, 0 was being
sent instead of pixel_format.
When crtc update scaler is called, we dont have the
fb to derive the pixel format. Added the function
parameter bool plane_scaler_check to account for this.

v12: Fixed failure in IGT debugfs_test.
fb is NULL in skl_update_scaler_plane
Due to this, accessing fb->format caused failure.
Patch checks fb before using.

v13: In the previous version there was a flaw.
In skl_update_scaler during plane_scaler_check
if the format was non-NV12, it would set need_scaling
to false. This could reset the previously set need_scaling
from a previous condition check. Patch fixes this.
Patch also adds minimum src height for YUV 420 formats
to 16 (as defined in BSpec) and adds for checking this
range.

v14: Addressed review comments from Maarten
Just add a check for NV12 min src height in
skl_update_scaler and retain the remaining checks
as is. Added Reviewed By from Juha-Pekka Heikkila.

v15: Rebased the series.

v16: Changed fb height restriction to be >= 16 as per
Bspec. Earlier it was > 16.

v17: Changed NV12 scaler out of range message debug
level from DRM_DEBUG_KMS to DRM_ERROR as commit fails
if it hits the condition.

v18: Restricting the src width and height to be multiplier
of 4 for NV12 in skl_update_scaler

Credits-to: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 49 
 drivers/gpu/drm/i915/intel_drv.h |  5 +++-
 drivers/gpu/drm/i915/intel_sprite.c  |  6 -
 3 files changed, 47 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 951583b..f8fea3d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3483,6 +3483,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_UYVY;
case DRM_FORMAT_VYUY:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
+   case DRM_FORMAT_NV12:
+   return PLANE_CTL_FORMAT_NV12;
default:
MISSING_CASE(pixel_format);
}
@@ -4727,7 +4729,9 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
 static int
 skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
  unsigned int scaler_user, int *scaler_id,
- int src_w, int src_h, int dst_w, int dst_h)
+ int src_w, int src_h, int dst_w, int dst_h,
+ bool plane_scaler_check,
+ uint32_t pixel_format)
 {
struct intel_crtc_scaler_state *scaler_state =
_state->scaler_state;
@@ -4745,6 +4749,10 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 */
need_scaling = src_w != dst_w || src_h != dst_h;
 
+   if (plane_scaler_check)
+   if (pixel_format == DRM_FORMAT_NV12)
+   need_scaling = true;
+
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
 
@@ -4784,6 +4792,14 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
return 0;
}
 
+   if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
+   (src_h < SKL_MIN_YUV_420_SRC_H || (src_h % 4) != 0 ||
+(src_w % 4) != 0)) {
+   DRM_DEBUG_KMS("NV12 %dx%d: src dimensions not valid\n",
+ src_w, src_h);
+   return -EINVAL;
+   }
+
/* range checks */
if (src_w < SKL_MIN_SRC_W || src_h < SKL_MIN_SRC_H ||
dst_w < SKL_MIN_DST_W || dst_h < SKL_MIN_DST_H ||
@@ -4823,9 +4839,10 @@ int skl_update_scaler_crtc(struct intel_crtc_state 
*state)
const struct drm_display_mode *adjusted_mode = 

[Intel-gfx] [PATCH v19 09/18] drm/i915/skl: split skl_compute_ddb function

2018-04-02 Thread Vidya Srinivas
From: Mahesh Kumar 

This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.

v2: Added reviewed by tag from Shashank Sharma

v3: Added reviewed by from Juha-Pekka Heikkila

v4: Rebased the series

v5: Fixed checkpatch error. Changed *changed = true
to (*changed) = true;

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_pm.c | 157 ++--
 1 file changed, 88 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3210868..ffed139 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5059,69 +5059,16 @@ skl_ddb_add_affected_planes(struct intel_crtc_state 
*cstate)
 static int
 skl_compute_ddb(struct drm_atomic_state *state)
 {
-   struct drm_device *dev = state->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct intel_crtc *intel_crtc;
struct skl_ddb_allocation *ddb = _state->wm_results.ddb;
-   uint32_t realloc_pipes = pipes_modified(state);
-   int ret;
-
-   /*
-* If this is our first atomic update following hardware readout,
-* we can't trust the DDB that the BIOS programmed for us.  Let's
-* pretend that all pipes switched active status so that we'll
-* ensure a full DDB recompute.
-*/
-   if (dev_priv->wm.distrust_bios_wm) {
-   ret = drm_modeset_lock(>mode_config.connection_mutex,
-  state->acquire_ctx);
-   if (ret)
-   return ret;
-
-   intel_state->active_pipe_changes = ~0;
-
-   /*
-* We usually only initialize intel_state->active_crtcs if we
-* we're doing a modeset; make sure this field is always
-* initialized during the sanitization process that happens
-* on the first commit too.
-*/
-   if (!intel_state->modeset)
-   intel_state->active_crtcs = dev_priv->active_crtcs;
-   }
-
-   /*
-* If the modeset changes which CRTC's are active, we need to
-* recompute the DDB allocation for *all* active pipes, even
-* those that weren't otherwise being modified in any way by this
-* atomic commit.  Due to the shrinking of the per-pipe allocations
-* when new active CRTC's are added, it's possible for a pipe that
-* we were already using and aren't changing at all here to suddenly
-* become invalid if its DDB needs exceeds its new allocation.
-*
-* Note that if we wind up doing a full DDB recompute, we can't let
-* any other display updates race with this transaction, so we need
-* to grab the lock on *all* CRTC's.
-*/
-   if (intel_state->active_pipe_changes) {
-   realloc_pipes = ~0;
-   intel_state->wm_results.dirty_pipes = ~0;
-   }
+   struct intel_crtc *crtc;
+   struct intel_crtc_state *cstate;
+   int ret, i;
 
-   /*
-* We're not recomputing for the pipes not included in the commit, so
-* make sure we start with the current state.
-*/
memcpy(ddb, _priv->wm.skl_hw.ddb, sizeof(*ddb));
 
-   for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
-   struct intel_crtc_state *cstate;
-
-   cstate = intel_atomic_get_crtc_state(state, intel_crtc);
-   if (IS_ERR(cstate))
-   return PTR_ERR(cstate);
-
+   for_each_new_intel_crtc_in_state(intel_state, crtc, cstate, i) {
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
@@ -5183,23 +5130,23 @@ skl_print_wm_changes(const struct drm_atomic_state 
*state)
 }
 
 static int
-skl_compute_wm(struct drm_atomic_state *state)
+skl_ddb_add_affected_pipes(struct drm_atomic_state *state, bool *changed)
 {
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *cstate;
-   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct skl_ddb_values *results = _state->wm_results;
struct drm_device *dev = state->dev;
-   struct skl_pipe_wm *pipe_wm;
-   bool changed = false;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_crtc *crtc;
+   const struct drm_crtc_state *cstate;
+   struct intel_crtc *intel_crtc;
+   struct 

[Intel-gfx] [PATCH v19 10/18] drm/i915: Display WA 827

2018-04-02 Thread Vidya Srinivas
Display WA 827 applies to GEN9 (excluede GLK) and CNL.
Switching the plane format from NV12 to RGB and leaving system idle
results in display underrun and corruption.
WA: Set the bit 15 & bit 19 to 1b in the CLKGATE_DIS_PSL
register for the pipe in which NV12 plane is enabled.

v2: Addressed review comments from Maarten and
Juha-Pekka Heikkila. Added reviewed by from
Juha-Pekka Heikkila.

v3: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_display.c | 34 ++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 176dca6..2afa96b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3812,6 +3812,9 @@ enum {
 #define _CLKGATE_DIS_PSL_A 0x46520
 #define _CLKGATE_DIS_PSL_B 0x46524
 #define _CLKGATE_DIS_PSL_C 0x46528
+#define   DUPS1_GATING_DIS (1 << 15)
+#define   DUPS2_GATING_DIS (1 << 19)
+#define   DUPS3_GATING_DIS (1 << 23)
 #define   DPF_GATING_DIS   (1 << 10)
 #define   DPF_RAM_GATING_DIS   (1 << 9)
 #define   DPFR_GATING_DIS  (1 << 8)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 28de533..b27e0b6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -488,6 +488,21 @@ static const struct intel_limit intel_limits_bxt = {
.p2 = { .p2_slow = 1, .p2_fast = 20 },
 };
 
+static void
+skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool enable)
+{
+   if (IS_SKYLAKE(dev_priv))
+   return;
+
+   if (enable)
+   I915_WRITE(CLKGATE_DIS_PSL(pipe),
+  DUPS1_GATING_DIS | DUPS2_GATING_DIS);
+   else
+   I915_WRITE(CLKGATE_DIS_PSL(pipe),
+  I915_READ(CLKGATE_DIS_PSL(pipe)) &
+  ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
+}
+
 static bool
 needs_modeset(const struct drm_crtc_state *state)
 {
@@ -5106,6 +5121,8 @@ static bool hsw_post_update_enable_ips(const struct 
intel_crtc_state *old_crtc_s
 static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
+   struct drm_device *dev = crtc->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct intel_crtc_state *pipe_config =

intel_atomic_get_new_crtc_state(to_intel_atomic_state(old_state),
@@ -5128,6 +5145,7 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
 
to_intel_plane(primary));
struct intel_plane_state *old_primary_state =
to_intel_plane_state(old_pri_state);
+   struct drm_framebuffer *fb = primary_state->base.fb;
 
intel_fbc_post_update(crtc);
 
@@ -5135,6 +5153,14 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
(needs_modeset(_config->base) ||
 !old_primary_state->base.visible))
intel_post_enable_primary(>base, pipe_config);
+
+   /* Display WA 827 */
+   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+   IS_CANNONLAKE(dev_priv)) {
+   if (fb && fb->format->format == DRM_FORMAT_NV12)
+   skl_wa_clkgate(dev_priv, crtc->pipe, false);
+   }
+
}
 }
 
@@ -5161,6 +5187,14 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
 
to_intel_plane(primary));
struct intel_plane_state *old_primary_state =
to_intel_plane_state(old_pri_state);
+   struct drm_framebuffer *fb = primary_state->base.fb;
+
+   /* Display WA 827 */
+   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+   IS_CANNONLAKE(dev_priv)) {
+   if (fb && fb->format->format == DRM_FORMAT_NV12)
+   skl_wa_clkgate(dev_priv, crtc->pipe, true);
+   }
 
intel_fbc_pre_update(crtc, pipe_config, primary_state);
/*
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 12/18] drm/i915: Set scaler mode for NV12

2018-04-02 Thread Vidya Srinivas
From: Chandra Konduru 

This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling

v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler

v3: Rebased (me)

v4: Rebased (me)

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)
Restricting the NV12 change for scaler to BXT and KBL
in this series.

v9: Rebased (me)

v10: As of now, NV12 has been tested on Gen9 and Gen10. However,
code is applicable to all GEN >= 9. Hence making
that change to keep it generic.
Comments under v8 is not valid anymore.

v11: Addressed review comments by Shashank Sharma.
For Gen10+, the scaler mode to be set it planar or normal
(single bit). Changed the code to be applicable to all
Gen.

v12: Addressed review comments from Shashank Sharma
For Gen9 (apart from GLK) bits 28:29 to be programmed
in PS_CTRL for NV12. For GLK and Gen10+, bit 29 to be set
for all Planar.

v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
Adding Reviewed by tag from Shashank Shamr

v14: Added reviewed by from Juha-Pekka Heikkila

v15: Rebased the series

Tested-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/intel_atomic.c | 14 --
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2afa96b..42f72a0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6652,6 +6652,8 @@ enum {
 #define PS_SCALER_MODE_MASK (3 << 28)
 #define PS_SCALER_MODE_DYN  (0 << 28)
 #define PS_SCALER_MODE_HQ  (1 << 28)
+#define SKL_PS_SCALER_MODE_NV12 (2 << 28)
+#define PS_SCALER_MODE_PLANAR (1 << 29)
 #define PS_PLANE_SEL_MASK  (7 << 25)
 #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
 #define PS_FILTER_MASK (3 << 23)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index e9fb6920..bb8c168 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -328,8 +328,18 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
}
 
/* set scaler mode */
-   if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
-   scaler_state->scalers[*scaler_id].mode = 0;
+   if ((INTEL_GEN(dev_priv) >= 9) &&
+   plane_state && plane_state->base.fb &&
+   plane_state->base.fb->format->format ==
+   DRM_FORMAT_NV12) {
+   if (INTEL_GEN(dev_priv) == 9 &&
+   !IS_GEMINILAKE(dev_priv) &&
+   !IS_SKYLAKE(dev_priv))
+   scaler_state->scalers[*scaler_id].mode =
+   SKL_PS_SCALER_MODE_NV12;
+   else
+   scaler_state->scalers[*scaler_id].mode =
+   PS_SCALER_MODE_PLANAR;
} else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) 
{
/*
 * when only 1 scaler is in use on either pipe A or B,
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 16/18] drm/i915: Add NV12 as supported format for sprite plane

2018-04-02 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 to list of supported formats for sprite plane.

v2: Rebased (me)

v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats

v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.

v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B

v7: Rebased (me)

v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.

v11: Addressed review comments from Shashank Sharma

v12: Addressed review comments from Shashank Sharma
Made the condition in intel_sprite_plane_create
simple and easy to read as suggested.

v13: Adding reviewed by tag from Shashank Sharma
Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Ville
Added skl_planar_formats to include NV12
and a check skl_plane_has_planar in sprite create
Added NV12 format to skl_mod_supported. These were
review comments from Kristian Høgsberg 

v15: Added reviewed by from Juha-Pekka Heikkila

v16: Rebased the series

Tested-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index aa1dfaa..d5dad44 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1253,6 +1253,19 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static uint32_t skl_planar_formats[] = {
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1347,6 +1360,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t 
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -1446,8 +1460,14 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
 
-   plane_formats = skl_plane_formats;
-   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   if (skl_plane_has_planar(dev_priv, pipe,
+PLANE_SPRITE0 + plane)) {
+   plane_formats = skl_planar_formats;
+   num_plane_formats = ARRAY_SIZE(skl_planar_formats);
+   } else {
+   plane_formats = skl_plane_formats;
+   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   }
 
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
modifiers = skl_plane_format_modifiers_ccs;
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 00/18] Add NV12 support

2018-04-02 Thread Vidya Srinivas
This patch series is adding NV12 support for Broxton display after rebasing on
latest drm-tip.
Initial series of the patches can be found here:
https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html

Previous revision history:
The first version of patches were reviewed when floated by Chandra in 2015
but currently there was a design change with respect to
- the way fb offset is handled
- the way rotation is handled
Current NV12 patch series has been ported as per the
current changes on drm-tip

Review comments from Ville (12th June 2017) have been addressed Review
comments from Clinton A Taylor (7th July 2017) have been addressed

Review comments from Clinton A Taylor (10th July 2017)
have been addressed. Had missed out tested-by/reviewed-by in the 
patches.
Fixed that error in this series.
Review comments from Ville (11th July 2017) addressed.
Review comments from Paauwe, Bob (29th July 2017) addressed.

Update from rev 28 Aug 2017
Rebased the series.
Tested with IGT for rotation, sprite and tiling combinations.
IGT Links:
https://patchwork.kernel.org/patch/9995943/
https://patchwork.kernel.org/patch/9995945/
Review comments by Maarten are addressed in this series.
NV12 enabled for Gen10.
Review comments from Shashank Sharma are addressed.
IGT debug_fs test failure fixed.
Added reviewed-by tag from Shashank Sharma for few patches
Addressed comments from Juha-Pekka Heikkila in few patches
(NV12 not to be supported for SKL)
Adding an additional patch Display WA 827 for underrun during NV12
Adding more WA implementation to see if it helps underruns
Addressed review comments from Ville regarding the planar formats
Added minimum src height for yuv 420 planar formats
Added NV12 in skl_mod_supported
(review comments from Kristian Høgsberg 

Update from previous series:
Addressed review comments from Ville and Maarten
Re-ordered the series as per Maarten's suggestion

Chandra Konduru (6):
  drm/i915: Set scaler mode for NV12
  drm/i915: Update format_is_yuv() to include NV12
  drm/i915: Upscale scaler max scale for NV12
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane
  drm/i915: Add NV12 support to intel_framebuffer_init

Mahesh Kumar (9):
  drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
  drm/i915/skl+: refactor WM calculation for NV12
  drm/i915/skl+: add NV12 in skl_format_to_fourcc
  drm/i915/skl+: support verification of DDB HW state for NV12
  drm/i915/skl+: NV12 related changes for WM
  drm/i915/skl+: pass skl_wm_level struct to wm compute func
  drm/i915/skl+: make sure higher latency level has higher wm value
  drm/i915/skl+: nv12 workaround disable WM level 1-7
  drm/i915/skl: split skl_compute_ddb function

Vidya Srinivas (3):
  drm/i915: Display WA 827
  drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
  drm/i915: Set src size restrictions for NV12

 drivers/gpu/drm/i915/i915_drv.h  |  10 +-
 drivers/gpu/drm/i915/i915_reg.h  |   5 +
 drivers/gpu/drm/i915/intel_atomic.c  |  14 +-
 drivers/gpu/drm/i915/intel_display.c | 162 +++--
 drivers/gpu/drm/i915/intel_drv.h |  15 +-
 drivers/gpu/drm/i915/intel_pm.c  | 438 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  50 +++-
 7 files changed, 502 insertions(+), 192 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH v19 01/18] drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values

2018-04-02 Thread Vidya Srinivas
From: Mahesh Kumar 

skl_wm_values struct contains values of pipe/plane DDB only.
so rename it for better readability of code. Similarly
skl_copy_wm_for_pipe copies DDB values.

s/skl_wm_values/skl_ddb_values
s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe

Changes since V1:
 - also change name of skl_copy_wm_for_pipe

v2: Added reviewed by from Juha-Pekka Heikkila

v3: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.h  |  4 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 16 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b17..d3c80d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1186,7 +1186,7 @@ struct skl_ddb_allocation {
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
-struct skl_wm_values {
+struct skl_ddb_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
 };
@@ -1885,7 +1885,7 @@ struct drm_i915_private {
/* current hardware state */
union {
struct ilk_wm_values hw;
-   struct skl_wm_values skl_hw;
+   struct skl_ddb_values skl_hw;
struct vlv_wm_values vlv;
struct g4x_wm_values g4x;
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d1452fd..7f77e6d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -482,7 +482,7 @@ struct intel_atomic_state {
bool skip_intermediate_wm;
 
/* Gen9+ only */
-   struct skl_wm_values wm_results;
+   struct skl_ddb_values wm_results;
 
struct i915_sw_fence commit_ready;
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 19e82aa..d2963bc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5042,9 +5042,9 @@ skl_compute_ddb(struct drm_atomic_state *state)
 }
 
 static void
-skl_copy_wm_for_pipe(struct skl_wm_values *dst,
-struct skl_wm_values *src,
-enum pipe pipe)
+skl_copy_ddb_for_pipe(struct skl_ddb_values *dst,
+ struct skl_ddb_values *src,
+ enum pipe pipe)
 {
memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
   sizeof(dst->ddb.y_plane[pipe]));
@@ -5095,7 +5095,7 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc *crtc;
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct skl_wm_values *results = _state->wm_results;
+   struct skl_ddb_values *results = _state->wm_results;
struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
@@ -5197,8 +5197,8 @@ static void skl_initial_wm(struct intel_atomic_state 
*state,
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct skl_wm_values *results = >wm_results;
-   struct skl_wm_values *hw_vals = _priv->wm.skl_hw;
+   struct skl_ddb_values *results = >wm_results;
+   struct skl_ddb_values *hw_vals = _priv->wm.skl_hw;
enum pipe pipe = intel_crtc->pipe;
 
if ((results->dirty_pipes & drm_crtc_mask(_crtc->base)) == 0)
@@ -5209,7 +5209,7 @@ static void skl_initial_wm(struct intel_atomic_state 
*state,
if (cstate->base.active_changed)
skl_atomic_update_crtc_wm(state, cstate);
 
-   skl_copy_wm_for_pipe(hw_vals, results, pipe);
+   skl_copy_ddb_for_pipe(hw_vals, results, pipe);
 
mutex_unlock(_priv->wm.wm_mutex);
 }
@@ -5341,7 +5341,7 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
 void skl_wm_get_hw_state(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct skl_wm_values *hw = _priv->wm.skl_hw;
+   struct skl_ddb_values *hw = _priv->wm.skl_hw;
struct skl_ddb_allocation *ddb = _priv->wm.skl_hw.ddb;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 17/18] drm/i915: Add NV12 support to intel_framebuffer_init

2018-04-02 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (Chandra Konduru)

v3: rebased (me)

v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case

v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.

v6: Rebased (me)

v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.

v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.

v9: Rebased (me)

v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable

v11: Addressed review comments from Shashank Sharma

v12: Adding Reviewed By from Shashank Sharma

v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Maarten.
Add checks for fb width height for NV12 and fail the fb
creation if check fails. Added reviewed by from
Juha-Pekka Heikkila

v15: Rebased the series

v16: Setting the minimum value during fb creating to 16
as per Bspec for NV12. Earlier minimum was expected
to be > 16. Now changed it to >=16.

v17: Restricting fb source width and height to multiplier of
4 in intel_framebuffer_init

Credits-to: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6941b30..9f7babf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14253,6 +14253,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_NV12:
+   if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv)) {
+   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
+ 
drm_get_format_name(mode_cmd->pixel_format,
+ _name));
+   goto err;
+   }
+   break;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
@@ -14265,6 +14273,16 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 
drm_helper_mode_fill_fb_struct(_priv->drm, fb, mode_cmd);
 
+   if (fb->format->format == DRM_FORMAT_NV12 &&
+   (fb->width < SKL_MIN_YUV_420_SRC_W ||
+fb->height < SKL_MIN_YUV_420_SRC_H ||
+(fb->width % 4) != 0 ||
+(fb->height % 4) != 0)) {
+   DRM_DEBUG_KMS("src fb %d x %d: dimensions not "
+ "met for planar format\n", fb->width, fb->height);
+   return -EINVAL;
+   }
+
for (i = 0; i < fb->format->num_planes; i++) {
u32 stride_alignment;
 
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 05/18] drm/i915/skl+: NV12 related changes for WM

2018-04-02 Thread Vidya Srinivas
From: Mahesh Kumar 

NV12 requires WM calculation for UV plane as well.
UV plane WM should also fulfill all the WM related restrictions.

v2: Addressed review comments from Shashank Sharma.

v3: Addressed review comments from Shashank Sharma
Changed plane_num to plane_id in skl_compute_plane_wm_params
and skl_compute_plane_wm.
Adding reviewed by tag from Shashank Sharma

v4: Added reviewed by from Juha-Pekka Heikkila

v5: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 50 +---
 3 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d499264..3115d26 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1202,6 +1202,7 @@ struct skl_wm_level {
 struct skl_wm_params {
bool x_tiled, y_tiled;
bool rc_surface;
+   bool is_planar;
uint32_t width;
uint8_t cpp;
uint32_t plane_pixel_rate;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ed79a61..272c091 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -602,6 +602,7 @@ struct intel_pipe_wm {
 
 struct skl_plane_wm {
struct skl_wm_level wm[8];
+   struct skl_wm_level uv_wm[8];
struct skl_wm_level trans_wm;
bool is_planar;
 };
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0f99652..854671f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4419,7 +4419,7 @@ static int
 skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
const struct intel_plane_state *intel_pstate,
-   struct skl_wm_params *wp)
+   struct skl_wm_params *wp, int plane_id)
 {
struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
const struct drm_plane_state *pstate = _pstate->base;
@@ -4432,6 +4432,12 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
if (!intel_wm_plane_visible(cstate, intel_pstate))
return 0;
 
+   /* only NV12 format has two planes */
+   if (plane_id == 1 && fb->format->format != DRM_FORMAT_NV12) {
+   DRM_DEBUG_KMS("Non NV12 format have single plane\n");
+   return -EINVAL;
+   }
+
wp->y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
  fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
  fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
@@ -4439,6 +4445,7 @@ skl_compute_plane_wm_params(const struct drm_i915_private 
*dev_priv,
wp->x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
wp->rc_surface = fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
 fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+   wp->is_planar = fb->format->format == DRM_FORMAT_NV12;
 
if (plane->id == PLANE_CURSOR) {
wp->width = intel_pstate->base.crtc_w;
@@ -4451,7 +4458,10 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
wp->width = drm_rect_width(_pstate->base.src) >> 16;
}
 
-   wp->cpp = fb->format->cpp[0];
+   if (plane_id == 1 && wp->is_planar)
+   wp->width /= 2;
+
+   wp->cpp = fb->format->cpp[plane_id];
wp->plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate,
 intel_pstate);
 
@@ -4649,7 +4659,8 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
  struct intel_crtc_state *cstate,
  const struct intel_plane_state *intel_pstate,
  const struct skl_wm_params *wm_params,
- struct skl_plane_wm *wm)
+ struct skl_plane_wm *wm,
+ int plane_id)
 {
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_plane *plane = intel_pstate->base.plane;
@@ -4657,15 +4668,19 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
int level, max_level = ilk_wm_max_level(dev_priv);
+   enum plane_id intel_plane_id = intel_plane->id;
int ret;
 
if (WARN_ON(!intel_pstate->base.fb))
return -EINVAL;
 
-   ddb_blocks = skl_ddb_entry_size(>plane[pipe][intel_plane->id]);
+   ddb_blocks = plane_id ?
+   

[Intel-gfx] [PATCH v19 15/18] drm/i915: Add NV12 as supported format for primary plane

2018-04-02 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 to list of supported formats for
primary plane

v2: Rebased (Chandra Konduru)

v3: Rebased (me)

v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats

v5: Rebased (me)

v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v7: Review comments by Ville addressed
Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)

v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.

v11: Adding Reviewed By tag from Shashank Sharma

v12: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v13: Addressed review comments from Ville
Added skl_pri_planar_formats to include NV12
and skl_plane_has_planar function to check for
NV12 support on plane. Added NV12 format to
skl_mod_supported. These were review comments
from Kristian Høgsberg 

v14: Added reviewed by from Juha-Pekka Heikkila

v15: Rebased the series

Tested-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 50 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f8fea3d..6941b30 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,6 +88,22 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint32_t skl_pri_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13118,6 +13134,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t 
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -13325,6 +13342,30 @@ static bool skl_plane_has_fbc(struct drm_i915_private 
*dev_priv,
return pipe == PIPE_A && plane_id == PLANE_PRIMARY;
 }
 
+bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum plane_id plane_id)
+{
+   if (plane_id == PLANE_PRIMARY) {
+   if (IS_SKYLAKE(dev_priv))
+   return false;
+   else if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C) &&
+!IS_GEMINILAKE(dev_priv))
+   return false;
+   } else if (plane_id >= PLANE_SPRITE0) {
+   if (plane_id == PLANE_CURSOR)
+   return false;
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) == 10) {
+   if (plane_id != PLANE_SPRITE0)
+   return false;
+   } else {
+   if (plane_id != PLANE_SPRITE0 || pipe == PIPE_C ||
+   IS_SKYLAKE(dev_priv))
+   return false;
+   }
+   }
+   return true;
+}
+
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13385,8 +13426,13 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
primary->check_plane = intel_check_primary_plane;
 
if (INTEL_GEN(dev_priv) >= 9) {
-   intel_primary_formats = skl_primary_formats;
-   num_formats = ARRAY_SIZE(skl_primary_formats);
+   if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+   intel_primary_formats = skl_pri_planar_formats;
+   num_formats = ARRAY_SIZE(skl_pri_planar_formats);
+   } else {
+   intel_primary_formats = skl_primary_formats;
+   num_formats = ARRAY_SIZE(skl_primary_formats);
+   }
 
if 

[Intel-gfx] [PATCH v19 02/18] drm/i915/skl+: refactor WM calculation for NV12

2018-04-02 Thread Vidya Srinivas
From: Mahesh Kumar 

Current code calculates DDB for planar formats in such a way that we
store DDB of plane-0 in plane 1 & vice-versa.
In order to make this clean this patch refactors WM/DDB calculation for
NV12 planar formats.

v2: Addressed review comments by Maarten

v3: Rebased and addressed review comments by Maarten

v4: Fixed a compilation issue of string replacement is_nv12 to
is_planar

v5: Added reviewed by from Juha-Pekka Heikkila

v6: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_drv.h  |   5 +-
 drivers/gpu/drm/i915/intel_drv.h |   1 +
 drivers/gpu/drm/i915/intel_pm.c  | 121 ---
 3 files changed, 66 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d3c80d4..d499264 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1182,8 +1182,9 @@ static inline bool skl_ddb_entry_equal(const struct 
skl_ddb_entry *e1,
 }
 
 struct skl_ddb_allocation {
-   struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
packed/uv */
-   struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
+   /* packed/y */
+   struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES];
+   struct skl_ddb_entry uv_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
 struct skl_ddb_values {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7f77e6d..d7310fe 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -603,6 +603,7 @@ struct intel_pipe_wm {
 struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level trans_wm;
+   bool is_planar;
 };
 
 struct skl_pipe_wm {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d2963bc..c051cd3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4009,9 +4009,9 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
*intel_crtc,
 static unsigned int
 skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
 const struct drm_plane_state *pstate,
-int y)
+const int plane)
 {
-   struct intel_plane *plane = to_intel_plane(pstate->plane);
+   struct intel_plane *intel_plane = to_intel_plane(pstate->plane);
struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
uint32_t data_rate;
uint32_t width = 0, height = 0;
@@ -4025,9 +4025,9 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
fb = pstate->fb;
format = fb->format->format;
 
-   if (plane->id == PLANE_CURSOR)
+   if (intel_plane->id == PLANE_CURSOR)
return 0;
-   if (y && format != DRM_FORMAT_NV12)
+   if (plane == 1 && format != DRM_FORMAT_NV12)
return 0;
 
/*
@@ -4038,19 +4038,14 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
width = drm_rect_width(_pstate->base.src) >> 16;
height = drm_rect_height(_pstate->base.src) >> 16;
 
-   /* for planar format */
-   if (format == DRM_FORMAT_NV12) {
-   if (y)  /* y-plane data rate */
-   data_rate = width * height *
-   fb->format->cpp[0];
-   else/* uv-plane data rate */
-   data_rate = (width / 2) * (height / 2) *
-   fb->format->cpp[1];
-   } else {
-   /* for packed formats */
-   data_rate = width * height * fb->format->cpp[0];
+   /* UV plane does 1/2 pixel sub-sampling */
+   if (plane == 1 && format == DRM_FORMAT_NV12) {
+   width /= 2;
+   height /= 2;
}
 
+   data_rate = width * height * fb->format->cpp[plane];
+
down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
 
return mul_round_up_u32_fixed16(data_rate, down_scale_amount);
@@ -4063,8 +4058,8 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
  */
 static unsigned int
 skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate,
-unsigned *plane_data_rate,
-unsigned *plane_y_data_rate)
+unsigned int *plane_data_rate,
+unsigned int *uv_plane_data_rate)
 {
struct drm_crtc_state *cstate = _cstate->base;
struct drm_atomic_state *state = cstate->state;
@@ -4080,17 +4075,17 @@ skl_get_total_relative_data_rate(struct 
intel_crtc_state *intel_cstate,
enum 

[Intel-gfx] [PATCH v19 13/18] drm/i915: Update format_is_yuv() to include NV12

2018-04-02 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 to format_is_yuv() function
for sprite planes.

v2:
-Use intel_ prefix for format_is_yuv (Ville)

v3: Rebased (me)

v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to the primary plane functions".
Changed commit message - function modified for
sprite planes.

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Changed intel_format_is_yuv function from
static to non-static. We need to use it later from
other files for check.

v11: Rebased the patch. format_is_yuv has already
been renamed to intel_format_is_yuv in the color
patch series which is already merged. This function
which was previously static has already been made
non-static. So this patch after rebase just adds
NV12 to intel_format_is_yuv function.

v12: Added reviewed by from Juha-Pekka Heikkila

v13/v14/v15: Rebased the series

Tested-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_sprite.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 272c091..de7ddb1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2054,6 +2054,7 @@ void skl_disable_plane(struct intel_plane *plane, struct 
intel_crtc *crtc);
 bool skl_plane_get_hw_state(struct intel_plane *plane);
 bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
   enum pipe pipe, enum plane_id plane_id);
+bool intel_format_is_yuv(uint32_t format);
 
 /* intel_tv.c */
 void intel_tv_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index dbdcf85..0652e58 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -48,6 +48,7 @@ bool intel_format_is_yuv(u32 format)
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_NV12:
return true;
default:
return false;
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 03/18] drm/i915/skl+: add NV12 in skl_format_to_fourcc

2018-04-02 Thread Vidya Srinivas
From: Mahesh Kumar 

Add support of recognizing DRM_FORMAT_NV12 from plane_format
register value.

v2: Added reviewed by tag from Mika Kahola

v3: Added reviewed by from Juha-Pekka Heikkila

v4: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Mika Kahola 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 415fb8c..3038218 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2662,6 +2662,8 @@ static int skl_format_to_fourcc(int format, bool 
rgb_order, bool alpha)
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
return DRM_FORMAT_RGB565;
+   case PLANE_CTL_FORMAT_NV12:
+   return DRM_FORMAT_NV12;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

2018-04-02 Thread Vidya Srinivas
As per display WA 1106, to avoid corruption issues
NV12 plane height needs to be multiplier of 4
We expect the src dimensions to be multiplier of 4
We fail the case where src width or height is not
multiple of 4 for NV12.
We also set the scaler destination height
and width to be multiple of 4. Without this, pipe
fifo underruns were seen on APL and KBL. We also
skip src trunction/adjustments for NV12 case and handle
the sizes directly in skl_update_plane

Credits-to: Maarten Lankhorst 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_drv.h|  2 ++
 drivers/gpu/drm/i915/intel_sprite.c | 19 ---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9c58da0..a1f718d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -159,6 +159,8 @@
 #define INTEL_I2C_BUS_DVO 1
 #define INTEL_I2C_BUS_SDVO 2
 
+#define MULT4(x) ((x + 3) & ~0x03)
+
 /* these are outputs from the chip - integrated only
external chips are via DVO or SDVO output */
 enum intel_output_type {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index d5dad44..b2292dd 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
unsigned long irqflags;
 
+   if (fb->format->format == DRM_FORMAT_NV12 &&
+   ((src_h % 4) != 0 || (src_w % 4) != 0)) {
+   DRM_DEBUG_KMS("NV12: src dimensions not valid\n");
+   return;
+   }
+
/* Sizes are 0 based */
src_w--;
src_h--;
@@ -292,9 +298,12 @@ skl_update_plane(struct intel_plane *plane,
  PS_SCALER_EN | PS_PLANE_SEL(plane_id) | 
scaler->mode);
I915_WRITE_FW(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
I915_WRITE_FW(SKL_PS_WIN_POS(pipe, scaler_id), (crtc_x << 16) | 
crtc_y);
-   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
- ((crtc_w + 1) << 16)|(crtc_h + 1));
-
+   if (fb->format->format == DRM_FORMAT_NV12)
+   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
+ (MULT4(crtc_w) << 16) | MULT4(crtc_h));
+   else
+   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
+ ((crtc_w + 1) << 16)|(crtc_h + 1));
I915_WRITE_FW(PLANE_POS(pipe, plane_id), 0);
} else {
I915_WRITE_FW(PLANE_POS(pipe, plane_id), (crtc_y << 16) | 
crtc_x);
@@ -969,6 +978,9 @@ intel_check_sprite_plane(struct intel_plane *plane,
return -EINVAL;
}
 
+   if (fb->format->format == DRM_FORMAT_NV12)
+   goto check_plane_surface;
+
/* setup can_scale, min_scale, max_scale */
if (INTEL_GEN(dev_priv) >= 9) {
if (state->base.fb)
@@ -1112,6 +1124,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
dst->y1 = crtc_y;
dst->y2 = crtc_y + crtc_h;
 
+check_plane_surface:
if (INTEL_GEN(dev_priv) >= 9) {
ret = skl_check_plane_surface(crtc_state, state);
if (ret)
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 06/18] drm/i915/skl+: pass skl_wm_level struct to wm compute func

2018-04-02 Thread Vidya Srinivas
From: Mahesh Kumar 

This patch passes skl_wm_level structure itself to watermark
computation function skl_compute_plane_wm function (instead
of its internal parameters). It reduces number of arguments
required to be passed.

v2: Addressed review comments by Shashank Sharma

v3: Adding reviewed by tag from Shashank Sharma

v4: Added reviewed by from Juha-Pekka Heikkila

v5: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_pm.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 854671f..eb17464 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4529,9 +4529,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
-   uint16_t *out_blocks, /* out */
-   uint8_t *out_lines, /* out */
-   bool *enabled /* out */)
+   struct skl_wm_level *result /* out */)
 {
const struct drm_plane_state *pstate = _pstate->base;
uint32_t latency = dev_priv->wm.skl_latency[level];
@@ -4545,7 +4543,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 
if (latency == 0 ||
!intel_wm_plane_visible(cstate, intel_pstate)) {
-   *enabled = false;
+   result->plane_en = false;
return 0;
}
 
@@ -4626,7 +4624,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if ((level > 0 && res_lines > 31) ||
res_blocks >= ddb_allocation ||
min_disp_buf_needed >= ddb_allocation) {
-   *enabled = false;
+   result->plane_en = false;
 
/*
 * If there are no valid level 0 watermarks, then we can't
@@ -4646,9 +4644,9 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
 
/* The number of lines are ignored for the level 0 watermark. */
-   *out_lines = level ? res_lines : 0;
-   *out_blocks = res_blocks;
-   *enabled = true;
+   result->plane_res_b = res_blocks;
+   result->plane_res_l = res_lines;
+   result->plane_en = true;
 
return 0;
 }
@@ -4688,9 +4686,7 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
   ddb_blocks,
   level,
   wm_params,
-  >plane_res_b,
-  >plane_res_l,
-  >plane_en);
+  result);
if (ret)
return ret;
}
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 11/18] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg

2018-04-02 Thread Vidya Srinivas
If the fb format is YUV, enable the plane CSC mode bits
for the conversion.

v2: Addressed review comments from Shashank Sharma
Alignment issue fixed in i915_reg.h

v3: Adding Reviewed By from Shashank Sharma

v4: Rebased the patch. As part of rebasing, re-using
the color series defines which are already merged.
plane_state->base.color_encoding might not be set for
NV12. For now, just using PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709
in glk_plane_color_ctl if format is NV12.

v5: Added reviewed by from Juha-Pekka Heikkila

v6: Rebased the series

Reviewed-by: Shashank Sharma 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b27e0b6..951583b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3630,6 +3630,11 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
 
if (intel_format_is_yuv(fb->format->format)) {
+   if (fb->format->format == DRM_FORMAT_NV12) {
+   plane_color_ctl |=
+   PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
+   goto out;
+   }
if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
plane_color_ctl |= 
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
else
@@ -3638,7 +3643,7 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
plane_color_ctl |= 
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
}
-
+out:
return plane_color_ctl;
 }
 
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 04/18] drm/i915/skl+: support verification of DDB HW state for NV12

2018-04-02 Thread Vidya Srinivas
From: Mahesh Kumar 

For YUV 420 Planar formats like NV12,
buffer allocation is done for Y and UV surfaces separately.
For NV12 plane formats, the UV buffer
allocation must be programmed in the Plane Buffer Config register
and the Y buffer allocation must be programmed in the
Plane NV12 Buffer Config register. Both register values
should be verified during verify_wm_state.

v2: Addressed review comments by Maarten.

v3: Addressed review comments by Shashank Sharma.

v4: Adding reviewed by tag from Shashank Sharma

v5: Added reviewed by from Juha-Pekka Heikkila

v6: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 51 +---
 3 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3038218..28de533 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2657,7 +2657,7 @@ static int i9xx_format_to_fourcc(int format)
}
 }
 
-static int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
 {
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7310fe..ed79a61 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1612,6 +1612,7 @@ u32 skl_plane_stride(const struct drm_framebuffer *fb, 
int plane,
 int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
 int i9xx_check_plane_surface(struct intel_plane_state *plane_state);
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha);
 
 /* intel_csr.c */
 void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c051cd3..0f99652 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3825,6 +3825,44 @@ static void skl_ddb_entry_init_from_hw(struct 
skl_ddb_entry *entry, u32 reg)
entry->end += 1;
 }
 
+static void
+skl_ddb_get_hw_plane_state(struct drm_i915_private *dev_priv,
+  const enum pipe pipe,
+  const enum plane_id plane_id,
+  struct skl_ddb_allocation *ddb /* out */)
+{
+   u32 val, val2 = 0;
+   int fourcc, pixel_format;
+
+   /* Cursor doesn't support NV12/planar, so no extra calculation needed */
+   if (plane_id == PLANE_CURSOR) {
+   val = I915_READ(CUR_BUF_CFG(pipe));
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   return;
+   }
+
+   val = I915_READ(PLANE_CTL(pipe, plane_id));
+
+   /* No DDB allocated for disabled planes */
+   if (!(val & PLANE_CTL_ENABLE))
+   return;
+
+   pixel_format = val & PLANE_CTL_FORMAT_MASK;
+   fourcc = skl_format_to_fourcc(pixel_format,
+ val & PLANE_CTL_ORDER_RGBX,
+ val & PLANE_CTL_ALPHA_MASK);
+
+   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+   val2 = I915_READ(PLANE_NV12_BUF_CFG(pipe, plane_id));
+
+   if (fourcc == DRM_FORMAT_NV12) {
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val2);
+   skl_ddb_entry_init_from_hw(>uv_plane[pipe][plane_id], val);
+   } else {
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   }
+}
+
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */)
 {
@@ -3841,16 +3879,9 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
 
-   for_each_plane_id_on_crtc(crtc, plane_id) {
-   u32 val;
-
-   if (plane_id != PLANE_CURSOR)
-   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
-   else
-   val = I915_READ(CUR_BUF_CFG(pipe));
-
-   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], 
val);
-   }
+   for_each_plane_id_on_crtc(crtc, plane_id)
+   skl_ddb_get_hw_plane_state(dev_priv, pipe,
+  plane_id, ddb);
 
intel_display_power_put(dev_priv, power_domain);
}
-- 
2.7.4

___
Intel-gfx 

[Intel-gfx] [PATCH v19 07/18] drm/i915/skl+: make sure higher latency level has higher wm value

2018-04-02 Thread Vidya Srinivas
From: Mahesh Kumar 

DDB allocation optimization algorithm requires/assumes ddb allocation for
any memory C-state level DDB value to be as high as level below the
current level. Render decompression requires level WM to be as high as
wm level-0. This patch fulfils both the requirements.

v2: Changed plane_num to plane_id in skl_compute_wm_levels

v3: Addressed review comments from Shashank Sharma
Changed the commit message "statement can be more clear,
"DDB value to be as high as level below " what is level below ?"

v4: Added reviewed by tag from Shashank Sharma

v5: Added reviewed by from Juha-Pekka Heikkila

v6: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_pm.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index eb17464..b318a27 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4529,6 +4529,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
+   const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */)
 {
const struct drm_plane_state *pstate = _pstate->base;
@@ -4596,6 +4597,15 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
} else {
res_blocks++;
}
+
+   /*
+* Make sure result blocks for higher latency levels are atleast
+* as high as level below the current level.
+* Assumption in DDB algorithm optimization for special cases.
+* Also covers Display WA #1125 for RC.
+*/
+   if (result_prev->plane_res_b > res_blocks)
+   res_blocks = result_prev->plane_res_b;
}
 
if (INTEL_GEN(dev_priv) >= 11) {
@@ -4679,6 +4689,13 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = plane_id ? >uv_wm[level] :
  >wm[level];
+   struct skl_wm_level *result_prev;
+
+   if (level)
+   result_prev = plane_id ? >uv_wm[level - 1] :
+ >wm[level - 1];
+   else
+   result_prev = plane_id ? >uv_wm[0] : >wm[0];
 
ret = skl_compute_plane_wm(dev_priv,
   cstate,
@@ -4686,6 +4703,7 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
   ddb_blocks,
   level,
   wm_params,
+  result_prev,
   result);
if (ret)
return ret;
-- 
2.7.4

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


[Intel-gfx] [PATCH v19 08/18] drm/i915/skl+: nv12 workaround disable WM level 1-7

2018-04-02 Thread Vidya Srinivas
From: Mahesh Kumar 

Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable latency levels 1 through 7
(WM1 - WM7) on NV12 planes.

v2: Addressed review comments by Maarten.

v3: Adding reviewed by tag from Shashank Sharma

v4: Added reviewed by from Juha-Pekka Heikkila

v5: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_pm.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b318a27..3210868 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4653,6 +4653,17 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
}
 
+   /*
+* Display WA #826 (SKL:ALL, BXT:ALL) & #1059 (CNL:A)
+* disable wm level 1-7 on NV12 planes
+*/
+   if (wp->is_planar && level >= 1 &&
+   (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
+IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))) {
+   result->plane_en = false;
+   return 0;
+   }
+
/* The number of lines are ignored for the level 0 watermark. */
result->plane_res_b = res_blocks;
result->plane_res_l = res_lines;
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Read Vprime thrice incase of mismatch

2018-04-02 Thread Ramalingam C



On Thursday 29 March 2018 08:08 PM, Sean Paul wrote:

On Thu, Mar 29, 2018 at 07:39:06PM +0530, Ramalingam C wrote:

In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.

This patch needed for DP HDCP1.4 CTS Test: 1B-05.

v2:
   Moved the V' validation into a function for retry. [Sean Paul]

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_hdcp.c | 113 +++---
  1 file changed, 70 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 96b9025dc759..f77d956b2b18 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -142,53 +142,17 @@ bool intel_hdcp_is_ksv_valid(u8 *ksv)
return true;
  }
  
-/* Implements Part 2 of the HDCP authorization procedure */

-static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+static inline

Why inline?

Its a mistake. Will correct it. thanks



+int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
+   const struct intel_hdcp_shim *shim,
+   u8 *ksv_fifo, u8 num_downstream, u8 *bstatus)
  {
struct drm_i915_private *dev_priv;
u32 vprime, sha_text, sha_leftovers, rep_ctl;
-   u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, j, sha_idx;
  
  	dev_priv = intel_dig_port->base.base.dev->dev_private;
  
-	ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);

-   if (ret) {
-   DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
-   return ret;
-   }
-
-   ret = shim->read_bstatus(intel_dig_port, bstatus);
-   if (ret)
-   return ret;
-
-   if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
-   DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
-   DRM_ERROR("Max Topology Limit Exceeded\n");
-   return -EPERM;
-   }
-
-   /*
-* When repeater reports 0 device count, HDCP1.4 spec allows disabling
-* the HDCP encryption. That implies that repeater can't have its own
-* display. As there is no consumption of encrypted content in the
-* repeater with 0 downstream devices, we are failing the
-* authentication.
-*/
-   num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
-   if (num_downstream == 0)
-   return -EINVAL;
-
-   ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
-   if (!ksv_fifo)
-   return -ENOMEM;
-
-   ret = shim->read_ksv_fifo(intel_dig_port, num_downstream, ksv_fifo);
-   if (ret)
-   return ret;
-
/* Process V' values from the receiver */
for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
ret = shim->read_v_prime_part(intel_dig_port, i, );
@@ -353,7 +317,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
return ret;
sha_idx += sizeof(sha_text);
} else {
-   DRM_ERROR("Invalid number of leftovers %d\n", sha_leftovers);
+   DRM_DEBUG("Invalid number of leftovers %d\n", sha_leftovers);
return -EINVAL;
}
  
@@ -381,14 +345,77 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,

if (intel_wait_for_register(dev_priv, HDCP_REP_CTL,
HDCP_SHA1_COMPLETE,
HDCP_SHA1_COMPLETE, 1)) {
-   DRM_ERROR("Timed out waiting for SHA1 complete\n");
+   DRM_DEBUG("Timed out waiting for SHA1 complete\n");
return -ETIMEDOUT;
}
if (!(I915_READ(HDCP_REP_CTL) & HDCP_SHA1_V_MATCH)) {
-   DRM_ERROR("SHA-1 mismatch, HDCP failed\n");
+   DRM_DEBUG("SHA-1 mismatch, HDCP failed\n");

I think the DEBUG should be DEBUG_KMS, consistent with the rest of the file?

Will make it uniform

--Ram



return -ENXIO;
}
  
+	return 0;

+}
+
+/* Implements Part 2 of the HDCP authorization procedure */
+static
+int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
+  const struct intel_hdcp_shim *shim)
+{
+   u8 bstatus[2], num_downstream, *ksv_fifo;
+   int ret, i, tries = 3;
+
+   ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
+   if (ret) {
+   DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
+   return ret;
+   }
+
+   ret = shim->read_bstatus(intel_dig_port, bstatus);
+   if (ret)
+   return ret;
+
+   if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
+   DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
+   DRM_ERROR("Max Topology Limit Exceeded\n");
+   return -EPERM;
+

Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of 4 for NV12

2018-04-02 Thread Srinivas, Vidya


> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, March 29, 2018 5:03 PM
> To: Maarten Lankhorst 
> Cc: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of
> 4 for NV12
> 
> On Thu, Mar 29, 2018 at 12:28:48PM +0200, Maarten Lankhorst wrote:
> > Op 29-03-18 om 11:19 schreef Srinivas, Vidya:
> > >
> > >> -Original Message-
> > >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > >> Sent: Thursday, March 29, 2018 2:19 PM
> > >> To: Srinivas, Vidya ; intel-
> > >> g...@lists.freedesktop.org
> > >> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane
> > >> size mult of
> > >> 4 for NV12
> > >>
> > >> Op 29-03-18 om 10:06 schreef Vidya Srinivas:
> > >>> As per display WA 1106, to avoid corruption issues
> > >>> NV12 plane height needs to be multiplier of 4 Hence we modify the
> > >>> fb src and destination height and width to be multiples of 4.
> > >>> Without this, pipe fifo underruns were seen on APL and KBL.
> > >>>
> > >>> Credits-to: Maarten Lankhorst 
> > >>> Signed-off-by: Vidya Srinivas 
> > >>> ---
> > >>>  drivers/gpu/drm/i915/intel_drv.h| 2 ++
> > >>>  drivers/gpu/drm/i915/intel_sprite.c | 8 
> > >>>  2 files changed, 10 insertions(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > >>> b/drivers/gpu/drm/i915/intel_drv.h
> > >>> index 9c58da0..a1f718d 100644
> > >>> --- a/drivers/gpu/drm/i915/intel_drv.h
> > >>> +++ b/drivers/gpu/drm/i915/intel_drv.h
> > >>> @@ -159,6 +159,8 @@
> > >>>  #define INTEL_I2C_BUS_DVO 1
> > >>>  #define INTEL_I2C_BUS_SDVO 2
> > >>>
> > >>> +#define MULT4(x) ((x + 3) & ~0x03)
> > >>> +
> > >>>  /* these are outputs from the chip - integrated only
> > >>> external chips are via DVO or SDVO output */  enum
> > >>> intel_output_type { diff --git
> > >>> a/drivers/gpu/drm/i915/intel_sprite.c
> > >>> b/drivers/gpu/drm/i915/intel_sprite.c
> > >>> index 538d938..9f466c6 100644
> > >>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> > >>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > >>> @@ -261,6 +261,14 @@ skl_update_plane(struct intel_plane *plane,
> > >>> crtc_w--;
> > >>> crtc_h--;
> > >>>
> > >>> +   if (fb->format->format == DRM_FORMAT_NV12) {
> > >>> +   src_w = MULT4(src_w);
> > >>> +   src_h = MULT4(src_h);
> > >>> +   crtc_w = MULT4(crtc_w);
> > >>> +   crtc_h = MULT4(crtc_h);
> > >>> +   DRM_ERROR("%d %d %d %d\n", src_w, src_h, crtc_w,
> > >> crtc_h);
> > >>> +   }
> > >>> +
> > >>> spin_lock_irqsave(_priv->uncore.lock, irqflags);
> > >>>
> > >>> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > >> Nearly there!
> > >>
> > >> Do we have limitations for width too? But I think we shouldn't ever
> > >> adjust src for any format.
> > >> This means that we should probably get rid of the
> > >> drm_rect_adjust_size call in intel_check_sprite_plane.
> > >>
> > >> If any limitations of NV12 are hit, we should reject with -EINVAL
> > >> instead so userspace can decide what to do.
> > >> The best place to put those checks is probably in
> > >> skl_update_scaler, where they will be checked by the primary plane too.
> > >>
> > >> This will mean the tests fail, but that can be fixed by selecting
> > >> 16 as width/height for NV12 in IGT. If you change it to 16 you can put
> my r-b on it.
> > >>
> > >> Also I think we should put the same limitations for width and
> > >> height being a multiple in intel_framebuffer_init.
> > >>
> > >> And on a final note for patch ordering, put the workaround and
> > >> gen10 patch before enabling nv12 support.
> > > Thank you. Okay, I will make these changes and check once. The
> > > limitation in Framebuffer init is already present where it expects
> > > width and height >= 16 As per bspec no minimum for width has been
> > > mentioned. And regarding the Add check for primary plane (same like
> > > sprite), can we add that as a separate patch Because if we add it
> > > with NV12 series, it would be like adding the changes and Returning
> before executing them.
> > I don't think we'll lose much if we fail to create a fb that's not a
> > multiple of 4 in height and width. Since the NV12 format is defined in
> > terms of 4x4 pixel blocks, I don't think it would be a loss to fail to 
> > create it,
> if we can't even display it.
> 
> The fb size is pretty much irrelevant since you can scan out just part of it
> anyway.
> 
> Anyway, as far as the src rect adjustments for sprites go, I guess we can just
> switch SKL sprites over to the primary plane codepath and add the relevant
> checks there. Hmm, and it looks like the primary plane packed YUV stuff is
> already pretty much broken since we 

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

2018-04-02 Thread Ramalingam C



On Thursday 29 March 2018 08:05 PM, Sean Paul wrote:

On Thu, Mar 29, 2018 at 07:39:05PM +0530, Ramalingam C wrote:

As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.

And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.

This patch is needed for DP HDCP1.4 CTS Test: 1A-06.

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_hdcp.c | 30 +++---
  1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 14ca5d3057a7..96b9025dc759 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -496,9 +496,11 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
}
  
  	/*

-* Wait for R0' to become available. The spec says 100ms from Aksv, but
-* some monitors can take longer than this. We'll set the timeout at
-* 300ms just to be sure.
+* Wait for R0' to become available. The spec says minimum 100ms from
+* Aksv, but some monitors can take longer than this. So we are
+* combinely waiting for 300mSec just to be sure in case of HDMI.
+* DP HDCP Spec mandates the two more reattempt to read R0, incase
+* of R0 mismatch.

I am sorry to nitpick comments, but this doesn't belong here. Leave this comment
alone and add the part about the DP spec requiring retries directly above the
loop where we're actually doing the retries.

Ok. I will take care in the next ver.

--Ram


Sean


 *
 * On DP, there's an R0_READY bit available but no such bit
 * exists on HDMI. Since the upper-bound is the same, we'll just do
@@ -506,15 +508,21 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
 */
wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
  
-	ri.reg = 0;

-   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
-   if (ret)
-   return ret;
-   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+   tries = 3;
+   for (i = 0; i < tries; i++) {
+   ri.reg = 0;
+   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
+   if (ret)
+   return ret;
+   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
  
-	/* Wait for Ri prime match */

-   if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
-(HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
+   /* Wait for Ri prime match */
+   if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
+   (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
+   break;
+   }
+
+   if (i == tries) {
DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
  I915_READ(PORT_HDCP_STATUS(port)));
return -ETIMEDOUT;
--
2.7.4



___
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: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3)

2018-04-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3)
URL   : https://patchwork.freedesktop.org/series/40851/
State : failure

== Summary ==

Series 40851v3 drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest
https://patchwork.freedesktop.org/api/1.0/series/40851/revisions/3/mbox/

 Possible new issues:

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-blb-e6850)

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:429s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:285  pass:219  dwarn:1   dfail:0   fail:1   skip:64  
time:378s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:533s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:514s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:524s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:512s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:321s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:410s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:471s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:471s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:661s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:440s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:509s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:513s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:433s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:593s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:525s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s

c46052cde6a50c5459e00791ffc4d5aa1ec58a9e drm-tip: 2018y-03m-30d-18h-56m-26s UTC 
integration manifest
b0bcc0a1ee76 drm/i915: Move vgpu balloon info into i915_virtual_gpu struct

== Logs ==

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


Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Check hdcp key loadability

2018-04-02 Thread Ramalingam C



On Thursday 29 March 2018 07:54 PM, Ville Syrjälä wrote:

On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam C wrote:

HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.

This patch enables the hdcp initialization for HSW, BDW, and BXT.

v2:
   Choose the PW# based on the platform.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
  drivers/gpu/drm/i915/intel_hdcp.c | 41 +--
  1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index f77d956b2b18..d8af09b46a44 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -37,6 +37,43 @@ static int intel_hdcp_poll_ksv_fifo(struct 
intel_digital_port *intel_dig_port,
return 0;
  }
  
+static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)

+{
+   struct i915_power_domains *power_domains = _priv->power_domains;
+   struct i915_power_well *power_well;
+   enum i915_power_well_id id;
+   bool enabled = false;
+
+   /*
+* On HSW and BDW, Display HW loads the Key as soon as Display resumes.
+* On all BXT+, SW can load the keys only when the PW#1 is turned on.
+*/
+   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   id = HSW_DISP_PW_GLOBAL;
+   else
+   id = SKL_DISP_PW_1;
+
+   mutex_lock(_domains->lock);
+
+   /* PG1 (power well #1) needs to be enabled */
+   for_each_power_well(dev_priv, power_well) {
+   if (power_well->id == id) {
+   enabled = power_well->ops->is_enabled(dev_priv,
+ power_well);
+   break;
+   }
+   }
+   mutex_unlock(_domains->lock);
+
+   /*
+* Another req for hdcp key loadability is enabled state of pll for
+* cdclk. Without active crtc we wont land here. So we are assuming that
+* cdclk is already on.
+*/
+
+   return enabled;
+}
+
  static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
  {
I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
@@ -615,8 +652,8 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
  connector->base.name, connector->base.base.id);
  
-	if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {

-   DRM_ERROR("PG1 is disabled, cannot load keys\n");
+   if (!hdcp_key_loadable(dev_priv)) {
+   DRM_ERROR("HDCP key Load is not possible\n");
return -ENXIO;
}

If you need the power well then why aren't you grabbing the correct
power domain reference somewhere?


Ville,

As HDCP is supposed to be enabled after the basic display is up, power well #1 
is supposed to be enabled.
If not that is mostly an error w.r.t HDCP.

So at this point we just want to verify whether required PW is up and HDCP key 
can be loaded from the HW. Else fail the HDCP request.

--Ram





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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3)

2018-04-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3)
URL   : https://patchwork.freedesktop.org/series/40851/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b0bcc0a1ee76 drm/i915: Move vgpu balloon info into i915_virtual_gpu struct
-:91: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#91: FILE: drivers/gpu/drm/i915/i915_vgpu.c:225:
+   ret = vgt_balloon_space(ggtt,
+   _info->space[VGPU_UNMAPPABLE_BALLOON_LOW],

-:102: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#102: FILE: drivers/gpu/drm/i915/i915_vgpu.c:234:
+   ret = vgt_balloon_space(ggtt,
+   _info->space[VGPU_UNMAPPABLE_BALLOON_HIGH],

-:113: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#113: FILE: drivers/gpu/drm/i915/i915_vgpu.c:243:
+   ret = vgt_balloon_space(ggtt,
+   _info->space[VGPU_MAPPABLE_BALLOON_LOW],

-:124: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#124: FILE: drivers/gpu/drm/i915/i915_vgpu.c:252:
+   ret = vgt_balloon_space(ggtt,
+   _info->space[VGPU_MAPPABLE_BALLOON_HIGH],

-:135: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#135: FILE: drivers/gpu/drm/i915/i915_vgpu.c:264:
+   vgt_deballoon_space(ggtt,
+   _info->space[VGPU_MAPPABLE_BALLOON_LOW]);

-:139: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#139: FILE: drivers/gpu/drm/i915/i915_vgpu.c:267:
+   vgt_deballoon_space(ggtt,
+   _info->space[VGPU_UNMAPPABLE_BALLOON_HIGH]);

-:143: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#143: FILE: drivers/gpu/drm/i915/i915_vgpu.c:270:
+   vgt_deballoon_space(ggtt,
+   _info->space[VGPU_UNMAPPABLE_BALLOON_LOW]);

total: 0 errors, 0 warnings, 7 checks, 119 lines checked

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


[Intel-gfx] [PATCH] drm/i915: Move vgpu balloon info into i915_virtual_gpu struct

2018-04-02 Thread Xiong Zhang
vgpu ballon info consists of four drm_mm_node which is used to reserve
ggtt space, then linux guest won't use these reserved ggtt space.

Each vgpu has its own ballon info, so move ballon info into
i915_virtual_gpu structure.

Signed-off-by: Xiong Zhang 
---
 drivers/gpu/drm/i915/i915_drv.h  | 14 
 drivers/gpu/drm/i915/i915_vgpu.c | 47 
 2 files changed, 37 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230b..2adc73d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1301,6 +1301,20 @@ struct i915_workarounds {
 struct i915_virtual_gpu {
bool active;
u32 caps;
+
+   struct balloon_info {
+   /*
+* There are up to 2 regions per mappable/unmappable graphic
+* memory that might be ballooned. Here, index 0/1 is for
+* mappable graphic memory, 2/3 for unmappable graphic memory.
+*/
+#define VGPU_MAPPABLE_BALLOON_LOW 0
+#define VGPU_MAPPABLE_BALLOON_HIGH1
+#define VGPU_UNMAPPABLE_BALLOON_LOW   2
+#define VGPU_UNMAPPABLE_BALLOON_HIGH  3
+#define VGPU_MAX_BALLOON_NUM  4
+   struct drm_mm_node space[VGPU_MAX_BALLOON_NUM];
+   } bl_info;
 };
 
 /* used in computing the new watermarks state */
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 7545686..79d3df4 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -86,17 +86,6 @@ bool intel_vgpu_has_full_48bit_ppgtt(struct drm_i915_private 
*dev_priv)
return dev_priv->vgpu.caps & VGT_CAPS_FULL_48BIT_PPGTT;
 }
 
-struct _balloon_info_ {
-   /*
-* There are up to 2 regions per mappable/unmappable graphic
-* memory that might be ballooned. Here, index 0/1 is for mappable
-* graphic memory, 2/3 for unmappable graphic memory.
-*/
-   struct drm_mm_node space[4];
-};
-
-static struct _balloon_info_ bl_info;
-
 static void vgt_deballoon_space(struct i915_ggtt *ggtt,
struct drm_mm_node *node)
 {
@@ -128,8 +117,9 @@ void intel_vgt_deballoon(struct drm_i915_private *dev_priv)
 
DRM_DEBUG("VGT deballoon.\n");
 
-   for (i = 0; i < 4; i++)
-   vgt_deballoon_space(_priv->ggtt, _info.space[i]);
+   for (i = 0; i < VGPU_MAX_BALLOON_NUM; i++)
+   vgt_deballoon_space(_priv->ggtt,
+   _priv->vgpu.bl_info.space[i]);
 }
 
 static int vgt_balloon_space(struct i915_ggtt *ggtt,
@@ -200,6 +190,7 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
 int intel_vgt_balloon(struct drm_i915_private *dev_priv)
 {
struct i915_ggtt *ggtt = _priv->ggtt;
+   struct balloon_info *bl_info;
unsigned long ggtt_end = ggtt->base.total;
 
unsigned long mappable_base, mappable_size, mappable_end;
@@ -230,34 +221,39 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
return -EINVAL;
}
 
+   bl_info = _priv->vgpu.bl_info;
/* Unmappable graphic memory ballooning */
if (unmappable_base > ggtt->mappable_end) {
-   ret = vgt_balloon_space(ggtt, _info.space[2],
-   ggtt->mappable_end, unmappable_base);
+   ret = vgt_balloon_space(ggtt,
+   _info->space[VGPU_UNMAPPABLE_BALLOON_LOW],
+   ggtt->mappable_end, unmappable_base);
 
if (ret)
goto err;
}
 
if (unmappable_end < ggtt_end) {
-   ret = vgt_balloon_space(ggtt, _info.space[3],
-   unmappable_end, ggtt_end);
+   ret = vgt_balloon_space(ggtt,
+   _info->space[VGPU_UNMAPPABLE_BALLOON_HIGH],
+   unmappable_end, ggtt_end);
if (ret)
goto err_upon_mappable;
}
 
/* Mappable graphic memory ballooning */
if (mappable_base) {
-   ret = vgt_balloon_space(ggtt, _info.space[0],
-   0, mappable_base);
+   ret = vgt_balloon_space(ggtt,
+   _info->space[VGPU_MAPPABLE_BALLOON_LOW],
+   0, mappable_base);
 
if (ret)
goto err_upon_unmappable;
}
 
if (mappable_end < ggtt->mappable_end) {
-   ret = vgt_balloon_space(ggtt, _info.space[1],
-   mappable_end, ggtt->mappable_end);
+   ret = vgt_balloon_space(ggtt,
+   _info->space[VGPU_MAPPABLE_BALLOON_HIGH],
+   mappable_end, ggtt->mappable_end);
 
if (ret)
goto err_below_mappable;
@@ -267,11 +263,14 @@ int 

[Intel-gfx] [PATCH v2] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

2018-04-02 Thread Xiong Zhang
The following call trace may exist in linux guest dmesg when guest i915
driver is unloaded.
[   90.776610] [drm:vgt_deballoon_space.isra.0 [i915]] deballoon space: range 
[0x0 - 0x0] 0 KiB.
[   90.776621] BUG: unable to handle kernel NULL pointer dereference at 
00c0
[   90.776691] IP: drm_mm_remove_node+0x4d/0x320 [drm]
[   90.776718] PGD 80012c7d0067 P4D 80012c7d0067 PUD 138e4c067 PMD 0
[   90.777091] task: 9adab60f2f00 task.stack: af39c0fe
[   90.777142] RIP: 0010:drm_mm_remove_node+0x4d/0x320 [drm]
[   90.777573] Call Trace:
[   90.777653]  intel_vgt_deballoon+0x4c/0x60 [i915]
[   90.29]  i915_ggtt_cleanup_hw+0x121/0x190 [i915]
[   90.92]  i915_driver_unload+0x145/0x180 [i915]
[   90.777856]  i915_pci_remove+0x15/0x20 [i915]
[   90.777890]  pci_device_remove+0x3b/0xc0
[   90.777916]  device_release_driver_internal+0x157/0x220
[   90.777945]  driver_detach+0x39/0x70
[   90.777967]  bus_remove_driver+0x51/0xd0
[   90.777990]  pci_unregister_driver+0x23/0x90
[   90.778019]  SyS_delete_module+0x1da/0x240
[   90.778045]  entry_SYSCALL_64_fastpath+0x24/0x87
[   90.778072] RIP: 0033:0x7f34312af067
[   90.778092] RSP: 002b:7ffdea3da0d8 EFLAGS: 0206
[   90.778297] RIP: drm_mm_remove_node+0x4d/0x320 [drm] RSP: af39c0fe3dc0
[   90.778344] ---[ end trace f4b1bc8305fc59dd ]---

Four drm_mm_node are used to reserve guest ggtt space, but some of them
may be skipped and not initialised due to space constraints in
intel_vgt_balloon(). If drm_mm_remove_node() is called with
uninitialized drm_mm_node, the above call trace occurs.

This patch check drm_mm_node's validity before calling
drm_mm_remove_node().

v2: Make commit message clear (Chris)

Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size under 
gvt environment")
Signed-off-by: Xiong Zhang 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_vgpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 5fe9f3f..7545686 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -100,6 +100,9 @@ static struct _balloon_info_ bl_info;
 static void vgt_deballoon_space(struct i915_ggtt *ggtt,
struct drm_mm_node *node)
 {
+   if (!node->allocated)
+   return;
+
DRM_DEBUG_DRIVER("deballoon space: range [0x%llx - 0x%llx] %llu KiB.\n",
 node->start,
 node->start + node->size,
-- 
2.7.4

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