[Intel-gfx] [PATCH igt] igt/gem_ppgtt: Flush the driver to idle before counting leaks

[Chris Wilson]

I have a cunning plan to make the vma open/close lazy to cache frequent
reallocations (as buffers are passed between applications, e.g. DRI).
However, this will mean that we will not be immediately closing vma and
so need to tell the kernel to process the idle handlers before checking
for leaks.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tests/gem_ppgtt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/gem_ppgtt.c b/tests/gem_ppgtt.c
index bed95db83..575b0e9d3 100644
--- a/tests/gem_ppgtt.c
+++ b/tests/gem_ppgtt.c
@@ -236,7 +236,7 @@ static void flink_and_close(void)
gem_sync(fd2, flinked_bo);
gem_close(fd2, flinked_bo);
 
-   igt_drop_caches_set(fd, DROP_RETIRE);
+   igt_drop_caches_set(fd, DROP_RETIRE | DROP_IDLE);
 
/* the flinked bo VMA should have been cleared now, so a new bo of the
 * same size should get the same offset
@@ -286,7 +286,7 @@ static void flink_and_exit(void)
exec_and_get_offset(fd3, gem_create(fd3, 4096));
close(fd3);
 
-   igt_drop_caches_set(fd, DROP_ACTIVE | DROP_RETIRE);
+   igt_drop_caches_set(fd, DROP_ACTIVE | DROP_RETIRE | DROP_IDLE);
igt_assert(!igt_debugfs_search(fd, "i915_gem_gtt", match));
 
close(fd);
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op

[Ramalingam C]

On Wednesday 18 April 2018 08:47 PM, Ville Syrjälä wrote:

On Wed, Apr 18, 2018 at 09:20:23AM +0300, Jani Nikula wrote:

On Wed, 18 Apr 2018, Ramalingam C  wrote:

On Tuesday 17 April 2018 11:39 PM, Ville Syrjälä wrote:

On Tue, Apr 17, 2018 at 02:25:32PM +0530, Ramalingam C wrote:

>From Gen9 onwards Bspec says HW supports Max Bytes per single RD/WR op is
511Bytes instead of previous 256Bytes used in SW.

This change allows the max bytes per op upto 511Bytes from Gen9 onwards.

v2:
No Change.
v3:
Inline function for max_xfer_size and renaming of the macro.[Jani]

Cc: Jani Nikula 
Cc: Chris Wilson 
Signed-off-by: Ramalingam C 
---
   drivers/gpu/drm/i915/i915_reg.h  |  1 +
   drivers/gpu/drm/i915/intel_i2c.c | 11 +--
   2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 475cac07d3e6..be6114a0e8ab 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3013,6 +3013,7 @@ enum i915_power_well_id {
   #define   GMBUS_CYCLE_STOP   (4<<25)
   #define   GMBUS_BYTE_COUNT_SHIFT 16
   #define   GMBUS_BYTE_COUNT_MAX   256U
+#define   GEN9_GMBUS_BYTE_COUNT_MAX 511U
   #define   GMBUS_SLAVE_INDEX_SHIFT 8
   #define   GMBUS_SLAVE_ADDR_SHIFT 1
   #define   GMBUS_SLAVE_READ   (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index e6875509bcd9..4367827d7661 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -361,6 +361,13 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv)
return ret;
   }
   
+static inline

+unsigned int gmbus_max_xfer_size(struct drm_i915_private *dev_priv)
+{
+   return (INTEL_GEN(dev_priv) >= 9) ? GEN9_GMBUS_BYTE_COUNT_MAX :
+   GMBUS_BYTE_COUNT_MAX;

Hmm. You sure about this 256 limit on older HW? The spec does sort of
say that 0-256 is the valid range, but the SPT+ docs still have that
same text, and the register has always had 9 bits for byte count. I
don't see any statements saying that they changed this in any way for
SPT. It only talks about >511 bytes needing the special treatment.

If we do this the I think you should just drop the defines and put the
raw numbers into this function. The extra indirection just makes life
harder. Also pointless parens around the GEN>9 check.

Even I couldn't get any place where BSpec says 256Bytes is the limit for
any platform. Everywhere 9bits are used.
And when I cross verified with other OS usage 511Bytes is used as limit
across all platforms.

Just to be cautious for not breaking any older platforms out in linux
world, I limited the extension of the limit to the known
and easily testable platforms at my desk (Gen9+)

Do you suggest we should apply 511Bytes as max limit for all platforms?
Do we have any means to test this new limit on all supported legacy
platforms?

Except enabling the full potential of the HW in SW, I dont see any ROI
here as most of the GMBUS reqs are <256Bytes.
Only in case of HDCP2.2 we need single read cycle for 538Bytes.

we have couple of options here: Please share your opinion to choose one
of them.
1. Just dont change the upper limit for RD/WR. Keep it as it is at
256Bytes. Anyway no user demands it.
2. As per HW capability, Change the upper limit for RD/WR to 511Bytes
for all platforms. This is needs the functional verification on all
legacy plat supported.
3. Change the upper limit for RD/WR to 511Bytes for newer platforms, say
Gen9+.

Please let's not change the limit for old platforms for absolutely no
gain. And if Ville insists anyway, let's leave that as a separate
follow-up change that can easily be reverted later.

I might consider using the 511 limit only for platforms that
HAS_GMBUS_BURST_READ too.

The original limit seems to have been added in 9535c4757b88 ("drm/i915:
cope with large i2c transfers") citing "the specs". Any recollection
anyone? Chris?

"Duble buffered data register and a 9 bit counter support 0 byte to 256
Byte transfers."
has always been in the spec (and still is for SPT+).
Seems like gap in Bspec. Just today HW team has clarified that all 
platforms support 511Bytes for single Gmbus read and write cycle.


--Ram




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

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Srinivas, Vidya]

> -Original Message-
> From: Kahola, Mika
> Sent: Wednesday, April 18, 2018 5:39 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
> skl_check_nv12_surface for NV12
> 
> On Wed, 2018-04-18 at 09:38 +0530, Vidya Srinivas wrote:
> > From: Maarten Lankhorst 
> >
> > We skip src trunction/adjustments for
> > NV12 case and handle the sizes directly.
> > Without this, pipe fifo underruns are seen on APL/KBL.
> >
> > v2: For NV12, making the src coordinates multiplier of 4
> >
> > v3: Moving all the src coords handling code for NV12 to
> > skl_check_nv12_surface
> The patch looks good to me.
> 
> Reviewed-by: Mika Kahola 

Thank you. Will add the RB in next push.

Regards
Vidya
> 
> >
> > Signed-off-by: Maarten Lankhorst 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 39
> > 
> >  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
> >  2 files changed, 50 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 925402e..b8dbaca 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct
> > intel_crtc_state *crtc_state,
> >     return 0;
> >  }
> >
> > +static int
> > +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> > +      struct intel_plane_state *plane_state) {
> > +   int crtc_x2 = plane_state->base.crtc_x + plane_state-
> > >base.crtc_w;
> > +   int crtc_y2 = plane_state->base.crtc_y + plane_state-
> > >base.crtc_h;
> > +
> > +   if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_y >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_w >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_h >> 16) % 4) != 0) {
> > +   DRM_DEBUG_KMS("src coords must be multiple of 4 for
> > NV12\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Clipping would cause a 1-3 pixel gap at the edge of the
> > screen? */
> > +   if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state-
> > >pipe_src_w % 4) ||
> > +   (crtc_y2 > crtc_state->pipe_src_h && crtc_state-
> > >pipe_src_h % 4)) {
> > +   DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> > %u,%u\n",
> > +     crtc_x2, crtc_y2,
> > +     crtc_state->pipe_src_w, crtc_state-
> > >pipe_src_h);
> > +   return -EINVAL;
> > +   }
> > +
> > +   plane_state->base.src.x1 =
> > +   DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18)
> > << 18;
> > +   plane_state->base.src.x2 =
> > +   DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18)
> > << 18;
> > +   plane_state->base.src.y1 =
> > +   DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18)
> > << 18;
> > +   plane_state->base.src.y2 =
> > +   DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18)
> > << 18;
> > +
> > +   return 0;
> > +}
> > +
> >  static int skl_check_nv12_aux_surface(struct intel_plane_state
> > *plane_state)
> >  {
> >     const struct drm_framebuffer *fb = plane_state->base.fb; @@ -
> 3201,6
> > +3237,9 @@ int skl_check_plane_surface(const struct intel_crtc_state
> > *crtc_state,
> >      * the main surface setup depends on it.
> >      */
> >     if (fb->format->format == DRM_FORMAT_NV12) {
> > +   ret = skl_check_nv12_surface(crtc_state,
> > plane_state);
> > +   if (ret)
> > +   return ret;
> >     ret = skl_check_nv12_aux_surface(plane_state);
> >     if (ret)
> >     return ret;
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 8b7947d..f9985fb 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> >     return vscale;
> >     }
> >
> > -   /* Make the source viewport size an exact multiple
> > of the scaling factors. */
> > -   drm_rect_adjust_size(src,
> > -    drm_rect_width(dst) * hscale -
> > drm_rect_width(src),
> > -    drm_rect_height(dst) * vscale -
> > drm_rect_height(src));
> > +   if (fb->format->format != DRM_FORMAT_NV12) {
> > +   /*
> > +    * Make the source viewport size
> > +    * an exact multiple of the scaling factors
> > +    */
> > +   drm_rect_adjust_size(src,
> > +    (drm_rect_width(dst) *
> > hscale -
> > +    

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Srinivas, Vidya]

> -Original Message-

> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]

> Sent: Thursday, April 19, 2018 12:06 AM

> To: Maarten Lankhorst 

> Cc: Srinivas, Vidya ; intel-

> g...@lists.freedesktop.org

> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add

> skl_check_nv12_surface for NV12

>

> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:

> > Op 18-04-18 om 17:32 schreef Ville Syrjälä:

> > > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:

> > >> From: Maarten Lankhorst 
> > >> >

> > >>

> > >> We skip src trunction/adjustments for

> > >> NV12 case and handle the sizes directly.

> > >> Without this, pipe fifo underruns are seen on APL/KBL.

> > >>

> > >> v2: For NV12, making the src coordinates multiplier of 4

> > >>

> > >> v3: Moving all the src coords handling code for NV12 to

> > >> skl_check_nv12_surface

> > >>

> > >> Signed-off-by: Maarten Lankhorst

> > >> >

> > >> Signed-off-by: Vidya Srinivas 
> > >> >

> > >> ---

> > >>  drivers/gpu/drm/i915/intel_display.c | 39

> > >> 

> > >>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++

> > >>  2 files changed, 50 insertions(+), 4 deletions(-)

> > >>

> > >> diff --git a/drivers/gpu/drm/i915/intel_display.c

> > >> b/drivers/gpu/drm/i915/intel_display.c

> > >> index 925402e..b8dbaca 100644

> > >> --- a/drivers/gpu/drm/i915/intel_display.c

> > >> +++ b/drivers/gpu/drm/i915/intel_display.c

> > >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const

> struct intel_crtc_state *crtc_state,

> > >>  return 0;

> > >>  }

> > >>

> > >> +static int

> > >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,

> > >> +   struct intel_plane_state 
> > >> *plane_state) {

> > >> +int crtc_x2 = plane_state->base.crtc_x + 
> > >> plane_state->base.crtc_w;

> > >> +int crtc_y2 = plane_state->base.crtc_y +

> > >> +plane_state->base.crtc_h;

> > >> +

> > >> +if (((plane_state->base.src_x >> 16) % 4) != 0 ||

> > >> +((plane_state->base.src_y >> 16) % 4) != 0 ||

> > >> +((plane_state->base.src_w >> 16) % 4) != 0 ||

> > >> +((plane_state->base.src_h >> 16) % 4) != 0) {

> > >> +DRM_DEBUG_KMS("src coords must be 
> > >> multiple of 4 for

> NV12\n");

> > >> +return -EINVAL;

> > >> +}

> > > I don't really see why we should check these. The clipped

> > > coordinates are what matters.

> >

> > To propagate our limits to the userspace. I think we should do it for

> > all formats, but NV12 is the first YUV format we have tests for. If we

> > could we should do something similar for the other YUV formats, but they

> have different requirements.

> >

> > In case of NV12 we don't have existing userspace, there will be

> > nothing that breaks if we enforce limits from the start.

>

> But what about sub-pixel coordinates? You're totally ignoring them here.

> We need to come up with some proper rules for this stuff.

>

> >

> > >> +

> > >> +/* Clipping would cause a 1-3 pixel gap at the edge of 
> > >> the screen? */

> > >> +if ((crtc_x2 > crtc_state->pipe_src_w && 
> > >> crtc_state->pipe_src_w %

> 4) ||

> > >> +(crtc_y2 > crtc_state->pipe_src_h && 
> > >> crtc_state->pipe_src_h % 4))

> {

> > >> +DRM_DEBUG_KMS("It's not possible to 
> > >> clip %u,%u to

> %u,%u\n",

> > >> +  crtc_x2, crtc_y2,

> > >> +  
> > >> crtc_state->pipe_src_w, crtc_state->pipe_src_h);

> > >> +return -EINVAL;

> > >> +}

> > > Why should we care? The current code already plays it fast and loose

> > > and allows the dst rectangle to shrink to accomodate the hw limits.

> > > If we want to change that we should change it universally.

> >

> > Unfortunately for the other formats we already have an existing

> > userspace

> > (X.org) that doesn't perform any validation. We can't change it for

> > that, but we can prevent future mistakes.

>

> We should do it uniformly. Not per-format. That will make the code

> unmaintainable real quick.

>

> >

> > >> +

> > >> +plane_state->base.src.x1 =

> > >> +
> > >> DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) <<

> 18;

> > >> +plane_state->base.src.x2 =

> > >> +
> > >> 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/fbdev: Enable late fbdev initial configuration (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/fbdev: Enable late fbdev initial configuration (rev4)
URL   : https://patchwork.freedesktop.org/series/41851/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4067_full -> Patchwork_8744_full =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41851/revisions/4/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-vebox:
  shard-kbl:  SKIP -> PASS +2

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP +3


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665, fdo#106023)

igt@kms_flip@2x-dpms-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#102887)

igt@kms_flip@2x-plain-flip-fb-recreate:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#103928)

igt@kms_flip@flip-vs-modeset-vs-hang-interruptible:
  shard-kbl:  PASS -> DMESG-WARN (fdo#103558, fdo#105602, 
fdo#103313) +1

igt@kms_sysfs_edid_timing:
  shard-apl:  PASS -> WARN (fdo#100047)

igt@pm_rpm@basic-pci-d3-state:
  shard-kbl:  PASS -> DMESG-WARN (fdo#103558, fdo#105602) +2


 Possible fixes 

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-apl:  FAIL (fdo#100368) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4067 -> Patchwork_8744

  CI_DRM_4067: 1c7ccdf37b04bedb10e2191d34dfbba62beb79ea @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8744: d356736d30be910191082e9535bee7f55303cd9e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Refine the has_audio assignment

[Shi, Yang A]

>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Wednesday, April 18, 2018 8:44 PM
>To: Chris Wilson ; Shi, Yang A 
>;
>intel-gfx@lists.freedesktop.org
>Cc: Shi, Yang A 
>Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refine the has_audio assignment
>
>On Fri, 13 Apr 2018, Chris Wilson  wrote:
>> Quoting Yang (2018-04-13 05:06:45)
>>> From: Yang Shi 
>>>
>>> Refine the has_audio assignment for dp and hdmi.
>>
>> s/Refine/Ignore the user override for/
>>
>> Why?
>
>Yang, we'll need the explanation before we continue with review or even 
>consider
>merging. We routinely ignore patches where questions go unanswered.
>
>BR,
>Jani.

This code change is just to make driver code more readable.
If(condition) value = a  else value = condition looks redundancy.

BR.
Yang.

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

Re: [Intel-gfx] [PATCH v3] drm/i915: set minimum CD clock to twice the BCLK.

[Kumar, Abhay]

On 4/18/2018 8:41 AM, Ville Syrjälä wrote:

On Wed, Apr 18, 2018 at 01:49:23PM +0300, Jani Nikula wrote:

On Tue, 17 Apr 2018, "Kumar, Abhay"  wrote:

On 4/17/2018 12:06 PM, Abhay Kumar wrote:

In glk when device boots with only 1366x768 panel, HDA codec doesn't comeup.
This result in no audio forever as cdclk is < 96Mhz.
This change will ensure CD clock to be twice of  BCLK.

v2:
  - Address comment (Jani)
  - New design approach
v3: - Typo fix on top of v1

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
Signed-off-by: Abhay Kumar 
---
   drivers/gpu/drm/i915/intel_cdclk.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index dc7db8a2caf8..6e93af4a46ea 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2143,7 +2143,7 @@ int intel_crtc_compute_min_cdclk(const struct 
intel_crtc_state *crtc_state)
/* According to BSpec, "The CD clock frequency must be at least twice
 * the frequency of the Azalia BCLK." and BCLK is 96 MHz by default.
 */
-   if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
+   if (INTEL_GEN(dev_priv) >= 9)
min_cdclk = max(2 * 96000, min_cdclk);
   
   	/*

Hi Ville, Jani,

 Since right version of this patch is taking time(doing modeset and
cdclk bump) as we need to poke sound driver. Can we please get this
v3(same as v1 with typo fix in comment) version of patch merged.
This works all the time and will unblock Audio and lot of folks. without
this patch audio card is not getting detected at all and blocking basic
audio feature.

I expanded on the code comment, rewrote the commit message, added cc:
stable, and resent the patch [1].

It's not a patch I much like, it's not even a complete fix, and I would
like this to be addressed properly going forward. However, the proper
fix is I think too invasive for stable, so here we are. I'm trying to at
least explain in the comment and commit message what's going on, for
posterity.

Ville, I'm not going to push the patch without your ack, but we can't
sit on this forever either. The patch papers over the most common
failure case, for now, so perhaps it'll buy us time to find a proper
solution.

While I don't particularly like this patch I also agree that it's the
least risky way to go for stable. So

Acked-by: Ville Syrjälä 


Abhay, if we merge this, I do expect your support in figuring out and
testing the proper fix. This is not it.

I also want to see a better solution going forward.


Yes will work on this.




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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON 
to HSW+ function
URL   : https://patchwork.freedesktop.org/series/41923/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8743_full =

== Summary - FAILURE ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@gem_eio@suspend:
  shard-hsw:  PASS -> DMESG-WARN


 Warnings 

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_flip@modeset-vs-vblank-race:
  shard-hsw:  PASS -> FAIL (fdo#103060)
  shard-apl:  PASS -> FAIL (fdo#103060)

igt@kms_flip@plain-flip-fb-recreate-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_mmap_write_crc:
  shard-apl:  PASS -> FAIL (fdo#103286)

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)

igt@prime_vgem@basic-fence-flip:
  shard-apl:  PASS -> FAIL (fdo#104008)


 Possible fixes 

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@flip-vs-blocking-wf-vblank:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS +2


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103286 https://bugs.freedesktop.org/show_bug.cgi?id=103286
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8743

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8743: 524271645ddca56c7333fb096cb311eb98a5cbc3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8743/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 drm/i915/fbdev: Enable late fbdev initial configuration (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/fbdev: Enable late fbdev initial configuration (rev4)
URL   : https://patchwork.freedesktop.org/series/41851/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4067 -> Patchwork_8744 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41851/revisions/4/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
  fi-skl-guc: PASS -> FAIL (fdo#103191)

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: PASS -> FAIL (fdo#104008)


 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS
  fi-skl-guc: FAIL (fdo#103191) -> PASS


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


== Participating hosts (34 -> 30) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bxt-dsi fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4067 -> Patchwork_8744

  CI_DRM_4067: 1c7ccdf37b04bedb10e2191d34dfbba62beb79ea @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8744: d356736d30be910191082e9535bee7f55303cd9e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

d356736d30be drm/i915/fbdev: Enable late fbdev initial configuration

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915/fbdev: Enable late fbdev initial configuration

[José Roberto de Souza]

If the initial fbdev configuration(intel_fbdev_initial_config()) runs and
there still no sink connected it will cause
drm_fb_helper_initial_config() to return 0 as no error happened(but
internally the return is -EAGAIN).
Because no framebuffer was allocated, when a sink is connected
intel_fbdev_output_poll_changed() will not execute
drm_fb_helper_hotplug_event() that would trigger another try to do the
initial fbdev configuration.

So here allowing drm_fb_helper_hotplug_event() to be executed when there
is not frambebuffer allocated and fbdev was not setup yet.

This issue also happens when a MST DP sink is connected since boot, as
the MST topology is discovered in parallel if intel_fbdev_initial_config()
is executed before the first sink MST is discovered it will cause this
same issue.

This is a follow up patch of
https://patchwork.freedesktop.org/patch/196089/

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
Cc: Rodrigo Vivi 
Signed-off-by: Chris Wilson 
Signed-off-by: José Roberto de Souza 
---

Changes from v1:
- not creating a dump framebuffer anymore, instead just allowing
drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.

 drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 7d41d139341b..e9e02b58b7be 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -807,7 +807,7 @@ void intel_fbdev_output_poll_changed(struct drm_device *dev)
return;
 
intel_fbdev_sync(ifbdev);
-   if (ifbdev->vma)
+   if (ifbdev->vma || ifbdev->helper.deferred_setup)
drm_fb_helper_hotplug_event(>helper);
 }
 
-- 
2.17.0

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Move the priotree struct to its 
own headers
URL   : https://patchwork.freedesktop.org/series/41911/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8740_full =

== Summary - FAILURE ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@gem_eio@unwedge-stress:
  shard-apl:  PASS -> FAIL


 Warnings 

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +2


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_flip@modeset-vs-vblank-race:
  shard-apl:  PASS -> FAIL (fdo#103060)

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@plain-flip-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#103928)

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@flip-vs-blocking-wf-vblank:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS +2


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8740

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8740: 80a6c86f4aeac5561931d675ac82e01624e37eb8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON 
to HSW+ function
URL   : https://patchwork.freedesktop.org/series/41923/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8743 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)


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


== Participating hosts (33 -> 31) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8743

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8743: 524271645ddca56c7333fb096cb311eb98a5cbc3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

524271645ddc drm/i915/dp: Avoid concurrent access when HW is using aux ch
87008545c0f1 drm/i915/dp: Improve intel_dp_aux_is_busy()
5a9cc41f7e89 drm/i915/dp: Move code to check if aux ch is busy to a function
16a97441a986 drm/i915/psr/bdw+: Enable CRC check in the static frame on the 
sink side
e463ec258771 drm/i915/psr: Handle PSR RFB storage error
440ab6965b08 drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
0a466f97bd5a drm/i915/psr: Remove intel_crtc_state parameter from disable()
f0dbcdf6 drm/i915/psr: Move PSR exit specific code to hardware specific 
function
9dc8e92b44ac drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON 
to HSW+ function
URL   : https://patchwork.freedesktop.org/series/41923/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
Okay!

Commit: drm/i915/psr: Move PSR exit specific code to hardware specific function
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression 
using sizeof(void)

Commit: drm/i915/psr: Remove intel_crtc_state parameter from disable()
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression 
using sizeof(void)

Commit: drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
Okay!

Commit: drm/i915/psr: Handle PSR RFB storage error
Okay!

Commit: drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side
Okay!

Commit: drm/i915/dp: Move code to check if aux ch is busy to a function
Okay!

Commit: drm/i915/dp: Improve intel_dp_aux_is_busy()
Okay!

Commit: drm/i915/dp: Avoid concurrent access when HW is using aux ch
Okay!

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON 
to HSW+ function
URL   : https://patchwork.freedesktop.org/series/41923/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
9dc8e92b44ac drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
f0dbcdf6 drm/i915/psr: Move PSR exit specific code to hardware specific 
function
0a466f97bd5a drm/i915/psr: Remove intel_crtc_state parameter from disable()
440ab6965b08 drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
-:54: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the 
previous line
#54: FILE: drivers/gpu/drm/i915/intel_psr.c:1002:
+   if (dev_priv->psr.active || dev_priv->psr.busy_frontbuffer_bits
+   || work_busy(_priv->psr.work.work))

total: 0 errors, 0 warnings, 1 checks, 78 lines checked
e463ec258771 drm/i915/psr: Handle PSR RFB storage error
16a97441a986 drm/i915/psr/bdw+: Enable CRC check in the static frame on the 
sink side
-:32: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#32: FILE: drivers/gpu/drm/i915/i915_reg.h:4019:
+#define   EDP_PSR_CRC_ENABLE   (1<<10) /* BDW+ */
  ^

total: 0 errors, 0 warnings, 1 checks, 60 lines checked
5a9cc41f7e89 drm/i915/dp: Move code to check if aux ch is busy to a function
-:41: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.txt
#41: FILE: drivers/gpu/drm/i915/intel_dp.c:1080:
+   msleep(1);

total: 0 errors, 1 warnings, 0 checks, 70 lines checked
87008545c0f1 drm/i915/dp: Improve intel_dp_aux_is_busy()
524271645ddc drm/i915/dp: Avoid concurrent access when HW is using aux ch

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

[Intel-gfx] [PATCH v2 2/9] drm/i915/psr: Move PSR exit specific code to hardware specific function

[José Roberto de Souza]

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 
Reviewed-by: Rodrigo Vivi 
---

No changes from v1.

 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 8e8667d9b084..476bca872d48 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 659180656f5b..ebc47e2b08ca 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -844,53 +844,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,
+  DP_SET_POWER_D0);
+}
 
-   /*
-* Send AUX wake up - Spec says after transitioning to PSR
-* active we have to send AUX wake up by writing 01h in DPCD
-  

[Intel-gfx] [PATCH v2 7/9] drm/i915/dp: Move code to check if aux ch is busy to a function

[José Roberto de Souza]

This reduces the spaghetti that intel_dp_aux_xfer().

Moved doing less changes possible here, improvements to the new
function in further patch.

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

New patch in this series.

 drivers/gpu/drm/i915/intel_dp.c | 52 +
 1 file changed, 34 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 701963a192ee..a11465c62950 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1062,6 +1062,38 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
*intel_dp,
   DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
 }
 
+static bool intel_dp_aux_is_busy(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);
+   i915_reg_t ch_ctl;
+   uint32_t status;
+   int try;
+
+   ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
+
+   for (try = 0; try < 3; try++) {
+   status = I915_READ_NOTRACE(ch_ctl);
+   if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
+   break;
+   msleep(1);
+   }
+
+   if (try == 3) {
+   static u32 last_status = -1;
+   const u32 status = I915_READ(ch_ctl);
+
+   if (status != last_status) {
+   WARN(1, "dp_aux_ch not started status 0x%08x\n",
+status);
+   last_status = status;
+   }
+   }
+
+   return true;
+}
+
 static int
 intel_dp_aux_xfer(struct intel_dp *intel_dp,
  const uint8_t *send, int send_bytes,
@@ -1074,7 +1106,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
i915_reg_t ch_ctl, ch_data[5];
uint32_t aux_clock_divider;
int i, ret, recv_bytes;
-   uint32_t status;
+   uint32_t status = 0;
int try, clock = 0;
bool has_aux_irq = HAS_AUX_IRQ(dev_priv);
bool vdd;
@@ -1102,23 +1134,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
intel_dp_check_edp(intel_dp);
 
/* Try to wait for any previous AUX channel activity */
-   for (try = 0; try < 3; try++) {
-   status = I915_READ_NOTRACE(ch_ctl);
-   if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
-   break;
-   msleep(1);
-   }
-
-   if (try == 3) {
-   static u32 last_status = -1;
-   const u32 status = I915_READ(ch_ctl);
-
-   if (status != last_status) {
-   WARN(1, "dp_aux_ch not started status 0x%08x\n",
-status);
-   last_status = status;
-   }
-
+   if (intel_dp_aux_is_busy(intel_dp)) {
ret = -EBUSY;
goto out;
}
-- 
2.17.0

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

[Intel-gfx] [PATCH v2 5/9] drm/i915/psr: Handle PSR RFB storage error

[José Roberto de Souza]

Sink will interrupt source when it have any problem saving or reading
the remote frame buffer.

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

Changes from v1:
- printing a debug message when sink assert a error

 drivers/gpu/drm/i915/intel_psr.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 4cb27faab707..558b08a43f9e 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1156,6 +1156,18 @@ void intel_psr_hpd_short_pulse_handle(struct intel_dp 
*intel_dp)
intel_psr_exit(dev_priv);
}
 
+   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_ERROR_STATUS, ) != 1) {
+   DRM_DEBUG_KMS("PSR_ERROR_STATUS read failed\n");
+   goto dpcd_error;
+   }
+
+   if (val & DP_PSR_RFB_STORAGE_ERROR) {
+   DRM_DEBUG_KMS("PSR RFB storage error, exiting PSR\n");
+   intel_psr_exit(dev_priv);
+   }
+   /* clear status register */
+   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);
+
/* TODO: handle other PSR/PSR2 errors */
 dpcd_error:
intel_psr_schedule_activate_work(dev_priv);
-- 
2.17.0

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

[Intel-gfx] [PATCH v2 3/9] drm/i915/psr: Remove intel_crtc_state parameter from disable()

[José Roberto de Souza]

It is only used by VLV/CHV and we can get this information from
intel_dp for those platforms.

Signed-off-by: José Roberto de Souza 
Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Lucas De Marchi 
Cc: Ville Syrjälä 
---

Changes from v1:
- not using legacy drm_crtc pointer(struct drm_crtc *crtc = 
intel_dig_port->base.base.crtc)

 drivers/gpu/drm/i915/i915_drv.h  |  3 +--
 drivers/gpu/drm/i915/intel_psr.c | 17 +++--
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 476bca872d48..f5ffb3d72cef 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 ebc47e2b08ca..934498505356 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -665,38 +665,35 @@ 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);
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_PSRSTAT(intel_dp->active_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 = I915_READ(VLV_PSRCTL(intel_dp->active_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);
+   I915_WRITE(VLV_PSRCTL(intel_dp->active_pipe), val);
 
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, intel_dp->active_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;
@@ -765,7 +762,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.17.0

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

[Intel-gfx] [PATCH v2 8/9] drm/i915/dp: Improve intel_dp_aux_is_busy()

[José Roberto de Souza]

- Doing earlier return when not busy
- using u32 instead of uint32_t
- counting from 3 to 0 as it is is the most common in the driver
- using DRM_WARN() instead of WARN()
- adding aux port name to the debug message
- nuking last_status, it is one static variable to all DP ports
also 2 different aux transactions with the same message size would
have the same ch_ctl value, if really desired to reduce the number
of debug messages it should be implemented a per aux ch last_status
- no need to sleep in the last try
- sleeping for 1 aux ch transaction time

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

New patch in this series.

 drivers/gpu/drm/i915/intel_dp.c | 23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a11465c62950..258e23961456 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1068,28 +1068,21 @@ static bool intel_dp_aux_is_busy(struct intel_dp 
*intel_dp)
struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
i915_reg_t ch_ctl;
-   uint32_t status;
-   int try;
+   u32 status;
+   unsigned int try;
 
ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
 
-   for (try = 0; try < 3; try++) {
+   for (try = 3; try; try--) {
status = I915_READ_NOTRACE(ch_ctl);
if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
-   break;
-   msleep(1);
+   return false;
+   if (try > 1)
+   usleep_range(400, 500);
}
 
-   if (try == 3) {
-   static u32 last_status = -1;
-   const u32 status = I915_READ(ch_ctl);
-
-   if (status != last_status) {
-   WARN(1, "dp_aux_ch not started status 0x%08x\n",
-status);
-   last_status = status;
-   }
-   }
+   DRM_WARN("DP aux %c is busy 0x%08x\n",
+aux_ch_name(intel_dp->aux_ch), status);
 
return true;
 }
-- 
2.17.0

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

[Intel-gfx] [PATCH v2 9/9] drm/i915/dp: Avoid concurrent access when HW is using aux ch

[José Roberto de Souza]

This will avoid some cases of concurrent access to aux ch registers when
hardware is using it(HW uses it when PSR, GTC and aux frame is enabled).

It is just first step to see if this scenario happens, if so it will be
properly handled as described in bspec.

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

New patch in this series, this is replacing to the patches in this series that
was exiting PSR before a aux transaction.
As discussed with Dhinakaran, let's check first if this scenary happens if
so I will bring those patches back.

 drivers/gpu/drm/i915/intel_dp.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 258e23961456..74abd4cd93dd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1062,7 +1062,7 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
*intel_dp,
   DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
 }
 
-static bool intel_dp_aux_is_busy(struct intel_dp *intel_dp)
+static bool intel_dp_aux_is_busy(struct intel_dp *intel_dp, unsigned int tries)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv =
@@ -1073,7 +1073,7 @@ static bool intel_dp_aux_is_busy(struct intel_dp 
*intel_dp)
 
ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
 
-   for (try = 3; try; try--) {
+   for (try = tries; try; try--) {
status = I915_READ_NOTRACE(ch_ctl);
if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
return false;
@@ -1127,7 +1127,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
intel_dp_check_edp(intel_dp);
 
/* Try to wait for any previous AUX channel activity */
-   if (intel_dp_aux_is_busy(intel_dp)) {
+   if (intel_dp_aux_is_busy(intel_dp, 3)) {
ret = -EBUSY;
goto out;
}
@@ -1148,6 +1148,18 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
 
/* Must try at least 3 times according to DP spec */
for (try = 0; try < 5; try++) {
+   /* WA: try to avoid concurrent access to aux ch
+* registers while hardware is using it, the other
+* way is not handled at all.
+*/
+   if (intel_dp_aux_is_busy(intel_dp, 1)) {
+   DRM_ERROR("Aux ch %c is busy, hw is using it",
+ aux_ch_name(intel_dp->aux_ch));
+   /* sleep for a transaction time */
+   usleep_range(400, 500);
+   continue;
+   }
+
/* Load the send data into the aux channel data 
registers */
for (i = 0; i < send_bytes; i += 4)
I915_WRITE(ch_data[i >> 2],
-- 
2.17.0

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

[Intel-gfx] [PATCH v2 4/9] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink

[José Roberto de Souza]

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 
---

Changes from v1:
- printing a debug message when sink assert a error

 drivers/gpu/drm/i915/intel_dp.c  |  2 ++
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_psr.c | 48 +---
 3 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..701963a192ee 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4462,6 +4462,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 5bd2263407b2..b79e15ecd052 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1901,6 +1901,7 @@ 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_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 934498505356..4cb27faab707 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -996,6 +996,15 @@ void intel_psr_invalidate(struct drm_i915_private 
*dev_priv,
mutex_unlock(_priv->psr.lock);
 }
 
+static void intel_psr_schedule_activate_work(struct drm_i915_private *dev_priv)
+{
+   if (dev_priv->psr.active || dev_priv->psr.busy_frontbuffer_bits
+   || work_busy(_priv->psr.work.work))
+   return;
+
+   schedule_delayed_work(_priv->psr.work, msecs_to_jiffies(100));
+}
+
 /**
  * intel_psr_flush - Flush PSR
  * @dev_priv: i915 device
@@ -1052,10 +1061,8 @@ 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));
+   intel_psr_schedule_activate_work(dev_priv);
+
mutex_unlock(_priv->psr.lock);
 }
 
@@ -1122,3 +1129,36 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
dev_priv->psr.exit = hsw_psr_exit;
}
 }
+
+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) || !intel_dp_is_edp(intel_dp))
+   return;
+
+   mutex_lock(>lock);
+
+   if (psr->enabled != intel_dp)
+   goto not_enabled;
+
+   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, ) != 1) {
+   DRM_DEBUG_KMS("PSR_STATUS read failed\n");
+   goto dpcd_error;
+   }
+
+   if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR) {
+   DRM_DEBUG_KMS("PSR sink internal error, exiting PSR\n");
+   intel_psr_exit(dev_priv);
+   }
+
+   /* TODO: handle other PSR/PSR2 errors */
+dpcd_error:
+   intel_psr_schedule_activate_work(dev_priv);
+not_enabled:
+   mutex_unlock(>lock);
+}
-- 
2.17.0

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

[Intel-gfx] [PATCH v2 6/9] drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side

[José Roberto de Souza]

Sink can be configured to calculate the CRC over the static frame and
compare with the CRC calculated and transmited in the VSC SDP by
source, if there is a mismatch sink will do a short pulse in HPD
and set DP_PSR_LINK_CRC_ERROR on DP_PSR_ERROR_STATUS.

Also spec recommends to disable MAX_SLEEP as a trigger to exit PSR when
CRC check is enabled to improve power savings.

Spec: 7723

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

Changes from v1:
- printing a debug message when sink assert a error

 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_psr.c | 24 +---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fb106026a1f4..d3efbd654889 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4016,6 +4016,7 @@ enum {
 #define   EDP_PSR_SKIP_AUX_EXIT(1<<12)
 #define   EDP_PSR_TP1_TP2_SEL  (0<<11)
 #define   EDP_PSR_TP1_TP3_SEL  (1<<11)
+#define   EDP_PSR_CRC_ENABLE   (1<<10) /* BDW+ */
 #define   EDP_PSR_TP2_TP3_TIME_500us   (0<<8)
 #define   EDP_PSR_TP2_TP3_TIME_100us   (1<<8)
 #define   EDP_PSR_TP2_TP3_TIME_2500us  (2<<8)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 558b08a43f9e..1920e7d03e06 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -290,6 +290,8 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
dpcd_val |= DP_PSR_ENABLE_PSR2;
if (dev_priv->psr.link_standby)
dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
+   if (!dev_priv->psr.psr2_enabled && INTEL_GEN(dev_priv) >= 8)
+   dpcd_val |= DP_PSR_CRC_VERIFICATION;
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
 
drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
@@ -377,6 +379,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
else
val |= EDP_PSR_TP1_TP2_SEL;
 
+   if (INTEL_GEN(dev_priv) >= 8)
+   val |= EDP_PSR_CRC_ENABLE;
+
val |= I915_READ(EDP_PSR_CTL) & EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK;
I915_WRITE(EDP_PSR_CTL, val);
 }
@@ -602,10 +607,12 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp,
 * preventing  other hw tracking issues now we can rely
 * on frontbuffer tracking.
 */
-   I915_WRITE(EDP_PSR_DEBUG,
-  EDP_PSR_DEBUG_MASK_MEMUP |
-  EDP_PSR_DEBUG_MASK_HPD |
-  EDP_PSR_DEBUG_MASK_LPSP);
+   u32 val = EDP_PSR_DEBUG_MASK_MEMUP | EDP_PSR_DEBUG_MASK_HPD
+ | EDP_PSR_DEBUG_MASK_LPSP;
+
+   if (INTEL_GEN(dev_priv) >= 8)
+   val |= EDP_PSR_DEBUG_MASK_MAX_SLEEP;
+   I915_WRITE(EDP_PSR_DEBUG, val);
}
 }
 
@@ -1161,14 +1168,17 @@ void intel_psr_hpd_short_pulse_handle(struct intel_dp 
*intel_dp)
goto dpcd_error;
}
 
-   if (val & DP_PSR_RFB_STORAGE_ERROR) {
-   DRM_DEBUG_KMS("PSR RFB storage error, exiting PSR\n");
+   if (val & (DP_PSR_RFB_STORAGE_ERROR | DP_PSR_LINK_CRC_ERROR)) {
+   if (val & DP_PSR_RFB_STORAGE_ERROR)
+   DRM_DEBUG_KMS("PSR RFB storage error, exiting PSR\n");
+   if (val & DP_PSR_LINK_CRC_ERROR)
+   DRM_DEBUG_KMS("PSR Link CRC error, exiting PSR\n");
intel_psr_exit(dev_priv);
}
/* clear status register */
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);
 
-   /* TODO: handle other PSR/PSR2 errors */
+   /* TODO: handle PSR2 errors */
 dpcd_error:
intel_psr_schedule_activate_work(dev_priv);
 not_enabled:
-- 
2.17.0

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

[Intel-gfx] [PATCH v2 1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

[José Roberto de Souza]

It was reading some random register in VLV and CHV.

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

No changes from v1.

 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 69a5b276f4d8..659180656f5b 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.17.0

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v11,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev16)

[Patchwork]

== Series Details ==

Series: series starting with [v11,1/2] drm/i915: Implement 
WaProgramMgsrForCorrectSliceSpecificMmioReads (rev16)
URL   : https://patchwork.freedesktop.org/series/40503/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8742 =

== Summary - FAILURE ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/40503/revisions/16/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@debugfs_test@read_all_entries:
  fi-cfl-u:   PASS -> DMESG-WARN
  fi-cfl-s3:  PASS -> DMESG-WARN
  fi-skl-6260u:   PASS -> DMESG-WARN
  fi-skl-gvtdvm:  PASS -> DMESG-WARN
  fi-bdw-gvtdvm:  PASS -> DMESG-WARN
  fi-bxt-j4205:   PASS -> DMESG-WARN
  fi-kbl-7500u:   PASS -> DMESG-WARN
  fi-bdw-5557u:   PASS -> DMESG-WARN
  fi-kbl-r:   PASS -> DMESG-WARN
  fi-skl-guc: PASS -> DMESG-WARN
  fi-kbl-7567u:   PASS -> DMESG-WARN
  fi-glk-j4005:   NOTRUN -> DMESG-WARN
  fi-skl-6600u:   PASS -> DMESG-WARN
  fi-bxt-dsi: NOTRUN -> DMESG-WARN
  fi-cfl-8700k:   PASS -> DMESG-WARN
  fi-bsw-n3050:   PASS -> DMESG-WARN
  fi-skl-6700k2:  PASS -> DMESG-WARN
  fi-skl-6770hq:  PASS -> DMESG-WARN

igt@gem_ringfill@basic-default-hang:
  fi-cnl-y3:  PASS -> DMESG-WARN


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)


 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (33 -> 31) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8742

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8742: 9960162c61d7419eb49300fa91164e0f5e32898b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

9960162c61d7 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
0f9b8e8c4c75 drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v4,1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/4] drm/i915: Always do WOPCM partitioning 
based on real firmware sizes
URL   : https://patchwork.freedesktop.org/series/41909/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8739_full =

== Summary - FAILURE ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@kms_frontbuffer_tracking@fbc-suspend:
  shard-kbl:  PASS -> DMESG-WARN +3

igt@perf@gen8-unprivileged-single-ctx-counters:
  shard-kbl:  PASS -> FAIL +1
  shard-apl:  PASS -> FAIL


 Warnings 

igt@drv_missed_irq:
  shard-apl:  PASS -> SKIP

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +2

igt@prime_vgem@sync-bsd2:
  shard-kbl:  PASS -> SKIP +31


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_eio@execbuf:
  shard-apl:  PASS -> INCOMPLETE (fdo#103927) +1

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@modeset-vs-vblank-race:
  shard-hsw:  PASS -> FAIL (fdo#103060) +1

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)

igt@prime_busy@wait-hang-vebox:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665) +4


 Possible fixes 

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@flip-vs-blocking-wf-vblank:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103558) -> PASS +1


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8739

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8739: f6e5a01f3c8931f5b6420e877f8a8e596821926f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8739/shards.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 series starting with [v11,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev16)

[Patchwork]

== Series Details ==

Series: series starting with [v11,1/2] drm/i915: Implement 
WaProgramMgsrForCorrectSliceSpecificMmioReads (rev16)
URL   : https://patchwork.freedesktop.org/series/40503/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
0f9b8e8c4c75 drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
-:63: CHECK:LINE_SPACING: Please don't use multiple blank lines
#63: FILE: drivers/gpu/drm/i915/intel_device_info.c:722:
 
+

total: 0 errors, 0 warnings, 1 checks, 90 lines checked
9960162c61d7 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
-:47: WARNING:BAD_SIGN_OFF: Duplicate signature
#47: 
Reviewed-by: Oscar Mateo 

total: 0 errors, 1 warnings, 0 checks, 50 lines checked

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

Re: [Intel-gfx] [PATCH v11 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

[Oscar Mateo]

On 4/18/2018 3:01 PM, Yunwei Zhang wrote:

WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.

However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.

Also, 0xFDC will lose its information after TDR/engine reset/power state
change.

References: HSD#1405586840, BSID#0575

v2:
  - use fls() instead of find_last_bit() (Chris)
  - added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
  - rebase on latest tip
v5:
  - Added references (Mika)
  - Change the ordered of passing arguments and etc. (Ursulin)
v7:
  - Rebased.
v8:
  - Reviewed by Oscar
  - Store default MCR value instead of calculate on the run. (Oscar)
v9:
  - Changed naming and label fixes. (Oscar)
  - Store only the selector instead of whole MCR. (Oscar)
v10:
  - Improved comments, naming and line breaknig. (Oscar)
v11:
  - Moved the comment to most relavent block. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/intel_device_info.c | 47 
  drivers/gpu/drm/i915/intel_device_info.h |  3 ++
  drivers/gpu/drm/i915/intel_engine_cs.c   | 10 +++
  3 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index a32ba72..ea62d45 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -719,6 +719,51 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
return 0;
  }
  
+

+static void sanitize_mcr(struct intel_device_info *info)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(info, struct drm_i915_private, info);
+   u32 mcr;
+   u32 mcr_slice_subslice_mask;
+   u32 mcr_slice_subslice_select;
+   u32 slice = fls(info->sseu.slice_mask);
+   u32 subslice = fls(info->sseu.subslice_mask[slice]);
+
+   if (INTEL_GEN(dev_priv) >= 11) {
+   mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
+ GEN11_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) |
+   GEN11_MCR_SUBSLICE(subslice);
+   } else {
+   mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK |
+ GEN8_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) |
+   GEN8_MCR_SUBSLICE(subslice);
+   }
+
+   mcr = I915_READ(GEN8_MCR_SELECTOR);
+   mcr &= ~mcr_slice_subslice_mask;
+
+   /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
+* Before any MMIO read into slice/subslice specific registers, MCR
+* packet control register needs to be programmed to point to any
+* enabled s/ss pair. Otherwise, incorrect values will be returned.
+* This means each subsequent MMIO read will be forwarded to an
+* specific s/ss combination, but this is OK since these registers
+* are consistent across s/ss in almost all cases. In the rare
+* occasions, such as INSTDONE, where this value is dependent
+* on s/ss combo, the read should be done with read_subslice_reg.
+*/
+   if (INTEL_GEN(dev_priv) >= 10)
+   mcr |= mcr_slice_subslice_select;
+
+   I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+
+   info->default_mcr_s_ss_select = mcr_slice_subslice_select;


Sorry: forget my r-b, this is broken. For GENs that do not need the WA, 
info->default_mcr_s_ss_select should be 0



+}
+
  /**
   * intel_device_info_runtime_init - initialize runtime info
   * @info: intel device info struct
@@ -851,6 +896,8 @@ void intel_device_info_runtime_init(struct 
intel_device_info *info)
else if (INTEL_INFO(dev_priv)->gen >= 11)
gen11_sseu_info_init(dev_priv);
  
+	sanitize_mcr(info);

+
/* Initialize command stream timestamp frequency */
info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv);
  }

[Intel-gfx] [PATCH v11 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

[Yunwei Zhang]

WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.

However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.

Also, 0xFDC will lose its information after TDR/engine reset/power state
change.

References: HSD#1405586840, BSID#0575

v2:
 - use fls() instead of find_last_bit() (Chris)
 - added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
 - rebase on latest tip
v5:
 - Added references (Mika)
 - Change the ordered of passing arguments and etc. (Ursulin)
v7:
 - Rebased.
v8:
 - Reviewed by Oscar
 - Store default MCR value instead of calculate on the run. (Oscar)
v9:
 - Changed naming and label fixes. (Oscar)
 - Store only the selector instead of whole MCR. (Oscar)
v10:
 - Improved comments, naming and line breaknig. (Oscar)
v11:
 - Moved the comment to most relavent block. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_device_info.c | 47 
 drivers/gpu/drm/i915/intel_device_info.h |  3 ++
 drivers/gpu/drm/i915/intel_engine_cs.c   | 10 +++
 3 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index a32ba72..ea62d45 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -719,6 +719,51 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
return 0;
 }
 
+
+static void sanitize_mcr(struct intel_device_info *info)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(info, struct drm_i915_private, info);
+   u32 mcr;
+   u32 mcr_slice_subslice_mask;
+   u32 mcr_slice_subslice_select;
+   u32 slice = fls(info->sseu.slice_mask);
+   u32 subslice = fls(info->sseu.subslice_mask[slice]);
+
+   if (INTEL_GEN(dev_priv) >= 11) {
+   mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
+ GEN11_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) |
+   GEN11_MCR_SUBSLICE(subslice);
+   } else {
+   mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK |
+ GEN8_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) |
+   GEN8_MCR_SUBSLICE(subslice);
+   }
+
+   mcr = I915_READ(GEN8_MCR_SELECTOR);
+   mcr &= ~mcr_slice_subslice_mask;
+
+   /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
+* Before any MMIO read into slice/subslice specific registers, MCR
+* packet control register needs to be programmed to point to any
+* enabled s/ss pair. Otherwise, incorrect values will be returned.
+* This means each subsequent MMIO read will be forwarded to an
+* specific s/ss combination, but this is OK since these registers
+* are consistent across s/ss in almost all cases. In the rare
+* occasions, such as INSTDONE, where this value is dependent
+* on s/ss combo, the read should be done with read_subslice_reg.
+*/
+   if (INTEL_GEN(dev_priv) >= 10)
+   mcr |= mcr_slice_subslice_select;
+
+   I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+
+   info->default_mcr_s_ss_select = mcr_slice_subslice_select;
+}
+
 /**
  * intel_device_info_runtime_init - initialize runtime info
  * @info: intel device info struct
@@ -851,6 +896,8 @@ void intel_device_info_runtime_init(struct 
intel_device_info *info)
else if (INTEL_INFO(dev_priv)->gen >= 11)
gen11_sseu_info_init(dev_priv);
 
+   sanitize_mcr(info);
+
/* Initialize command stream timestamp frequency */
info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv);
 }
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 933e316..2feccee 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/crc: Only report a single overflow when a CRC fd is opened

[Patchwork]

== Series Details ==

Series: drm/crc: Only report a single overflow when a CRC fd is opened
URL   : https://patchwork.freedesktop.org/series/41897/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8737_full =

== Summary - WARNING ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-vebox:
  shard-kbl:  PASS -> SKIP

igt@perf_pmu@rc6:
  shard-kbl:  SKIP -> PASS +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#102887)

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@drv_suspend@forcewake:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  INCOMPLETE (fdo#106023, fdo#103665) -> PASS

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@flip-vs-blocking-wf-vblank:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS +2

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8737

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8737: e17f1c739f3f4bfe59ec5192330fdea1e109ea34 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for gpu: drm: i915: Change return type to vm_fault_t (rev2)

[Patchwork]

== Series Details ==

Series: gpu: drm: i915: Change return type to vm_fault_t (rev2)
URL   : https://patchwork.freedesktop.org/series/41893/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8736_full =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41893/revisions/2/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd1:
  shard-kbl:  PASS -> SKIP +1

igt@gem_mocs_settings@mocs-rc6-bsd2:
  shard-kbl:  SKIP -> PASS

igt@kms_vblank@pipe-a-query-forked-busy:
  shard-snb:  PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_flip@plain-flip-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@flip-vs-blocking-wf-vblank:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS +2

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8736

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8736: 045e647f1204c28a28882560da315568d838e3ea @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v10,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev15)

[Patchwork]

== Series Details ==

Series: series starting with [v10,1/2] drm/i915: Implement 
WaProgramMgsrForCorrectSliceSpecificMmioReads (rev15)
URL   : https://patchwork.freedesktop.org/series/40503/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8741 =

== Summary - FAILURE ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/40503/revisions/15/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@debugfs_test@read_all_entries:
  fi-cfl-u:   PASS -> DMESG-WARN
  fi-cfl-s3:  PASS -> DMESG-WARN
  fi-skl-6260u:   PASS -> DMESG-WARN
  fi-skl-gvtdvm:  PASS -> DMESG-WARN
  fi-bdw-gvtdvm:  PASS -> DMESG-WARN
  fi-bxt-j4205:   PASS -> DMESG-WARN
  fi-kbl-7500u:   PASS -> DMESG-WARN
  fi-bdw-5557u:   PASS -> DMESG-WARN
  fi-kbl-r:   PASS -> DMESG-WARN
  fi-skl-guc: PASS -> DMESG-WARN
  fi-kbl-7567u:   PASS -> DMESG-WARN
  fi-glk-j4005:   NOTRUN -> DMESG-WARN
  fi-skl-6600u:   PASS -> DMESG-WARN
  fi-bxt-dsi: NOTRUN -> DMESG-WARN
  fi-cfl-8700k:   PASS -> DMESG-WARN
  fi-bsw-n3050:   PASS -> DMESG-WARN
  fi-skl-6700k2:  PASS -> DMESG-WARN
  fi-skl-6770hq:  PASS -> DMESG-WARN

igt@gem_ringfill@basic-default-hang:
  fi-cnl-y3:  PASS -> DMESG-WARN


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084) +1


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (33 -> 31) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8741

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8741: c243c40dcab2358a6001f5edf03bb78a66f2e8cc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

c243c40dcab2 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
4d91b554a00a drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

== Logs ==

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

Re: [Intel-gfx] [PATCH v10 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

[Oscar Mateo]

On 4/18/2018 1:23 PM, Yunwei Zhang wrote:

L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.

However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.

References: HSDES#1405586840

v2:
  - use fls instead of find_last_bit (Chris)
  - use is_power_of_2() instead of counting bit set (Chris)
v3:
  - rebase on latest tip
v5:
  - Added references (Mika)
  - Move local variable into scope where they are used (Ursulin)
  - use a new local variable to reduce long line of code (Ursulin)
v6:
  - Some coding style and use more local variables for clearer
logic (Ursulin)
v7:
  - Rebased.
v8:
  - Reviewed by Oscar.
v9:
  - Fixed label location. (Oscar)
v10:
  - Improved comments and replaced magical number. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 


Re-
Reviewed-by: Oscar Mateo 


---
  drivers/gpu/drm/i915/i915_reg.h  |  4 
  drivers/gpu/drm/i915/intel_device_info.c | 34 
  2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fb10602..6c9c01b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2709,6 +2709,10 @@ enum i915_power_well_id {
  #define   GEN10_F2_SS_DIS_SHIFT   18
  #define   GEN10_F2_SS_DIS_MASK(0xf << GEN10_F2_SS_DIS_SHIFT)
  
+#define	GEN10_MIRROR_FUSE3		_MMIO(0x9118)

+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK   0x0F
+
  #define GEN8_EU_DISABLE0  _MMIO(0x9134)
  #define   GEN8_EU_DIS0_S0_MASK0xff
  #define   GEN8_EU_DIS0_S1_SHIFT   24
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 3791b52..a42842d 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -741,6 +741,40 @@ static void sanitize_mcr(struct intel_device_info *info)
u32 slice = fls(info->sseu.slice_mask);
u32 subslice = fls(info->sseu.subslice_mask[slice]);
  
+	/*

+* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
+* L3Banks could be fused off in single slice scenario. If that is
+* the case, we might need to program MCR select to a valid L3Bank
+* by default, to make sure we correctly read certain registers
+* later on (in the range 0xB100 - 0xB3FF).
+* This might be incompatible with
+* WaProgramMgsrForCorrectSliceSpecificMmioReads.
+* Fortunately, this should not happen in production hardware, so
+* we only assert that this is the case (instead of implementing
+* something more complex that requires checking the range of every
+* MMIO read).
+*/
+   if (INTEL_GEN(dev_priv) >= 10 &&
+   is_power_of_2(info->sseu.slice_mask)) {
+   /*
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
+   u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+   u8 ss_mask = info->sseu.subslice_mask[slice];
+
+   u8 enabled_mask = (ss_mask | ss_mask >>
+  GEN10_L3BANK_PAIR_COUNT) &
+  GEN10_L3BANK_MASK;
+   u8 disabled_mask = fuse3 & GEN10_L3BANK_MASK;
+
+   /*
+* Production silicon should have matched L3Bank and
+* subslice enabled
+*/
+   WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
+   }
+
if (INTEL_GEN(dev_priv) >= 11) {
mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
  GEN11_MCR_SUBSLICE_MASK;


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

Re: [Intel-gfx] [PATCH v10 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

[Oscar Mateo]

On 4/18/2018 1:23 PM, Yunwei Zhang wrote:

WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.

However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.

Also, 0xFDC will lose its information after TDR/engine reset/power state
change.

References: HSD#1405586840, BSID#0575

v2:
  - use fls() instead of find_last_bit() (Chris)
  - added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
  - rebase on latest tip
v5:
  - Added references (Mika)
  - Change the ordered of passing arguments and etc. (Ursulin)
v7:
  - Rebased.
v8:
  - Reviewed by Oscar
  - Store default MCR value instead of calculate on the run. (Oscar)
v9:
  - Changed naming and label fixes. (Oscar)
  - Store only the selector instead of whole MCR. (Oscar)
v10:
  - Improved comments, naming and line breaknig. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/intel_device_info.c | 48 
  drivers/gpu/drm/i915/intel_device_info.h |  3 ++
  drivers/gpu/drm/i915/intel_engine_cs.c   | 10 +++
  3 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index a32ba72..3791b52 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -719,6 +719,52 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
return 0;
  }
  
+

+/*
+ * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
+ * Before any MMIO read into slice/subslice specific registers, MCR
+ * packet control register needs to be programmed to point to any
+ * enabled s/ss pair. Otherwise, incorrect values will be returned.
+ * This means each subsequent MMIO read will be forwarded to an
+ * specific s/ss combination, but this is OK since these registers
+ * are consistent across s/ss in almost all cases. In the rare
+ * occasions, such as INSTDONE, where this value is dependent
+ * on s/ss combo, the read should be done with read_subslice_reg.
+ */


If you move the above comment block to the actual WA, which is:

if (INTEL_GEN(dev_priv) >= 10)
mcr |= mcr_slice_subslice_select;


this patch is:

Reviewed-by: Oscar Mateo 

this time for real :)


+static void sanitize_mcr(struct intel_device_info *info)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(info, struct drm_i915_private, info);
+   u32 mcr;
+   u32 mcr_slice_subslice_mask;
+   u32 mcr_slice_subslice_select;
+   u32 slice = fls(info->sseu.slice_mask);
+   u32 subslice = fls(info->sseu.subslice_mask[slice]);
+
+   if (INTEL_GEN(dev_priv) >= 11) {
+   mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
+ GEN11_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) |
+   GEN11_MCR_SUBSLICE(subslice);
+   } else {
+   mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK |
+ GEN8_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) |
+   GEN8_MCR_SUBSLICE(subslice);
+   }
+
+   mcr = I915_READ(GEN8_MCR_SELECTOR);
+   mcr &= ~mcr_slice_subslice_mask;
+
+   /* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl */
+   if (INTEL_GEN(dev_priv) >= 10)
+   mcr |= mcr_slice_subslice_select;
+
+   I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+
+   info->default_mcr_s_ss_select = mcr_slice_subslice_select;
+}
+
  /**
   * intel_device_info_runtime_init - initialize runtime info
   * @info: intel device info struct
@@ -851,6 +897,8 @@ void intel_device_info_runtime_init(struct 
intel_device_info *info)
else if (INTEL_INFO(dev_priv)->gen >= 11)
gen11_sseu_info_init(dev_priv);
  
+	sanitize_mcr(info);

+
/* Initialize command stream timestamp frequency */

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v10,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev15)

[Patchwork]

== Series Details ==

Series: series starting with [v10,1/2] drm/i915: Implement 
WaProgramMgsrForCorrectSliceSpecificMmioReads (rev15)
URL   : https://patchwork.freedesktop.org/series/40503/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
4d91b554a00a drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
-:61: CHECK:LINE_SPACING: Please don't use multiple blank lines
#61: FILE: drivers/gpu/drm/i915/intel_device_info.c:722:
 
+

total: 0 errors, 0 warnings, 1 checks, 91 lines checked
c243c40dcab2 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

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

[Intel-gfx] [PATCH v10 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

[Yunwei Zhang]

L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.

However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.

References: HSDES#1405586840

v2:
 - use fls instead of find_last_bit (Chris)
 - use is_power_of_2() instead of counting bit set (Chris)
v3:
 - rebase on latest tip
v5:
 - Added references (Mika)
 - Move local variable into scope where they are used (Ursulin)
 - use a new local variable to reduce long line of code (Ursulin)
v6:
 - Some coding style and use more local variables for clearer
   logic (Ursulin)
v7:
 - Rebased.
v8:
 - Reviewed by Oscar.
v9:
 - Fixed label location. (Oscar)
v10:
 - Improved comments and replaced magical number. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h  |  4 
 drivers/gpu/drm/i915/intel_device_info.c | 34 
 2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fb10602..6c9c01b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2709,6 +2709,10 @@ enum i915_power_well_id {
 #define   GEN10_F2_SS_DIS_SHIFT18
 #define   GEN10_F2_SS_DIS_MASK (0xf << GEN10_F2_SS_DIS_SHIFT)
 
+#defineGEN10_MIRROR_FUSE3  _MMIO(0x9118)
+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK   0x0F
+
 #define GEN8_EU_DISABLE0   _MMIO(0x9134)
 #define   GEN8_EU_DIS0_S0_MASK 0xff
 #define   GEN8_EU_DIS0_S1_SHIFT24
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 3791b52..a42842d 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -741,6 +741,40 @@ static void sanitize_mcr(struct intel_device_info *info)
u32 slice = fls(info->sseu.slice_mask);
u32 subslice = fls(info->sseu.subslice_mask[slice]);
 
+   /*
+* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
+* L3Banks could be fused off in single slice scenario. If that is
+* the case, we might need to program MCR select to a valid L3Bank
+* by default, to make sure we correctly read certain registers
+* later on (in the range 0xB100 - 0xB3FF).
+* This might be incompatible with
+* WaProgramMgsrForCorrectSliceSpecificMmioReads.
+* Fortunately, this should not happen in production hardware, so
+* we only assert that this is the case (instead of implementing
+* something more complex that requires checking the range of every
+* MMIO read).
+*/
+   if (INTEL_GEN(dev_priv) >= 10 &&
+   is_power_of_2(info->sseu.slice_mask)) {
+   /*
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
+   u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+   u8 ss_mask = info->sseu.subslice_mask[slice];
+
+   u8 enabled_mask = (ss_mask | ss_mask >>
+  GEN10_L3BANK_PAIR_COUNT) &
+  GEN10_L3BANK_MASK;
+   u8 disabled_mask = fuse3 & GEN10_L3BANK_MASK;
+
+   /*
+* Production silicon should have matched L3Bank and
+* subslice enabled
+*/
+   WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
+   }
+
if (INTEL_GEN(dev_priv) >= 11) {
mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
  GEN11_MCR_SUBSLICE_MASK;
-- 
2.7.4

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

[Intel-gfx] [PATCH v10 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

[Yunwei Zhang]

WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.

However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.

Also, 0xFDC will lose its information after TDR/engine reset/power state
change.

References: HSD#1405586840, BSID#0575

v2:
 - use fls() instead of find_last_bit() (Chris)
 - added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
 - rebase on latest tip
v5:
 - Added references (Mika)
 - Change the ordered of passing arguments and etc. (Ursulin)
v7:
 - Rebased.
v8:
 - Reviewed by Oscar
 - Store default MCR value instead of calculate on the run. (Oscar)
v9:
 - Changed naming and label fixes. (Oscar)
 - Store only the selector instead of whole MCR. (Oscar)
v10:
 - Improved comments, naming and line breaknig. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_device_info.c | 48 
 drivers/gpu/drm/i915/intel_device_info.h |  3 ++
 drivers/gpu/drm/i915/intel_engine_cs.c   | 10 +++
 3 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index a32ba72..3791b52 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -719,6 +719,52 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
return 0;
 }
 
+
+/*
+ * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
+ * Before any MMIO read into slice/subslice specific registers, MCR
+ * packet control register needs to be programmed to point to any
+ * enabled s/ss pair. Otherwise, incorrect values will be returned.
+ * This means each subsequent MMIO read will be forwarded to an
+ * specific s/ss combination, but this is OK since these registers
+ * are consistent across s/ss in almost all cases. In the rare
+ * occasions, such as INSTDONE, where this value is dependent
+ * on s/ss combo, the read should be done with read_subslice_reg.
+ */
+static void sanitize_mcr(struct intel_device_info *info)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(info, struct drm_i915_private, info);
+   u32 mcr;
+   u32 mcr_slice_subslice_mask;
+   u32 mcr_slice_subslice_select;
+   u32 slice = fls(info->sseu.slice_mask);
+   u32 subslice = fls(info->sseu.subslice_mask[slice]);
+
+   if (INTEL_GEN(dev_priv) >= 11) {
+   mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
+ GEN11_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) |
+   GEN11_MCR_SUBSLICE(subslice);
+   } else {
+   mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK |
+ GEN8_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) |
+   GEN8_MCR_SUBSLICE(subslice);
+   }
+
+   mcr = I915_READ(GEN8_MCR_SELECTOR);
+   mcr &= ~mcr_slice_subslice_mask;
+
+   /* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl */
+   if (INTEL_GEN(dev_priv) >= 10)
+   mcr |= mcr_slice_subslice_select;
+
+   I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+
+   info->default_mcr_s_ss_select = mcr_slice_subslice_select;
+}
+
 /**
  * intel_device_info_runtime_init - initialize runtime info
  * @info: intel device info struct
@@ -851,6 +897,8 @@ void intel_device_info_runtime_init(struct 
intel_device_info *info)
else if (INTEL_INFO(dev_priv)->gen >= 11)
gen11_sseu_info_init(dev_priv);
 
+   sanitize_mcr(info);
+
/* Initialize command stream timestamp frequency */
info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv);
 }
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 933e316..2feccee 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -176,6 +176,9 @@ struct 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/audio: set minimum CD clock to twice the BCLK

[Patchwork]

== Series Details ==

Series: drm/i915/audio: set minimum CD clock to twice the BCLK
URL   : https://patchwork.freedesktop.org/series/41888/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8735_full =

== Summary - WARNING ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-bsd1:
  shard-kbl:  PASS -> SKIP

igt@gem_mocs_settings@mocs-rc6-bsd2:
  shard-kbl:  SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
  shard-hsw:  PASS -> FAIL (fdo#104873)

igt@kms_flip@modeset-vs-vblank-race:
  shard-snb:  PASS -> FAIL (fdo#103060)

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)

igt@perf@short-reads:
  shard-kbl:  PASS -> FAIL (fdo#103183)


 Possible fixes 

igt@drv_suspend@forcewake:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@flip-vs-blocking-wf-vblank:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103558) -> PASS +2

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103183 https://bugs.freedesktop.org/show_bug.cgi?id=103183
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8735

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8735: bfb500c3510f626c212169ec498ddee1413c9736 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its 
own headers (rev2)
URL   : https://patchwork.freedesktop.org/series/41827/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8734_full =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41827/revisions/2/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-modeset-vs-vblank-race:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)

igt@prime_mmap_coherency@read:
  shard-hsw:  PASS -> DMESG-WARN (fdo#102614) +1


 Possible fixes 

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@flip-vs-blocking-wf-vblank:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 3) ==

  Missing(6): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-kbl 
shard-glkb 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8734

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8734: d45621446c373467ef2f658526ce56b70a42fba7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

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

[Sean Paul]

Hi Dave,
Here's the first misc-fixes pull. It unfortunately contains a backmerge due to
Eric committing Daniel's patch before I had a chance to fast forward. Anyways,
it's not too convoluted, so I'll try to win the race this week :-). In general,
this is going to become more common as the number of committers grows. If it
bugs you, let me know and we'll figure out a process to avoid it.


drm-misc-fixes-2018-04-18-1:
drm-misc-fixes:

stable: vc4: Fix memory leak during BO teardown (Daniel)
dp: Add i2c retry for LSPCON adapters (Imre)
hdcp: Fix device count mask (Ramalingam)

Cc: Daniel J Blueman 
Cc: Ramalingam C 

Cheers, Sean


The following changes since commit a10beabba213924d876f2d10ca9351aeab93f58a:

  Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2018-04-13 09:25:21 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-04-18-1

for you to fetch changes up to 7eb2c4dd54ff841f2fe509a84973eb25fa20bda2:

  drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state 
(2018-04-18 16:33:14 +0300)


drm-misc-fixes:

stable: vc4: Fix memory leak during BO teardown (Daniel)
dp: Add i2c retry for LSPCON adapters (Imre)
hdcp: Fix device count mask (Ramalingam)

Cc: Daniel J Blueman 
Cc: Ramalingam C 


Daniel J Blueman (1):
  drm/vc4: Fix memory leak during BO teardown

Imre Deak (1):
  drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state

Ramalingam C (1):
  drm: Fix HDCP downstream dev count read

Sean Paul (1):
  Merge airlied/drm-next into drm-misc-fixes

 drivers/gpu/drm/drm_dp_dual_mode_helper.c  | 39 --
 drivers/gpu/drm/vc4/vc4_bo.c   |  2 ++
 drivers/gpu/drm/vc4/vc4_validate_shaders.c |  1 +
 include/drm/drm_hdcp.h |  2 +-
 4 files changed, 36 insertions(+), 8 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
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 [CI,1/3] drm/i915: Move the priotree struct to its own headers

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Move the priotree struct to its 
own headers
URL   : https://patchwork.freedesktop.org/series/41911/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8740 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)


 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (33 -> 31) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8740

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8740: 80a6c86f4aeac5561931d675ac82e01624e37eb8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

80a6c86f4aea drm/i915: Pack params to engine->schedule() into a struct
7d660e218d01 drm/i915: Rename priotree to sched
f9eaeb0abf9f drm/i915: Move the priotree struct to its own headers

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Move the priotree struct to its 
own headers
URL   : https://patchwork.freedesktop.org/series/41911/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Move the priotree struct to its own headers
Okay!

Commit: drm/i915: Rename priotree to sched
Okay!

Commit: drm/i915: Pack params to engine->schedule() into a struct
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression 
using sizeof(void)

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Move the priotree struct to its 
own headers
URL   : https://patchwork.freedesktop.org/series/41911/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f9eaeb0abf9f drm/i915: Move the priotree struct to its own headers
-:72: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#72: 
new file mode 100644

-:77: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#77: FILE: drivers/gpu/drm/i915/i915_scheduler.h:1:
+/*

total: 0 errors, 2 warnings, 0 checks, 108 lines checked
7d660e218d01 drm/i915: Rename priotree to sched
80a6c86f4aea drm/i915: Pack params to engine->schedule() into a struct

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

[Intel-gfx] [CI 2/3] drm/i915: Rename priotree to sched

[Chris Wilson]

Having moved the priotree struct into i915_scheduler.h, identify it as
the scheduling element and rebrand into i915_sched. This becomes more
useful as we start attaching more information we require to propagate
through the scheduler.

v2: Use i915_sched_node for future distinctiveness

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gpu_error.c   |  2 +-
 drivers/gpu/drm/i915/i915_request.c | 66 +-
 drivers/gpu/drm/i915/i915_request.h |  6 +-
 drivers/gpu/drm/i915/i915_scheduler.h   |  4 +-
 drivers/gpu/drm/i915/intel_engine_cs.c  |  4 +-
 drivers/gpu/drm/i915/intel_guc_submission.c |  8 +--
 drivers/gpu/drm/i915/intel_lrc.c| 77 +++--
 7 files changed, 85 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index effaf982b19b..6b5b9b3ded02 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1278,7 +1278,7 @@ static void record_request(struct i915_request *request,
   struct drm_i915_error_request *erq)
 {
erq->context = request->ctx->hw_id;
-   erq->priority = request->priotree.priority;
+   erq->priority = request->sched.priority;
erq->ban_score = atomic_read(>ctx->ban_score);
erq->seqno = request->global_seqno;
erq->jiffies = request->emitted_jiffies;
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 9ca9c24b4421..dfcc6a0df3fb 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -125,22 +125,22 @@ i915_dependency_free(struct drm_i915_private *i915,
 }
 
 static void
-__i915_priotree_add_dependency(struct i915_priotree *pt,
-  struct i915_priotree *signal,
-  struct i915_dependency *dep,
-  unsigned long flags)
+__i915_sched_node_add_dependency(struct i915_sched_node *node,
+struct i915_sched_node *signal,
+struct i915_dependency *dep,
+unsigned long flags)
 {
INIT_LIST_HEAD(>dfs_link);
list_add(>wait_link, >waiters_list);
-   list_add(>signal_link, >signalers_list);
+   list_add(>signal_link, >signalers_list);
dep->signaler = signal;
dep->flags = flags;
 }
 
 static int
-i915_priotree_add_dependency(struct drm_i915_private *i915,
-struct i915_priotree *pt,
-struct i915_priotree *signal)
+i915_sched_node_add_dependency(struct drm_i915_private *i915,
+  struct i915_sched_node *node,
+  struct i915_sched_node *signal)
 {
struct i915_dependency *dep;
 
@@ -148,16 +148,18 @@ i915_priotree_add_dependency(struct drm_i915_private 
*i915,
if (!dep)
return -ENOMEM;
 
-   __i915_priotree_add_dependency(pt, signal, dep, I915_DEPENDENCY_ALLOC);
+   __i915_sched_node_add_dependency(node, signal, dep,
+I915_DEPENDENCY_ALLOC);
return 0;
 }
 
 static void
-i915_priotree_fini(struct drm_i915_private *i915, struct i915_priotree *pt)
+i915_sched_node_fini(struct drm_i915_private *i915,
+struct i915_sched_node *node)
 {
-   struct i915_dependency *dep, *next;
+   struct i915_dependency *dep, *tmp;
 
-   GEM_BUG_ON(!list_empty(>link));
+   GEM_BUG_ON(!list_empty(>link));
 
/*
 * Everyone we depended upon (the fences we wait to be signaled)
@@ -165,8 +167,8 @@ i915_priotree_fini(struct drm_i915_private *i915, struct 
i915_priotree *pt)
 * However, retirement is run independently on each timeline and
 * so we may be called out-of-order.
 */
-   list_for_each_entry_safe(dep, next, >signalers_list, signal_link) {
-   GEM_BUG_ON(!i915_priotree_signaled(dep->signaler));
+   list_for_each_entry_safe(dep, tmp, >signalers_list, signal_link) {
+   GEM_BUG_ON(!i915_sched_node_signaled(dep->signaler));
GEM_BUG_ON(!list_empty(>dfs_link));
 
list_del(>wait_link);
@@ -175,8 +177,8 @@ i915_priotree_fini(struct drm_i915_private *i915, struct 
i915_priotree *pt)
}
 
/* Remove ourselves from everyone who depends upon us */
-   list_for_each_entry_safe(dep, next, >waiters_list, wait_link) {
-   GEM_BUG_ON(dep->signaler != pt);
+   list_for_each_entry_safe(dep, tmp, >waiters_list, wait_link) {
+   GEM_BUG_ON(dep->signaler != node);
GEM_BUG_ON(!list_empty(>dfs_link));
 
list_del(>signal_link);
@@ -186,12 +188,12 @@ i915_priotree_fini(struct drm_i915_private *i915, struct 
i915_priotree 

[Intel-gfx] [CI 3/3] drm/i915: Pack params to engine->schedule() into a struct

[Chris Wilson]

Today we only want to pass along the priority to engine->schedule(), but
in the future we want to have much more control over the various aspects
of the GPU during a context's execution, for example controlling the
frequency allowed. As we need an ever growing number of parameters for
scheduling, move those into a struct for convenience.

v2: Move the anonymous struct into its own function for legibility and
ye olde gcc.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/gvt/scheduler.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  3 ++-
 drivers/gpu/drm/i915/i915_gem.c   | 18 +
 drivers/gpu/drm/i915/i915_gem_context.c   |  8 
 drivers/gpu/drm/i915/i915_gem_context.h   | 13 +---
 drivers/gpu/drm/i915/i915_gpu_error.c |  8 
 drivers/gpu/drm/i915/i915_gpu_error.h |  5 +++--
 drivers/gpu/drm/i915/i915_request.c   |  4 ++--
 drivers/gpu/drm/i915/i915_request.h   |  1 +
 drivers/gpu/drm/i915/i915_scheduler.h | 17 +++-
 drivers/gpu/drm/i915/intel_display.c  | 11 +-
 drivers/gpu/drm/i915/intel_engine_cs.c| 18 ++---
 drivers/gpu/drm/i915/intel_guc_submission.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c  | 20 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  4 +++-
 .../gpu/drm/i915/selftests/intel_hangcheck.c  |  4 ++--
 drivers/gpu/drm/i915/selftests/intel_lrc.c|  8 +---
 17 files changed, 91 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 638abe84857c..f3d21849b0cb 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -1135,7 +1135,7 @@ int intel_vgpu_setup_submission(struct intel_vgpu *vgpu)
return PTR_ERR(s->shadow_ctx);
 
if (HAS_LOGICAL_RING_PREEMPTION(vgpu->gvt->dev_priv))
-   s->shadow_ctx->priority = INT_MAX;
+   s->shadow_ctx->sched.priority = INT_MAX;
 
bitmap_zero(s->shadow_ctx_desc_updated, I915_NUM_ENGINES);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8e8667d9b084..028691108125 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -75,6 +75,7 @@
 #include "i915_gem_timeline.h"
 #include "i915_gpu_error.h"
 #include "i915_request.h"
+#include "i915_scheduler.h"
 #include "i915_vma.h"
 
 #include "intel_gvt.h"
@@ -3158,7 +3159,7 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
 struct intel_rps_client *rps);
 int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
  unsigned int flags,
- int priority);
+ const struct i915_sched_attr *attr);
 #define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
 
 int __must_check
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4c9d2a6f7d28..795ca83aed7a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -564,7 +564,8 @@ i915_gem_object_wait_reservation(struct reservation_object 
*resv,
return timeout;
 }
 
-static void __fence_set_priority(struct dma_fence *fence, int prio)
+static void __fence_set_priority(struct dma_fence *fence,
+const struct i915_sched_attr *attr)
 {
struct i915_request *rq;
struct intel_engine_cs *engine;
@@ -577,11 +578,12 @@ static void __fence_set_priority(struct dma_fence *fence, 
int prio)
 
rcu_read_lock();
if (engine->schedule)
-   engine->schedule(rq, prio);
+   engine->schedule(rq, attr);
rcu_read_unlock();
 }
 
-static void fence_set_priority(struct dma_fence *fence, int prio)
+static void fence_set_priority(struct dma_fence *fence,
+  const struct i915_sched_attr *attr)
 {
/* Recurse once into a fence-array */
if (dma_fence_is_array(fence)) {
@@ -589,16 +591,16 @@ static void fence_set_priority(struct dma_fence *fence, 
int prio)
int i;
 
for (i = 0; i < array->num_fences; i++)
-   __fence_set_priority(array->fences[i], prio);
+   __fence_set_priority(array->fences[i], attr);
} else {
-   __fence_set_priority(fence, prio);
+   __fence_set_priority(fence, attr);
}
 }
 
 int
 i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
  unsigned int flags,
- int prio)
+ const struct i915_sched_attr *attr)
 {
struct dma_fence *excl;
 
@@ -613,7 +615,7 @@ i915_gem_object_wait_priority(struct drm_i915_gem_object 
*obj,
  

[Intel-gfx] [CI 1/3] drm/i915: Move the priotree struct to its own headers

[Chris Wilson]

Over time the priotree has grown from a sorted list to a more
complicated structure for propagating constraints along the dependency
chain to try and resolve priority inversion. Start to segregate this
information from the rest of the request/fence tracking.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_request.h   | 39 +-
 drivers/gpu/drm/i915/i915_scheduler.h | 57 +++
 2 files changed, 58 insertions(+), 38 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_scheduler.h

diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 7d6eb82eeb91..e6f7c5f4ec7f 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -28,6 +28,7 @@
 #include 
 
 #include "i915_gem.h"
+#include "i915_scheduler.h"
 #include "i915_sw_fence.h"
 
 #include 
@@ -48,44 +49,6 @@ struct intel_signal_node {
struct list_head link;
 };
 
-struct i915_dependency {
-   struct i915_priotree *signaler;
-   struct list_head signal_link;
-   struct list_head wait_link;
-   struct list_head dfs_link;
-   unsigned long flags;
-#define I915_DEPENDENCY_ALLOC BIT(0)
-};
-
-/*
- * "People assume that time is a strict progression of cause to effect, but
- * actually, from a nonlinear, non-subjective viewpoint, it's more like a big
- * ball of wibbly-wobbly, timey-wimey ... stuff." -The Doctor, 2015
- *
- * Requests exist in a complex web of interdependencies. Each request
- * has to wait for some other request to complete before it is ready to be run
- * (e.g. we have to wait until the pixels have been rendering into a texture
- * before we can copy from it). We track the readiness of a request in terms
- * of fences, but we also need to keep the dependency tree for the lifetime
- * of the request (beyond the life of an individual fence). We use the tree
- * at various points to reorder the requests whilst keeping the requests
- * in order with respect to their various dependencies.
- */
-struct i915_priotree {
-   struct list_head signalers_list; /* those before us, we depend upon */
-   struct list_head waiters_list; /* those after us, they depend upon us */
-   struct list_head link;
-   int priority;
-};
-
-enum {
-   I915_PRIORITY_MIN = I915_CONTEXT_MIN_USER_PRIORITY - 1,
-   I915_PRIORITY_NORMAL = I915_CONTEXT_DEFAULT_PRIORITY,
-   I915_PRIORITY_MAX = I915_CONTEXT_MAX_USER_PRIORITY + 1,
-
-   I915_PRIORITY_INVALID = INT_MIN
-};
-
 struct i915_capture_list {
struct i915_capture_list *next;
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h 
b/drivers/gpu/drm/i915/i915_scheduler.h
new file mode 100644
index ..9d6ea9fa6e59
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -0,0 +1,57 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef _I915_SCHEDULER_H_
+#define _I915_SCHEDULER_H_
+
+#include 
+
+#include 
+
+enum {
+   I915_PRIORITY_MIN = I915_CONTEXT_MIN_USER_PRIORITY - 1,
+   I915_PRIORITY_NORMAL = I915_CONTEXT_DEFAULT_PRIORITY,
+   I915_PRIORITY_MAX = I915_CONTEXT_MAX_USER_PRIORITY + 1,
+
+   I915_PRIORITY_INVALID = INT_MIN
+};
+
+/*
+ * "People assume that time is a strict progression of cause to effect, but
+ * actually, from a nonlinear, non-subjective viewpoint, it's more like a big
+ * ball of wibbly-wobbly, timey-wimey ... stuff." -The Doctor, 2015
+ *
+ * Requests exist in a complex web of interdependencies. Each request
+ * has to wait for some other request to complete before it is ready to be run
+ * (e.g. we have to wait until the pixels have been rendering into a texture
+ * before we can copy from it). We track the readiness of a request in terms
+ * of fences, but we also need to keep the dependency tree for the lifetime
+ * of the request (beyond the life of an individual fence). We use the tree
+ * at various points to reorder the requests whilst keeping the requests
+ * in order with respect to their various dependencies.
+ *
+ * There is no active component to the "scheduler". As we know the dependency
+ * DAG of each request, we are able to insert it into a sorted queue when it
+ * is ready, and are able to reorder its portion of the graph to accommodate
+ * dynamic priority changes.
+ */
+struct i915_priotree {
+   struct list_head signalers_list; /* those before us, we depend upon */
+   struct list_head waiters_list; /* those after us, they depend upon us */
+   struct list_head link;
+   int priority;
+};
+
+struct i915_dependency {
+   struct i915_priotree *signaler;
+   struct list_head signal_link;
+   struct list_head wait_link;
+   struct list_head dfs_link;
+   unsigned long flags;
+#define I915_DEPENDENCY_ALLOC BIT(0)
+};
+
+#endif /* _I915_SCHEDULER_H_ */
-- 
2.17.0

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance

[Patchwork]

== Series Details ==

Series: drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance
URL   : https://patchwork.freedesktop.org/series/41883/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8733_full =

== Summary - WARNING ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +2

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_store@cachelines-bsd:
  shard-hsw:  PASS -> FAIL (fdo#17)

igt@kms_flip@2x-flip-vs-wf_vblank:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-apl:  PASS -> FAIL (fdo#100368)

igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt:
  shard-apl:  PASS -> FAIL (fdo#103167)

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  INCOMPLETE (fdo#106023, fdo#103665) -> PASS

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@flip-vs-blocking-wf-vblank:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103558) -> PASS +2

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS


  fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8733

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8733: 7f451ce363f70a1962ea45efa8fc972afcbc000d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Ville Syrjälä]

On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> >> From: Maarten Lankhorst 
> >>
> >> We skip src trunction/adjustments for
> >> NV12 case and handle the sizes directly.
> >> Without this, pipe fifo underruns are seen on APL/KBL.
> >>
> >> v2: For NV12, making the src coordinates multiplier of 4
> >>
> >> v3: Moving all the src coords handling code for NV12
> >> to skl_check_nv12_surface
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> Signed-off-by: Vidya Srinivas 
> >> ---
> >>  drivers/gpu/drm/i915/intel_display.c | 39 
> >> 
> >>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
> >>  2 files changed, 50 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 925402e..b8dbaca 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct 
> >> intel_crtc_state *crtc_state,
> >>return 0;
> >>  }
> >>  
> >> +static int
> >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> >> + struct intel_plane_state *plane_state)
> >> +{
> >> +  int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> >> +  int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
> >> +
> >> +  if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> >> +  ((plane_state->base.src_y >> 16) % 4) != 0 ||
> >> +  ((plane_state->base.src_w >> 16) % 4) != 0 ||
> >> +  ((plane_state->base.src_h >> 16) % 4) != 0) {
> >> +  DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
> >> +  return -EINVAL;
> >> +  }
> > I don't really see why we should check these. The clipped coordinates
> > are what matters.
> 
> To propagate our limits to the userspace. I think we should do it for all 
> formats,
> but NV12 is the first YUV format we have tests for. If we could we should do
> something similar for the other YUV formats, but they have different 
> requirements.
> 
> In case of NV12 we don't have existing userspace, there will be nothing that
> breaks if we enforce limits from the start.

But what about sub-pixel coordinates? You're totally ignoring them here.
We need to come up with some proper rules for this stuff.

> 
> >> +
> >> +  /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> >> +  if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
> >> +  (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
> >> +  DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
> >> +crtc_x2, crtc_y2,
> >> +crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> >> +  return -EINVAL;
> >> +  }
> > Why should we care? The current code already plays it fast and loose
> > and allows the dst rectangle to shrink to accomodate the hw limits.
> > If we want to change that we should change it universally.
> 
> Unfortunately for the other formats we already have an existing userspace
> (X.org) that doesn't perform any validation. We can't change it for that,
> but we can prevent future mistakes.

We should do it uniformly. Not per-format. That will make the code
unmaintainable real quick.

> 
> >> +
> >> +  plane_state->base.src.x1 =
> >> +  DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
> >> +  plane_state->base.src.x2 =
> >> +  DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
> >> +  plane_state->base.src.y1 =
> >> +  DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
> >> +  plane_state->base.src.y2 =
> >> +  DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
> > Since this can now increase the size of the source rectangle our
> > scaling factor checks are no longer 100% valid. We might end up with
> > a scaling factor that is too high.
> >
> > I don't really like any of these "let's make NV12 behave special"
> > tricks. We should make the code behave the same way for all pixel
> > formats instead of adding format specific hacks.
> 
> This is not nivalid because we restrict the original src coordinates to be
> a multiple of 4, you can only clip to something smaller, not to something
> bigger. :)

The clipped coordinates can be whatever thanks to scaling/etc.

Also why are we trying to make everything a multiple of four? I don't
remember any hw restrictions like that.

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

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for gpu: drm: i915: Change return type to vm_fault_t (rev2)

[Souptick Joarder]

On Wed, Apr 18, 2018 at 9:24 PM, Patchwork
 wrote:
> == Series Details ==
>
> Series: gpu: drm: i915: Change return type to vm_fault_t (rev2)
> URL   : https://patchwork.freedesktop.org/series/41893/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> 045e647f1204 gpu: drm: i915: Change return type to vm_fault_t
> -:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit 
> <12+ chars of sha1> ("")' - ie: 'commit 1c8f422059ae ("mm: change 
> return type to vm_fault_t")'

Does it mean I need to send v3 with correction ?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Maarten Lankhorst]

Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>> From: Maarten Lankhorst 
>>
>> We skip src trunction/adjustments for
>> NV12 case and handle the sizes directly.
>> Without this, pipe fifo underruns are seen on APL/KBL.
>>
>> v2: For NV12, making the src coordinates multiplier of 4
>>
>> v3: Moving all the src coords handling code for NV12
>> to skl_check_nv12_surface
>>
>> Signed-off-by: Maarten Lankhorst 
>> Signed-off-by: Vidya Srinivas 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 39 
>> 
>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
>>  2 files changed, 50 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 925402e..b8dbaca 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct 
>> intel_crtc_state *crtc_state,
>>  return 0;
>>  }
>>  
>> +static int
>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>> +   struct intel_plane_state *plane_state)
>> +{
>> +int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
>> +int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
>> +
>> +if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>> +((plane_state->base.src_y >> 16) % 4) != 0 ||
>> +((plane_state->base.src_w >> 16) % 4) != 0 ||
>> +((plane_state->base.src_h >> 16) % 4) != 0) {
>> +DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
>> +return -EINVAL;
>> +}
> I don't really see why we should check these. The clipped coordinates
> are what matters.

To propagate our limits to the userspace. I think we should do it for all 
formats,
but NV12 is the first YUV format we have tests for. If we could we should do
something similar for the other YUV formats, but they have different 
requirements.

In case of NV12 we don't have existing userspace, there will be nothing that
breaks if we enforce limits from the start.

>> +
>> +/* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
>> +if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
>> +(crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
>> +DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
>> +  crtc_x2, crtc_y2,
>> +  crtc_state->pipe_src_w, crtc_state->pipe_src_h);
>> +return -EINVAL;
>> +}
> Why should we care? The current code already plays it fast and loose
> and allows the dst rectangle to shrink to accomodate the hw limits.
> If we want to change that we should change it universally.

Unfortunately for the other formats we already have an existing userspace
(X.org) that doesn't perform any validation. We can't change it for that,
but we can prevent future mistakes.

>> +
>> +plane_state->base.src.x1 =
>> +DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
>> +plane_state->base.src.x2 =
>> +DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
>> +plane_state->base.src.y1 =
>> +DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
>> +plane_state->base.src.y2 =
>> +DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
> Since this can now increase the size of the source rectangle our
> scaling factor checks are no longer 100% valid. We might end up with
> a scaling factor that is too high.
>
> I don't really like any of these "let's make NV12 behave special"
> tricks. We should make the code behave the same way for all pixel
> formats instead of adding format specific hacks.

This is not nivalid because we restrict the original src coordinates to be
a multiple of 4, you can only clip to something smaller, not to something
bigger. :)

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Wait for vblank after register read

[Patchwork]

== Series Details ==

Series: drm/i915: Wait for vblank after register read
URL   : https://patchwork.freedesktop.org/series/41877/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8731_full =

== Summary - FAILURE ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@kms_flip@blocking-absolute-wf_vblank-interruptible:
  shard-apl:  PASS -> FAIL


 Warnings 

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)

igt@kms_vblank@pipe-b-accuracy-idle:
  shard-hsw:  PASS -> FAIL (fdo#102583)

igt@pm_rpm@universal-planes:
  shard-kbl:  PASS -> DMESG-WARN (fdo#103558, fdo#105602)


 Possible fixes 

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@flip-vs-blocking-wf-vblank:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS

igt@prime_self_import@basic-with_fd_dup:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8731

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8731: e03bb4d9e64828ac5797f6750752437e0a683383 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Enable late fbdev initial configuration

[Souza, Jose]

On Wed, 2018-04-18 at 17:55 +0100, Chris Wilson wrote:
> Quoting Souza, Jose (2018-04-18 17:42:47)
> > On Wed, 2018-04-18 at 09:26 +0100, Chris Wilson wrote:
> > > Quoting Souza, Jose (2018-04-18 01:07:16)
> > > > On Wed, 2018-04-18 at 00:44 +0100, Chris Wilson wrote:
> > > > > Quoting José Roberto de Souza (2018-04-17 23:34:18)
> > > > > > If the initial fbdev
> > > > > > configuration(intel_fbdev_initial_config())
> > > > > > runs and
> > > > > > there still no sink connected it will cause
> > > > > > drm_fb_helper_initial_config() to return 0 as no error
> > > > > > happened(but
> > > > > > internally the return is -EAGAIN).
> > > > > > Because no framebuffer was allocated, when a sink is
> > > > > > connected
> > > > > > intel_fbdev_output_poll_changed() will not execute
> > > > > > drm_fb_helper_hotplug_event() that would trigger another
> > > > > > try to
> > > > > > do
> > > > > > the
> > > > > > initial fbdev configuration.
> > > > > > 
> > > > > > So here creating a dummy framebuffer of 800x600, so
> > > > > > drm_fb_helper_hotplug_event() will be executed and fbdev
> > > > > > can be
> > > > > > properly
> > > > > > setup when a sink is connected, if needed the dummy
> > > > > > framebuffer
> > > > > > will be
> > > > > > freed and a new with the proper size will be allocated.
> > > > > > 
> > > > > > This issue also happens when a MST DP sink is connected
> > > > > > since
> > > > > > boot,
> > > > > > as
> > > > > > the MST topology is discovered in parallel if
> > > > > > intel_fbdev_initial_config()
> > > > > > is executed before the first sink MST is discovered it will
> > > > > > cause
> > > > > > this
> > > > > > same issue.
> > > > > > 
> > > > > > This is a follow up patch of
> > > > > > https://patchwork.freedesktop.org/patch/196089/
> > > > > > 
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=1041
> > > > > > 58
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=1044
> > > > > > 25
> > > > > > Cc: Chris Wilson 
> > > > > > Cc: Rodrigo Vivi 
> > > > > > Signed-off-by: José Roberto de Souza 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_fbdev.c | 24
> > > > > > +++-
> > > > > >  1 file changed, 23 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > > b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > > index 7d41d139341b..773577d39782 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > > @@ -696,14 +696,36 @@ int intel_fbdev_init(struct
> > > > > > drm_device
> > > > > > *dev)
> > > > > > return 0;
> > > > > >  }
> > > > > >  
> > > > > > +static void intel_fbdev_dummy_fb_create(struct intel_fbdev
> > > > > > *ifbdev)
> > > > > > +{
> > > > > > +   struct drm_fb_helper_surface_size sizes;
> > > > > > +
> > > > > > +   sizes.fb_width = 800;
> > > > > > +   sizes.fb_height = 600;
> > > > > > +   sizes.surface_width = sizes.fb_width;
> > > > > > +   sizes.surface_height = sizes.fb_height;
> > > > > > +   sizes.surface_bpp = 32;
> > > > > > +   sizes.surface_depth = 24;
> > > > > > +
> > > > > > +   if (intelfb_create(>helper, ))
> > > > > > +   DRM_ERROR("Unable to create dummy
> > > > > > framebufer");
> > > > > > +}
> > > > > > +
> > > > > >  static void intel_fbdev_initial_config(void *data,
> > > > > > async_cookie_t
> > > > > > cookie)
> > > > > >  {
> > > > > > struct intel_fbdev *ifbdev = data;
> > > > > >  
> > > > > > /* Due to peculiar init order wrt to hpd handling
> > > > > > this
> > > > > > is
> > > > > > separate. */
> > > > > > if (drm_fb_helper_initial_config(>helper,
> > > > > > -ifbdev-
> > > > > > > preferred_bpp))
> > > > > > 
> > > > > > +ifbdev-
> > > > > > > preferred_bpp)) {
> > > > > > 
> > > > > > intel_fbdev_unregister(to_i915(ifbdev-
> > > > > > > helper.dev));
> > > > > > 
> > > > > > +   return;
> > > > > > +   }
> > > > > > +
> > > > > > +   mutex_lock(>helper.lock);
> > > > > > +   if (!ifbdev->vma)
> > > > > > +   intel_fbdev_dummy_fb_create(ifbdev);
> > > > > > +   mutex_unlock(>helper.lock);
> > > > > >  }
> > > > > 
> > > > > Did you try
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > index 65a3313723c9..4120c635742d 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > @@ -493,6 +493,7 @@ static bool
> > > > > intel_fb_initial_config(struct
> > > > > drm_fb_helper *fb_helper,
> > > > >  bail:
> > > > > DRM_DEBUG_KMS("Not using firmware
> > > > > configuration\n");
> > > > > memcpy(enabled, save_enabled, count);
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/4] drm/i915: Always do WOPCM partitioning 
based on real firmware sizes
URL   : https://patchwork.freedesktop.org/series/41909/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8739 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927)


 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (33 -> 31) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8739

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8739: f6e5a01f3c8931f5b6420e877f8a8e596821926f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

f6e5a01f3c89 HAX enable guc for CI
03aa3dbadc8a drm/i915: Add code to accept valid locked WOPCM register values
c531aeed1378 drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset 
register
a83dfdf266d5 drm/i915: Always do WOPCM partitioning based on real firmware sizes

== Logs ==

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

[Intel-gfx] [PATCH v4 4/4] HAX enable guc for CI

[Jackie Li]

Signed-off-by: Jackie Li 
---
 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..53037b5 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, -1) \
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 v4 2/4] drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset register

[Jackie Li]

The enable_guc modparam is used to enable/disable GuC/HuC FW uploading
dynamically during i915 module loading. If WOPCM offset register was locked
without having HUC_LOADING_AGENT_GUC bit set to 1, the module reloading
with both GuC and HuC FW will fail since we need to set this bit to 1 for
HuC FW uploading.

Since HUC_LOADING_AGENT_GUC bit has no impact on GuC FW uploading, this
patch updates the register updating code to make sure the WOPCM offset
register is always locked with HUC_LOADING_AGENT_GUC bit set to 1 which
will guarantee successful uploading of both GuC and HuC FW. We will further
take care of the locked values in the following enhancement patch.

v4:
 - Fixed typo in commit message (Michal Wajdeczko)

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
Reviewed-by: John Spotswood 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 74bf76f..b1c08ca 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -238,8 +238,6 @@ static inline int write_and_verify(struct drm_i915_private 
*dev_priv,
 int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
 {
struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
-   u32 huc_agent;
-   u32 mask;
int err;
 
if (!USES_GUC(dev_priv))
@@ -255,10 +253,10 @@ int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
if (err)
goto err_out;
 
-   huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0;
-   mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET,
-  wopcm->guc.base | huc_agent, mask,
+  wopcm->guc.base | HUC_LOADING_AGENT_GUC,
+  GUC_WOPCM_OFFSET_MASK | HUC_LOADING_AGENT_GUC |
+  GUC_WOPCM_OFFSET_VALID,
   GUC_WOPCM_OFFSET_VALID);
if (err)
goto err_out;
-- 
2.7.4

___
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: Always do WOPCM partitioning based on real firmware sizes

[Jackie Li]

After enabled the WOPCM write-once registers locking status checking,
reloading of the i915 module will fail with modparam enable_guc set to 3
(enable GuC and HuC firmware loading) if the module was originally loaded
with enable_guc set to 1 (only enable GuC firmware loading). This is
because WOPCM registers were updated and locked without considering the HuC
FW size. Since we need both GuC and HuC FW sizes to determine the final
layout of WOPCM, we should always calculate the WOPCM layout based on the
actual sizes of the GuC and HuC firmware available for a specific platform
if we need continue to support enable/disable HuC FW loading dynamically
with enable_guc modparam.

This patch splits uC firmware fetching into two stages. First stage is to
fetch the firmware image and verify the firmware header. uC firmware will
be marked as verified and this will make FW info available for following
WOPCM layout calculation. The second stage is to create a GEM object and
copy the FW data into the created GEM object which will only be available
when GuC/HuC loading is enabled by enable_guc modparam. This will guarantee
that the WOPCM layout will be always be calculated correctly without making
any assumptions to the GuC and HuC firmware sizes.

v3:
 - Rebase

v4:
 - Renamed the new parameter add to intel_uc_fw_fetch (Michal)

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
Reviewed-by: John Spotswood 
---
 drivers/gpu/drm/i915/intel_uc.c| 14 --
 drivers/gpu/drm/i915/intel_uc_fw.c | 31 ---
 drivers/gpu/drm/i915/intel_uc_fw.h |  7 +--
 3 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 1cffaf7..73b8f6c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -172,11 +172,8 @@ void intel_uc_init_early(struct drm_i915_private *i915)
 
sanitize_options_early(i915);
 
-   if (USES_GUC(i915))
-   intel_uc_fw_fetch(i915, >fw);
-
-   if (USES_HUC(i915))
-   intel_uc_fw_fetch(i915, >fw);
+   intel_uc_fw_fetch(i915, >fw, USES_GUC(i915));
+   intel_uc_fw_fetch(i915, >fw, USES_HUC(i915));
 }
 
 void intel_uc_cleanup_early(struct drm_i915_private *i915)
@@ -184,11 +181,8 @@ void intel_uc_cleanup_early(struct drm_i915_private *i915)
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
 
-   if (USES_HUC(i915))
-   intel_uc_fw_fini(>fw);
-
-   if (USES_GUC(i915))
-   intel_uc_fw_fini(>fw);
+   intel_uc_fw_fini(>fw);
+   intel_uc_fw_fini(>fw);
 
guc_free_load_err_log(guc);
 }
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c 
b/drivers/gpu/drm/i915/intel_uc_fw.c
index 6e8e0b5..c1fed06 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -33,11 +33,13 @@
  *
  * @dev_priv: device private
  * @uc_fw: uC firmware
+ * @fetch: whether fetch uC firmware into GEM object or not
  *
- * Fetch uC firmware into GEM obj.
+ * Fetch and verify uC firmware and copy firmware data into GEM object if
+ * @fetch is true.
  */
 void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
-  struct intel_uc_fw *uc_fw)
+  struct intel_uc_fw *uc_fw, bool fetch)
 {
struct pci_dev *pdev = dev_priv->drm.pdev;
struct drm_i915_gem_object *obj;
@@ -154,17 +156,24 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
goto fail;
}
 
-   obj = i915_gem_object_create_from_data(dev_priv, fw->data, fw->size);
-   if (IS_ERR(obj)) {
-   err = PTR_ERR(obj);
-   DRM_DEBUG_DRIVER("%s fw object_create err=%d\n",
-intel_uc_fw_type_repr(uc_fw->type), err);
-   goto fail;
+   uc_fw->size = fw->size;
+   uc_fw->fetch_status = INTEL_UC_FIRMWARE_VERIFIED;
+
+   if (fetch) {
+   obj = i915_gem_object_create_from_data(dev_priv, fw->data,
+  fw->size);
+   if (IS_ERR(obj)) {
+   err = PTR_ERR(obj);
+   DRM_DEBUG_DRIVER("%s fw object_create err=%d\n",
+intel_uc_fw_type_repr(uc_fw->type),
+err);
+   goto fail;
+   }
+
+   uc_fw->obj = obj;
+   uc_fw->fetch_status = INTEL_UC_FIRMWARE_SUCCESS;
}
 
-   uc_fw->obj = obj;
-   uc_fw->size = fw->size;
-   uc_fw->fetch_status = INTEL_UC_FIRMWARE_SUCCESS;
DRM_DEBUG_DRIVER("%s fw fetch %s\n",

[Intel-gfx] [PATCH v4 3/4] drm/i915: Add code to accept valid locked WOPCM register values

[Jackie Li]

In current code, we only compare the locked WOPCM register values with the
calculated values. However, we can continue loading GuC/HuC firmware if the
locked (or partially locked) values were valid for current GuC/HuC firmware
sizes.

This patch added a new code path to verify whether the locked register
values can be used for GuC/HuC firmware loading, it will recalculate the
verify the new values if these registers were partially locked, so that we
won't fail the GuC/HuC firmware loading even if the locked register values
are different from the calculated ones.

v2:
 - Update WOPCM register only if it's not locked

v4:
 - Fixed typo in code comments (Michal)
 - Refined function names and parameters (Michal)
 - Avoided duplicated function calls (Michal)
 - Refined register updating ordering (Michal)

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
Reviewed-by: John Spotswood 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 251 -
 1 file changed, 194 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index b1c08ca..8fdcc48 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -51,6 +51,8 @@
 /* 8KB from GUC_WOPCM_RESERVED is reserved for GuC stack. */
 #define GUC_WOPCM_STACK_RESERVED   (8 * 1024)
 
+/* GuC WOPCM Size value needs to be aligned to 4KB. */
+#define GUC_WOPCM_SIZE_ALIGNMENT   (1UL << GUC_WOPCM_SIZE_SHIFT)
 /* GuC WOPCM Offset value needs to be aligned to 16KB. */
 #define GUC_WOPCM_OFFSET_ALIGNMENT (1UL << GUC_WOPCM_OFFSET_SHIFT)
 
@@ -86,60 +88,104 @@ static inline u32 context_reserved_size(struct 
drm_i915_private *i915)
return 0;
 }
 
-static inline int gen9_check_dword_gap(u32 guc_wopcm_base, u32 guc_wopcm_size)
+static inline int gen9_check_dword_gap(struct intel_wopcm *wopcm)
 {
-   u32 offset;
+   u32 gen9_min_guc_wopcm_size = wopcm->guc.base + GEN9_GUC_WOPCM_OFFSET +
+ sizeof(u32);
 
/*
 * GuC WOPCM size shall be at least a dword larger than the offset from
 * WOPCM base (GuC WOPCM offset from WOPCM base + GEN9_GUC_WOPCM_OFFSET)
 * due to hardware limitation on Gen9.
 */
-   offset = guc_wopcm_base + GEN9_GUC_WOPCM_OFFSET;
-   if (offset > guc_wopcm_size ||
-   (guc_wopcm_size - offset) < sizeof(u32)) {
+   if (wopcm->guc.size < gen9_min_guc_wopcm_size) {
DRM_ERROR("GuC WOPCM size %uKiB is too small. %uKiB needed.\n",
- guc_wopcm_size / 1024,
- (u32)(offset + sizeof(u32)) / 1024);
+ wopcm->guc.size / 1024,
+ gen9_min_guc_wopcm_size / 1024);
return -E2BIG;
}
 
return 0;
 }
 
-static inline int gen9_check_huc_fw_fits(u32 guc_wopcm_size, u32 huc_fw_size)
+static inline int gen9_check_huc_fw_fits(struct intel_wopcm *wopcm,
+u32 huc_fw_size)
 {
+   u32 available_guc_wopcm = wopcm->guc.size - GUC_WOPCM_RESERVED;
+
/*
 * On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
 * size to be larger than or equal to HuC firmware size. Otherwise,
 * firmware uploading would fail.
 */
-   if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) {
+   if (huc_fw_size > available_guc_wopcm) {
DRM_ERROR("HuC FW (%uKiB) won't fit in GuC WOPCM (%uKiB).\n",
- huc_fw_size / 1024,
- (guc_wopcm_size - GUC_WOPCM_RESERVED) / 1024);
+ huc_fw_size / 1024, available_guc_wopcm / 1024);
return -E2BIG;
}
 
return 0;
 }
 
-static inline int check_hw_restriction(struct drm_i915_private *i915,
-  u32 guc_wopcm_base, u32 guc_wopcm_size,
+static inline int check_hw_restriction(struct intel_wopcm *wopcm,
   u32 huc_fw_size)
 {
+   struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
int err = 0;
 
if (IS_GEN9(i915))
-   err = gen9_check_dword_gap(guc_wopcm_base, guc_wopcm_size);
+   err = gen9_check_dword_gap(wopcm);
 
if (!err &&
(IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)))
-   err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
+   err = gen9_check_huc_fw_fits(wopcm, huc_fw_size);
 
return err;
 }
 
+static inline u32 fw_usable_wopcm_size(struct intel_wopcm *wopcm)
+{
+   struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
+ 

Re: [Intel-gfx] [PATCH i-g-t 09/11] trace.pl: Add support for colouring context execution

[Lionel Landwerlin]

One suggestion below, otherwise :

Reviewed-by: Lionel Landwerlin 

On 06/03/18 04:43, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Add the command line switch which uses different colours for different
context execution boxes.

Signed-off-by: Tvrtko Ursulin 
Cc: John Harrison 
---
  scripts/trace.pl | 41 +++--
  1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index e7ce273ef26a..ff61dea0768d 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -40,6 +40,7 @@ my $trace = 0;
  my $avg_delay_stats = 0;
  my $squash_context_id = 0;
  my $gpu_timeline = 0;
+my $colour_contexts = 0;
  
  my @args;
  
@@ -110,6 +111,8 @@ Usage:

--squash-ctx-id Squash context id by substracting engine
id from ctx id.
--gpu-timeline  Draw overall GPU busy timeline.
+  --colour-contexts / -c   Use different colours for different
+   context execution boxes.
  ENDHELP
  
  		exit 0;

@@ -279,6 +282,20 @@ sub arg_skip_box
return @_;
  }
  
+sub arg_colour_contexts

+{
+   return unless scalar(@_);
+
+   if ($_[0] eq '--colour-contexts' or
+   $_[0] eq '--color-contexts' or
+   $_[0] eq '-c') {
+   shift @_;
+   $colour_contexts = 1;
+   }
+
+   return @_;
+}
+
  @args = @ARGV;
  while (@args) {
my $left = scalar(@args);
@@ -294,6 +311,7 @@ while (@args) {
@args = arg_split_requests(@args);
@args = arg_ignore_ring(@args);
@args = arg_skip_box(@args);
+   @args = arg_colour_contexts(@args);
  
  	last if $left == scalar(@args);

  }
@@ -581,6 +599,7 @@ foreach my $key (@sorted_keys) {
  
  my $last_ts = 0;

  my $first_ts;
+my $min_ctx;
  
  foreach my $key (@sorted_keys) {

my $ring = $db{$key}->{'ring'};
@@ -590,6 +609,8 @@ foreach my $key (@sorted_keys) {
  
  	$first_ts = $db{$key}->{'queue'} if not defined $first_ts or $db{$key}->{'queue'} < $first_ts;

$last_ts = $end if $end > $last_ts;
+   $min_ctx = $db{$key}->{'ctx'} if not defined $min_ctx or
+$db{$key}->{'ctx'} < $min_ctx;
  
  	$db{$key}->{'context-complete-delay'} = $end - $notify;

$db{$key}->{'execute-delay'} = $start - $db{$key}->{'submit'};
@@ -721,6 +742,8 @@ foreach my $key (keys %reqwait) {
  say sprintf('GPU: %.2f%% idle, %.2f%% busy',
 $flat_busy{'gpu-idle'}, $flat_busy{'gpu-busy'}) unless $html;
  
+my $execute_colour = $colour_contexts ? 'multi-colour' : 'pink';

+
  print <
  
@@ -741,7 +764,7 @@ print {'name'}, $db{$key}->{'ctx'}, 
$db{$key}->{'seqno'});
@@ -898,7 +934,8 @@ foreach my $key (sort sortQueue keys %db) {
if (exists $db{$key}->{'incomplete'}) {
$style = 'color: white; background-color: red;';
} else {
-   $style = 'color: black; background-color: pink;';
+   $style = 'color: black; background-color: ' .
+ ctx_colour($ctx) . ';';
}
$content = "$name $db{$key}->{'port'}";
$content .= ' ??? ' if exists 
$db{$key}->{'incomplete'};



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

Re: [Intel-gfx] [PATCH v9 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

[Oscar Mateo]

On 4/18/2018 9:40 AM, Oscar Mateo wrote:



On 4/17/2018 3:59 PM, Yunwei Zhang wrote:

L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank 
pairs

are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank 
range

will return 0 instead of correct values.

However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.

References: HSDES#1405586840

v2:
  - use fls instead of find_last_bit (Chris)
  - use is_power_of_2() instead of counting bit set (Chris)
v3:
  - rebase on latest tip
v5:
  - Added references (Mika)
  - Move local variable into scope where they are used (Ursulin)
  - use a new local variable to reduce long line of code (Ursulin)
v6:
  - Some coding style and use more local variables for clearer
    logic (Ursulin)
v7:
  - Rebased.
v8:
  - Reviewed by Oscar.
v9:
  - Fixed label location. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_reg.h  |  4 
  drivers/gpu/drm/i915/intel_device_info.c | 23 +++
  2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h 
b/drivers/gpu/drm/i915/i915_reg.h

index fb10602..6c9c01b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2709,6 +2709,10 @@ enum i915_power_well_id {
  #define   GEN10_F2_SS_DIS_SHIFT    18
  #define   GEN10_F2_SS_DIS_MASK    (0xf << GEN10_F2_SS_DIS_SHIFT)
  +#define    GEN10_MIRROR_FUSE3    _MMIO(0x9118)
+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK   0x0F
+
  #define GEN8_EU_DISABLE0    _MMIO(0x9134)
  #define   GEN8_EU_DIS0_S0_MASK    0xff
  #define   GEN8_EU_DIS0_S1_SHIFT    24
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c

index 1a4288f..530b6ba 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -729,6 +729,29 @@ static void sanitize_mcr(struct 
intel_device_info *info)

  u32 slice = fls(info->sseu.slice_mask);
  u32 subslice = fls(info->sseu.subslice_mask[slice]);
  +    /*
+ * WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
+ * L3Banks could be fused off in single slice scenario, however, if
+ * more than one slice is enabled, this should not happen.
+ */


Maybe a better explanation is warranted:

/*
 * WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
 * L3Banks could be fused off in single slice scenario. If that is the 
case,

 * we might need to program MCR select to a valid L3Bank by default,
 * to make sure we correctly read certain registers later on
* (in the range 0xB100 - 0xB3FF).
 * This might be incompatible with 
WaProgramMgsrForCorrectSliceSpecificMmioReads.

 * Fortunately, this should not happen in production hardware, so we only
 * assert that this is the case (instead of implementing something more 
complex

 * that requires checking the range of every MMIO read).
 */


+    if (is_power_of_2(info->sseu.slice_mask)) {


This WA is only required for GEN >= 10. In other GENs, 
GEN10_MIRROR_FUSE3 does not even exist!



+    /*
+ * read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+ * enabled subslice, no need to redirect MCR packet
+ */
+    u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+    u8 ss_mask = info->sseu.subslice_mask[slice];
+
+    u8 enabled_mask = (ss_mask | ss_mask >> 4) & 0xf;
+    u8 disabled_mask = fuse3 & 0xf;
+


You defined GEN10_L3BANK_MASK. Might as well use it :)


+    /*
+ * Production silicon should have matched L3Bank and
+ * subslice enabled
+ */
+    WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
+    }
+
  if (INTEL_GEN(dev_priv) >= 11) {
  mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
    GEN11_MCR_SUBSLICE_MASK;




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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 07/11] trace.pl: Move min/max timestamp lookup to last loop

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 06/03/18 04:43, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

It makes sense to fetch the min and max timestamp only after the
last sort of the array.

Signed-off-by: Tvrtko Ursulin 
Cc: John Harrison 
---
  scripts/trace.pl | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index d49d25d6c1ca..27b39efcebbd 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -531,8 +531,6 @@ foreach my $key (keys %db) {
  # GPU time accounting
  my (%running, %runnable, %queued, %batch_avg, %batch_total_avg, %batch_count);
  my (%submit_avg, %execute_avg, %ctxsave_avg);
-my $last_ts = 0;
-my $first_ts;
  
  sub sortStart {

my $as = $db{$a}->{'start'};
@@ -554,9 +552,6 @@ foreach my $key (@sorted_keys) {
my $ring = $db{$key}->{'ring'};
my $end = $db{$key}->{'end'};
  
-	$first_ts = $db{$key}->{'queue'} if not defined $first_ts or $db{$key}->{'queue'} < $first_ts;

-   $last_ts = $end if $end > $last_ts;
-
# correct duration of merged batches
if ($correct_durations and exists $db{$key}->{'no-end'}) {
my $ctx = $db{$key}->{'ctx'};
@@ -584,12 +579,18 @@ foreach my $key (@sorted_keys) {
  
  @sorted_keys = sort sortStart keys %db if $re_sort;
  
+my $last_ts = 0;

+my $first_ts;
+
  foreach my $key (@sorted_keys) {
my $ring = $db{$key}->{'ring'};
my $end = $db{$key}->{'end'};
my $start = $db{$key}->{'start'};
my $notify = $db{$key}->{'notify'};
  
+	$first_ts = $db{$key}->{'queue'} if not defined $first_ts or $db{$key}->{'queue'} < $first_ts;

+   $last_ts = $end if $end > $last_ts;
+
$db{$key}->{'context-complete-delay'} = $end - $notify;
$db{$key}->{'execute-delay'} = $start - $db{$key}->{'submit'};
$db{$key}->{'submit-delay'} = $db{$key}->{'submit'} - 
$db{$key}->{'queue'};



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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 06/11] trace.pl: Move sortQueue near its user

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 06/03/18 04:43, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Just to clear up some space for incoming code refactoring.

Signed-off-by: Tvrtko Ursulin 
Cc: John Harrison 
---
  scripts/trace.pl | 22 +++---
  1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index 509df6c0dd8b..d49d25d6c1ca 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -545,17 +545,6 @@ sub sortStart {
return $val;
  }
  
-sub sortQueue {

-   my $as = $db{$a}->{'queue'};
-   my $bs = $db{$b}->{'queue'};
-   my $val;
-
-   $val = $as <=> $bs;
-   $val = $a cmp $b if $val == 0;
-
-   return $val;
-}
-
  my @sorted_keys = sort sortStart keys %db;
  my $re_sort = 0;
  
@@ -859,6 +848,17 @@ print <{'queue'};
+   my $bs = $db{$b}->{'queue'};
+   my $val;
+
+   $val = $as <=> $bs;
+   $val = $a cmp $b if $val == 0;
+
+   return $val;
+}
+
  my $i = 0;
  foreach my $key (sort sortQueue keys %db) {
my ($name, $ctx, $seqno) = ($db{$key}->{'name'}, $db{$key}->{'ctx'}, 
$db{$key}->{'seqno'});



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

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Enable late fbdev initial configuration

[Chris Wilson]

Quoting Souza, Jose (2018-04-18 17:42:47)
> On Wed, 2018-04-18 at 09:26 +0100, Chris Wilson wrote:
> > Quoting Souza, Jose (2018-04-18 01:07:16)
> > > On Wed, 2018-04-18 at 00:44 +0100, Chris Wilson wrote:
> > > > Quoting José Roberto de Souza (2018-04-17 23:34:18)
> > > > > If the initial fbdev
> > > > > configuration(intel_fbdev_initial_config())
> > > > > runs and
> > > > > there still no sink connected it will cause
> > > > > drm_fb_helper_initial_config() to return 0 as no error
> > > > > happened(but
> > > > > internally the return is -EAGAIN).
> > > > > Because no framebuffer was allocated, when a sink is connected
> > > > > intel_fbdev_output_poll_changed() will not execute
> > > > > drm_fb_helper_hotplug_event() that would trigger another try to
> > > > > do
> > > > > the
> > > > > initial fbdev configuration.
> > > > > 
> > > > > So here creating a dummy framebuffer of 800x600, so
> > > > > drm_fb_helper_hotplug_event() will be executed and fbdev can be
> > > > > properly
> > > > > setup when a sink is connected, if needed the dummy framebuffer
> > > > > will be
> > > > > freed and a new with the proper size will be allocated.
> > > > > 
> > > > > This issue also happens when a MST DP sink is connected since
> > > > > boot,
> > > > > as
> > > > > the MST topology is discovered in parallel if
> > > > > intel_fbdev_initial_config()
> > > > > is executed before the first sink MST is discovered it will
> > > > > cause
> > > > > this
> > > > > same issue.
> > > > > 
> > > > > This is a follow up patch of
> > > > > https://patchwork.freedesktop.org/patch/196089/
> > > > > 
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
> > > > > Cc: Chris Wilson 
> > > > > Cc: Rodrigo Vivi 
> > > > > Signed-off-by: José Roberto de Souza 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_fbdev.c | 24
> > > > > +++-
> > > > >  1 file changed, 23 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > index 7d41d139341b..773577d39782 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > > @@ -696,14 +696,36 @@ int intel_fbdev_init(struct drm_device
> > > > > *dev)
> > > > > return 0;
> > > > >  }
> > > > >  
> > > > > +static void intel_fbdev_dummy_fb_create(struct intel_fbdev
> > > > > *ifbdev)
> > > > > +{
> > > > > +   struct drm_fb_helper_surface_size sizes;
> > > > > +
> > > > > +   sizes.fb_width = 800;
> > > > > +   sizes.fb_height = 600;
> > > > > +   sizes.surface_width = sizes.fb_width;
> > > > > +   sizes.surface_height = sizes.fb_height;
> > > > > +   sizes.surface_bpp = 32;
> > > > > +   sizes.surface_depth = 24;
> > > > > +
> > > > > +   if (intelfb_create(>helper, ))
> > > > > +   DRM_ERROR("Unable to create dummy framebufer");
> > > > > +}
> > > > > +
> > > > >  static void intel_fbdev_initial_config(void *data,
> > > > > async_cookie_t
> > > > > cookie)
> > > > >  {
> > > > > struct intel_fbdev *ifbdev = data;
> > > > >  
> > > > > /* Due to peculiar init order wrt to hpd handling this
> > > > > is
> > > > > separate. */
> > > > > if (drm_fb_helper_initial_config(>helper,
> > > > > -ifbdev-
> > > > > >preferred_bpp))
> > > > > +ifbdev-
> > > > > >preferred_bpp)) {
> > > > > intel_fbdev_unregister(to_i915(ifbdev-
> > > > > > helper.dev));
> > > > > 
> > > > > +   return;
> > > > > +   }
> > > > > +
> > > > > +   mutex_lock(>helper.lock);
> > > > > +   if (!ifbdev->vma)
> > > > > +   intel_fbdev_dummy_fb_create(ifbdev);
> > > > > +   mutex_unlock(>helper.lock);
> > > > >  }
> > > > 
> > > > Did you try
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > index 65a3313723c9..4120c635742d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > @@ -493,6 +493,7 @@ static bool intel_fb_initial_config(struct
> > > > drm_fb_helper *fb_helper,
> > > >  bail:
> > > > DRM_DEBUG_KMS("Not using firmware
> > > > configuration\n");
> > > > memcpy(enabled, save_enabled, count);
> > > > +   fb_helper->deferred_setup = true;
> > > 
> > > This is too earlier to set deferred_setup when
> > > intel_fb_initial_config() fails,
> > > __drm_fb_helper_initial_config_and_unlock() will then try to
> > > probe/create a fb but as there is no sink connected it will fail
> > > too.
> > > 
> > > Also __drm_fb_helper_initial_config_and_unlock() is already setting
> > > deferred_setup if both attempts fails.
> > 
> > 

Re: [Intel-gfx] [PATCH v9 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

[Oscar Mateo]

On 4/18/2018 9:45 AM, Oscar Mateo wrote:



On 4/18/2018 9:38 AM, Chris Wilson wrote:

Quoting Oscar Mateo (2018-04-18 17:30:41)


On 4/17/2018 3:58 PM, Yunwei Zhang wrote:

+ /*
+  * HW expects MCR to be programed to a enabled slice/subslice 
pair

+  * before any MMIO read into slice/subslice register
+  */
The comment above makes more sense in sanitize_mcr, together with 
the WA

label. You can make it a bit more verbose with the info in the commit
message. Something like this:

/*
   * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
   * Before any MMIO read into slice/subslice specific registers, MCR
   * packet control register needs to be programmed to point to any
   * enabled s/ss pair. Otherwise, incorrect values will be returned.
   * This means each subsequent MMIO read will be forwarded to an
   * specific s/ss combination, but this is OK since these registers
   * are consistent across s/ss in almost all cases. In the rare
   * occasions, such as INSTDONE, where this value is dependent
   * on s/ss combo, the read shoud be done with read_subslice_reg.
   */

I don't think any other comment is required here.

Apart from the answer to the earlier question, what mmio read after this
point? If all slice/subslice register access is through this function,
what are you trying to protect? Very curious.
-Chris


The problem is that the BSpec does not have a comprehensive list of 
registers that live in the slice/subslice, so it's difficult to know 
when this is going to become a problem. For example, I know from 
previous experience that the MOCS tables are replicated across slices 
(that's why we couldn't let UMD decide when to shutdown them: because 
the MOCS tables get lost as soon as you reconfigure the number of 
s/ss. The only way to do this in by poking in the context, so that the 
MOCS gets reprogrammed immediately after).


This hasn't been an issue until know because the hardware would route 
your read to a valid s/ss combo whenever the MCR select was 0s. 
Apparently, this is not the case anymore...

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

Re: [Intel-gfx] [PATCH v9 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

[Oscar Mateo]

On 4/18/2018 9:38 AM, Chris Wilson wrote:

Quoting Oscar Mateo (2018-04-18 17:30:41)


On 4/17/2018 3:58 PM, Yunwei Zhang wrote:

+ /*
+  * HW expects MCR to be programed to a enabled slice/subslice pair
+  * before any MMIO read into slice/subslice register
+  */

The comment above makes more sense in sanitize_mcr, together with the WA
label. You can make it a bit more verbose with the info in the commit
message. Something like this:

/*
   * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
   * Before any MMIO read into slice/subslice specific registers, MCR
   * packet control register needs to be programmed to point to any
   * enabled s/ss pair. Otherwise, incorrect values will be returned.
   * This means each subsequent MMIO read will be forwarded to an
   * specific s/ss combination, but this is OK since these registers
   * are consistent across s/ss in almost all cases. In the rare
   * occasions, such as INSTDONE, where this value is dependent
   * on s/ss combo, the read shoud be done with read_subslice_reg.
   */

I don't think any other comment is required here.

Apart from the answer to the earlier question, what mmio read after this
point? If all slice/subslice register access is through this function,
what are you trying to protect? Very curious.
-Chris


The problem is that the BSpec does not have a comprehensive list of 
registers that live in the slice/subslice, so it's difficult to know 
when this is going to become a problem. For example, I know from 
previous experience that the MOCS tables are replicated across slices 
(that's why we couldn't let UMD decide when to shutdown them: because 
the MOCS tables get lost as soon as you reconfigure the number of s/ss. 
The only way to do this in by poking in the context, so that the MOCS 
gets reprogrammed immediately after).

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Enabling content-type setting for HDMI displays.

[Patchwork]

== Series Details ==

Series: Enabling content-type setting for HDMI displays.
URL   : https://patchwork.freedesktop.org/series/41876/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4065_full -> Patchwork_8730_full =

== Summary - WARNING ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-vebox:
  shard-kbl:  PASS -> SKIP +1

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  SKIP -> PASS +3


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_color@pipe-a-legacy-gamma:
  shard-kbl:  PASS -> DMESG-WARN (fdo#105602, fdo#103558) +18

igt@kms_flip@modeset-vs-vblank-race:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_setmode@basic:
  shard-apl:  PASS -> FAIL (fdo#99912)

igt@kms_sysfs_edid_timing:
  shard-apl:  PASS -> WARN (fdo#100047)


 Possible fixes 

igt@gem_eio@in-flight-suspend:
  shard-kbl:  DMESG-WARN (fdo#103313) -> PASS

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  INCOMPLETE (fdo#103665, fdo#106023) -> PASS

igt@kms_cursor_crc@cursor-256x85-offscreen:
  shard-hsw:  DMESG-FAIL -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103558) -> PASS +20

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103313, fdo#103558) -> 
PASS +4


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 4) ==

  Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4065 -> Patchwork_8730

  CI_DRM_4065: c7cec67f9e1da120bc3b8782bb8013b285789c96 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8730: 73070dc1a0d9ce14dcda607deb37f2eb9e4f6061 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Enable late fbdev initial configuration

[Souza, Jose]

On Wed, 2018-04-18 at 09:26 +0100, Chris Wilson wrote:
> Quoting Souza, Jose (2018-04-18 01:07:16)
> > On Wed, 2018-04-18 at 00:44 +0100, Chris Wilson wrote:
> > > Quoting José Roberto de Souza (2018-04-17 23:34:18)
> > > > If the initial fbdev
> > > > configuration(intel_fbdev_initial_config())
> > > > runs and
> > > > there still no sink connected it will cause
> > > > drm_fb_helper_initial_config() to return 0 as no error
> > > > happened(but
> > > > internally the return is -EAGAIN).
> > > > Because no framebuffer was allocated, when a sink is connected
> > > > intel_fbdev_output_poll_changed() will not execute
> > > > drm_fb_helper_hotplug_event() that would trigger another try to
> > > > do
> > > > the
> > > > initial fbdev configuration.
> > > > 
> > > > So here creating a dummy framebuffer of 800x600, so
> > > > drm_fb_helper_hotplug_event() will be executed and fbdev can be
> > > > properly
> > > > setup when a sink is connected, if needed the dummy framebuffer
> > > > will be
> > > > freed and a new with the proper size will be allocated.
> > > > 
> > > > This issue also happens when a MST DP sink is connected since
> > > > boot,
> > > > as
> > > > the MST topology is discovered in parallel if
> > > > intel_fbdev_initial_config()
> > > > is executed before the first sink MST is discovered it will
> > > > cause
> > > > this
> > > > same issue.
> > > > 
> > > > This is a follow up patch of
> > > > https://patchwork.freedesktop.org/patch/196089/
> > > > 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
> > > > Cc: Chris Wilson 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_fbdev.c | 24
> > > > +++-
> > > >  1 file changed, 23 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > index 7d41d139341b..773577d39782 100644
> > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > @@ -696,14 +696,36 @@ int intel_fbdev_init(struct drm_device
> > > > *dev)
> > > > return 0;
> > > >  }
> > > >  
> > > > +static void intel_fbdev_dummy_fb_create(struct intel_fbdev
> > > > *ifbdev)
> > > > +{
> > > > +   struct drm_fb_helper_surface_size sizes;
> > > > +
> > > > +   sizes.fb_width = 800;
> > > > +   sizes.fb_height = 600;
> > > > +   sizes.surface_width = sizes.fb_width;
> > > > +   sizes.surface_height = sizes.fb_height;
> > > > +   sizes.surface_bpp = 32;
> > > > +   sizes.surface_depth = 24;
> > > > +
> > > > +   if (intelfb_create(>helper, ))
> > > > +   DRM_ERROR("Unable to create dummy framebufer");
> > > > +}
> > > > +
> > > >  static void intel_fbdev_initial_config(void *data,
> > > > async_cookie_t
> > > > cookie)
> > > >  {
> > > > struct intel_fbdev *ifbdev = data;
> > > >  
> > > > /* Due to peculiar init order wrt to hpd handling this
> > > > is
> > > > separate. */
> > > > if (drm_fb_helper_initial_config(>helper,
> > > > -ifbdev-
> > > > >preferred_bpp))
> > > > +ifbdev-
> > > > >preferred_bpp)) {
> > > > intel_fbdev_unregister(to_i915(ifbdev-
> > > > > helper.dev));
> > > > 
> > > > +   return;
> > > > +   }
> > > > +
> > > > +   mutex_lock(>helper.lock);
> > > > +   if (!ifbdev->vma)
> > > > +   intel_fbdev_dummy_fb_create(ifbdev);
> > > > +   mutex_unlock(>helper.lock);
> > > >  }
> > > 
> > > Did you try
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > > b/drivers/gpu/drm/i915/intel_fbdev.c
> > > index 65a3313723c9..4120c635742d 100644
> > > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > > @@ -493,6 +493,7 @@ static bool intel_fb_initial_config(struct
> > > drm_fb_helper *fb_helper,
> > >  bail:
> > > DRM_DEBUG_KMS("Not using firmware
> > > configuration\n");
> > > memcpy(enabled, save_enabled, count);
> > > +   fb_helper->deferred_setup = true;
> > 
> > This is too earlier to set deferred_setup when
> > intel_fb_initial_config() fails,
> > __drm_fb_helper_initial_config_and_unlock() will then try to
> > probe/create a fb but as there is no sink connected it will fail
> > too.
> > 
> > Also __drm_fb_helper_initial_config_and_unlock() is already setting
> > deferred_setup if both attempts fails.
> 
> So...
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 7d41d139341b..5f138a03dd2a 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -807,7 +807,7 @@ void intel_fbdev_output_poll_changed(struct
> 

Re: [Intel-gfx] [PATCH v9 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

[Oscar Mateo]

On 4/17/2018 3:59 PM, Yunwei Zhang wrote:

L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.

However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.

References: HSDES#1405586840

v2:
  - use fls instead of find_last_bit (Chris)
  - use is_power_of_2() instead of counting bit set (Chris)
v3:
  - rebase on latest tip
v5:
  - Added references (Mika)
  - Move local variable into scope where they are used (Ursulin)
  - use a new local variable to reduce long line of code (Ursulin)
v6:
  - Some coding style and use more local variables for clearer
logic (Ursulin)
v7:
  - Rebased.
v8:
  - Reviewed by Oscar.
v9:
  - Fixed label location. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_reg.h  |  4 
  drivers/gpu/drm/i915/intel_device_info.c | 23 +++
  2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fb10602..6c9c01b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2709,6 +2709,10 @@ enum i915_power_well_id {
  #define   GEN10_F2_SS_DIS_SHIFT   18
  #define   GEN10_F2_SS_DIS_MASK(0xf << GEN10_F2_SS_DIS_SHIFT)
  
+#define	GEN10_MIRROR_FUSE3		_MMIO(0x9118)

+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK   0x0F
+
  #define GEN8_EU_DISABLE0  _MMIO(0x9134)
  #define   GEN8_EU_DIS0_S0_MASK0xff
  #define   GEN8_EU_DIS0_S1_SHIFT   24
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 1a4288f..530b6ba 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -729,6 +729,29 @@ static void sanitize_mcr(struct intel_device_info *info)
u32 slice = fls(info->sseu.slice_mask);
u32 subslice = fls(info->sseu.subslice_mask[slice]);
  
+	/*

+* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
+* L3Banks could be fused off in single slice scenario, however, if
+* more than one slice is enabled, this should not happen.
+*/
+   if (is_power_of_2(info->sseu.slice_mask)) {


This WA is only required for GEN >= 10. In other GENs, 
GEN10_MIRROR_FUSE3 does not even exist!



+   /*
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
+   u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+   u8 ss_mask = info->sseu.subslice_mask[slice];
+
+   u8 enabled_mask = (ss_mask | ss_mask >> 4) & 0xf;
+   u8 disabled_mask = fuse3 & 0xf;
+


You defined GEN10_L3BANK_MASK. Might as well use it :)


+   /*
+* Production silicon should have matched L3Bank and
+* subslice enabled
+*/
+   WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
+   }
+
if (INTEL_GEN(dev_priv) >= 11) {
mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
  GEN11_MCR_SUBSLICE_MASK;


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

Re: [Intel-gfx] [PATCH v9 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

[Chris Wilson]

Quoting Oscar Mateo (2018-04-18 17:30:41)
> 
> 
> On 4/17/2018 3:58 PM, Yunwei Zhang wrote:
> > + /*
> > +  * HW expects MCR to be programed to a enabled slice/subslice pair
> > +  * before any MMIO read into slice/subslice register
> > +  */
> 
> The comment above makes more sense in sanitize_mcr, together with the WA 
> label. You can make it a bit more verbose with the info in the commit 
> message. Something like this:
> 
> /*
>   * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
>   * Before any MMIO read into slice/subslice specific registers, MCR
>   * packet control register needs to be programmed to point to any
>   * enabled s/ss pair. Otherwise, incorrect values will be returned.
>   * This means each subsequent MMIO read will be forwarded to an
>   * specific s/ss combination, but this is OK since these registers
>   * are consistent across s/ss in almost all cases. In the rare
>   * occasions, such as INSTDONE, where this value is dependent
>   * on s/ss combo, the read shoud be done with read_subslice_reg.
>   */
> 
> I don't think any other comment is required here.

Apart from the answer to the earlier question, what mmio read after this
point? If all slice/subslice register access is through this function,
what are you trying to protect? Very curious.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Don't use -ETIMEDOUT from inside a test

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Don't use -ETIMEDOUT from inside a test
URL   : https://patchwork.freedesktop.org/series/41828/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4065_full -> Patchwork_8728_full =

== Summary - WARNING ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@kms_atomic@atomic_invalid_params:
  shard-snb:  PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#102887)

igt@kms_flip@2x-modeset-vs-vblank-race:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@2x-plain-flip-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_setmode@basic:
  shard-apl:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@kms_cursor_crc@cursor-256x85-offscreen:
  shard-hsw:  DMESG-FAIL -> PASS


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


== Participating hosts (9 -> 3) ==

  Missing(6): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-kbl 
shard-glkb 


== Build changes ==

* Linux: CI_DRM_4065 -> Patchwork_8728

  CI_DRM_4065: c7cec67f9e1da120bc3b8782bb8013b285789c96 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8728: 500d4881d94713807a515b0de2f6cf5125e276de @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH v9 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

[Oscar Mateo]

On 4/17/2018 3:58 PM, Yunwei Zhang wrote:

WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.

However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.

Also, 0xFDC will lose its information after TDR/engine reset/power state
change.

References: HSD#1405586840, BSID#0575

v2:
  - use fls() instead of find_last_bit() (Chris)
  - added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
  - rebase on latest tip
v5:
  - Added references (Mika)
  - Change the ordered of passing arguments and etc. (Ursulin)
v7:
  - Rebased.
v8:
  - Reviewed by Oscar
  - Store default MCR value instead of calculate on the run. (Oscar)
v9:
  - Changed naming and label fixes. (Oscar)
  - Store only the selector instead of whole MCR. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/intel_device_info.c | 35 
  drivers/gpu/drm/i915/intel_device_info.h |  3 +++
  drivers/gpu/drm/i915/intel_engine_cs.c   | 14 -
  3 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index a32ba72..1a4288f 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -719,6 +719,39 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
return 0;
  }
  
+static void sanitize_mcr(struct intel_device_info *info)

+{
+   struct drm_i915_private *dev_priv =
+   container_of(info, struct drm_i915_private, info);
+   u32 mcr;
+   u32 mcr_slice_subslice_mask;
+   u32 mcr_slice_subslice_select;
+   u32 slice = fls(info->sseu.slice_mask);
+   u32 subslice = fls(info->sseu.subslice_mask[slice]);
+
+   if (INTEL_GEN(dev_priv) >= 11) {
+   mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
+ GEN11_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) |
+   GEN11_MCR_SUBSLICE(subslice);
+   } else {
+   mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK |
+ GEN8_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) |
+   GEN8_MCR_SUBSLICE(subslice);
+   }
+
+   mcr = I915_READ(GEN8_MCR_SELECTOR);
+   mcr &= ~mcr_slice_subslice_mask;
+
+   /* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl */
+   if (INTEL_GEN(dev_priv) >= 10)
+   mcr |= mcr_slice_subslice_select;


Blank line here. The I915_WRITE is both for the WA and for the 
sanitation of the register.



+   I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+
+   info->default_mcr_ss_select = mcr_slice_subslice_select;
+}
+
  /**
   * intel_device_info_runtime_init - initialize runtime info
   * @info: intel device info struct
@@ -851,6 +884,8 @@ void intel_device_info_runtime_init(struct 
intel_device_info *info)
else if (INTEL_INFO(dev_priv)->gen >= 11)
gen11_sseu_info_init(dev_priv);
  
+	sanitize_mcr(info);

+
/* Initialize command stream timestamp frequency */
info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv);
  }
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 933e316..2c47a62 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -176,6 +176,9 @@ struct intel_device_info {
/* Slice/subslice/EU info */
struct sseu_dev_info sseu;
  
+	/* default selected slice/subslice in MCR packet control */

+   u32 default_mcr_ss_select;
+


default_mcr_s_ss_select? (yes, I know we are not coherent with the 
meaning of 's' and 'ss' in many other places).



u32 cs_timestamp_frequency_khz;
  
  	struct color_luts {

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1a83707..1ba2826 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Move request->ctx aside

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Move request->ctx aside
URL   : https://patchwork.freedesktop.org/series/41903/
State : failure

== Summary ==

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

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/crc: Only report a single overflow when a CRC fd is opened

[Patchwork]

== Series Details ==

Series: drm/crc: Only report a single overflow when a CRC fd is opened
URL   : https://patchwork.freedesktop.org/series/41897/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8737 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927)


 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (33 -> 32) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8737

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8737: e17f1c739f3f4bfe59ec5192330fdea1e109ea34 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

e17f1c739f3f drm/crc: Only report a single overflow when a CRC fd is opened

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8737/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 drm/crc: Only report a single overflow when a CRC fd is opened

[Patchwork]

== Series Details ==

Series: drm/crc: Only report a single overflow when a CRC fd is opened
URL   : https://patchwork.freedesktop.org/series/41897/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e17f1c739f3f drm/crc: Only report a single overflow when a CRC fd is opened
-:52: WARNING:TYPO_SPELLING: 'occured' may be misspelled - perhaps 'occurred'?
#52: FILE: include/drm/drm_debugfs_crc.h:46:
+ * @overflow: whether an overflow occured.

total: 0 errors, 1 warnings, 0 checks, 37 lines checked

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

[Intel-gfx] ✓ Fi.CI.BAT: success for gpu: drm: i915: Change return type to vm_fault_t (rev2)

[Patchwork]

== Series Details ==

Series: gpu: drm: i915: Change return type to vm_fault_t (rev2)
URL   : https://patchwork.freedesktop.org/series/41893/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8736 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41893/revisions/2/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_frontbuffer_tracking@basic:
  fi-cnl-y3:  PASS -> FAIL (fdo#103167)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927)


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


== Participating hosts (33 -> 32) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8736

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8736: 045e647f1204c28a28882560da315568d838e3ea @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

045e647f1204 gpu: drm: i915: Change return type to vm_fault_t

== Logs ==

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

Re: [Intel-gfx] [PATCH v10 10/11] drm: Add aspect ratio parsing in DRM layer

[Nautiyal, Ankit K]

On 4/17/2018 11:17 PM, Ville Syrjälä wrote:

On Tue, Apr 17, 2018 at 10:45:07AM +0530, Nautiyal, Ankit K wrote:

On 4/6/2018 11:14 PM, Ville Syrjälä wrote:

On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote:

This patch is causing failure of IGT test kms_3d. The kms_3d test
expects the no. of 3d modes to be 13.

(The test has hard-coded value for expected no. of 3d modes as 13)

But due to the addition of "matching aspect_ratio" in drm_mode_equal in
this patch, the total no. of

modes in the connector modelist is increased by 2, resulting in failure
of assertion 'mode_count==13'.

If kms_3d isn't setting the aspect ratio cap how is it affected by these
changes?

In drm_mode.c, the drm_mode_connector_list_update() uses drm_mode_equal,
to remove duplicate modes in connector_modes from the
connector->probe_modes.
Earlier, it wasn't matching for aspect-ratio and was discarding two of
the modes with aspect ratio,
as duplicates of other modes in the list.

Later, when we are pruning the modes in drm_mode_get_connector, the
logic there assumes,
that the modes are in a sorted order so that we just match with the last
valid mode for uniqueness.
This isn't the case with the spoofed edid in kms_3d.
Earlier, I was thinking if we should change the no. of expected modes in
kms_3d,
but that's not correct approach.

So finally, The pruning logic needs to be changed, to do away with any
assumption and check
all the modes in the list for duplicates. This however will take more
time to remove duplicates.

Any other suggestions on this?

What are all the modes this EDID gives us? The order in which the
modes are listed in the EDID should not be relevant as we sort
the mode list ourselves, and thus similar modes should appear back to
back on the list. So I don't really understand how we fail to
discard these two modes.


As we know the kms_3d test does not set the aspect ratio cap, the modes 
with aspect-ratios must be pruned,

unless they are unique.
Now the list of mode in kms_3d is something like this:
...
1280x720@60 flags 0x1c005 [3D mode - top and bottom] ->1
1280x720@60 flags 0x4005 [3D mode -frame packing] -> 2
1280x720@60 flags 0x1c005 [3D mode -top and bottom with aspect ratio]->3
1280x720@60 flags 0x4005 [3D mode frame packing with aspect ratio] ->4
...

The first two 3D modes are able to pass and are added in the 
drm_mode_get_connector mode list.
For third mode , the 3d mode with aspect ratio, must be pruned if not 
unique. So we check with the last valid mode in the list (1280x720@60 
flags 0x4005).

Everything matches except the 3d mode flags. So it gets added to the list.
For the fourth again, the mode with aspect ratio must be pruned, (not 
unique), but when we check with the last valid mode,

the 3d flags doesn't match, and we add that also in the list.

had the list been sorted by flag also:
1280x720@60 flags 0x1c005 [3D mode top and bottom]
1280x720@60 flags 0x1c005 [3D mode top and bottom with aspect ratio]
1280x720@60 flags 0x4005 [3D mode frame packing]
1280x720@60 flags 0x4005 [3D mode frame packing aspect ratio]

the aspect-ratio modes would have been pruned.

To avoid these scenarios, the best way is to modify the pruning logic to 
check against the whole list of already added modes.

I will send a patch for that shortly.

Regards,
Ankit




Regards
-Ankit


Perhaps this need to be handled in the test.

-Regards,

Ankit


On 4/6/2018 10:34 PM, Nautiyal, Ankit K wrote:

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new flags
   provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for gpu: drm: i915: Change return type to vm_fault_t (rev2)

[Patchwork]

== Series Details ==

Series: gpu: drm: i915: Change return type to vm_fault_t (rev2)
URL   : https://patchwork.freedesktop.org/series/41893/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: gpu: drm: i915: Change return type to vm_fault_t
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression 
using sizeof(void)

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for gpu: drm: i915: Change return type to vm_fault_t (rev2)

[Patchwork]

== Series Details ==

Series: gpu: drm: i915: Change return type to vm_fault_t (rev2)
URL   : https://patchwork.freedesktop.org/series/41893/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
045e647f1204 gpu: drm: i915: Change return type to vm_fault_t
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 1c8f422059ae ("mm: change return 
type to vm_fault_t")'
#11: 
Reference id -> 1c8f422059ae ("mm: change return type to

total: 1 errors, 0 warnings, 0 checks, 64 lines checked

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

Re: [Intel-gfx] [PATCH] drm: Print unadorned pointers

[Felix Kuehling]

On 2018-04-18 05:24 AM, Alexey Brodkin wrote:
> After commit ad67b74 ("printk: hash addresses printed with %p")
> pointers are being hashed when printed. However, this makes
> debug output completely useless. Switch to %px in order to see the
> unadorned kernel pointers.
My understanding of the printk pointer hashing change was to force
people to think more carefully when they really need to print a kernel
pointer. When it is only used to identify an object, then a hash works
just fine. Most of the changes I see in amdgpu/amdkfd fall into this
category.

As I see it, changing all %p to %px by a script takes the thought
process out of it and subverts the intention of the original pointer
hashing change.

Regards,
  Felix


>
> This was done with the following one-liner:
>  find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i 
> '/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} +
>
> Signed-off-by: Alexey Brodkin 
> Cc: Borislav Petkov 
> Cc: Tobin C. Harding 
> Cc: Alex Deucher 
> Cc: Andrey Grodzovsky 
> Cc: Arnd Bergmann 
> Cc: Benjamin Gaignard 
> Cc: Chen-Yu Tsai 
> Cc: Christian Gmeiner 
> Cc: "Christian König" 
> Cc: Cihangir Akturk 
> Cc: CK Hu 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: David Airlie 
> Cc: "David (ChunMing) Zhou" 
> Cc: Gerd Hoffmann 
> Cc: Greg Kroah-Hartman 
> Cc: Gustavo Padovan 
> Cc: Harry Wentland 
> Cc: "Heiko Stübner" 
> Cc: Ingo Molnar 
> Cc: Jani Nikula 
> Cc: "Jerry (Fangzhi) Zuo" 
> Cc: Joonas Lahtinen 
> Cc: Krzysztof Kozlowski 
> Cc: "Leo (Sunpeng) Li" 
> Cc: Lucas Stach 
> Cc: Maarten Lankhorst 
> Cc: Matthias Brugger 
> Cc: Maxime Ripard 
> Cc: "Michel Dänzer" 
> Cc: Oded Gabbay 
> Cc: Philipp Zabel 
> Cc: Rob Clark 
> Cc: Rodrigo Vivi 
> Cc: Roger He 
> Cc: Roman Li 
> Cc: Russell King 
> Cc: Samuel Li 
> Cc: Sandy Huang 
> Cc: Sean Paul 
> Cc: Shirish S 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Cc: Tom Lendacky 
> Cc: Tony Cheng 
> Cc: Vincent Abriou 
> Cc: VMware Graphics 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: etna...@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   | 14 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c|  2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_device.c| 10 ++---
>  drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c  |  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_events.c|  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |  2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c   |  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 18 -
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 14 +++
>  .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  2 +-
>  drivers/gpu/drm/armada/armada_gem.c| 12 +++---
>  drivers/gpu/drm/drm_atomic.c   | 44 
> +++---
>  drivers/gpu/drm/drm_bufs.c |  8 ++--
>  drivers/gpu/drm/drm_dp_mst_topology.c  |  4 +-
>  drivers/gpu/drm/drm_lease.c|  6 +--
>  drivers/gpu/drm/drm_lock.c |  2 +-
>  drivers/gpu/drm/drm_scatter.c  |  4 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  6 +--
>  drivers/gpu/drm/i810/i810_dma.c|  2 +-
>  drivers/gpu/drm/i915/i915_perf.c   |  2 +-
>  drivers/gpu/drm/i915/intel_display.c   |  2 +-
>  drivers/gpu/drm/i915/intel_guc_ct.c|  4 

Re: [Intel-gfx] [PATCH] drm: Print unadorned pointers

[Greg Kroah-Hartman]

On Wed, Apr 18, 2018 at 12:24:50PM +0300, Alexey Brodkin wrote:
> After commit ad67b74 ("printk: hash addresses printed with %p")
> pointers are being hashed when printed. However, this makes
> debug output completely useless. Switch to %px in order to see the
> unadorned kernel pointers.
> 
> This was done with the following one-liner:
>  find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i 
> '/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} +
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Borislav Petkov 
> Cc: Tobin C. Harding 
> Cc: Alex Deucher 
> Cc: Andrey Grodzovsky 
> Cc: Arnd Bergmann 
> Cc: Benjamin Gaignard 
> Cc: Chen-Yu Tsai 
> Cc: Christian Gmeiner 
> Cc: "Christian König" 
> Cc: Cihangir Akturk 
> Cc: CK Hu 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: David Airlie 
> Cc: "David (ChunMing) Zhou" 
> Cc: Gerd Hoffmann 
> Cc: Greg Kroah-Hartman 
> Cc: Gustavo Padovan 
> Cc: Harry Wentland 
> Cc: "Heiko Stübner" 
> Cc: Ingo Molnar 
> Cc: Jani Nikula 
> Cc: "Jerry (Fangzhi) Zuo" 
> Cc: Joonas Lahtinen 
> Cc: Krzysztof Kozlowski 
> Cc: "Leo (Sunpeng) Li" 
> Cc: Lucas Stach 
> Cc: Maarten Lankhorst 
> Cc: Matthias Brugger 
> Cc: Maxime Ripard 
> Cc: "Michel Dänzer" 
> Cc: Oded Gabbay 
> Cc: Philipp Zabel 
> Cc: Rob Clark 
> Cc: Rodrigo Vivi 
> Cc: Roger He 
> Cc: Roman Li 
> Cc: Russell King 
> Cc: Samuel Li 
> Cc: Sandy Huang 
> Cc: Sean Paul 
> Cc: Shirish S 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Cc: Tom Lendacky 
> Cc: Tony Cheng 
> Cc: Vincent Abriou 
> Cc: VMware Graphics 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: etna...@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   | 14 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c|  2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_device.c| 10 ++---
>  drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c  |  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_events.c|  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |  2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c   |  4 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 18 -
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 14 +++
>  .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  2 +-
>  drivers/gpu/drm/armada/armada_gem.c| 12 +++---
>  drivers/gpu/drm/drm_atomic.c   | 44 
> +++---
>  drivers/gpu/drm/drm_bufs.c |  8 ++--
>  drivers/gpu/drm/drm_dp_mst_topology.c  |  4 +-
>  drivers/gpu/drm/drm_lease.c|  6 +--
>  drivers/gpu/drm/drm_lock.c |  2 +-
>  drivers/gpu/drm/drm_scatter.c  |  4 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  6 +--
>  drivers/gpu/drm/i810/i810_dma.c|  2 +-
>  drivers/gpu/drm/i915/i915_perf.c   |  2 +-
>  drivers/gpu/drm/i915/intel_display.c   |  2 +-
>  drivers/gpu/drm/i915/intel_guc_ct.c|  4 +-
>  drivers/gpu/drm/i915/intel_guc_submission.c|  2 +-
>  drivers/gpu/drm/i915/intel_uc_fw.c |  2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_gem.c |  2 +-
>  drivers/gpu/drm/mga/mga_warp.c |  2 +-
>  drivers/gpu/drm/msm/msm_drv.c  |  4 +-
>  drivers/gpu/drm/qxl/qxl_cmd.c  |  4 +-
>  drivers/gpu/drm/qxl/qxl_fb.c   |  2 +-
>  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/audio: set minimum CD clock to twice the BCLK

[Patchwork]

== Series Details ==

Series: drm/i915/audio: set minimum CD clock to twice the BCLK
URL   : https://patchwork.freedesktop.org/series/41888/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8735 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (33 -> 31) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8735

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8735: bfb500c3510f626c212169ec498ddee1413c9736 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

bfb500c3510f drm/i915/audio: set minimum CD clock to twice the BCLK

== Logs ==

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

Re: [Intel-gfx] [PATCH v3] drm/i915: set minimum CD clock to twice the BCLK.

[Ville Syrjälä]

On Wed, Apr 18, 2018 at 01:49:23PM +0300, Jani Nikula wrote:
> On Tue, 17 Apr 2018, "Kumar, Abhay"  wrote:
> > On 4/17/2018 12:06 PM, Abhay Kumar wrote:
> >> In glk when device boots with only 1366x768 panel, HDA codec doesn't 
> >> comeup.
> >> This result in no audio forever as cdclk is < 96Mhz.
> >> This change will ensure CD clock to be twice of  BCLK.
> >>
> >> v2:
> >>  - Address comment (Jani)
> >>  - New design approach
> >> v3: - Typo fix on top of v1
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
> >> Signed-off-by: Abhay Kumar 
> >> ---
> >>   drivers/gpu/drm/i915/intel_cdclk.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> >> b/drivers/gpu/drm/i915/intel_cdclk.c
> >> index dc7db8a2caf8..6e93af4a46ea 100644
> >> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> >> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> >> @@ -2143,7 +2143,7 @@ int intel_crtc_compute_min_cdclk(const struct 
> >> intel_crtc_state *crtc_state)
> >>/* According to BSpec, "The CD clock frequency must be at least twice
> >> * the frequency of the Azalia BCLK." and BCLK is 96 MHz by default.
> >> */
> >> -  if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
> >> +  if (INTEL_GEN(dev_priv) >= 9)
> >>min_cdclk = max(2 * 96000, min_cdclk);
> >>   
> >>/*
> > Hi Ville, Jani,
> >
> > Since right version of this patch is taking time(doing modeset and 
> > cdclk bump) as we need to poke sound driver. Can we please get this 
> > v3(same as v1 with typo fix in comment) version of patch merged.
> > This works all the time and will unblock Audio and lot of folks. without 
> > this patch audio card is not getting detected at all and blocking basic 
> > audio feature.
> 
> I expanded on the code comment, rewrote the commit message, added cc:
> stable, and resent the patch [1].
> 
> It's not a patch I much like, it's not even a complete fix, and I would
> like this to be addressed properly going forward. However, the proper
> fix is I think too invasive for stable, so here we are. I'm trying to at
> least explain in the comment and commit message what's going on, for
> posterity.
> 
> Ville, I'm not going to push the patch without your ack, but we can't
> sit on this forever either. The patch papers over the most common
> failure case, for now, so perhaps it'll buy us time to find a proper
> solution.

While I don't particularly like this patch I also agree that it's the
least risky way to go for stable. So

Acked-by: Ville Syrjälä 

> 
> Abhay, if we merge this, I do expect your support in figuring out and
> testing the proper fix. This is not it.

I also want to see a better solution going forward.

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

Re: [Intel-gfx] [PATCH] drm/crc: Only report a single overflow when a CRC fd is opened

[Ville Syrjälä]

On Wed, Apr 18, 2018 at 02:51:21PM +0200, Maarten Lankhorst wrote:
> This reduces the amount of spam when you debug a CRC reading
> program.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_debugfs_crc.c | 9 -
>  include/drm/drm_debugfs_crc.h | 3 ++-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index 9f8312137cad..5a052c511e62 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -139,6 +139,7 @@ static int crtc_crc_data_count(struct drm_crtc_crc *crc)
>  static void crtc_crc_cleanup(struct drm_crtc_crc *crc)
>  {
>   kfree(crc->entries);
> + crc->overflow = false;
>   crc->entries = NULL;
>   crc->head = 0;
>   crc->tail = 0;
> @@ -391,8 +392,14 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool 
> has_frame,
>   tail = crc->tail;
>  
>   if (CIRC_SPACE(head, tail, DRM_CRC_ENTRIES_NR) < 1) {
> + bool overflow = crc->overflow;

'was_overflow' or something to indicate this is the old value?

> +
> + crc->overflow = true;
>   spin_unlock(>lock);
> - DRM_ERROR("Overflow of CRC buffer, userspace reads too 
> slow.\n");
> +
> + if (!overflow)
> + DRM_ERROR("Overflow of CRC buffer, userspace reads too 
> slow.\n");

would make this a bit less confusing perhaps. Now it reads as
"if (no overflow) DRM_ERROR("we have an overflow");" which makes no
sense on the first glance.

Apart from that
Reviewed-by: Ville Syrjälä 

> +
>   return -ENOBUFS;
>   }
>  
> diff --git a/include/drm/drm_debugfs_crc.h b/include/drm/drm_debugfs_crc.h
> index 7d63b1d4adb9..b225eeb30d05 100644
> --- a/include/drm/drm_debugfs_crc.h
> +++ b/include/drm/drm_debugfs_crc.h
> @@ -43,6 +43,7 @@ struct drm_crtc_crc_entry {
>   * @lock: protects the fields in this struct
>   * @source: name of the currently configured source of CRCs
>   * @opened: whether userspace has opened the data file for reading
> + * @overflow: whether an overflow occured.
>   * @entries: array of entries, with size of %DRM_CRC_ENTRIES_NR
>   * @head: head of circular queue
>   * @tail: tail of circular queue
> @@ -52,7 +53,7 @@ struct drm_crtc_crc_entry {
>  struct drm_crtc_crc {
>   spinlock_t lock;
>   const char *source;
> - bool opened;
> + bool opened, overflow;
>   struct drm_crtc_crc_entry *entries;
>   int head, tail;
>   size_t values_cnt;
> -- 
> 2.17.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/audio: set minimum CD clock to twice the BCLK

[Patchwork]

== Series Details ==

Series: drm/i915/audio: set minimum CD clock to twice the BCLK
URL   : https://patchwork.freedesktop.org/series/41888/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/audio: set minimum CD clock to twice the BCLK
-O:drivers/gpu/drm/i915/intel_cdclk.c:2147:29: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_cdclk.c:2159:29: warning: expression using 
sizeof(void)

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

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Ville Syrjälä]

On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> From: Maarten Lankhorst 
> 
> We skip src trunction/adjustments for
> NV12 case and handle the sizes directly.
> Without this, pipe fifo underruns are seen on APL/KBL.
> 
> v2: For NV12, making the src coordinates multiplier of 4
> 
> v3: Moving all the src coords handling code for NV12
> to skl_check_nv12_surface
> 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Vidya Srinivas 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 39 
> 
>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
>  2 files changed, 50 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 925402e..b8dbaca 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct 
> intel_crtc_state *crtc_state,
>   return 0;
>  }
>  
> +static int
> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> +struct intel_plane_state *plane_state)
> +{
> + int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> + int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
> +
> + if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> + ((plane_state->base.src_y >> 16) % 4) != 0 ||
> + ((plane_state->base.src_w >> 16) % 4) != 0 ||
> + ((plane_state->base.src_h >> 16) % 4) != 0) {
> + DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
> + return -EINVAL;
> + }

I don't really see why we should check these. The clipped coordinates
are what matters.

> +
> + /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> + if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
> + (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
> + DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
> +   crtc_x2, crtc_y2,
> +   crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> + return -EINVAL;
> + }

Why should we care? The current code already plays it fast and loose
and allows the dst rectangle to shrink to accomodate the hw limits.
If we want to change that we should change it universally.

> +
> + plane_state->base.src.x1 =
> + DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
> + plane_state->base.src.x2 =
> + DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
> + plane_state->base.src.y1 =
> + DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
> + plane_state->base.src.y2 =
> + DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;

Since this can now increase the size of the source rectangle our
scaling factor checks are no longer 100% valid. We might end up with
a scaling factor that is too high.

I don't really like any of these "let's make NV12 behave special"
tricks. We should make the code behave the same way for all pixel
formats instead of adding format specific hacks.

> +
> + return 0;
> +}
> +
>  static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
>  {
>   const struct drm_framebuffer *fb = plane_state->base.fb;
> @@ -3201,6 +3237,9 @@ int skl_check_plane_surface(const struct 
> intel_crtc_state *crtc_state,
>* the main surface setup depends on it.
>*/
>   if (fb->format->format == DRM_FORMAT_NV12) {
> + ret = skl_check_nv12_surface(crtc_state, plane_state);
> + if (ret)
> + return ret;
>   ret = skl_check_nv12_aux_surface(plane_state);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 8b7947d..f9985fb 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane *plane,
>   return vscale;
>   }
>  
> - /* Make the source viewport size an exact multiple of the 
> scaling factors. */
> - drm_rect_adjust_size(src,
> -  drm_rect_width(dst) * hscale - 
> drm_rect_width(src),
> -  drm_rect_height(dst) * vscale - 
> drm_rect_height(src));
> + if (fb->format->format != DRM_FORMAT_NV12) {
> + /*
> +  * Make the source viewport size
> +  * an exact multiple of the scaling factors
> +  */
> + drm_rect_adjust_size(src,
> +  

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its 
own headers (rev2)
URL   : https://patchwork.freedesktop.org/series/41827/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8734 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41827/revisions/2/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (33 -> 32) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8734

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8734: d45621446c373467ef2f658526ce56b70a42fba7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

d45621446c37 drm/i915: Pack params to engine->schedule() into a struct
a11ef25b82dd drm/i915: Rename priotree to sched
690cae7b1c87 drm/i915: Move the priotree struct to its own headers

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/3] just some guess work to findout the culprit. If this breaks then we know what do.

[Jani Nikula]

On Wed, 14 Feb 2018, "Kumar, Abhijeet"  wrote:
> On 2/14/2018 4:48 PM, Takashi Iwai wrote:
>> On Wed, 14 Feb 2018 10:06:19 +0100,
>> Kumar, Abhijeet wrote:
>>>
>>>
>>> On 2/14/2018 2:17 PM, Chris Wilson wrote:
 Quoting Kumar, Abhijeet (2018-02-14 04:53:57)
> On 2/14/2018 9:36 AM, abhijeet.ku...@intel.com wrote:
>
>   From: Abhijeet Kumar 
>
>   ---
>sound/pci/hda/hda_codec.c | 2 +-
>1 file changed, 1 insertion(+), 1 deletion(-)
>
>   diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
>   index 8c1b07e300a8..377d5719b4cd 100644
>   --- a/sound/pci/hda/hda_codec.c
>   +++ b/sound/pci/hda/hda_codec.c
>   @@ -2714,7 +2714,7 @@ static unsigned int 
> hda_sync_power_state(struct hda_codec *codec,
>   int count;
>
>   for (count = 0;count < 500; count++) {
>   -   state = snd_hda_codec_read(codec, fg, 0,
>   +   state = snd_hdac_codec_read(>core, fg, 0,
>  AC_VERB_GET_POWER_STATE, 
> 0);
>   if (state & AC_PWRST_ERROR){
>   msleep(20);
>
>
> Both tests are passing on hsw and bdw devices.I can conclude that none of 
> my
> changes
 Where did you run this against CI? (Due to the nature of patchwork it
 will not have picked this up as a new revision.)
>>> You can find it here https://patchwork.freedesktop.org/series/38212/.
>>> I've reverted my patch and made my changes in hda_codec inorder to
>>> demonstrate my changes is not
>>> breaking it.
> in "ALSA: hda: Make use of core codec functions to sync power state" is "
> directly" causing the regression.
> As this patch series changes the previously defined sync function similar 
> to
> the latest one (the one defined
> in the defaulter patch).
 If you have no answer, we will apply the revert to our CI so that we do
 not lose coverage.
>>> I guess, I don't have any issue by reverting this single patch alone
>>> as i already said this patch had
>>> no functional change! It just had few optimization which  i believe we
>>> can skip for now.  :)
>> Well, it still doesn't explain.  The loop count is 500 and we have
>> msleep(1), so it should be almost identical with the jiffies timeout.
>
> Even when the loop count is 500 and we have msleep(1) in earlier defined 
> sync function.
> We dont see wait_for_suspended assertion failing. See results for rev1 here
> https://patchwork.freedesktop.org/series/38188/
>> We need more investigation, in which code path the bug is triggered.
>
> I'm convinced.It seems like some other issue which was hidden earlier 
> had come into play
> because of trivial code movement. It needs more triage. Can we enable 
> debugs logs and
> try the test again? I'm afraid I dont have the hardware with me locally 
> right now.I'll try arranging.
> Meanwhile maybe someone from CI team can help with logs ?
>
> https://bugs.freedesktop.org/show_bug.cgi?id=105069

This remains an issue. The regressing commit is now in v4.17-rc1. We've
reverted it in our local branches to unblock CI.

Can we please get some closure here, if nothing else works then please
revert and go back to the drawing board.

BR,
Jani.



>
> Warm Regards,
> Abhijeet
>>
>>
>> thanks,
>>
>> Takashi
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op

[Ville Syrjälä]

On Wed, Apr 18, 2018 at 09:20:23AM +0300, Jani Nikula wrote:
> On Wed, 18 Apr 2018, Ramalingam C  wrote:
> > On Tuesday 17 April 2018 11:39 PM, Ville Syrjälä wrote:
> >> On Tue, Apr 17, 2018 at 02:25:32PM +0530, Ramalingam C wrote:
> >>> >From Gen9 onwards Bspec says HW supports Max Bytes per single RD/WR op is
> >>> 511Bytes instead of previous 256Bytes used in SW.
> >>>
> >>> This change allows the max bytes per op upto 511Bytes from Gen9 onwards.
> >>>
> >>> v2:
> >>>No Change.
> >>> v3:
> >>>Inline function for max_xfer_size and renaming of the macro.[Jani]
> >>>
> >>> Cc: Jani Nikula 
> >>> Cc: Chris Wilson 
> >>> Signed-off-by: Ramalingam C 
> >>> ---
> >>>   drivers/gpu/drm/i915/i915_reg.h  |  1 +
> >>>   drivers/gpu/drm/i915/intel_i2c.c | 11 +--
> >>>   2 files changed, 10 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >>> b/drivers/gpu/drm/i915/i915_reg.h
> >>> index 475cac07d3e6..be6114a0e8ab 100644
> >>> --- a/drivers/gpu/drm/i915/i915_reg.h
> >>> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >>> @@ -3013,6 +3013,7 @@ enum i915_power_well_id {
> >>>   #define   GMBUS_CYCLE_STOP  (4<<25)
> >>>   #define   GMBUS_BYTE_COUNT_SHIFT 16
> >>>   #define   GMBUS_BYTE_COUNT_MAX   256U
> >>> +#define   GEN9_GMBUS_BYTE_COUNT_MAX 511U
> >>>   #define   GMBUS_SLAVE_INDEX_SHIFT 8
> >>>   #define   GMBUS_SLAVE_ADDR_SHIFT 1
> >>>   #define   GMBUS_SLAVE_READ  (1<<0)
> >>> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> >>> b/drivers/gpu/drm/i915/intel_i2c.c
> >>> index e6875509bcd9..4367827d7661 100644
> >>> --- a/drivers/gpu/drm/i915/intel_i2c.c
> >>> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> >>> @@ -361,6 +361,13 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv)
> >>>   return ret;
> >>>   }
> >>>   
> >>> +static inline
> >>> +unsigned int gmbus_max_xfer_size(struct drm_i915_private *dev_priv)
> >>> +{
> >>> + return (INTEL_GEN(dev_priv) >= 9) ? GEN9_GMBUS_BYTE_COUNT_MAX :
> >>> + GMBUS_BYTE_COUNT_MAX;
> >> Hmm. You sure about this 256 limit on older HW? The spec does sort of
> >> say that 0-256 is the valid range, but the SPT+ docs still have that
> >> same text, and the register has always had 9 bits for byte count. I
> >> don't see any statements saying that they changed this in any way for
> >> SPT. It only talks about >511 bytes needing the special treatment.
> >>
> >> If we do this the I think you should just drop the defines and put the
> >> raw numbers into this function. The extra indirection just makes life
> >> harder. Also pointless parens around the GEN>9 check.
> > Even I couldn't get any place where BSpec says 256Bytes is the limit for 
> > any platform. Everywhere 9bits are used.
> > And when I cross verified with other OS usage 511Bytes is used as limit 
> > across all platforms.
> >
> > Just to be cautious for not breaking any older platforms out in linux 
> > world, I limited the extension of the limit to the known
> > and easily testable platforms at my desk (Gen9+)
> >
> > Do you suggest we should apply 511Bytes as max limit for all platforms?
> > Do we have any means to test this new limit on all supported legacy 
> > platforms?
> >
> > Except enabling the full potential of the HW in SW, I dont see any ROI 
> > here as most of the GMBUS reqs are <256Bytes.
> > Only in case of HDCP2.2 we need single read cycle for 538Bytes.
> >
> > we have couple of options here: Please share your opinion to choose one 
> > of them.
> > 1. Just dont change the upper limit for RD/WR. Keep it as it is at 
> > 256Bytes. Anyway no user demands it.
> > 2. As per HW capability, Change the upper limit for RD/WR to 511Bytes 
> > for all platforms. This is needs the functional verification on all 
> > legacy plat supported.
> > 3. Change the upper limit for RD/WR to 511Bytes for newer platforms, say 
> > Gen9+.
> 
> Please let's not change the limit for old platforms for absolutely no
> gain. And if Ville insists anyway, let's leave that as a separate
> follow-up change that can easily be reverted later.
> 
> I might consider using the 511 limit only for platforms that
> HAS_GMBUS_BURST_READ too.
> 
> The original limit seems to have been added in 9535c4757b88 ("drm/i915:
> cope with large i2c transfers") citing "the specs". Any recollection
> anyone? Chris?

"Duble buffered data register and a 9 bit counter support 0 byte to 256
Byte transfers."
has always been in the spec (and still is for SPT+).

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its 
own headers (rev2)
URL   : https://patchwork.freedesktop.org/series/41827/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Move the priotree struct to its own headers
Okay!

Commit: drm/i915: Rename priotree to sched
Okay!

Commit: drm/i915: Pack params to engine->schedule() into a struct
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression 
using sizeof(void)

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its 
own headers (rev2)
URL   : https://patchwork.freedesktop.org/series/41827/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
690cae7b1c87 drm/i915: Move the priotree struct to its own headers
-:72: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#72: 
new file mode 100644

-:77: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#77: FILE: drivers/gpu/drm/i915/i915_scheduler.h:1:
+/*

total: 0 errors, 2 warnings, 0 checks, 103 lines checked
a11ef25b82dd drm/i915: Rename priotree to sched
d45621446c37 drm/i915: Pack params to engine->schedule() into a struct

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance

[Patchwork]

== Series Details ==

Series: drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance
URL   : https://patchwork.freedesktop.org/series/41883/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8733 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (33 -> 31) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8733

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8733: 7f451ce363f70a1962ea45efa8fc972afcbc000d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

7f451ce363f7 drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance

== Logs ==

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 00/11] trace.pl fixes

[Tvrtko Ursulin]

On 06/03/2018 12:43, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Collection of fixes on top of John's recent work.

Problems were mostly in the request split logic which had several issues both
in my original version, and also after John's improvements.

Handling of "incomplete" requests (the ones which received neither notify nor
context complete) was also a bit incorrect.

After this series it seems to work fine, famous last words. Anyway with my test
data it correctly draws the timeline with no overalaps considering both merged
requests and submission to port 1.

I also added context colouring mode so it is easier to follow the timeline and
started using hw_id for context id's for additional readability.

v2:

  * Update for tracepoint renames. (new in series)
  * Remove hw_id change. (droppped from series)

  * Fix incomplete handling in split mode (-s).

This did not work well for workloads which generate very few
intel_engine_notify events. I am not that confident it is 100% correct now,
but at least it doesn't crash the script and output for one other workload I
had lying around looks correct.

I guess the moral of the story here is split mode is not easy to get right 
if
it is considered just a side project and more time needs to be set aside to
triple-check it.

John Harrison (4):
   scripts/trace.pl: More hash key optimisations
   scripts/trace.pl: Sort order
   scripts/trace.pl: Calculate stats only after all munging
   scripts/trace.pl: Simplify 'end' & 'notify' generation

Tvrtko Ursulin (7):
   trace.pl: Catch-up with tracepoint renames


From here v...


   trace.pl: Move sortQueue near its user
   trace.pl: Move min/max timestamp lookup to last loop
   trace.pl: Fix engine busy accounting in split mode
   trace.pl: Add support for colouring context execution
   trace.pl: Fix incomplete request handling
   trace.pl: Fix request split mode


... to here ^.

Only six patches to review and four even don't need much thinking!

Regards,

Tvrtko


___
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/icl: Adjust BSD2 semantics to mean any second VCS instance

[Patchwork]

== Series Details ==

Series: drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance
URL   : https://patchwork.freedesktop.org/series/41883/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
7f451ce363f7 drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance
-:12: WARNING:TYPO_SPELLING: 'targetted' may be misspelled - perhaps 'targeted'?
#12: 
it can be targetted by execbuf.

total: 0 errors, 1 warnings, 0 checks, 36 lines checked

___
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/fbdev: Enable late fbdev initial configuration (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/fbdev: Enable late fbdev initial configuration (rev3)
URL   : https://patchwork.freedesktop.org/series/41851/
State : failure

== Summary ==

Applying: drm/i915/fbdev: Enable late fbdev initial configuration
error: patch failed: drivers/gpu/drm/i915/intel_fbdev.c:807
error: drivers/gpu/drm/i915/intel_fbdev.c: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Using index info to reconstruct a base tree...
Patch failed at 0001 drm/i915/fbdev: Enable late fbdev initial configuration
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wait for vblank after register read

[Patchwork]

== Series Details ==

Series: drm/i915: Wait for vblank after register read
URL   : https://patchwork.freedesktop.org/series/41877/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8731 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
  fi-cfl-s3:  PASS -> FAIL (fdo#103481)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (33 -> 31) ==

  Additional (2): fi-glk-j4005 fi-bxt-dsi 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4066 -> Patchwork_8731

  CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8731: e03bb4d9e64828ac5797f6750752437e0a683383 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

e03bb4d9e648 drm/i915: Wait for vblank after register read

== Logs ==

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

[Intel-gfx] [PATCH 3/3] drm/i915: Store a pointer to intel_context in i915_request

[Chris Wilson]

To ease the frequent and ugly pointer dance of
>gem_context->engine[request->engine->id] during request
submission, store that pointer as request->hw_context. One major
advantage that we will exploit later is that this decouples the logical
context state from the engine itself.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/mmio_context.c   |   6 +-
 drivers/gpu/drm/i915/gvt/mmio_context.h   |   2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  | 141 ++--
 drivers/gpu/drm/i915/gvt/scheduler.h  |   1 -
 drivers/gpu/drm/i915/i915_debugfs.c   |  20 ++-
 drivers/gpu/drm/i915/i915_drv.h   |   1 +
 drivers/gpu/drm/i915/i915_gem.c   |  14 +-
 drivers/gpu/drm/i915/i915_gem_context.c   |  19 +--
 drivers/gpu/drm/i915/i915_gem_context.h   |  27 +++-
 drivers/gpu/drm/i915/i915_gpu_error.c |   2 +-
 drivers/gpu/drm/i915/i915_perf.c  |  28 ++--
 drivers/gpu/drm/i915/i915_request.c   |  23 ++-
 drivers/gpu/drm/i915/i915_request.h   |   3 +-
 drivers/gpu/drm/i915/intel_engine_cs.c|  61 ---
 drivers/gpu/drm/i915/intel_guc_ads.c  |   2 +-
 drivers/gpu/drm/i915/intel_guc_submission.c   |  15 +-
 drivers/gpu/drm/i915/intel_lrc.c  | 151 +++---
 drivers/gpu/drm/i915/intel_lrc.h  |   7 -
 drivers/gpu/drm/i915/intel_ringbuffer.c   | 104 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |   9 +-
 drivers/gpu/drm/i915/selftests/mock_context.c |   7 +
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  41 +++--
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   5 +
 23 files changed, 381 insertions(+), 308 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c 
b/drivers/gpu/drm/i915/gvt/mmio_context.c
index a5bac83d53a9..708170e61625 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.c
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
@@ -446,9 +446,9 @@ static void switch_mocs(struct intel_vgpu *pre, struct 
intel_vgpu *next,
 
 #define CTX_CONTEXT_CONTROL_VAL0x03
 
-bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id)
+bool is_inhibit_context(struct intel_context *ce)
 {
-   u32 *reg_state = ctx->engine[ring_id].lrc_reg_state;
+   const u32 *reg_state = ce->lrc_reg_state;
u32 inhibit_mask =
_MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
 
@@ -501,7 +501,7 @@ static void switch_mmio(struct intel_vgpu *pre,
 * itself.
 */
if (mmio->in_context &&
-   !is_inhibit_context(s->shadow_ctx, ring_id))
+   
!is_inhibit_context(>shadow_ctx->__engine[ring_id]))
continue;
 
if (mmio->mask)
diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.h 
b/drivers/gpu/drm/i915/gvt/mmio_context.h
index 0439eb8057a8..5c3b9ff9f96a 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.h
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.h
@@ -49,7 +49,7 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
 
 void intel_gvt_init_engine_mmio_context(struct intel_gvt *gvt);
 
-bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id);
+bool is_inhibit_context(struct intel_context *ce);
 
 int intel_vgpu_restore_inhibit_context(struct intel_vgpu *vgpu,
   struct i915_request *req);
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f64cccb2e793..c2e440200b0c 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -54,11 +54,8 @@ static void set_context_pdp_root_pointer(
 
 static void update_shadow_pdps(struct intel_vgpu_workload *workload)
 {
-   struct intel_vgpu *vgpu = workload->vgpu;
-   int ring_id = workload->ring_id;
-   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   shadow_ctx->engine[ring_id].state->obj;
+   workload->req->hw_context->state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
 
@@ -128,9 +125,8 @@ static int populate_shadow_context(struct 
intel_vgpu_workload *workload)
struct intel_vgpu *vgpu = workload->vgpu;
struct intel_gvt *gvt = vgpu->gvt;
int ring_id = workload->ring_id;
-   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   shadow_ctx->engine[ring_id].state->obj;
+   workload->req->hw_context->state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
void *dst;
@@ -280,10 +276,8 @@ static int shadow_context_status_change(struct 
notifier_block *nb,
return NOTIFY_OK;
 }
 
-static void shadow_context_descriptor_update(struct i915_gem_context 

[Intel-gfx] [PATCH 1/3] drm/i915: Move request->ctx aside

[Chris Wilson]

In the next patch, we want to store the intel_context pointer inside
i915_request, as it is frequently access via a convoluted dance when
submitting the request to hw. Having two context pointers inside
i915_request leads to confusion so first rename the existing
i915_gem_context pointer to i915_request.gem_context.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/gvt/scheduler.c  |  4 +--
 drivers/gpu/drm/i915/i915_debugfs.c   |  4 +--
 drivers/gpu/drm/i915/i915_gem.c   | 10 +++
 drivers/gpu/drm/i915/i915_gpu_error.c | 18 +++-
 drivers/gpu/drm/i915/i915_request.c   |  8 ++---
 drivers/gpu/drm/i915/i915_request.h   |  2 +-
 drivers/gpu/drm/i915/i915_trace.h |  6 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c|  2 +-
 drivers/gpu/drm/i915/intel_guc_submission.c   |  7 +++--
 drivers/gpu/drm/i915/intel_lrc.c  | 29 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c   | 11 +++
 .../gpu/drm/i915/selftests/intel_hangcheck.c  |  5 +++-
 drivers/gpu/drm/i915/selftests/intel_lrc.c|  2 +-
 13 files changed, 58 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f3d21849b0cb..f64cccb2e793 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -205,7 +205,7 @@ static int populate_shadow_context(struct 
intel_vgpu_workload *workload)
 
 static inline bool is_gvt_request(struct i915_request *req)
 {
-   return i915_gem_context_force_single_submission(req->ctx);
+   return i915_gem_context_force_single_submission(req->gem_context);
 }
 
 static void save_ring_hw_state(struct intel_vgpu *vgpu, int ring_id)
@@ -305,7 +305,7 @@ static int copy_workload_to_ring_buffer(struct 
intel_vgpu_workload *workload)
struct i915_request *req = workload->req;
 
if (IS_KABYLAKE(req->i915) &&
-   is_inhibit_context(req->ctx, req->engine->id))
+   is_inhibit_context(req->gem_context, req->engine->id))
intel_vgpu_restore_inhibit_context(vgpu, req);
 
/* allocate shadow ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e0274f41bc76..792f69e44ba5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -539,8 +539,8 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
   struct i915_request,
   client_link);
rcu_read_lock();
-   task = pid_task(request && request->ctx->pid ?
-   request->ctx->pid : file->pid,
+   task = pid_task(request && request->gem_context->pid ?
+   request->gem_context->pid : file->pid,
PIDTYPE_PID);
print_file_stats(m, task ? task->comm : "", stats);
rcu_read_unlock();
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..4dba735505d4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3108,7 +3108,7 @@ static void skip_request(struct i915_request *request)
 static void engine_skip_context(struct i915_request *request)
 {
struct intel_engine_cs *engine = request->engine;
-   struct i915_gem_context *hung_ctx = request->ctx;
+   struct i915_gem_context *hung_ctx = request->gem_context;
struct intel_timeline *timeline;
unsigned long flags;
 
@@ -3118,7 +3118,7 @@ static void engine_skip_context(struct i915_request 
*request)
spin_lock(>lock);
 
list_for_each_entry_continue(request, >timeline->requests, link)
-   if (request->ctx == hung_ctx)
+   if (request->gem_context == hung_ctx)
skip_request(request);
 
list_for_each_entry(request, >requests, link)
@@ -3164,11 +3164,11 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
}
 
if (stalled) {
-   i915_gem_context_mark_guilty(request->ctx);
+   i915_gem_context_mark_guilty(request->gem_context);
skip_request(request);
 
/* If this context is now banned, skip all pending requests. */
-   if (i915_gem_context_is_banned(request->ctx))
+   if (i915_gem_context_is_banned(request->gem_context))
engine_skip_context(request);
} else {
/*
@@ -3178,7 +3178,7 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
 */
request = i915_gem_find_active_request(engine);
if (request) {
-   

[Intel-gfx] [PATCH 2/3] drm/i915: Move fiddling with engine->last_retired_context

[Chris Wilson]

Move the knowledge about resetting the current context tracking on the
engine from inside i915_gem_context.c into intel_engine_cs.c

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c  | 24 
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
 3 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 74435affe23f..2fe779cab298 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -514,16 +514,8 @@ void i915_gem_contexts_lost(struct drm_i915_private 
*dev_priv)
 
lockdep_assert_held(_priv->drm.struct_mutex);
 
-   for_each_engine(engine, dev_priv, id) {
-   engine->legacy_active_context = NULL;
-   engine->legacy_active_ppgtt = NULL;
-
-   if (!engine->last_retired_context)
-   continue;
-
-   engine->context_unpin(engine, engine->last_retired_context);
-   engine->last_retired_context = NULL;
-   }
+   for_each_engine(engine, dev_priv, id)
+   intel_engine_lost_context(engine);
 }
 
 void i915_gem_contexts_fini(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 0248d64c2a72..4749426f9cad 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1084,6 +1084,30 @@ void intel_engines_unpark(struct drm_i915_private *i915)
}
 }
 
+
+/**
+ * intel_engine_lost_context: called when the GPU is reset into unknown state
+ * @engine: the engine
+ *
+ * We have either reset the GPU or otherwise about to lose state tracking of
+ * the current GPU logical state (e.g. suspend). On next use, it is therefore
+ * imperative that we make no presumptions about the current state and load
+ * from scratch.
+ */
+void intel_engine_lost_context(struct intel_engine_cs *engine)
+{
+   struct i915_gem_context *ctx;
+
+   lockdep_assert_held(>i915->drm.struct_mutex);
+
+   engine->legacy_active_context = NULL;
+   engine->legacy_active_ppgtt = NULL;
+
+   ctx = fetch_and_zero(>last_retired_context);
+   if (ctx)
+   engine->context_unpin(engine, ctx);
+}
+
 bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
 {
switch (INTEL_GEN(engine->i915)) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index c5e27905b0e1..1231695fb4da 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -1044,6 +1044,8 @@ bool intel_engine_has_kernel_context(const struct 
intel_engine_cs *engine);
 void intel_engines_park(struct drm_i915_private *i915);
 void intel_engines_unpark(struct drm_i915_private *i915);
 
+void intel_engine_lost_context(struct intel_engine_cs *engine);
+
 void intel_engines_reset_default_submission(struct drm_i915_private *i915);
 unsigned int intel_engines_has_context_isolation(struct drm_i915_private 
*i915);
 
-- 
2.17.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Enabling content-type setting for HDMI displays.

[Patchwork]

== Series Details ==

Series: Enabling content-type setting for HDMI displays.
URL   : https://patchwork.freedesktop.org/series/41876/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4065 -> Patchwork_8730 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084) +1


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


== Participating hosts (34 -> 31) ==

  Additional (1): fi-bxt-dsi 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-cnl-psr fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4065 -> Patchwork_8730

  CI_DRM_4065: c7cec67f9e1da120bc3b8782bb8013b285789c96 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8730: 73070dc1a0d9ce14dcda607deb37f2eb9e4f6061 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

73070dc1a0d9 i915: content-type property for HDMI connector
ffb3db0b7c7e drm: content-type property for HDMI connector

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state

[Jani Nikula]

On Mon, 16 Apr 2018, Clint Taylor  wrote:
> On 04/16/2018 08:53 AM, Imre Deak wrote:
>> LSPCON adapters in low-power state may ignore the first I2C write during
>> TMDS output buffer enabling, resulting in a blank screen even with an
>> otherwise enabled pipe. Fix this by reading back and validating the
>> written value a few times.
>>
>> The problem was noticed on GLK machines with an onboard LSPCON adapter
>> after entering/exiting DC5 power state. Doing an I2C read of the adapter
>> ID as the first transaction - instead of the I2C write to enable the
>> TMDS buffers - returns the correct value. Based on this we assume that
>> the transaction itself is sent properly, it's only the adapter that is
>> not ready for some reason to accept this first write after waking from
>> low-power state. In my case the second I2C write attempt always
>> succeeded.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105854
>> Cc: Clinton Taylor 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Imre Deak 
>> ---
>>   drivers/gpu/drm/drm_dp_dual_mode_helper.c | 39 
>> +--
>>   1 file changed, 32 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
>> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
>> index 02a50929af67..e7f4fe2848a5 100644
>> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
>> @@ -350,19 +350,44 @@ int drm_dp_dual_mode_set_tmds_output(enum 
>> drm_dp_dual_mode_type type,
>>   {
>>  uint8_t tmds_oen = enable ? 0 : DP_DUAL_MODE_TMDS_DISABLE;
>>  ssize_t ret;
>> +int retry;
>>   
>>  if (type < DRM_DP_DUAL_MODE_TYPE2_DVI)
>>  return 0;
>>   
>> -ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
>> - _oen, sizeof(tmds_oen));
>> -if (ret) {
>> -DRM_DEBUG_KMS("Failed to %s TMDS output buffers\n",
>> -  enable ? "enable" : "disable");
>> -return ret;
>> +/*
>> + * LSPCON adapters in low-power state may ignore the first write, so
>> + * read back and verify the written value a few times.
>> + */
>> +for (retry = 0; retry < 3; retry++) {
>> +uint8_t tmp;
>> +
>> +ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
>> + _oen, sizeof(tmds_oen));
>> +if (ret) {
>> +DRM_DEBUG_KMS("Failed to %s TMDS output buffers (%d 
>> attempts)\n",
>> +  enable ? "enable" : "disable",
>> +  retry + 1);
>> +return ret;
>> +}
>> +
>> +ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
>> +, sizeof(tmp));
>> +if (ret) {
>> +DRM_DEBUG_KMS("I2C read failed during TMDS output 
>> buffer %s (%d attempts)\n",
>> +  enable ? "enabling" : "disabling",
>> +  retry + 1);
>> +return ret;
>> +}
>> +
>> +if (tmp == tmds_oen)
>> +return 0;
>>  }
>>   
>> -return 0;
>> +DRM_DEBUG_KMS("I2C write value mismatch during TMDS output buffer %s\n",
>> +  enable ? "enabling" : "disabling");
>> +
>> +return -EIO;
>>   }
>>   EXPORT_SYMBOL(drm_dp_dual_mode_set_tmds_output);
>>   
>
> Appears to fix the issue seen on GLK with LSPCON and DMC firmware 
> loaded. Customer was concerned about the fix being in DRM instead of 
> i915. However, there are no other SOCs that use this DRM function.
>
> Reviewed-by: Clint Taylor 
> Tested-by: Clint Taylor 

Pushed to drm-misc-fixes, thanks for the patch.

Clint and Ville, many thanks for your testing and review, alas I screwed
up and pushed this without the tags added to the commit. I'm sorry. I
expect better from myself. :(

BR,
Jani.


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

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Fix error checking for wait_var_timeout

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Fix error checking for wait_var_timeout
URL   : https://patchwork.freedesktop.org/series/41835/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4063_full -> Patchwork_8727_full =

== Summary - WARNING ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  SKIP -> PASS +3

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-pwrite:
  shard-hsw:  SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_suspend@forcewake:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  PASS -> FAIL (fdo#105707)

igt@kms_flip@modeset-vs-vblank-race:
  shard-hsw:  PASS -> FAIL (fdo#103060)


 Possible fixes 

igt@drv_selftest@mock_breadcrumbs:
  shard-hsw:  DMESG-FAIL (fdo#106085) -> PASS
  shard-snb:  DMESG-FAIL (fdo#106085) -> PASS
  shard-apl:  DMESG-FAIL (fdo#106085) -> PASS
  shard-kbl:  DMESG-FAIL (fdo#106085) -> PASS

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@plain-flip-fb-recreate-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
  shard-apl:  FAIL (fdo#103925) -> PASS

igt@kms_setmode@basic:
  shard-apl:  FAIL (fdo#99912) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#106085 https://bugs.freedesktop.org/show_bug.cgi?id=106085
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 4) ==

  Missing(2): shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4063 -> Patchwork_8727

  CI_DRM_4063: 9bdf0998d567cbe94f712c8f3e8295fb0446e114 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8727: 2b384334a9ae14feeb342a44369d8d20a5aa1930 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8727/shards.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 Enabling content-type setting for HDMI displays.

[Patchwork]

== Series Details ==

Series: Enabling content-type setting for HDMI displays.
URL   : https://patchwork.freedesktop.org/series/41876/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ffb3db0b7c7e drm: content-type property for HDMI connector
-:78: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#78: FILE: drivers/gpu/drm/drm_connector.c:1016:
+   drm_object_attach_property(>base,
+   connector->dev->mode_config.content_type_property,

-:108: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#108: FILE: drivers/gpu/drm/drm_connector.c:1303:
+   drm_property_create_enum(dev, 0, "content type",
+   drm_content_type_enum_list,

-:111: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"!dev->mode_config.content_type_property"
#111: FILE: drivers/gpu/drm/drm_connector.c:1306:
+   if (dev->mode_config.content_type_property == NULL)

total: 0 errors, 0 warnings, 3 checks, 148 lines checked
73070dc1a0d9 i915: content-type property for HDMI connector

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