[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: add asynchrounous plane update (rev3)

[Patchwork]

== Series Details ==

Series: drm: add asynchrounous plane update (rev3)
URL   : https://patchwork.freedesktop.org/series/25814/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_atomic_plane.o
drivers/gpu/drm/i915/intel_atomic_plane.c: In function 
‘intel_plane_atomic_async_update’:
drivers/gpu/drm/i915/intel_atomic_plane.c:291:29: error: passing argument 1 of 
‘intel_plane->update_plane’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   intel_plane->update_plane(plane,
 ^
drivers/gpu/drm/i915/intel_atomic_plane.c:291:29: note: expected ‘struct 
intel_plane *’ but argument is of type ‘struct drm_plane *’
drivers/gpu/drm/i915/intel_atomic_plane.c:296:30: error: passing argument 1 of 
‘intel_plane->disable_plane’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   intel_plane->disable_plane(plane, crtc);
  ^
drivers/gpu/drm/i915/intel_atomic_plane.c:296:30: note: expected ‘struct 
intel_plane *’ but argument is of type ‘struct drm_plane *’
drivers/gpu/drm/i915/intel_atomic_plane.c:296:37: error: passing argument 2 of 
‘intel_plane->disable_plane’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   intel_plane->disable_plane(plane, crtc);
 ^
drivers/gpu/drm/i915/intel_atomic_plane.c:296:37: note: expected ‘struct 
intel_crtc *’ but argument is of type ‘struct drm_crtc *’
cc1: all warnings being treated as errors
scripts/Makefile.build:302: recipe for target 
'drivers/gpu/drm/i915/intel_atomic_plane.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_atomic_plane.o] Error 1
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1016: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] [PATCH] drm/vc4: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.

v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)

v4: add drm_atomic_helper_async() commit (Eric Anholt)

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Anholt 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_kms.c   |  20 
 drivers/gpu/drm/vc4/vc4_plane.c | 100 +++-
 2 files changed, 57 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 928d191..08ff231 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -113,6 +113,26 @@ static int vc4_atomic_commit(struct drm_device *dev,
struct drm_plane *plane;
struct drm_plane_state *new_state;
 
+   if (state->async_update) {
+   ret = down_interruptible(>async_modeset);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_prepare_planes(dev, state);
+   if (ret) {
+   up(>async_modeset);
+   return ret;
+   }
+
+   drm_atomic_helper_async_commit(dev, state);
+
+   drm_atomic_helper_cleanup_planes(dev, state);
+
+   up(>async_modeset);
+
+   return 0;
+   }
+
c = commit_init(state);
if (!c)
return -ENOMEM;
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index da18dec..c0c2c49 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -736,70 +736,41 @@ void vc4_plane_async_set_fb(struct drm_plane *plane, 
struct drm_framebuffer *fb)
vc4_state->dlist[vc4_state->ptr0_offset] = addr;
 }
 
-static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
-   .atomic_check = vc4_plane_atomic_check,
-   .atomic_update = vc4_plane_atomic_update,
-};
-
-static void vc4_plane_destroy(struct drm_plane *plane)
-{
-   drm_plane_helper_disable(plane);
-   drm_plane_cleanup(plane);
-}
-
-/* Implements immediate (non-vblank-synced) updates of the cursor
- * position, or falls back to the atomic helper otherwise.
- */
-static int
-vc4_update_plane(struct drm_plane *plane,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h,
-struct drm_modeset_acquire_ctx *ctx)
+static int vc4_plane_atomic_async_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
 {
-   struct drm_plane_state *plane_state;
-   struct vc4_plane_state *vc4_state;
-
-   if (plane != crtc->cursor)
-   goto out;
-
-   plane_state = plane->state;
-   vc4_state = to_vc4_plane_state(plane_state);
+   if (plane != state->crtc->cursor)
+   return -EINVAL;
 
-   if (!plane_state)
-   goto out;
+   if (!plane->state)
+   return -EINVAL;
 
/* No configuring new scaling in the fast path. */
-   if (crtc_w != plane_state->crtc_w ||
-   crtc_h != plane_state->crtc_h ||
-   src_w != plane_state->src_w ||
-   src_h != plane_state->src_h) {
-   goto out;
+   if (state->crtc_w != plane->state->crtc_w ||
+   state->crtc_h != plane->state->crtc_h ||
+   state->src_w != plane->state->src_w ||
+   state->src_h != plane->state->src_h) {
+   return -EINVAL;
}
 
-   if (fb != plane_state->fb) {
-   drm_atomic_set_fb_for_plane(plane->state, fb);
-   vc4_plane_async_set_fb(plane, fb);
-   }
+   return 0;
+}
 
-   /* Set the cursor's position on the screen.  This is the
-* expected change from the drm_mode_cursor_universal()
-* helper.
-*/
-   plane_state->crtc_x = crtc_x;
-   plane_state->crtc_y = crtc_y;
+static void vc4_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+   struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
 
-   /* Allow changing the start position within the cursor BO, if
-* that matters.
-*/
-   plane_state->src_x = src_x;
-   plane_state->src_y = src_y;
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: add asynchrounous plane update (rev2)

[Patchwork]

== Series Details ==

Series: drm: add asynchrounous plane update (rev2)
URL   : https://patchwork.freedesktop.org/series/25814/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_atomic_plane.o
drivers/gpu/drm/i915/intel_atomic_plane.c: In function 
‘intel_plane_atomic_async_update’:
drivers/gpu/drm/i915/intel_atomic_plane.c:291:29: error: passing argument 1 of 
‘intel_plane->update_plane’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   intel_plane->update_plane(plane,
 ^
drivers/gpu/drm/i915/intel_atomic_plane.c:291:29: note: expected ‘struct 
intel_plane *’ but argument is of type ‘struct drm_plane *’
drivers/gpu/drm/i915/intel_atomic_plane.c:296:30: error: passing argument 1 of 
‘intel_plane->disable_plane’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   intel_plane->disable_plane(plane, crtc);
  ^
drivers/gpu/drm/i915/intel_atomic_plane.c:296:30: note: expected ‘struct 
intel_plane *’ but argument is of type ‘struct drm_plane *’
drivers/gpu/drm/i915/intel_atomic_plane.c:296:37: error: passing argument 2 of 
‘intel_plane->disable_plane’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   intel_plane->disable_plane(plane, crtc);
 ^
drivers/gpu/drm/i915/intel_atomic_plane.c:296:37: note: expected ‘struct 
intel_crtc *’ but argument is of type ‘struct drm_crtc *’
cc1: all warnings being treated as errors
scripts/Makefile.build:302: recipe for target 
'drivers/gpu/drm/i915/intel_atomic_plane.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_atomic_plane.o] Error 1
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1016: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] [PATCH v2 6/6 squash] drm/vc4: Fixup for the drm core async changes.

[Eric Anholt]

With this squashed in, the vc4 patch is:
Reviewed-by: Eric Anholt 

Signed-off-by: Eric Anholt 
---

Without this, the cursor never moved :)

 drivers/gpu/drm/vc4/vc4_plane.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index aac3a31a9260..59f7ab6b1831 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -792,6 +792,9 @@ static void vc4_plane_atomic_async_update(struct drm_plane 
*plane,
if (plane->state->fb != new_state->fb)
vc4_plane_async_set_fb(plane, new_state->fb);
 
+   /* Update the display list based on the new crtc_x/y. */
+   vc4_plane_atomic_check(plane, plane->state);
+
/* Note that we can't just call vc4_plane_write_dlist()
 * because that would smash the context data that the HVS is
 * currently using.
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Andrey Grodzovsky]

Just a reminder.

Thanks.

On 06/09/2017 05:30 PM, Andrey Grodzovsky wrote:

Problem:
While running IGT kms_atomic_transition test suite i encountered
a hang in drmHandleEvent immidietly follwoing an atomic_commit.
After dumping the atomic state I relized that in this case there was
not even one CRTC attached to the state and only disabled
planes. This probably due to a commit which hadn't changed any property
which would require attaching crtc state. This means drmHandleEvent
will never wake up from read since without CRTC in atomic state
the event fd will not be singnaled.
This point to a bug in IGT but also DRM should gracefully
fail  such scenario so no hang on user side will happen.

Fix:
Explicitly fail by failing atomic_commit early in
drm_mode_atomic_commit where such problem can be identified.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/drm_atomic.c | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..32eae1c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device *dev,
  {
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
-   int i, ret;
+   int i, c = 0, ret;
  
  	if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)

return 0;
@@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device *dev,
  
  			crtc_state->event->base.fence = fence;

}
+
+   c++;
}
  
+	/*

+* Having this flag means user mode pends on event which will never
+* reach due to lack of at least one CRTC for signaling
+*/
+   if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
+   return -EINVAL;
+
return 0;
  }
  
@@ -2179,6 +2188,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,

drm_mode_object_unreference(obj);
}
  
+

+
ret = prepare_crtc_signaling(dev, state, arg, file_priv, _state,
 _fences);
if (ret)


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

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Vivi, Rodrigo]

On Fri, 2017-06-16 at 00:10 +0300, Jani Nikula wrote:
> On Thu, 15 Jun 2017, Rodrigo Vivi  wrote:
> > On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
> >  wrote:
> >> On Thu, 15 Jun 2017, Ander Conselvan De Oliveira  
> >> wrote:
> >>> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
>  Hi Ander,
> 
> 
>  On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
>  > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
>  > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper 
>  > >  wrote:
>  > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
>  > > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
>  > > > >
>  > > > > New ddb allocation algorithm is a show stopper on my SKL system.
>  > > > >
>  > > > > Besides not be able to get external DP 4k@60 (through USB type 
>  > > > > C),
>  > > > > It fully hang my screen when unplugging the USB type C.
>  > > > >
>  > > > > Cc: Mahesh Kumar 
>  > > > > Cc: Maarten Lankhorst 
>  > > > > Cc: Matt Roper 
>  > > > > Signed-off-by: Rodrigo Vivi 
>  > > >
>  > > > Is there a bugzilla entry with details/logs from the failure we can
>  > > > refer to?
>  > >
>  > > nope, since I know it was working few weeks ago and then stopped
>  > > working I went directly
>  > > to bisect so I could get my system usable quickly again.
>  > >
>  > > But yes, I need to open a proper bugzilla and provide logs.
>  > > Should we revert first and grab logs latter or we are going to try to
>  > > analyse logs and fix?
>  > >
>  > > Anyways this is a big show stopper so I believe we revert at least
>  > > before next pull request.
>  >
>  > This patch also causes artifacts in dual screen setups. All the 
>  > scanlines below
>  > the mouse cursor are wrong, sometimes containing a shade of gray and 
>  > others
>  > repeating the image above. I've seen this in APL and GLK using 
>  > DSI+HDMI,
>  > eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank 
>  > and reports
>  > lack of signal.
>  >
>  > I've noticed fifo underrun messages. I compared the ddb allocation in 
>  > GLK with a
>  > working and non-working kernel, but they were the same.
> 
>  your observation looks like one we observed in one of the Linux variant
>  program.
>  There was an configuration where lower WM-level having higher DDB
>  requirement than higher levels. Which was leading to lower WM levels
>  getting disabled.
> 
>  Can you please try with following patch to see if it's solving the 
>  problem.
> 
>  https://patchwork.freedesktop.org/patch/161571/
> >>>
> >>> I tested that in my GLK, but it didn't help. Still getting artifacts 
> >>> following
> >>> the mouse cursor.
> >>
> >> If the revert helps the GLK case as well, please let's revert. We
> >> generally waste too much time trying to get things fixed when the revert
> >> and return to the drawing board is the way to go.
> >
> > Agreed.
> > But:
> >
> > dim: ERROR: 11cabd424587c77596ceb198284a4c50a2784602 is lacking
> > mandatory review, aborting
> 
> Then shove in
> 
> Acked-by: Jani Nikula 

ops, just saw now...
would changing the full Acknowledge-by to Acked-by from Matt helped? 

> 
> >
> >>
> >> Rodrigo, please add the Bugzilla: reference and proper Fixes: line.
> >
> > Do we need "Fixes:" on the Revert who already references the original
> > git commit?
> > I didn't find any Revert patch in our tree with the Fixes this is why
> > I'm asking.
> 
> We need it because Fixes: is the thing that tooling looks at. Wherever a
>  goes, Fixes:  follows.

Yeap, makes sense.
Thanks

> 
> BR,
> Jani.
> 
> >
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >>>
> >>> Ander
> >>>
>  Rodrigo,
> 
>  Can you please also check if this is the same reason for your failure.
>  I'm arranging for a system with SKL+USB type-C DP 4K@60 & eDP. will
>  debug this further.
> 
>  -Mahesh
> 
>  >
>  > Ander
>  > > When you say you can't get DP 4k@60, are you seeing messages
>  > > > in dmesg about the setup being outside system watermark 
>  > > > limitations or
>  > > > are you just getting a black screen?
>  > >
>  > > just getting a blank screen on DP when plugging usb-c and a locked-up
>  > > screen on eDP when removing usb-c.
>  > >
>  > > >
>  > > > Matt
>  > > >
>  > > > > ---
>  > > > >   drivers/gpu/drm/i915/intel_pm.c | 257 
>  > > > > +++-
>  > > > >   1 file changed, 98 insertions(+), 159 deletions(-)
>  > > > >
>  > 

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Vivi, Rodrigo]

Patch merge to dinq.

I will try to get some logs here soon to sum to glk ones.

On Thu, 2017-06-15 at 14:01 -0700, Rodrigo Vivi wrote:
> On Thu, Jun 15, 2017 at 1:55 PM, Matt Roper  wrote:
> > On Thu, Jun 15, 2017 at 01:52:02PM -0700, Rodrigo Vivi wrote:
> >> On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
> >>  wrote:
> >> > On Thu, 15 Jun 2017, Ander Conselvan De Oliveira  
> >> > wrote:
> >> >> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
> >> >>> Hi Ander,
> >> >>>
> >> >>>
> >> >>> On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
> >> >>> > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
> >> >>> > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper 
> >> >>> > >  wrote:
> >> >>> > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
> >> >>> > > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
> >> >>> > > > >
> >> >>> > > > > New ddb allocation algorithm is a show stopper on my SKL 
> >> >>> > > > > system.
> >> >>> > > > >
> >> >>> > > > > Besides not be able to get external DP 4k@60 (through USB type 
> >> >>> > > > > C),
> >> >>> > > > > It fully hang my screen when unplugging the USB type C.
> >> >>> > > > >
> >> >>> > > > > Cc: Mahesh Kumar 
> >> >>> > > > > Cc: Maarten Lankhorst 
> >> >>> > > > > Cc: Matt Roper 
> >> >>> > > > > Signed-off-by: Rodrigo Vivi 
> >> >>> > > >
> >> >>> > > > Is there a bugzilla entry with details/logs from the failure we 
> >> >>> > > > can
> >> >>> > > > refer to?
> >> >>> > >
> >> >>> > > nope, since I know it was working few weeks ago and then stopped
> >> >>> > > working I went directly
> >> >>> > > to bisect so I could get my system usable quickly again.
> >> >>> > >
> >> >>> > > But yes, I need to open a proper bugzilla and provide logs.
> >> >>> > > Should we revert first and grab logs latter or we are going to try 
> >> >>> > > to
> >> >>> > > analyse logs and fix?
> >> >>> > >
> >> >>> > > Anyways this is a big show stopper so I believe we revert at least
> >> >>> > > before next pull request.
> >> >>> >
> >> >>> > This patch also causes artifacts in dual screen setups. All the 
> >> >>> > scanlines below
> >> >>> > the mouse cursor are wrong, sometimes containing a shade of gray and 
> >> >>> > others
> >> >>> > repeating the image above. I've seen this in APL and GLK using 
> >> >>> > DSI+HDMI,
> >> >>> > eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank 
> >> >>> > and reports
> >> >>> > lack of signal.
> >> >>> >
> >> >>> > I've noticed fifo underrun messages. I compared the ddb allocation 
> >> >>> > in GLK with a
> >> >>> > working and non-working kernel, but they were the same.
> >> >>>
> >> >>> your observation looks like one we observed in one of the Linux variant
> >> >>> program.
> >> >>> There was an configuration where lower WM-level having higher DDB
> >> >>> requirement than higher levels. Which was leading to lower WM levels
> >> >>> getting disabled.
> >> >>>
> >> >>> Can you please try with following patch to see if it's solving the 
> >> >>> problem.
> >> >>>
> >> >>> https://patchwork.freedesktop.org/patch/161571/
> >> >>
> >> >> I tested that in my GLK, but it didn't help. Still getting artifacts 
> >> >> following
> >> >> the mouse cursor.
> >> >
> >> > If the revert helps the GLK case as well, please let's revert. We
> >> > generally waste too much time trying to get things fixed when the revert
> >> > and return to the drawing board is the way to go.
> >>
> >> Agreed.
> >> But:
> >>
> >> dim: ERROR: 11cabd424587c77596ceb198284a4c50a2784602 is lacking
> >> mandatory review, aborting
> >
> > Does dim require a formal r-b on direct reverts?  If so, you can promote
> > my Acked-by to a full Reviewed-by to make it happy.  :-)
> 
> Maybe it is something we need to fix in dim, but while I'm not sure I
> will fully respect dim and use your rv-b,
> and also respect Jani request and keep Fixes.
> 
> Thanks
> 
> >
> >
> > Matt
> >
> >>
> >> >
> >> > Rodrigo, please add the Bugzilla: reference and proper Fixes: line.
> >>
> >> Do we need "Fixes:" on the Revert who already references the original
> >> git commit?
> >> I didn't find any Revert patch in our tree with the Fixes this is why
> >> I'm asking.
> >>
> >> >
> >> > BR,
> >> > Jani.
> >> >
> >> >
> >> >>
> >> >> Ander
> >> >>
> >> >>> Rodrigo,
> >> >>>
> >> >>> Can you please also check if this is the same reason for your failure.
> >> >>> I'm arranging for a system with SKL+USB type-C DP 4K@60 & eDP. will
> >> >>> debug this further.
> >> >>>
> >> >>> -Mahesh
> >> >>>
> >> >>> >
> >> >>> > Ander
> >> >>> > > When you say you can't get DP 4k@60, are you seeing messages
> >> >>> > > > in dmesg about the setup being outside system watermark 
> >> >>> > > > limitations or
> >> >>> > > > are you just 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Store 9 bits of PCI Device ID for platforms with a LP PCH

[Patchwork]

== Series Details ==

Series: drm/i915: Store 9 bits of PCI Device ID for platforms with a LP PCH
URL   : https://patchwork.freedesktop.org/series/25874/
State : warning

== Summary ==

Series 25874v1 drm/i915: Store 9 bits of PCI Device ID for platforms with a LP 
PCH
https://patchwork.freedesktop.org/api/1.0/series/25874/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-bdw-5557u)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
fail   -> PASS   (fi-snb-2600) fdo#100215 +1
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup bad-nb-words-3:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup bad-pipe:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup bad-source:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup hang-read-crc-pipe-a:
fail   -> DMESG-FAIL (fi-skl-6700hq) fdo#101154 +15
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-bdw-5557u)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-bdw-5557u)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-bdw-5557u)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (fi-bdw-5557u)
Subgroup basic-rte:
pass   -> DMESG-WARN (fi-bdw-5557u)
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> DMESG-WARN (fi-bdw-5557u)
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-bdw-5557u)
Subgroup basic-no-display:
pass   -> DMESG-WARN (fi-bdw-5557u)
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-bdw-5557u)
Subgroup basic-reload-final:
pass   -> DMESG-WARN (fi-bdw-5557u)

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

fi-bdw-5557u total:278  pass:256  dwarn:11  dfail:0   fail:0   skip:11  
time:457s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:489s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:588s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:556s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:500s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:590s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:437s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:420s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:468s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:497s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:518s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:581s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:578s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:483s
fi-skl-6700hqtotal:278  pass:224  dwarn:5   dfail:16  fail:11  skip:22  
time:487s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:515s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:517s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:515s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:668s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:0   skip:29  
time:412s

3b204b9a85e7f2868671949da81e2d52a5eef76b drm-tip: 2017y-06m-15d-20h-40m-07s UTC 
integration manifest
a25633c drm/i915: Store 9 bits of PCI Device ID for platforms with a LP PCH

== Logs ==

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

Re: [Intel-gfx] [PATCH v9 10/21] drm/i915: Add engine reset count in get-reset-stats ioctl

[Michel Thierry]

On 15/06/17 14:14, Chris Wilson wrote:

Quoting Michel Thierry (2017-06-15 21:18:17)

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

To start the discussion, include just a total engine reset count. If it
is deemed useful, it can be extended to report each engine separately.
Our igt's gem_reset_stats test will need changes to ignore the pad field,
since it can now return reset_engine_count.

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


Nope. You have now defined that pad works as an output-only parameter.
It is no longer in a state of flux and can be any value on input. The
test in gem_reset_stats becomes invalid.


Ok, I'll also have to make more changes to that test; the existing 
subtests must enforce i915.reset=1 (or read both reset_count and 
pad/reset_engine_count).

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

Re: [Intel-gfx] [PATCH IGT v2] Replace mentions of Intel GPU Tools by IGT GPU Tools

[Jani Nikula]

On Thu, 15 Jun 2017, Rodrigo Vivi  wrote:
> What does IGT stand for nowadays? :)

IGT GPU Tools. :)

BR,
Jani.


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

Re: [Intel-gfx] [PATCH v9 10/21] drm/i915: Add engine reset count in get-reset-stats ioctl

[Chris Wilson]

Quoting Michel Thierry (2017-06-15 21:18:17)
> Users/tests relying on the total reset count will start seeing a smaller
> number since most of the hangs can be handled by engine reset.
> Note that if reset engine x, context a running on engine y will be unaware
> and unaffected.
> 
> To start the discussion, include just a total engine reset count. If it
> is deemed useful, it can be extended to report each engine separately.
> Our igt's gem_reset_stats test will need changes to ignore the pad field,
> since it can now return reset_engine_count.
> 
> v2: s/engine_reset/reset_engine/, use union in uapi to not break 
> compatibility.
> v3: Keep rejecting attempts to use pad as input (Antonio)

Nope. You have now defined that pad works as an output-only parameter.
It is no longer in a state of flux and can be any value on input. The
test in gem_reset_stats becomes invalid.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Jani Nikula]

On Thu, 15 Jun 2017, Rodrigo Vivi  wrote:
> On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
>  wrote:
>> On Thu, 15 Jun 2017, Ander Conselvan De Oliveira  
>> wrote:
>>> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
 Hi Ander,


 On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
 > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
 > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper 
 > >  wrote:
 > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
 > > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
 > > > >
 > > > > New ddb allocation algorithm is a show stopper on my SKL system.
 > > > >
 > > > > Besides not be able to get external DP 4k@60 (through USB type C),
 > > > > It fully hang my screen when unplugging the USB type C.
 > > > >
 > > > > Cc: Mahesh Kumar 
 > > > > Cc: Maarten Lankhorst 
 > > > > Cc: Matt Roper 
 > > > > Signed-off-by: Rodrigo Vivi 
 > > >
 > > > Is there a bugzilla entry with details/logs from the failure we can
 > > > refer to?
 > >
 > > nope, since I know it was working few weeks ago and then stopped
 > > working I went directly
 > > to bisect so I could get my system usable quickly again.
 > >
 > > But yes, I need to open a proper bugzilla and provide logs.
 > > Should we revert first and grab logs latter or we are going to try to
 > > analyse logs and fix?
 > >
 > > Anyways this is a big show stopper so I believe we revert at least
 > > before next pull request.
 >
 > This patch also causes artifacts in dual screen setups. All the 
 > scanlines below
 > the mouse cursor are wrong, sometimes containing a shade of gray and 
 > others
 > repeating the image above. I've seen this in APL and GLK using DSI+HDMI,
 > eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank and 
 > reports
 > lack of signal.
 >
 > I've noticed fifo underrun messages. I compared the ddb allocation in 
 > GLK with a
 > working and non-working kernel, but they were the same.

 your observation looks like one we observed in one of the Linux variant
 program.
 There was an configuration where lower WM-level having higher DDB
 requirement than higher levels. Which was leading to lower WM levels
 getting disabled.

 Can you please try with following patch to see if it's solving the problem.

 https://patchwork.freedesktop.org/patch/161571/
>>>
>>> I tested that in my GLK, but it didn't help. Still getting artifacts 
>>> following
>>> the mouse cursor.
>>
>> If the revert helps the GLK case as well, please let's revert. We
>> generally waste too much time trying to get things fixed when the revert
>> and return to the drawing board is the way to go.
>
> Agreed.
> But:
>
> dim: ERROR: 11cabd424587c77596ceb198284a4c50a2784602 is lacking
> mandatory review, aborting

Then shove in

Acked-by: Jani Nikula 

>
>>
>> Rodrigo, please add the Bugzilla: reference and proper Fixes: line.
>
> Do we need "Fixes:" on the Revert who already references the original
> git commit?
> I didn't find any Revert patch in our tree with the Fixes this is why
> I'm asking.

We need it because Fixes: is the thing that tooling looks at. Wherever a
 goes, Fixes:  follows.

BR,
Jani.

>
>>
>> BR,
>> Jani.
>>
>>
>>>
>>> Ander
>>>
 Rodrigo,

 Can you please also check if this is the same reason for your failure.
 I'm arranging for a system with SKL+USB type-C DP 4K@60 & eDP. will
 debug this further.

 -Mahesh

 >
 > Ander
 > > When you say you can't get DP 4k@60, are you seeing messages
 > > > in dmesg about the setup being outside system watermark limitations 
 > > > or
 > > > are you just getting a black screen?
 > >
 > > just getting a blank screen on DP when plugging usb-c and a locked-up
 > > screen on eDP when removing usb-c.
 > >
 > > >
 > > > Matt
 > > >
 > > > > ---
 > > > >   drivers/gpu/drm/i915/intel_pm.c | 257 
 > > > > +++-
 > > > >   1 file changed, 98 insertions(+), 159 deletions(-)
 > > > >
 > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
 > > > > b/drivers/gpu/drm/i915/intel_pm.c
 > > > > index aa9d8ce..dc4275d 100644
 > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
 > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
 > > > > @@ -4140,41 +4140,13 @@ int skl_check_pipe_max_pixel_rate(struct 
 > > > > intel_crtc *intel_crtc,
 > > > >minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
 > > > >   }
 > > > >
 

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Rodrigo Vivi]

On Thu, Jun 15, 2017 at 1:55 PM, Matt Roper  wrote:
> On Thu, Jun 15, 2017 at 01:52:02PM -0700, Rodrigo Vivi wrote:
>> On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
>>  wrote:
>> > On Thu, 15 Jun 2017, Ander Conselvan De Oliveira  
>> > wrote:
>> >> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
>> >>> Hi Ander,
>> >>>
>> >>>
>> >>> On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
>> >>> > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
>> >>> > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper 
>> >>> > >  wrote:
>> >>> > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
>> >>> > > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
>> >>> > > > >
>> >>> > > > > New ddb allocation algorithm is a show stopper on my SKL system.
>> >>> > > > >
>> >>> > > > > Besides not be able to get external DP 4k@60 (through USB type 
>> >>> > > > > C),
>> >>> > > > > It fully hang my screen when unplugging the USB type C.
>> >>> > > > >
>> >>> > > > > Cc: Mahesh Kumar 
>> >>> > > > > Cc: Maarten Lankhorst 
>> >>> > > > > Cc: Matt Roper 
>> >>> > > > > Signed-off-by: Rodrigo Vivi 
>> >>> > > >
>> >>> > > > Is there a bugzilla entry with details/logs from the failure we can
>> >>> > > > refer to?
>> >>> > >
>> >>> > > nope, since I know it was working few weeks ago and then stopped
>> >>> > > working I went directly
>> >>> > > to bisect so I could get my system usable quickly again.
>> >>> > >
>> >>> > > But yes, I need to open a proper bugzilla and provide logs.
>> >>> > > Should we revert first and grab logs latter or we are going to try to
>> >>> > > analyse logs and fix?
>> >>> > >
>> >>> > > Anyways this is a big show stopper so I believe we revert at least
>> >>> > > before next pull request.
>> >>> >
>> >>> > This patch also causes artifacts in dual screen setups. All the 
>> >>> > scanlines below
>> >>> > the mouse cursor are wrong, sometimes containing a shade of gray and 
>> >>> > others
>> >>> > repeating the image above. I've seen this in APL and GLK using 
>> >>> > DSI+HDMI,
>> >>> > eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank 
>> >>> > and reports
>> >>> > lack of signal.
>> >>> >
>> >>> > I've noticed fifo underrun messages. I compared the ddb allocation in 
>> >>> > GLK with a
>> >>> > working and non-working kernel, but they were the same.
>> >>>
>> >>> your observation looks like one we observed in one of the Linux variant
>> >>> program.
>> >>> There was an configuration where lower WM-level having higher DDB
>> >>> requirement than higher levels. Which was leading to lower WM levels
>> >>> getting disabled.
>> >>>
>> >>> Can you please try with following patch to see if it's solving the 
>> >>> problem.
>> >>>
>> >>> https://patchwork.freedesktop.org/patch/161571/
>> >>
>> >> I tested that in my GLK, but it didn't help. Still getting artifacts 
>> >> following
>> >> the mouse cursor.
>> >
>> > If the revert helps the GLK case as well, please let's revert. We
>> > generally waste too much time trying to get things fixed when the revert
>> > and return to the drawing board is the way to go.
>>
>> Agreed.
>> But:
>>
>> dim: ERROR: 11cabd424587c77596ceb198284a4c50a2784602 is lacking
>> mandatory review, aborting
>
> Does dim require a formal r-b on direct reverts?  If so, you can promote
> my Acked-by to a full Reviewed-by to make it happy.  :-)

Maybe it is something we need to fix in dim, but while I'm not sure I
will fully respect dim and use your rv-b,
and also respect Jani request and keep Fixes.

Thanks

>
>
> Matt
>
>>
>> >
>> > Rodrigo, please add the Bugzilla: reference and proper Fixes: line.
>>
>> Do we need "Fixes:" on the Revert who already references the original
>> git commit?
>> I didn't find any Revert patch in our tree with the Fixes this is why
>> I'm asking.
>>
>> >
>> > BR,
>> > Jani.
>> >
>> >
>> >>
>> >> Ander
>> >>
>> >>> Rodrigo,
>> >>>
>> >>> Can you please also check if this is the same reason for your failure.
>> >>> I'm arranging for a system with SKL+USB type-C DP 4K@60 & eDP. will
>> >>> debug this further.
>> >>>
>> >>> -Mahesh
>> >>>
>> >>> >
>> >>> > Ander
>> >>> > > When you say you can't get DP 4k@60, are you seeing messages
>> >>> > > > in dmesg about the setup being outside system watermark 
>> >>> > > > limitations or
>> >>> > > > are you just getting a black screen?
>> >>> > >
>> >>> > > just getting a blank screen on DP when plugging usb-c and a locked-up
>> >>> > > screen on eDP when removing usb-c.
>> >>> > >
>> >>> > > >
>> >>> > > > Matt
>> >>> > > >
>> >>> > > > > ---
>> >>> > > > >   drivers/gpu/drm/i915/intel_pm.c | 257 
>> >>> > > > > +++-
>> >>> > > > >   1 file changed, 98 insertions(+), 159 deletions(-)
>> >>> > > > >
>> 

Re: [Intel-gfx] [PATCH IGT v2] Replace mentions of Intel GPU Tools by IGT GPU Tools

[Rodrigo Vivi]

What does IGT stand for nowadays? :)



On Thu, Jun 15, 2017 at 12:53 PM, Jani Nikula
 wrote:
> On Mon, 12 Jun 2017, Paul Kocialkowski  
> wrote:
>> Since IGT supports much more that testing for the Intel DRM driver, it
>> was renamed to IGT GPU Tools instead of Intel GPU Tools.
>>
>> This replaces the remaining mentions of Intel GPU Tools in favor of
>> IGT GPU tools.
>
> There's still a bunch of "intel-gpu-tools" references left after this,
> though not all of them need to be updated right now.
>
> BR,
> Jani.
>
>>
>> Signed-off-by: Paul Kocialkowski 
>> ---
>>  README   | 14 +++---
>>  configure.ac |  2 +-
>>  2 files changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/README b/README
>> index 26171a17..b860ca91 100644
>> --- a/README
>> +++ b/README
>> @@ -1,18 +1,18 @@
>> -Intel GPU Tools
>> -===
>> +IGT GPU Tools
>> +=
>>
>>  Description
>>  ---
>>
>> -Intel GPU Tools is a collection of tools for development and testing of the
>> -Intel DRM driver. There are many macro-level test suites that get used 
>> against
>> +IGT GPU Tools is a collection of tools for development and testing of DRM
>> +drivers. There are many macro-level test suites that get used against
>>  the driver, including xtest, rendercheck, piglit, and oglconform, but 
>> failures
>>  from those can be difficult to track down to kernel changes, and many 
>> require
>>  complicated build procedures or specific testing environments to get useful
>> -results. Therefore, Intel GPU Tools includes low-level tools and tests
>> -specifically for development and testing of the Intel DRM Driver.
>> +results. Therefore, IGT GPU Tools includes low-level tools and tests
>> +specifically for development and testing of DRM drivers.
>>
>> -Intel GPU Tools is split into several sections:
>> +IGT GPU Tools is split into several sections:
>>
>>  benchmarks/
>>   This is a collection of useful microbenchmarks that can be used to tune
>> diff --git a/configure.ac b/configure.ac
>> index 0418e605..efc81acb 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -379,7 +379,7 @@ AC_OUTPUT
>>
>>  # Print a summary of the compilation
>>  echo ""
>> -echo "Intel GPU tools"
>> +echo "IGT GPU Tools"
>>
>>  echo ""
>>  echo " • Tests:"
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Store 9 bits of PCI Device ID for platforms with a LP PCH

[Dhinakaran Pandiyan]

Although we use 9 bits of Device ID for identifying PCH, only 8 bits are
stored in dev_priv->pch_id. This makes HAS_PCH_CNP_LP() and
HAS_PCH_SPT_LP() incorrect. Fix this by storing all the 9 bits for the
platforms with LP PCH.

Also, use the extended 9 bits for detecting PCH_LPT_LP.

Cc: Rodrigo Vivi 
Cc: Jani Nikula 
Cc: Imre Deak 
Fixes: commit ec7e0bb35f8d ("drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH")
Reported-by: Imre Deak 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_drv.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1f802de..29caf05 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -176,31 +176,34 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
unsigned short id_ext = pch->device &
INTEL_PCH_DEVICE_ID_MASK_EXT;
 
-   dev_priv->pch_id = id;
-
if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
+   dev_priv->pch_id = id;
dev_priv->pch_type = PCH_IBX;
DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
WARN_ON(!IS_GEN5(dev_priv));
} else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
+   dev_priv->pch_id = id;
dev_priv->pch_type = PCH_CPT;
DRM_DEBUG_KMS("Found CougarPoint PCH\n");
WARN_ON(!(IS_GEN6(dev_priv) ||
IS_IVYBRIDGE(dev_priv)));
} else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
/* PantherPoint is CPT compatible */
+   dev_priv->pch_id = id;
dev_priv->pch_type = PCH_CPT;
DRM_DEBUG_KMS("Found PantherPoint PCH\n");
WARN_ON(!(IS_GEN6(dev_priv) ||
IS_IVYBRIDGE(dev_priv)));
} else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
+   dev_priv->pch_id = id;
dev_priv->pch_type = PCH_LPT;
DRM_DEBUG_KMS("Found LynxPoint PCH\n");
WARN_ON(!IS_HASWELL(dev_priv) &&
!IS_BROADWELL(dev_priv));
WARN_ON(IS_HSW_ULT(dev_priv) ||
IS_BDW_ULT(dev_priv));
-   } else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+   } else if (id_ext == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+   dev_priv->pch_id = id_ext;
dev_priv->pch_type = PCH_LPT;
DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
WARN_ON(!IS_HASWELL(dev_priv) &&
@@ -208,26 +211,31 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
WARN_ON(!IS_HSW_ULT(dev_priv) &&
!IS_BDW_ULT(dev_priv));
} else if (id == INTEL_PCH_SPT_DEVICE_ID_TYPE) {
+   dev_priv->pch_id = id;
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
} else if (id_ext == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
+   dev_priv->pch_id = id_ext;
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
} else if (id == INTEL_PCH_KBP_DEVICE_ID_TYPE) {
+   dev_priv->pch_id = id;
dev_priv->pch_type = PCH_KBP;
DRM_DEBUG_KMS("Found KabyPoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
} else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
+   dev_priv->pch_id = id;
dev_priv->pch_type = PCH_CNP;
DRM_DEBUG_KMS("Found CannonPoint PCH\n");

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Matt Roper]

On Thu, Jun 15, 2017 at 01:52:02PM -0700, Rodrigo Vivi wrote:
> On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
>  wrote:
> > On Thu, 15 Jun 2017, Ander Conselvan De Oliveira  
> > wrote:
> >> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
> >>> Hi Ander,
> >>>
> >>>
> >>> On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
> >>> > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
> >>> > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper 
> >>> > >  wrote:
> >>> > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
> >>> > > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
> >>> > > > >
> >>> > > > > New ddb allocation algorithm is a show stopper on my SKL system.
> >>> > > > >
> >>> > > > > Besides not be able to get external DP 4k@60 (through USB type C),
> >>> > > > > It fully hang my screen when unplugging the USB type C.
> >>> > > > >
> >>> > > > > Cc: Mahesh Kumar 
> >>> > > > > Cc: Maarten Lankhorst 
> >>> > > > > Cc: Matt Roper 
> >>> > > > > Signed-off-by: Rodrigo Vivi 
> >>> > > >
> >>> > > > Is there a bugzilla entry with details/logs from the failure we can
> >>> > > > refer to?
> >>> > >
> >>> > > nope, since I know it was working few weeks ago and then stopped
> >>> > > working I went directly
> >>> > > to bisect so I could get my system usable quickly again.
> >>> > >
> >>> > > But yes, I need to open a proper bugzilla and provide logs.
> >>> > > Should we revert first and grab logs latter or we are going to try to
> >>> > > analyse logs and fix?
> >>> > >
> >>> > > Anyways this is a big show stopper so I believe we revert at least
> >>> > > before next pull request.
> >>> >
> >>> > This patch also causes artifacts in dual screen setups. All the 
> >>> > scanlines below
> >>> > the mouse cursor are wrong, sometimes containing a shade of gray and 
> >>> > others
> >>> > repeating the image above. I've seen this in APL and GLK using DSI+HDMI,
> >>> > eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank and 
> >>> > reports
> >>> > lack of signal.
> >>> >
> >>> > I've noticed fifo underrun messages. I compared the ddb allocation in 
> >>> > GLK with a
> >>> > working and non-working kernel, but they were the same.
> >>>
> >>> your observation looks like one we observed in one of the Linux variant
> >>> program.
> >>> There was an configuration where lower WM-level having higher DDB
> >>> requirement than higher levels. Which was leading to lower WM levels
> >>> getting disabled.
> >>>
> >>> Can you please try with following patch to see if it's solving the 
> >>> problem.
> >>>
> >>> https://patchwork.freedesktop.org/patch/161571/
> >>
> >> I tested that in my GLK, but it didn't help. Still getting artifacts 
> >> following
> >> the mouse cursor.
> >
> > If the revert helps the GLK case as well, please let's revert. We
> > generally waste too much time trying to get things fixed when the revert
> > and return to the drawing board is the way to go.
> 
> Agreed.
> But:
> 
> dim: ERROR: 11cabd424587c77596ceb198284a4c50a2784602 is lacking
> mandatory review, aborting

Does dim require a formal r-b on direct reverts?  If so, you can promote
my Acked-by to a full Reviewed-by to make it happy.  :-)


Matt

> 
> >
> > Rodrigo, please add the Bugzilla: reference and proper Fixes: line.
> 
> Do we need "Fixes:" on the Revert who already references the original
> git commit?
> I didn't find any Revert patch in our tree with the Fixes this is why
> I'm asking.
> 
> >
> > BR,
> > Jani.
> >
> >
> >>
> >> Ander
> >>
> >>> Rodrigo,
> >>>
> >>> Can you please also check if this is the same reason for your failure.
> >>> I'm arranging for a system with SKL+USB type-C DP 4K@60 & eDP. will
> >>> debug this further.
> >>>
> >>> -Mahesh
> >>>
> >>> >
> >>> > Ander
> >>> > > When you say you can't get DP 4k@60, are you seeing messages
> >>> > > > in dmesg about the setup being outside system watermark limitations 
> >>> > > > or
> >>> > > > are you just getting a black screen?
> >>> > >
> >>> > > just getting a blank screen on DP when plugging usb-c and a locked-up
> >>> > > screen on eDP when removing usb-c.
> >>> > >
> >>> > > >
> >>> > > > Matt
> >>> > > >
> >>> > > > > ---
> >>> > > > >   drivers/gpu/drm/i915/intel_pm.c | 257 
> >>> > > > > +++-
> >>> > > > >   1 file changed, 98 insertions(+), 159 deletions(-)
> >>> > > > >
> >>> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> >>> > > > > b/drivers/gpu/drm/i915/intel_pm.c
> >>> > > > > index aa9d8ce..dc4275d 100644
> >>> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> >>> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> >>> > > > > @@ -4140,41 +4140,13 @@ int skl_check_pipe_max_pixel_rate(struct 
> >>> > > > > intel_crtc *intel_crtc,
> >>> > > > >

Re: [Intel-gfx] [PATCH] drm/i915: fix the issue DP-1 not working in guest

[Jani Nikula]

On Thu, 15 Jun 2017, Ville Syrjälä  wrote:
> On Thu, Jun 15, 2017 at 03:53:18AM +, Anuar, Nuhairi wrote:
>> To be clear, I believe right now, GVT-g architecture on upstream still only 
>> have one Virtualized DP monitor which will be on port B/D, but we have 
>> patches (not yet upstream) that have 3 virtualized DP monitors which will be 
>> attached to Port A/B/D. So we need to add this flexibility in the code so 
>> that it is not conflicted with eDP logic.
>
> Please don't do that. Real hardware doesn't support non-eDP on port A,
> so your virtualized thing shouldn't either. Why aren't you putting it on
> port C instead?

Agreed. Otherwise we may end up piling up more intel_vgpu_active()
checks all over the place.

BR,
Jani.


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

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

[Sean Paul]

Hi Dave,
Here's the final drm-misc-next request for 4.13, we'll switch over to
drm-misc-next-fixes for 4.13 with drm-misc-next now targetting 4.14. I'll send
out a separate email to -misc committers to ensure we're all on the same page.

The drm_panel_bridge change introduced a little bit of instability when it first
landed, but it seems like all of that has been fixed and things should be good
to go. Along the same lines, we gained a handful of new panels in panel-simple
and a couple dedicated panel drivers as well.

Aside from those items, one thing to watch out for is the mxsfb patch. I had
applied it to -next first, but upon request from Jani, I also merged it to
-fixes and included it in my PR earlier today. Hopefully it won't cause
problems in the next couple of weeks before merge window, but figured it was
worth mentioning.

drm-misc-next-2017-06-15:
Cross-subsystem Changes:
- dt-bindings: add vendor prefix for NLT Technologies, Ltd. (Lucas)
- dt-bindings: Add support for samsung s6e3hf2 panel (Hoegeun)

Core Changes:
- Add drm_panel_bridge to avoid connector boilerplate in drivers (Eric)
- Trival fixes for dupe forward decl and reduce scope of variable (Dawid)

Driver Changes:
- dw-hdmi: Use mode_valid hook on bridge instead of connector (Jose)
- vc4,atmel-hlcdc: Use drm_panel_bridge where appropriate (Eric)
- panel: Add Innolux P079ZCA panel driver (Chris)
- panel-simple: Add NL12880B20-05, NL192108AC18-02D, P320HVN03 panels (Lucas)
- panel-samsung-s6e3ha2: Add s6e3hf2 panel support (Hoegeun)
- zte,vc4,pl111,panel,mxsfb: Miscellaneous fixes

Cc: Jose Abreu 
Cc: Eric Anholt 
Cc: Chris Zhong 
Cc: Lucas Stach 
Cc: Hoegeun Kwon 
Cc: Dawid Kurek 

Cheers, Sean


The following changes since commit 7f696942a7e52df2a99410bf23da513f9aad04fb:

  drm/vc4: Mark the device as active when enabling runtime PM. (2017-06-02 
13:00:47 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-06-15

for you to fetch changes up to ac7c748317f515f426f48e72964c71142506f7a6:

  drm: Reduce scope of 'state' variable (2017-06-15 14:26:02 -0400)


Cross-subsystem Changes:
- dt-bindings: add vendor prefix for NLT Technologies, Ltd. (Lucas)
- dt-bindings: Add support for samsung s6e3hf2 panel (Hoegeun)

Core Changes:
- Add drm_panel_bridge to avoid connector boilerplate in drivers (Eric)
- Trival fixes for dupe forward decl and reduce scope of variable (Dawid)

Driver Changes:
- dw-hdmi: Use mode_valid hook on bridge instead of connector (Jose)
- vc4,atmel-hlcdc: Use drm_panel_bridge where appropriate (Eric)
- panel: Add Innolux P079ZCA panel driver (Chris)
- panel-simple: Add NL12880B20-05, NL192108AC18-02D, P320HVN03 panels (Lucas)
- panel-samsung-s6e3ha2: Add s6e3hf2 panel support (Hoegeun)
- zte,vc4,pl111,panel,mxsfb: Miscellaneous fixes

Cc: Jose Abreu 
Cc: Eric Anholt 
Cc: Chris Zhong 
Cc: Lucas Stach 
Cc: Hoegeun Kwon 
Cc: Dawid Kurek 


Arnd Bergmann (2):
  drm/panel: S6E3HA2 needs backlight code
  drm/panel: add backlight dependency for sitronix-st7789v

Benjamin Gaignard (1):
  drm: zte: use devm_of_platform_populate()

Boris Brezillon (1):
  drm/atmel-hlcdc: Fix panel registration

Chris Zhong (2):
  dt-bindings: Add INNOLUX P079ZCA panel bindings
  drm/panel: add Innolux P079ZCA panel driver

Christophe JAILLET (1):
  drm/vc4: Fix resource leak in 'vc4_get_hang_state_ioctl()' in error 
handling path

Dawid Kurek (2):
  drm: Remove duplicate forward declaration
  drm: Reduce scope of 'state' variable

Eric Anholt (6):
  drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.
  drm/vc4: Switch DSI to the panel-bridge layer, and support bridges.
  drm/vc4: Switch DPI to using the panel-bridge helper.
  drm/atmel-hlcdc: Drop custom encoder cleanup func.
  drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.
  drm/pl111: Fix offset calculation for the primary plane.

Fabio Estevam (1):
  drm: mxsfb_crtc: Reset the eLCDIF controller

Hans Verkuil (1):
  drm/vc4/vc4_bo.c: always set bo->resv

Hoegeun Kwon (2):
  dt-bindings: Add support for samsung s6e3hf2 panel
  drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board

Jose Abreu (1):
  drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback

Jyri Sarha (1):
  drm: Add const to name field declaration in struct drm_prop_enum_list

Lucas Stach (4):
  drm/panel: simple: add support for NEC NL12880B20-05
  dt-bindings: add vendor prefix for NLT Technologies, Ltd.
  drm/panel: simple: add 

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Rodrigo Vivi]

On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
 wrote:
> On Thu, 15 Jun 2017, Ander Conselvan De Oliveira  wrote:
>> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
>>> Hi Ander,
>>>
>>>
>>> On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
>>> > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
>>> > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper 
>>> > >  wrote:
>>> > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
>>> > > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
>>> > > > >
>>> > > > > New ddb allocation algorithm is a show stopper on my SKL system.
>>> > > > >
>>> > > > > Besides not be able to get external DP 4k@60 (through USB type C),
>>> > > > > It fully hang my screen when unplugging the USB type C.
>>> > > > >
>>> > > > > Cc: Mahesh Kumar 
>>> > > > > Cc: Maarten Lankhorst 
>>> > > > > Cc: Matt Roper 
>>> > > > > Signed-off-by: Rodrigo Vivi 
>>> > > >
>>> > > > Is there a bugzilla entry with details/logs from the failure we can
>>> > > > refer to?
>>> > >
>>> > > nope, since I know it was working few weeks ago and then stopped
>>> > > working I went directly
>>> > > to bisect so I could get my system usable quickly again.
>>> > >
>>> > > But yes, I need to open a proper bugzilla and provide logs.
>>> > > Should we revert first and grab logs latter or we are going to try to
>>> > > analyse logs and fix?
>>> > >
>>> > > Anyways this is a big show stopper so I believe we revert at least
>>> > > before next pull request.
>>> >
>>> > This patch also causes artifacts in dual screen setups. All the scanlines 
>>> > below
>>> > the mouse cursor are wrong, sometimes containing a shade of gray and 
>>> > others
>>> > repeating the image above. I've seen this in APL and GLK using DSI+HDMI,
>>> > eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank and 
>>> > reports
>>> > lack of signal.
>>> >
>>> > I've noticed fifo underrun messages. I compared the ddb allocation in GLK 
>>> > with a
>>> > working and non-working kernel, but they were the same.
>>>
>>> your observation looks like one we observed in one of the Linux variant
>>> program.
>>> There was an configuration where lower WM-level having higher DDB
>>> requirement than higher levels. Which was leading to lower WM levels
>>> getting disabled.
>>>
>>> Can you please try with following patch to see if it's solving the problem.
>>>
>>> https://patchwork.freedesktop.org/patch/161571/
>>
>> I tested that in my GLK, but it didn't help. Still getting artifacts 
>> following
>> the mouse cursor.
>
> If the revert helps the GLK case as well, please let's revert. We
> generally waste too much time trying to get things fixed when the revert
> and return to the drawing board is the way to go.

Agreed.
But:

dim: ERROR: 11cabd424587c77596ceb198284a4c50a2784602 is lacking
mandatory review, aborting

>
> Rodrigo, please add the Bugzilla: reference and proper Fixes: line.

Do we need "Fixes:" on the Revert who already references the original
git commit?
I didn't find any Revert patch in our tree with the Fixes this is why
I'm asking.

>
> BR,
> Jani.
>
>
>>
>> Ander
>>
>>> Rodrigo,
>>>
>>> Can you please also check if this is the same reason for your failure.
>>> I'm arranging for a system with SKL+USB type-C DP 4K@60 & eDP. will
>>> debug this further.
>>>
>>> -Mahesh
>>>
>>> >
>>> > Ander
>>> > > When you say you can't get DP 4k@60, are you seeing messages
>>> > > > in dmesg about the setup being outside system watermark limitations or
>>> > > > are you just getting a black screen?
>>> > >
>>> > > just getting a blank screen on DP when plugging usb-c and a locked-up
>>> > > screen on eDP when removing usb-c.
>>> > >
>>> > > >
>>> > > > Matt
>>> > > >
>>> > > > > ---
>>> > > > >   drivers/gpu/drm/i915/intel_pm.c | 257 
>>> > > > > +++-
>>> > > > >   1 file changed, 98 insertions(+), 159 deletions(-)
>>> > > > >
>>> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>>> > > > > b/drivers/gpu/drm/i915/intel_pm.c
>>> > > > > index aa9d8ce..dc4275d 100644
>>> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
>>> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
>>> > > > > @@ -4140,41 +4140,13 @@ int skl_check_pipe_max_pixel_rate(struct 
>>> > > > > intel_crtc *intel_crtc,
>>> > > > >minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
>>> > > > >   }
>>> > > > >
>>> > > > > -static void
>>> > > > > -skl_enable_plane_wm_levels(const struct drm_i915_private *dev_priv,
>>> > > > > -uint16_t plane_ddb,
>>> > > > > -uint16_t max_level,
>>> > > > > -struct skl_plane_wm *wm)
>>> > > > > -{
>>> > > > > - int level;
>>> > > > > - /*
>>> > > > > -  * Now enable all levels in WM 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/glk: Split GLK DSI device ready functionality

[Jani Nikula]

On Tue, 13 Jun 2017, Madhav Chauhan  wrote:
> This patch divides glk_dsi_device_ready() function into
> two part. First part will program LP wake and MIPI DSI mode
> to MIPI_CTRL reg using newly defined function glk_dsi_enable_io().
> glk_dsi_enable_io() will be called from intel_dsi_pre_enable.
> Second part will do remaining device ready activities using
> the existing function glk_dsi_device_ready().

Both pushed to dinq, thanks for the patches.

BR,
Jani.


>
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 25 ++---
>  1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 54030b6..6074014 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -346,12 +346,12 @@ static bool intel_dsi_compute_config(struct 
> intel_encoder *encoder,
>   return true;
>  }
>  
> -static void glk_dsi_device_ready(struct intel_encoder *encoder)
> +static void glk_dsi_enable_io(struct intel_encoder *encoder)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
>   enum port port;
> - u32 tmp, val;
> + u32 tmp;
>  
>   /* Set the MIPI mode
>* If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
> @@ -381,6 +381,14 @@ static void glk_dsi_device_ready(struct intel_encoder 
> *encoder)
>   GLK_MIPIIO_PORT_POWERED, 20))
>   DRM_ERROR("MIPIO port is powergated\n");
>   }
> +}
> +
> +static void glk_dsi_device_ready(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> + enum port port;
> + u32 val;
>  
>   /* Wait for MIPI PHY status bit to set */
>   for_each_dsi_port(port, intel_dsi->ports) {
> @@ -391,8 +399,8 @@ static void glk_dsi_device_ready(struct intel_encoder 
> *encoder)
>   }
>  
>   /* Get IO out of reset */
> - tmp = I915_READ(MIPI_CTRL(PORT_A));
> - I915_WRITE(MIPI_CTRL(PORT_A), tmp | GLK_MIPIIO_RESET_RELEASED);
> + val = I915_READ(MIPI_CTRL(PORT_A));
> + I915_WRITE(MIPI_CTRL(PORT_A), val | GLK_MIPIIO_RESET_RELEASED);
>  
>   /* Get IO out of Low power state*/
>   for_each_dsi_port(port, intel_dsi->ports) {
> @@ -427,9 +435,9 @@ static void glk_dsi_device_ready(struct intel_encoder 
> *encoder)
>   val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
>   I915_WRITE(MIPI_DEVICE_READY(port), val);
>  
> - tmp = I915_READ(MIPI_CTRL(port));
> - tmp &= ~GLK_LP_WAKE;
> - I915_WRITE(MIPI_CTRL(port), tmp);
> + val = I915_READ(MIPI_CTRL(port));
> + val &= ~GLK_LP_WAKE;
> + I915_WRITE(MIPI_CTRL(port), val);
>   }
>  
>   /* Wait for Stop state */
> @@ -811,6 +819,9 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> *encoder,
>   /* Deassert reset */
>   intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>  
> + if (IS_GEMINILAKE(dev_priv))
> + glk_dsi_enable_io(encoder);
> +
>   /* Put device in ready state (LP-11) */
>   intel_dsi_device_ready(encoder);

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

Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for HSW/BDW in virtual environment

[Jani Nikula]

On Thu, 15 Jun 2017, Xiong Zhang  wrote:
> In a IGD passthrough environment, the real ISA bridge may doesn't exist.
> then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is
> used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as
> LPT_H,then errors occur when i915 runs on LPT_LP machines with igd
> passthrough.
>
> This patch set pch_id for HSW/BDW according to IGD type and isn't fully
> correct. But it solves such issue on HSW/BDW ult/ulx machines.
> QA CI system is blocked by this issue for a long time, it's better that
> we could merge it to unblock QA CI system.
>
> We know the root cause is in device model of virtual passthrough, and
> will resolve it in the future with several parts cooperation in kernel,
> qemu and xen.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99938
>
> Signed-off-by: Xiong Zhang 

Please always indicate when you're sending a new version of a patch. For
example, there's plenty of old discussion in the thread starting at [1].


BR,
Jani.


[1] 
http://mid.mail-archive.com/1490778167-21424-1-git-send-email-xiong.y.zhang@intel.com


> ---
>  drivers/gpu/drm/i915/i915_drv.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1f802de..2e664c5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -135,6 +135,10 @@ static enum intel_pch intel_virt_detect_pch(struct 
> drm_i915_private *dev_priv)
>   DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
>   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
>   ret = PCH_LPT;
> + if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> + dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
> + else
> + dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
>   DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
>   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
>   ret = PCH_SPT;

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Gen8+ engine-reset (rev13)

[Patchwork]

== Series Details ==

Series: Gen8+ engine-reset (rev13)
URL   : https://patchwork.freedesktop.org/series/21868/
State : success

== Summary ==

Series 21868v13 Gen8+ engine-reset
https://patchwork.freedesktop.org/api/1.0/series/21868/revisions/13/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
fail   -> PASS   (fi-snb-2600) fdo#100215

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:469s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:485s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:584s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:553s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:498s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:588s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:435s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:420s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:466s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:498s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:514s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:474s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:569s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:584s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:488s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:452s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:516s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:501s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:511s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:628s
fi-snb-2600  total:278  pass:247  dwarn:0   dfail:0   fail:1   skip:29  
time:403s

467eb330a8121f66d7a8aa7a37991ab24f11aedc drm-tip: 2017y-06m-15d-20h-00m-09s UTC 
integration manifest
e4f78c7 drm/i915: Watchdog timeout: Export media reset count from GuC to debugfs
f3f25d0 drm/i915: Watchdog timeout: Include threshold value in error state
3a8730e drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
678d01b drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+
69362be drm/i915: Watchdog timeout: IRQ handler for gen8+
c3d23a4 drm/i915: Watchdog timeout: Pass GuC shared data structure during param 
load
67b9619 drm/i915/guc: Add support for reset engine using GuC commands
7dbc199 drm/i915/guc: Rename the function that resets the GuC
a24f86f drm/i915/guc: Provide register list to be saved/restored during engine 
reset
c089e05 drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder
206cc32 drm/i915/selftests: reset engine self tests
8697b3e drm/i915: Add engine reset count in get-reset-stats ioctl
95eb905 drm/i915: Enable Engine reset and recovery support
f8bcd30 drm/i915: Carry on with reset even if hw engine is not ready
7f5adfe drm/i915: Export per-engine reset count info to debugfs
975f351 drm/i915: Add engine reset count to error state
7019293 drm/i915: Add support for per engine reset recovery
23f6937 drm/i915: Include reset engine information in has_gpu_reset getparam
fce2787 drm/i915: Modify error handler for per engine hang recovery
fb6a802 drm/i915: Update i915.reset to handle engine resets
b0feb0ba drm/i915: Look for active requests earlier in the reset path

== Logs ==

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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Alex Williamson]

On Thu, 15 Jun 2017 18:00:38 +0200
Gerd Hoffmann  wrote:

>   Hi,
> 
> > > +struct vfio_dmabuf_mgr_plane_info {
> > > + __u64 start;
> > > + __u64 drm_format_mod;
> > > + __u32 drm_format;
> > > + __u32 width;
> > > + __u32 height;
> > > + __u32 stride;
> > > + __u32 size;
> > > + __u32 x_pos;
> > > + __u32 y_pos;
> > > + __u32 padding;
> > > +};
> > > +  
> > 
> > This structure is generic, can remove dmabuf from its name,
> > vfio_plane_info or vfio_vgpu_surface_info since this will only be
> > used
> > by vgpu.  
> 
> Agree.

I'm not sure I agree regarding the vgpu statement, maybe this is not
dmabuf specific, but what makes it vgpu specific?  We need to separate
our current usage plans from what it's actually describing and I don't
see that it describes anything vgpu specific.
 
> > > +struct vfio_dmabuf_mgr_query_plane {
> > > + __u32 argsz;
> > > + __u32 flags;
> > > + struct vfio_dmabuf_mgr_plane_info plane_info;
> > > + __u32 plane_id;
> > > +};
> > > +
> > > +#define VFIO_DMABUF_MGR_QUERY_PLANE _IO(VFIO_TYPE, VFIO_BASE + 15)
> > > +  
> > 
> > This same interface can be used to query surface/plane information
> > for
> > both, dmabuf and region, case. Here also 'DMABUF' can be removed and
> > define flags if you want to differentiate query for 'dmabuf' and
> > 'region'.  
> 
> Hmm, any specific reason why you want use a ioctl for that?  I would
> simply place a "struct vfio_dmabuf_mgr_plane_info" (or whatever the
> final name will be) at the start of the region.

Right, these are ioctls on the dmabuf mgr fd, not the vfio device fd,
if you're exposing a region with the info I wouldn't think you'd want
the hassle of managing this separate fd when you could do something
like Gerd suggests with defining the first page of the regions as
containing the structure.  Maybe you could even allow mmap of that page
to reduce the overhead of getting the current state.  For the sake of
userspace, I'd hope we'd still use the same structure for either the
ioctl or region mapping.  I'm not really in favor of declaring that
this particular ioctl might exist on the device fd when such-and-such
region is present otherwise it might exist on a dmabuf manager fd.
Thanks,

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

Re: [Intel-gfx] [PATCH 6/7] drm/i915: also move version 2 of the register picking macros up

[Jani Nikula]

On Tue, 13 Jun 2017, Paulo Zanoni  wrote:
> Make sure all the macros are next to each other so it's easier to spot
> all the options available.

Please also move _MIPI_PORT and _MMIO_MIPI up. Btw they're another
variant...

BR,
Jani.

>
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3e46ba1..a97af4a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -53,6 +53,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  
>  #define _PIPE(pipe, a, b) _PICK(pipe, a, b)
>  #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
> +#define _MMIO_PIPE2(pipe, reg) _MMIO(dev_priv->info.pipe_offsets[pipe] - \
> + dev_priv->info.pipe_offsets[PIPE_A] + (reg) + \
> + dev_priv->info.display_mmio_offset)
>  #define _MMIO_PIPE3(pipe, ...) _MMIO(_PICK3(pipe, __VA_ARGS__))
>  
>  #define _PLANE(plane, a, b) _PICK(plane, a, b)
> @@ -60,6 +63,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  
>  #define _TRANS(tran, a, b) _PICK(tran, a, b)
>  #define _MMIO_TRANS(tran, a, b) _MMIO(_TRANS(tran, a, b))
> +#define _MMIO_TRANS2(pipe, reg) _MMIO(dev_priv->info.trans_offsets[(pipe)] - 
> \
> + dev_priv->info.trans_offsets[TRANSCODER_A] + (reg) + \
> + dev_priv->info.display_mmio_offset)
>  
>  #define _PORT(port, a, b) _PICK(port, a, b)
>  #define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b))
> @@ -3700,10 +3706,6 @@ enum {
>  #define CHV_TRANSCODER_C_OFFSET 0x63000
>  #define TRANSCODER_EDP_OFFSET 0x6f000
>  
> -#define _MMIO_TRANS2(pipe, reg) _MMIO(dev_priv->info.trans_offsets[(pipe)] - 
> \
> - dev_priv->info.trans_offsets[TRANSCODER_A] + (reg) + \
> - dev_priv->info.display_mmio_offset)
> -
>  #define HTOTAL(trans)_MMIO_TRANS2(trans, _HTOTAL_A)
>  #define HBLANK(trans)_MMIO_TRANS2(trans, _HBLANK_A)
>  #define HSYNC(trans) _MMIO_TRANS2(trans, _HSYNC_A)
> @@ -5189,10 +5191,6 @@ enum {
>   */
>  #define PIPE_EDP_OFFSET  0x7f000
>  
> -#define _MMIO_PIPE2(pipe, reg) _MMIO(dev_priv->info.pipe_offsets[pipe] - \
> - dev_priv->info.pipe_offsets[PIPE_A] + (reg) + \
> - dev_priv->info.display_mmio_offset)
> -
>  #define PIPECONF(pipe)   _MMIO_PIPE2(pipe, _PIPEACONF)
>  #define PIPEDSL(pipe)_MMIO_PIPE2(pipe, _PIPEADSL)
>  #define PIPEFRAME(pipe)  _MMIO_PIPE2(pipe, _PIPEAFRAMEHIGH)

-- 
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 7/7] drm/i915: extract a _PICK2 macro

[Jani Nikula]

On Wed, 14 Jun 2017, Rodrigo Vivi  wrote:
> On Wed, Jun 14, 2017 at 8:16 AM, Ville Syrjälä
>  wrote:
>> On Tue, Jun 13, 2017 at 04:33:50PM -0300, Paulo Zanoni wrote:
>>> Do it just like we do with _PICK and _PICK3, so our code looks a
>>> little more uniform.
>>>
>>> Signed-off-by: Paulo Zanoni 
>>> ---
>>>  drivers/gpu/drm/i915/i915_reg.h | 12 ++--
>>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index a97af4a..3fb7b63 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -49,13 +49,14 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>>>  }
>>>
>
> yeap, as you predicted on the cover letter here starts the name bikeshedings 
> ;)
>
>>>  #define _PICK(__index, a, b) ((a) + (__index) * ((b) - (a)))
>
> for me this is more like a "guess" based on the gap, but specially
> I have concern about reusing the name that was for a totally different use.
> PICK before this list is a "select from a list" and after this series is
> "select base on uniform gap"
>
>>> +#define _PICK2(__index, __offsets, a) (__offsets[__index] - __offsets[0] + 
>>> \
>>> +(a) + 
>>> dev_priv->info.display_mmio_offset)
>
> and this is a select based on common base offset.
>
>>>  #define _PICK3(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
>
> and this is actual pick from a list
>
> also I don't like the numbers as versions of the macro...
> I'd prefer to use just in number of arguments as before.
>
> so, what about:
>
> s/PICK(/PICK_GAP
> s/PICK2/PICK_OFFSET
> s/PICK3/PICK_LIST

Just _LINEAR, _ARRAY, _PICK.

Or PICK_LINEAR, PICK_ARRAY, PICK_VA (or PICK_ARGS).

BR,
Jani.


>
> ?
>
> or
>
> s/PICK(/SELECT_GAP
> s/PICK2/SELECT_OFFSET
> s/PICK3/SELECT_LIST
>
> ?
>
>>>
>>>  #define _PIPE(pipe, a, b) _PICK(pipe, a, b)
>>>  #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
>>> -#define _MMIO_PIPE2(pipe, reg) _MMIO(dev_priv->info.pipe_offsets[pipe] - \
>>> - dev_priv->info.pipe_offsets[PIPE_A] + (reg) + \
>>> - dev_priv->info.display_mmio_offset)
>>> +#define _MMIO_PIPE2(pipe, reg) _MMIO(_PICK2(pipe, 
>>> dev_priv->info.pipe_offsets, \
>>> + reg))
>>>  #define _MMIO_PIPE3(pipe, ...) _MMIO(_PICK3(pipe, __VA_ARGS__))
>>>
>>>  #define _PLANE(plane, a, b) _PICK(plane, a, b)
>>> @@ -63,9 +64,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>>>
>>>  #define _TRANS(tran, a, b) _PICK(tran, a, b)
>>>  #define _MMIO_TRANS(tran, a, b) _MMIO(_TRANS(tran, a, b))
>>> -#define _MMIO_TRANS2(pipe, reg) _MMIO(dev_priv->info.trans_offsets[(pipe)] 
>>> - \
>>> - dev_priv->info.trans_offsets[TRANSCODER_A] + (reg) + \
>>> - dev_priv->info.display_mmio_offset)
>>> +#define _MMIO_TRANS2(tran, reg) _MMIO(_PICK2(tran, \
>>> +  dev_priv->info.trans_offsets, 
>>> reg))
>>
>> No love for cursor/palette offsets?
>>
>>>
>>>  #define _PORT(port, a, b) _PICK(port, a, b)
>>>  #define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b))
>>> --
>>> 2.9.4
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>> --
>> Ville Syrjälä
>> Intel OTC
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 5/7] drm/i915: add _PICK macro for the "a + index * (b - a)" macros

[Jani Nikula]

On Tue, 13 Jun 2017, Paulo Zanoni  wrote:
> Instead of duplicating the macro everywhere, add a single definition
> for it and call it just like we do with the _PICK3 macros.
>
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d271098..3e46ba1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -48,25 +48,26 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>   return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
>  }
>  
> +#define _PICK(__index, a, b) ((a) + (__index) * ((b) - (a)))

The change overall is good but I'd name this in a way that emphasizes
the registers are evenly spaced. _LINEAR?

BR,
Jani.

>  #define _PICK3(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
>  
> -#define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
> +#define _PIPE(pipe, a, b) _PICK(pipe, a, b)
>  #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
>  #define _MMIO_PIPE3(pipe, ...) _MMIO(_PICK3(pipe, __VA_ARGS__))
>  
> -#define _PLANE(plane, a, b) _PIPE(plane, a, b)
> -#define _MMIO_PLANE(plane, a, b) _MMIO_PIPE(plane, a, b)
> +#define _PLANE(plane, a, b) _PICK(plane, a, b)
> +#define _MMIO_PLANE(plane, a, b) _MMIO(_PLANE(plane, a, b))
>  
> -#define _TRANS(tran, a, b) ((a) + (tran)*((b)-(a)))
> +#define _TRANS(tran, a, b) _PICK(tran, a, b)
>  #define _MMIO_TRANS(tran, a, b) _MMIO(_TRANS(tran, a, b))
>  
> -#define _PORT(port, a, b) ((a) + (port)*((b)-(a)))
> +#define _PORT(port, a, b) _PICK(port, a, b)
>  #define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b))
>  #define _MMIO_PORT3(port, ...) _MMIO(_PICK3(port, __VA_ARGS__))
>  #define _MMIO_PORT3_LN(port, ln, a0, a1, b, c, d, e, f)  
> \
>   _MMIO(_PICK3(port, a0, b, c, d, e, f) + (ln * (a1 - a0)))
>  
> -#define _PLL(pll, a, b) ((a) + (pll)*((b)-(a)))
> +#define _PLL(pll, a, b) _PICK(pll, a, b)
>  #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
>  
>  #define _PHY3(phy, ...) _PICK3(phy, __VA_ARGS__)
> @@ -6415,7 +6416,7 @@ enum {
>  #define _PS_ECC_STAT_2B 0x68AD0
>  #define _PS_ECC_STAT_1C 0x691D0
>  
> -#define _ID(id, a, b) ((a) + (id)*((b)-(a)))
> +#define _ID(id, a, b) _PICK(id, a, b)
>  #define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
>   _ID(id, _PS_1A_CTRL, _PS_2A_CTRL),   \
>   _ID(id, _PS_1B_CTRL, _PS_2B_CTRL))

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

Re: [Intel-gfx] [PATCH 4/7] drm/i915: rename _PICK to _PICK3

[Jani Nikula]

On Tue, 13 Jun 2017, Paulo Zanoni  wrote:
> All of the macros that call _PICK are named _X_3, so let's rename
> _PICK to _PICK3. The reason we're doing this is because we're going to
> have _PICK and _PICK2. Consider _PICK3 as the third variation of the
> PICK macros (well, actually it *is* the third variation...).

I named it PICK because it "picks" one of a list, i.e. it doesn't
compute anything. I guess I'd like to keep the name.

BR,
Jani.


>
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 33 -
>  1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1d5a0f8..d271098 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -48,11 +48,11 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>   return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
>  }
>  
> -#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
> +#define _PICK3(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
>  
>  #define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
>  #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
> -#define _MMIO_PIPE3(pipe, ...) _MMIO(_PICK(pipe, __VA_ARGS__))
> +#define _MMIO_PIPE3(pipe, ...) _MMIO(_PICK3(pipe, __VA_ARGS__))
>  
>  #define _PLANE(plane, a, b) _PIPE(plane, a, b)
>  #define _MMIO_PLANE(plane, a, b) _MMIO_PIPE(plane, a, b)
> @@ -62,15 +62,14 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  
>  #define _PORT(port, a, b) ((a) + (port)*((b)-(a)))
>  #define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b))
> -#define _MMIO_PORT3(port, ...) _MMIO(_PICK(port, __VA_ARGS__))
> -#define _MMIO_PORT6(port, ...) _MMIO(_PICK(port, __VA_ARGS__))
> -#define _MMIO_PORT6_LN(port, ln, a0, a1, b, c, d, e, f)  
> \
> - _MMIO(_PICK(port, a0, b, c, d, e, f) + (ln * (a1 - a0)))
> +#define _MMIO_PORT3(port, ...) _MMIO(_PICK3(port, __VA_ARGS__))
> +#define _MMIO_PORT3_LN(port, ln, a0, a1, b, c, d, e, f)  
> \
> + _MMIO(_PICK3(port, a0, b, c, d, e, f) + (ln * (a1 - a0)))
>  
>  #define _PLL(pll, a, b) ((a) + (pll)*((b)-(a)))
>  #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
>  
> -#define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
> +#define _PHY3(phy, ...) _PICK3(phy, __VA_ARGS__)
>  #define _MMIO_PHY3(phy, ...) _MMIO(_PHY3(phy, __VA_ARGS__))
>  
>  #define _MASKED_FIELD(mask, value) ({
>\
> @@ -1709,14 +1708,14 @@ enum skl_disp_power_wells {
>  #define _CNL_PORT_PCS_DW1_LN0_C  0x162C04
>  #define _CNL_PORT_PCS_DW1_LN0_D  0x162E04
>  #define _CNL_PORT_PCS_DW1_LN0_F  0x162804
> -#define CNL_PORT_PCS_DW1_GRP(port)   _MMIO_PORT6(port, \
> +#define CNL_PORT_PCS_DW1_GRP(port)   _MMIO_PORT3(port, \
>   _CNL_PORT_PCS_DW1_GRP_AE, \
>   _CNL_PORT_PCS_DW1_GRP_B, \
>   _CNL_PORT_PCS_DW1_GRP_C, \
>   _CNL_PORT_PCS_DW1_GRP_D, \
>   _CNL_PORT_PCS_DW1_GRP_AE, \
>   _CNL_PORT_PCS_DW1_GRP_F)
> -#define CNL_PORT_PCS_DW1_LN0(port)   _MMIO_PORT6(port, \
> +#define CNL_PORT_PCS_DW1_LN0(port)   _MMIO_PORT3(port, \
>   _CNL_PORT_PCS_DW1_LN0_AE, \
>   _CNL_PORT_PCS_DW1_LN0_B, \
>   _CNL_PORT_PCS_DW1_LN0_C, \
> @@ -1735,14 +1734,14 @@ enum skl_disp_power_wells {
>  #define _CNL_PORT_TX_DW2_LN0_C   0x162C48
>  #define _CNL_PORT_TX_DW2_LN0_D   0x162E48
>  #define _CNL_PORT_TX_DW2_LN0_F   0x162A48
> -#define CNL_PORT_TX_DW2_GRP(port)_MMIO_PORT6(port, \
> +#define CNL_PORT_TX_DW2_GRP(port)_MMIO_PORT3(port, \
>   _CNL_PORT_TX_DW2_GRP_AE, \
>   _CNL_PORT_TX_DW2_GRP_B, \
>   _CNL_PORT_TX_DW2_GRP_C, \
>   _CNL_PORT_TX_DW2_GRP_D, \
>   _CNL_PORT_TX_DW2_GRP_AE, \
>   _CNL_PORT_TX_DW2_GRP_F)
> -#define CNL_PORT_TX_DW2_LN0(port)_MMIO_PORT6(port, \
> +#define CNL_PORT_TX_DW2_LN0(port)_MMIO_PORT3(port, \
>   _CNL_PORT_TX_DW2_LN0_AE, \
>   _CNL_PORT_TX_DW2_LN0_B, \
>   _CNL_PORT_TX_DW2_LN0_C, \
> @@ -1764,14 +1763,14 @@ enum skl_disp_power_wells {
>  #define 

[Intel-gfx] [PATCH v9 21/21] drm/i915: Watchdog timeout: Export media reset count from GuC to debugfs

[Michel Thierry]

From firmware v8.8, GuC provides the count of media engine resets
(watchdog timeout). This information is available in the GuC shared
context data struct, which resides in the first page of the default
(kernel) lrc context.

Since GuC handled engine resets are transparent for kernel and user,
provide a simple debugfs entry to see the number of times media reset
has happened.

v2: Remove unnecessary struct_mutex, _get_dirty_page and kmap_atomic;
use READ_ONCE. (Chris)

Cc: Chris Wilson 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_debugfs.c   | 22 ++
 drivers/gpu/drm/i915/intel_guc_fwif.h | 18 ++
 2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e9c5527b7bff..13353e7c397f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1403,6 +1403,26 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static u32 i915_watchdog_reset_count(struct drm_i915_private *dev_priv)
+{
+   struct i915_gem_context *ctx;
+   struct page *page;
+   struct guc_shared_ctx_data *guc_shared_data;
+   u32 guc_media_reset_count;
+
+   if (!i915.enable_guc_submission)
+   return 0;
+
+   ctx = dev_priv->kernel_context;
+   page = i915_gem_object_get_page(ctx->engine[RCS].state->obj,
+   LRC_GUCSHR_PN);
+   guc_shared_data = kmap(page);
+   guc_media_reset_count = READ_ONCE(guc_shared_data->media_reset_count);
+   kunmap(page);
+
+   return guc_media_reset_count;
+}
+
 static int i915_reset_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -1411,6 +1431,8 @@ static int i915_reset_info(struct seq_file *m, void 
*unused)
enum intel_engine_id id;
 
seq_printf(m, "full gpu reset = %u\n", i915_reset_count(error));
+   seq_printf(m, "GuC watchdog/media reset = %u\n",
+  i915_watchdog_reset_count(dev_priv));
 
for_each_engine(engine, dev_priv, id) {
seq_printf(m, "%s = %u\n", engine->name,
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 2a42ef5f40f0..526c70614b38 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -543,6 +543,24 @@ union guc_log_control {
u32 value;
 } __packed;
 
+/* GuC Shared Context Data Struct */
+struct guc_shared_ctx_data {
+   u32 addr_of_last_preempted_data_low;
+   u32 addr_of_last_preempted_data_high;
+   u32 addr_of_last_preempted_data_high_tmp;
+   u32 padding;
+   u32 is_mapped_to_proxy;
+   u32 proxy_ctx_id;
+   u32 engine_reset_ctx_id;
+   u32 media_reset_count;
+   u32 reserved[8];
+   u32 uk_last_ctx_switch_reason;
+   u32 was_reset;
+   u32 lrca_gpu_addr;
+   u32 execlist_ctx;
+   u32 reserved1[32];
+} __packed;
+
 /* This Action will be programmed in C180 - SOFT_SCRATCH_O_REG */
 enum intel_guc_action {
INTEL_GUC_ACTION_DEFAULT = 0x0,
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 11/21] drm/i915/selftests: reset engine self tests

[Michel Thierry]

Check that we can reset specific engines, also check the fallback to
full reset if something didn't work.

v2: rebase.
v3: use RESET_ENGINE_IN_PROGRESS flag.
v4: use I915_RESET_ENGINE flag.

Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 150 +++
 1 file changed, 150 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index aa31d6c0cdfb..f54b32d9b50c 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -322,6 +322,57 @@ static int igt_global_reset(void *arg)
return err;
 }
 
+static int igt_reset_engine(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   unsigned int reset_count, reset_engine_count;
+   int err = 0;
+
+   /* Check that we can issue a global GPU and engine reset */
+
+   if (!intel_has_gpu_reset(i915))
+   return 0;
+
+   if (!intel_has_reset_engine(i915))
+   return 0;
+
+   for_each_engine(engine, i915, id) {
+   set_bit(I915_RESET_ENGINE + engine->id, >gpu_error.flags);
+   reset_count = i915_reset_count(>gpu_error);
+   reset_engine_count = i915_reset_engine_count(>gpu_error,
+engine);
+
+   err = i915_reset_engine(engine);
+   if (err) {
+   pr_err("i915_reset_engine failed\n");
+   break;
+   }
+
+   if (i915_reset_count(>gpu_error) != reset_count) {
+   pr_err("Full GPU reset recorded! (engine reset 
expected)\n");
+   err = -EINVAL;
+   break;
+   }
+
+   if (i915_reset_engine_count(>gpu_error, engine) ==
+   reset_engine_count) {
+   pr_err("No %s engine reset recorded!\n", engine->name);
+   err = -EINVAL;
+   break;
+   }
+
+   clear_bit(I915_RESET_ENGINE + engine->id,
+ >gpu_error.flags);
+   }
+
+   if (i915_terminally_wedged(>gpu_error))
+   err = -EIO;
+
+   return err;
+}
+
 static u32 fake_hangcheck(struct drm_i915_gem_request *rq)
 {
u32 reset_count;
@@ -526,13 +577,112 @@ static int igt_reset_queue(void *arg)
return err;
 }
 
+static int igt_render_engine_reset_fallback(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct intel_engine_cs *engine = i915->engine[RCS];
+   struct hang h;
+   struct drm_i915_gem_request *rq;
+   unsigned int reset_count, reset_engine_count;
+   int err = 0;
+
+   /* Check that we can issue a global GPU and engine reset */
+
+   if (!intel_has_gpu_reset(i915))
+   return 0;
+
+   if (!intel_has_reset_engine(i915))
+   return 0;
+
+   set_bit(I915_RESET_BACKOFF, >gpu_error.flags);
+   mutex_lock(>drm.struct_mutex);
+
+   err = hang_init(, i915);
+   if (err)
+   goto unlock;
+
+   rq = hang_create_request(, engine, i915->kernel_context);
+   if (IS_ERR(rq)) {
+   err = PTR_ERR(rq);
+   goto fini;
+   }
+
+   i915_gem_request_get(rq);
+   __i915_add_request(rq, true);
+
+   /* make reset engine fail */
+   rq->fence.error = -EIO;
+
+   if (!wait_for_hang(, rq)) {
+   pr_err("Failed to start request %x\n", rq->fence.seqno);
+   err = -EIO;
+   goto fini;
+   }
+
+   reset_engine_count = i915_reset_engine_count(>gpu_error, engine);
+   reset_count = fake_hangcheck(rq);
+
+   /* unlock since we'll call handle_error */
+   mutex_unlock(>drm.struct_mutex);
+   clear_bit(I915_RESET_BACKOFF, >gpu_error.flags);
+
+   i915_handle_error(i915, intel_engine_flag(engine), "live test");
+
+   if (i915_reset_engine_count(>gpu_error, engine) !=
+   reset_engine_count) {
+   pr_err("render engine reset recorded! (full reset expected)\n");
+   err = -EINVAL;
+   goto fini;
+   }
+
+   if (i915_reset_count(>gpu_error) == reset_count) {
+   pr_err("No full GPU reset recorded!\n");
+   err = -EINVAL;
+   goto fini;
+   }
+
+   /*
+* by using fence.error = -EIO, full reset sets the wedged flag, do one
+* more full reset to re-enable the hw.
+*/
+   if (i915_terminally_wedged(>gpu_error)) {
+   set_bit(I915_RESET_BACKOFF, >gpu_error.flags);
+   mutex_lock(>drm.struct_mutex);
+   rq->fence.error = 0;
+
+   set_bit(I915_RESET_HANDOFF, >gpu_error.flags);
+   i915_reset(i915);
+   

[Intel-gfx] [PATCH v9 14/21] drm/i915/guc: Rename the function that resets the GuC

[Michel Thierry]

intel_guc_reset sounds more like the microcontroller is the one performing
a reset, while in this case is the opposite. intel_reset_guc not only
makes it clearer, it follows the other intel_reset functions available.

v2: Print error message in English.

Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c | 4 ++--
 drivers/gpu/drm/i915/intel_uncore.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f68cfdf640f3..e657d56120d7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3104,7 +3104,7 @@ extern bool intel_has_gpu_reset(struct drm_i915_private 
*dev_priv);
 extern void i915_reset(struct drm_i915_private *dev_priv);
 extern int i915_reset_engine(struct intel_engine_cs *engine);
 extern bool intel_has_reset_engine(struct drm_i915_private *dev_priv);
-extern int intel_guc_reset(struct drm_i915_private *dev_priv);
+extern int intel_reset_guc(struct drm_i915_private *dev_priv);
 extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine);
 extern void intel_hangcheck_init(struct drm_i915_private *dev_priv);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 27e072cc96eb..a8930f2feacf 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -46,9 +46,9 @@ static int __intel_uc_reset_hw(struct drm_i915_private 
*dev_priv)
int ret;
u32 guc_status;
 
-   ret = intel_guc_reset(dev_priv);
+   ret = intel_reset_guc(dev_priv);
if (ret) {
-   DRM_ERROR("GuC reset failed, ret = %d\n", ret);
+   DRM_ERROR("Failed to reset GuC, ret = %d\n", ret);
return ret;
}
 
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index b99b7c69a525..713a88cebf57 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1734,7 +1734,7 @@ bool intel_has_reset_engine(struct drm_i915_private 
*dev_priv)
i915.reset >= 2);
 }
 
-int intel_guc_reset(struct drm_i915_private *dev_priv)
+int intel_reset_guc(struct drm_i915_private *dev_priv)
 {
int ret;
 
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 09/21] drm/i915: Enable Engine reset and recovery support

[Michel Thierry]

This feature is made available only from Gen8, for previous gen devices
driver uses legacy full gpu reset.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 045cadb77285..14e2c2e57f96 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,7 @@ struct i915_params i915 __read_mostly = {
.prefault_disable = 0,
.load_detect_test = 0,
.force_reset_modeset_test = 0,
-   .reset = 1,
+   .reset = 2,
.error_capture = true,
.invert_brightness = 0,
.disable_display = 0,
@@ -116,7 +116,7 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
 module_param_named_unsafe(reset, i915.reset, int, 0600);
-MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset 
[default], 2=engine reset)");
+MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset, 
2=engine reset [default])");
 
 #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
 module_param_named(error_capture, i915.error_capture, bool, 0600);
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 18/21] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+

[Michel Thierry]

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

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

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

Cc: Chris Wilson 
Signed-off-by: Tomas Elf 
Signed-off-by: Ian Lister 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_gem_context.h |  4 ++
 drivers/gpu/drm/i915/intel_lrc.c| 85 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 ++
 3 files changed, 89 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 4af2ab94558b..88700bdbb4e1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -150,6 +150,10 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+   /** watchdog_threshold: hw watchdog threshold value,
+* in clock counts
+*/
+   u32 watchdog_threshold;
bool initialised;
} engine[I915_NUM_ENGINES];
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a66c23de80dc..cf0d5717bb92 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1387,7 +1387,10 @@ static int gen8_emit_bb_start(struct 
drm_i915_gem_request *req,
  u64 offset, u32 len,
  const unsigned int flags)
 {
+   struct intel_engine_cs *engine = req->engine;
u32 *cs;
+   u32 num_dwords;
+   bool watchdog_running = false;
int ret;
 
/* Don't rely in hw updating PDPs, specially in lite-restore.
@@ -1397,20 +1400,38 @@ static int gen8_emit_bb_start(struct 
drm_i915_gem_request *req,
 * not idle). PML4 is allocated during ppgtt init so this is
 * not needed in 48-bit.*/
if (req->ctx->ppgtt &&
-   (intel_engine_flag(req->engine) & req->ctx->ppgtt->pd_dirty_rings) 
&&
+   (intel_engine_flag(engine) & req->ctx->ppgtt->pd_dirty_rings) &&
!i915_vm_is_48bit(>ctx->ppgtt->base) &&
!intel_vgpu_active(req->i915)) {
ret = intel_logical_ring_emit_pdps(req);
if (ret)
return ret;
 
-   req->ctx->ppgtt->pd_dirty_rings &= 
~intel_engine_flag(req->engine);
+   req->ctx->ppgtt->pd_dirty_rings &= ~intel_engine_flag(engine);
+   }
+
+   /* bb_start only */
+   num_dwords = 4;
+
+   /* check if watchdog will be required */
+   if (req->ctx->engine[engine->id].watchdog_threshold != 0) {
+   GEM_BUG_ON(!engine->emit_start_watchdog ||
+  !engine->emit_stop_watchdog);
+
+   /* + start_watchdog (6) + stop_watchdog (4) */
+   num_dwords += 10;
+   watchdog_running = true;
}
 
-   cs = intel_ring_begin(req, 4);
+   cs = intel_ring_begin(req, num_dwords);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
+   if (watchdog_running) {
+   /* Start watchdog timer */
+   cs = engine->emit_start_watchdog(req, cs);
+   }
+
/* FIXME(BDW): Address space and security selectors. */
*cs++ = MI_BATCH_BUFFER_START_GEN8 |
(flags & I915_DISPATCH_SECURE ? 0 : BIT(8)) |
@@ -1418,8 +1439,13 @@ static int gen8_emit_bb_start(struct 
drm_i915_gem_request *req,
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
*cs++ = MI_NOOP;
-   intel_ring_advance(req, cs);
 
+   if (watchdog_running) {
+   /* Cancel watchdog timer */
+   cs = engine->emit_stop_watchdog(req, cs);
+   }
+
+   intel_ring_advance(req, cs);
return 0;
 }
 
@@ -1586,6 +1612,49 @@ static void gen8_watchdog_irq_handler(unsigned long data)
intel_uncore_forcewake_put(dev_priv, engine->fw_domains);
 }
 
+static u32 *gen8_emit_start_watchdog(struct drm_i915_gem_request *req, u32 *cs)
+{
+   struct intel_engine_cs *engine = req->engine;
+   struct i915_gem_context *ctx = req->ctx;
+   struct intel_context *ce = >engine[engine->id];
+
+   /* XXX: no watchdog support in BCS engine */
+   GEM_BUG_ON(engine->id == BCS);
+
+   /*
+* watchdog register must never be 

[Intel-gfx] [PATCH v9 04/21] drm/i915: Include reset engine information in has_gpu_reset getparam

[Michel Thierry]

So users (tests) can detect which type of reset (engine vs global) is
active.

Suggested-by: Chris Wilson 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5035375aa67e..e4c4bc41c378 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -322,6 +322,8 @@ static int i915_getparam(struct drm_device *dev, void *data,
break;
case I915_PARAM_HAS_GPU_RESET:
value = i915.enable_hangcheck && intel_has_gpu_reset(dev_priv);
+   if (value && intel_has_reset_engine(dev_priv))
+   value = 2;
break;
case I915_PARAM_HAS_RESOURCE_STREAMER:
value = HAS_RESOURCE_STREAMER(dev_priv);
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 20/21] drm/i915: Watchdog timeout: Include threshold value in error state

[Michel Thierry]

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

v2: Only do it for gen8+ (and prevent a missing-case warn).

Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_gpu_error.c | 12 
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8d9bf4c303b6..b11bd181ff4c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -963,6 +963,7 @@ struct i915_gpu_state {
int ban_score;
int active;
int guilty;
+   int watchdog_threshold;
} context;
 
struct drm_i915_error_object {
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index ebd5501ec134..515fedb61751 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -388,9 +388,11 @@ static void error_print_context(struct 
drm_i915_error_state_buf *m,
const char *header,
const struct drm_i915_error_context *ctx)
 {
-   err_printf(m, "%s%s[%d] user_handle %d hw_id %d, ban score %d guilty %d 
active %d\n",
+   err_printf(m, "%s%s[%d] user_handle %d hw_id %d, ban score %d guilty %d 
active %d, watchdog %dus\n",
   header, ctx->comm, ctx->pid, ctx->handle, ctx->hw_id,
-  ctx->ban_score, ctx->guilty, ctx->active);
+  ctx->ban_score, ctx->guilty, ctx->active,
+  INTEL_GEN(m->i915) >= 8 ?
+   watchdog_to_us(m->i915, ctx->watchdog_threshold) : 0);
 }
 
 static void error_print_engine(struct drm_i915_error_state_buf *m,
@@ -1349,7 +1351,8 @@ static void error_record_engine_execlists(struct 
intel_engine_cs *engine,
 }
 
 static void record_context(struct drm_i915_error_context *e,
-  struct i915_gem_context *ctx)
+  struct i915_gem_context *ctx,
+  u32 engine_id)
 {
if (ctx->pid) {
struct task_struct *task;
@@ -1368,6 +1371,7 @@ static void record_context(struct drm_i915_error_context 
*e,
e->ban_score = ctx->ban_score;
e->guilty = ctx->guilty_count;
e->active = ctx->active_count;
+   e->watchdog_threshold = ctx->engine[engine_id].watchdog_threshold;
 }
 
 static void request_record_user_bo(struct drm_i915_gem_request *request,
@@ -1431,7 +1435,7 @@ static void i915_gem_record_rings(struct drm_i915_private 
*dev_priv,
ee->vm = request->ctx->ppgtt ?
>ctx->ppgtt->base : >base;
 
-   record_context(>context, request->ctx);
+   record_context(>context, request->ctx, engine->id);
 
/* We need to copy these to an anonymous buffer
 * as the simplest method to avoid being overwritten
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 12/21] drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

[Michel Thierry]

From: Daniele Ceraolo Spurio 

The mmio_start offset for the whitelist is the first FORCE_TO_NONPRIV
register the GuC can use to restore the provided whitelist when an
engine reset via GuC (which we still don't support) is triggered.

We're currently adding the mmio_base of the engine to the absolute
address of the RCS version of the register, which results in the wrong
offset. Fix it by using the definition we already have instead of
re-defining it in the GuC FW header.

Also add a comment to avoid future issues with FORCE_TO_NONPRIV
registers, which are also used by the workaround framework.

v2: improve comment (Michal), move comment about save/restore because it
is not related to the mmio_white_list field.

v3: rebase/resurrect.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michał Winiarski 
Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Cc: Oscar Mateo 
Reviewed-by: Michał Winiarski  (v2)
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 11 +--
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 -
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 48a1e9349a2c..4913ec991f4d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1051,10 +1051,17 @@ static int guc_ads_create(struct intel_guc *guc)
/* MMIO reg state */
for_each_engine(engine, dev_priv, id) {
blob->reg_state.white_list[engine->guc_id].mmio_start =
-   engine->mmio_base + GUC_MMIO_WHITE_LIST_START;
+   
i915_mmio_reg_offset(RING_FORCE_TO_NONPRIV(engine->mmio_base, 0));
 
-   /* Nothing to be saved or restored for now. */
+   /*
+* Note: if the GuC whitelist management is enabled, the values
+* should be filled using the workaround framework to avoid
+* inconsistencies with the handling of FORCE_TO_NONPRIV
+* registers.
+*/
blob->reg_state.white_list[engine->guc_id].count = 0;
+
+   /* Nothing to be saved or restored for now. */
}
 
/*
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 5fa286074811..6cbf7c97d186 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -435,7 +435,6 @@ struct guc_policies {
 #define GUC_REGSET_SAVE_CURRENT_VALUE  0x10
 
 #define GUC_REGSET_MAX_REGISTERS   25
-#define GUC_MMIO_WHITE_LIST_START  0x24d0
 #define GUC_MMIO_WHITE_LIST_MAX12
 #define GUC_S3_SAVE_SPACE_PAGES10
 
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 16/21] drm/i915: Watchdog timeout: Pass GuC shared data structure during param load

[Michel Thierry]

For watchdog / media reset, the firmware must know the address of the shared
data page (the first page of the default context).

This information should be in DWORD 9 of the GUC_CTL structure.

v2: Use guc_ggtt_offset (Chris).
Store the ggtt offset of the default ctx as we needed for
suspend/resume/reset (Daniele).

Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 21 ++---
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  2 +-
 drivers/gpu/drm/i915/intel_guc_loader.c| 11 +++
 drivers/gpu/drm/i915/intel_uc.h|  2 ++
 4 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 782ef09b90f5..78c2c2ead524 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1388,7 +1388,6 @@ void i915_guc_submission_reenable_engine(struct 
intel_engine_cs *engine)
 int intel_guc_suspend(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
-   struct i915_gem_context *ctx;
u32 data[3];
 
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
@@ -1396,13 +1395,11 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
 
gen9_disable_guc_interrupts(dev_priv);
 
-   ctx = dev_priv->kernel_context;
-
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
-   /* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state);
+   /* first page of default ctx is shared data with GuC */
+   data[2] = guc->shared_data_offset;
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -1414,7 +1411,6 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
 int intel_guc_resume(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
-   struct i915_gem_context *ctx;
u32 data[3];
 
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
@@ -1423,12 +1419,10 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (i915.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
 
-   ctx = dev_priv->kernel_context;
-
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
-   /* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state);
+   /* first page of default ctx is shared data with GuC */
+   data[2] = guc->shared_data_offset;
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -1437,14 +1431,11 @@ int i915_guc_reset_engine(struct intel_engine_cs 
*engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
struct intel_guc *guc = _priv->guc;
-   struct i915_gem_context *ctx;
u32 data[7];
 
if (!i915.enable_guc_submission)
return 0;
 
-   ctx = dev_priv->kernel_context;
-
/*
 * The affected context report is populated by GuC and is provided
 * to the driver using the shared page. We request for it but don't
@@ -1456,8 +1447,8 @@ int i915_guc_reset_engine(struct intel_engine_cs *engine)
data[3] = 0;
data[4] = 0;
data[5] = guc->execbuf_client->stage_id;
-   /* first page is shared data with GuC */
-   data[6] = guc_ggtt_offset(ctx->engine[RCS].state);
+   /* first page of default ctx is shared data with GuC */
+   data[6] = guc->shared_data_offset;
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 022704a835b3..2a42ef5f40f0 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -135,7 +135,7 @@
 #define   GUC_ADS_ADDR_SHIFT   11
 #define   GUC_ADS_ADDR_MASK0xf800
 
-#define GUC_CTL_RSRVD  9
+#define GUC_CTL_SHARED_DATA9
 
 #define GUC_CTL_MAX_DWORDS (SOFT_SCRATCH_COUNT - 2) /* [1..14] */
 
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 8b0ae7fce7f2..52071879bec0 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -108,6 +108,7 @@ static void guc_params_init(struct drm_i915_private 
*dev_priv)
 {
struct intel_guc *guc = _priv->guc;
u32 params[GUC_CTL_MAX_DWORDS];
+   struct i915_gem_context *ctx;
int i;
 
memset(, 0, sizeof(params));
@@ -156,6 +157,16 @@ static void guc_params_init(struct drm_i915_private 
*dev_priv)
params[GUC_CTL_FEATURE] &= ~GUC_CTL_DISABLE_SCHEDULER;
 

[Intel-gfx] [PATCH v9 RFC 08/21] drm/i915: Carry on with reset even if hw engine is not ready

[Michel Thierry]

We try to get the engines ready/idle before triggering the reset, but it
has been seen that sometimes the hw never acknowledges this.

If we miss the acknowledgment, carry on with the reset instead of
leaving the GPU in a wedged state.

The frequency of missed acknowledgment from hw is low, but it has been
seen at least once in CI.

References: https://intel-gfx-ci.01.org/CI/Trybot_831/
Reported-by: Antonio Argenziano 
Cc: Mika Kuoppala 
Cc: Chris Wilson 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_uncore.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 1ed3dd8df850..b99b7c69a525 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1630,8 +1630,12 @@ static int gen8_reset_engine_start(struct 
intel_engine_cs *engine)
 RESET_CTL_READY_TO_RESET,
 RESET_CTL_READY_TO_RESET,
 700);
-   if (ret)
-   DRM_ERROR("%s: reset request timeout\n", engine->name);
+   if (GEM_WARN_ON(ret)) {
+   /* hw did not ack ready-to-reset, reset anyway */
+   DRM_DEBUG_DRIVER("%s: reset request timeout, continue\n",
+engine->name);
+   ret = 0;
+   }
 
return ret;
 }
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 07/21] drm/i915: Export per-engine reset count info to debugfs

[Michel Thierry]

A new variable is added to export the reset counts to debugfs, this
includes full gpu reset and engine reset count. This is useful for tests
where they are expected to trigger reset; these counts are checked before
and after the test to ensure the same.

v2: Include reset engine count in i915_engine_info too (Chris).

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a6ba2100bb88..e9c5527b7bff 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1403,6 +1403,23 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static int i915_reset_info(struct seq_file *m, void *unused)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct i915_gpu_error *error = _priv->gpu_error;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   seq_printf(m, "full gpu reset = %u\n", i915_reset_count(error));
+
+   for_each_engine(engine, dev_priv, id) {
+   seq_printf(m, "%s = %u\n", engine->name,
+  i915_reset_engine_count(error, engine));
+   }
+
+   return 0;
+}
+
 static int ironlake_drpc_info(struct seq_file *m)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -3279,6 +3296,7 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
 static int i915_engine_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct i915_gpu_error *error = _priv->gpu_error;
struct intel_engine_cs *engine;
enum intel_engine_id id;
 
@@ -3302,6 +3320,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
   engine->hangcheck.seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp),
   engine->timeline->inflight_seqnos);
+   seq_printf(m, "\tReset count: %d\n",
+  i915_reset_engine_count(error, engine));
 
rcu_read_lock();
 
@@ -4814,6 +4834,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
+   {"i915_reset_info", i915_reset_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
{"i915_emon_status", i915_emon_status, 0},
{"i915_ring_freq_table", i915_ring_freq_table, 0},
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 03/21] drm/i915: Modify error handler for per engine hang recovery

[Michel Thierry]

This is a preparatory patch which modifies error handler to do per engine
hang recovery. The actual patch which implements this sequence follows
later in the series. The aim is to prepare existing recovery function to
adapt to this new function where applicable (which fails at this point
because core implementation is lacking) and continue recovery using legacy
full gpu reset.

A helper function is also added to query the availability of engine
reset. A subsequent patch will add the capability to query which type
of reset is present (engine -> full -> no-reset) via the get-param
ioctl.

It has been decided that the error events that are used to notify user of
reset will only be sent in case if full chip reset. In case of just
single (or multiple) engine resets, userspace won't be notified by these
events.

Note that this implementation of engine reset is for i915 directly
submitting to the ELSP, where the driver manages the hang detection,
recovery and resubmission. With GuC submission these tasks are shared
between driver and firmware; i915 will still responsible for detecting a
hang, and when it does it will have to request GuC to reset that Engine and
remind the firmware about the outstanding submissions. This will be
added in different patch.

v2: rebase, advertise engine reset availability in platform definition,
add note about GuC submission.
v3: s/*engine_reset*/*reset_engine*/. (Chris)
Handle reset as 2 level resets, by first going to engine only and fall
backing to full/chip reset as needed, i.e. reset_engine will need the
struct_mutex.
v4: Pass the engine mask to i915_reset. (Chris)
v5: Rebase, update selftests.
v6: Rebase, prepare for mutex-less reset engine.
v7: Pass reset_engine mask as a function parameter, and iterate over the
engine mask for reset_engine. (Chris)
v8: Use i915.reset >=2 in has_reset_engine; remove redundant reset
logging; add a reset-engine-in-progress flag to prevent concurrent
resets, and avoid dual purposing of reset-backoff. (Chris)
v9: Support reset of different engines in parallel (Chris)
v10: Handle reset-engine flag locking better (Chris)

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Ian Lister 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.c | 13 +++
 drivers/gpu/drm/i915/i915_drv.h | 10 +
 drivers/gpu/drm/i915/i915_irq.c | 45 +
 drivers/gpu/drm/i915/i915_pci.c |  5 -
 drivers/gpu/drm/i915/intel_uncore.c | 11 +
 5 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a534412a5551..5035375aa67e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1901,6 +1901,19 @@ void i915_reset(struct drm_i915_private *dev_priv)
goto finish;
 }
 
+/**
+ * i915_reset_engine - reset GPU engine to recover from a hang
+ * @engine: engine to reset
+ *
+ * Reset a specific GPU engine. Useful if a hang is detected.
+ * Returns zero on successful reset or otherwise an error code.
+ */
+int i915_reset_engine(struct intel_engine_cs *engine)
+{
+   /* FIXME: replace me with engine reset sequence */
+   return -ENODEV;
+}
+
 static int i915_pm_suspend(struct device *kdev)
 {
struct pci_dev *pdev = to_pci_dev(kdev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d5d94fbbf042..6101e76cc5ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -753,6 +753,7 @@ struct intel_csr {
func(has_csr); \
func(has_ddi); \
func(has_dp_mst); \
+   func(has_reset_engine); \
func(has_fbc); \
func(has_fpga_dbg); \
func(has_full_ppgtt); \
@@ -1548,6 +1549,12 @@ struct i915_gpu_error {
 * inspect the bit and do the reset directly, otherwise the worker
 * waits for the struct_mutex.
 *
+* #I915_RESET_ENGINE[num_engines] - Since the driver doesn't need to
+* acquire the struct_mutex to reset an engine, we need an explicit
+* flag to prevent two concurrent reset attempts in the same engine.
+* As the number of engines continues to grow, allocate the flags from
+* the most significant bits.
+*
 * #I915_WEDGED - If reset fails and we can no longer use the GPU,
 * we set the #I915_WEDGED bit. Prior to command submission, e.g.
 * i915_gem_request_alloc(), this bit is checked and the sequence
@@ -1557,6 +1564,7 @@ struct i915_gpu_error {
 #define I915_RESET_BACKOFF 0
 #define I915_RESET_HANDOFF 1
 #define I915_WEDGED(BITS_PER_LONG - 1)
+#define I915_RESET_ENGINE  (I915_WEDGED - I915_NUM_ENGINES)
 
/**
 * Waitqueue to 

[Intel-gfx] [PATCH v9 19/21] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

[Michel Thierry]

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

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

Note, UABI engine ids and i915 engine ids are different, and this patch
uses the i915 ones. Some kind of mapping table [1] is required if we
decide to use the UABI engine ids.

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

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

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

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

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

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.h | 56 +++
 drivers/gpu/drm/i915/i915_gem_context.c | 95 +
 drivers/gpu/drm/i915/intel_lrc.c|  5 +-
 include/uapi/drm/i915_drm.h |  1 +
 4 files changed, 155 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 94c7d856174c..8d9bf4c303b6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2196,6 +2196,9 @@ struct drm_i915_private {
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 
965 */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
 
+   /* Command stream timestamp base - helps define watchdog threshold */
+   u32 cs_timestamp_base;
+
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
unsigned int max_cdclk_freq;
@@ -3605,6 +3608,59 @@ i915_gem_context_lookup_timeline(struct i915_gem_context 
*ctx,
return >timeline.engine[engine->id];
 }
 
+/*
+ * BDW, CHV & SKL+ Timestamp timer resolution = 0.080 uSec,
+ * or 1250 counts per second, or ~12 counts per microsecond.
+ *
+ * But BXT/GLK Timestamp timer resolution is different, 0.052 uSec,
+ * or 1920 counts per second, or ~19 counts per microsecond.
+ *
+ * Future-proofing, some day it won't be as simple as just GEN & IS_LP.
+ */
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+static inline u32 cs_timestamp_in_us(struct drm_i915_private *dev_priv)
+{
+   u32 cs_timestamp_base = dev_priv->cs_timestamp_base;
+
+   if (cs_timestamp_base)
+   return cs_timestamp_base;
+
+   switch (INTEL_GEN(dev_priv)) {
+   default:
+   MISSING_CASE(INTEL_GEN(dev_priv));
+   /* fall through */
+   case 9:
+   cs_timestamp_base = IS_GEN9_LP(dev_priv) ?
+   GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+   GEN8_TIMESTAMP_CNTS_PER_USEC;
+   break;
+   case 8:
+   cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+   break;
+   }
+
+   dev_priv->cs_timestamp_base = cs_timestamp_base;
+   return cs_timestamp_base;
+}
+
+static inline u32
+watchdog_to_us(struct drm_i915_private *dev_priv, u32 value_in_clock_counts)
+{
+   return value_in_clock_counts / cs_timestamp_in_us(dev_priv);
+}
+
+static inline u32
+watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
+{
+   u64 threshold = value_in_us * cs_timestamp_in_us(dev_priv);
+
+   if (overflows_type(threshold, u32))
+   return -EINVAL;
+
+   return threshold;
+}
+
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
 void i915_oa_init_reg_state(struct intel_engine_cs *engine,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 04766fdcc4dc..d02460a7ad58 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -337,6 +337,95 @@ 

[Intel-gfx] [PATCH v9 10/21] drm/i915: Add engine reset count in get-reset-stats ioctl

[Michel Thierry]

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

To start the discussion, include just a total engine reset count. If it
is deemed useful, it can be extended to report each engine separately.
Our igt's gem_reset_stats test will need changes to ignore the pad field,
since it can now return reset_engine_count.

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

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

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index c5d1666d7071..04766fdcc4dc 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1029,6 +1029,8 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_reset_stats *args = data;
struct i915_gem_context *ctx;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
int ret;
 
if (args->flags || args->pad)
@@ -1047,10 +1049,16 @@ int i915_gem_context_reset_stats_ioctl(struct 
drm_device *dev,
return PTR_ERR(ctx);
}
 
-   if (capable(CAP_SYS_ADMIN))
+   if (capable(CAP_SYS_ADMIN)) {
args->reset_count = i915_reset_count(_priv->gpu_error);
-   else
+   for_each_engine(engine, dev_priv, id)
+   args->reset_engine_count +=
+   i915_reset_engine_count(_priv->gpu_error,
+   engine);
+   } else {
args->reset_count = 0;
+   args->reset_engine_count = 0;
+   }
 
args->batch_active = ctx->guilty_count;
args->batch_pending = ctx->active_count;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 15bc9f78ba4d..c599d47629ac 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1286,7 +1286,11 @@ struct drm_i915_reset_stats {
/* Number of batches lost pending for execution, for this context */
__u32 batch_pending;
 
-   __u32 pad;
+   union {
+   __u32 pad;
+   /* Engine resets since boot/module reload, for all contexts */
+   __u32 reset_engine_count;
+   };
 };
 
 struct drm_i915_gem_userptr {
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 13/21] drm/i915/guc: Provide register list to be saved/restored during engine reset

[Michel Thierry]

GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be saved is controlled by
flags. We provide a minimal set of registers that we want GuC to save and
restore. This is not an issue in case of engine reset as driver initializes
most of them following an engine reset, but in case of media reset (aka
watchdog reset) which is completely internal to GuC (including resubmission
of hung workload), it is necessary to provide this list, otherwise GuC won't
be able to schedule further workloads after a reset. This is the minimal
set of registers identified for things to work as expected but if we see
any new issues, this register list can be expanded.

In order to not loose any existing workarounds, we have to let GuC know
the registers and its values. These will be reapplied after the reset.
Note that we can't just read the current value because most of these
registers are masked (so we have a workaround for a workaround for a
workaround).

v2: REGSET_MASKED is too difficult for GuC, use REGSET_SAVE_DEFAULT_VALUE
and current value from RING_MODE reg instead; no need to preserve
head/tail either, be extra paranoid and save whitelisted registers (Daniele).

v3: Workarounds added only once during _init_workarounds also have to
been restored, or we risk loosing them after internal GuC reset
(Daniele).

v4: Rename macro used to keep track the workaround registers we will
have to restore after reset (s/I915_GUC_REG_WRITE/WA_REG_WR_GUC_RESTORE).

v5: Only ask guc to reapply workarounds in case of render reset (Daniele).

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Arun Siluvery 
Signed-off-by: Jeff McGee 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.h|  3 ++
 drivers/gpu/drm/i915/i915_guc_submission.c | 70 +-
 drivers/gpu/drm/i915/intel_engine_cs.c | 65 ++-
 3 files changed, 116 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6e98ab53f55e..f68cfdf640f3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1873,7 +1873,10 @@ struct i915_wa_reg {
 
 struct i915_workarounds {
struct i915_wa_reg reg[I915_MAX_WA_REGS];
+   /* list of registers (and their values) that GuC will have to restore */
+   struct i915_wa_reg guc_reg[GUC_REGSET_MAX_REGISTERS];
u32 count;
+   u32 guc_count;
u32 hw_whitelist_count[I915_NUM_ENGINES];
 };
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4913ec991f4d..2bb18d24ed42 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1018,6 +1018,24 @@ static void guc_policies_init(struct guc_policies 
*policies)
policies->is_valid = 1;
 }
 
+/*
+ * In this macro it is highly unlikely to exceed max value but even if we did
+ * it is not an error so just throw a warning and continue. Only side effect
+ * in continuing further means some registers won't be added to save/restore
+ * list.
+ */
+#define GUC_ADD_MMIO_REG_ADS(node, reg_addr, _flags, defvalue) \
+   do {\
+   u32 __count = node->number_of_registers;\
+   if (WARN_ON(__count >= GUC_REGSET_MAX_REGISTERS))   \
+   continue;   \
+   node->registers[__count].offset = reg_addr.reg; \
+   node->registers[__count].flags = (_flags);  \
+   if (defvalue)   \
+   node->registers[__count].value = (defvalue);\
+   node->number_of_registers++;\
+   } while (0)
+
 static int guc_ads_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -1031,6 +1049,7 @@ static int guc_ads_create(struct intel_guc *guc)
u8 reg_state_buffer[GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE];
} __packed *blob;
struct intel_engine_cs *engine;
+   struct i915_workarounds *workarounds = _priv->workarounds;
enum intel_engine_id id;
u32 base;
 
@@ -1050,6 +1069,49 @@ static int guc_ads_create(struct intel_guc *guc)
 
/* MMIO reg state */
for_each_engine(engine, dev_priv, id) {
+   u32 i;
+   struct guc_mmio_regset *eng_reg =
+   >reg_state.engine_reg[engine->guc_id];
+
+   /*
+* Provide a list of registers to be saved/restored during gpu
+* reset. This is mainly required for Media reset (aka watchdog
+* timeout) which is completely under the 

[Intel-gfx] [PATCH v9 06/21] drm/i915: Add engine reset count to error state

[Michel Thierry]

Driver maintains count of how many times a given engine is reset, useful to
capture this in error state also. It gives an idea of how engine is coping
up with the workloads it is executing before this error state.

A follow-up patch will provide this information in debugfs.

v2: s/engine_reset/reset_engine/ (Chris)
Define count as unsigned int (Tvrtko)

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.c   |  3 +++
 drivers/gpu/drm/i915/i915_drv.h   | 10 ++
 drivers/gpu/drm/i915/i915_gpu_error.c |  3 +++
 3 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e8cb4617ecc0..78df1477080a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1955,7 +1955,10 @@ int i915_reset_engine(struct intel_engine_cs *engine)
 * process to program RING_MODE, HWSP and re-enable submission.
 */
ret = engine->init_hw(engine);
+   if (ret)
+   goto out;
 
+   error->reset_engine_count[engine->id]++;
 out:
return ret;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1612f4d97463..6e98ab53f55e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -923,6 +923,7 @@ struct i915_gpu_state {
enum intel_engine_hangcheck_action hangcheck_action;
struct i915_address_space *vm;
int num_requests;
+   u32 reset_count;
 
/* position of active request inside the ring */
u32 rq_head, rq_post, rq_tail;
@@ -1566,6 +1567,9 @@ struct i915_gpu_error {
 #define I915_WEDGED(BITS_PER_LONG - 1)
 #define I915_RESET_ENGINE  (I915_WEDGED - I915_NUM_ENGINES)
 
+   /** Number of times an engine has been reset */
+   u32 reset_engine_count[I915_NUM_ENGINES];
+
/**
 * Waitqueue to signal when a hang is detected. Used to for waiters
 * to release the struct_mutex for the reset to procede.
@@ -3468,6 +3472,12 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
return READ_ONCE(error->reset_count);
 }
 
+static inline u32 i915_reset_engine_count(struct i915_gpu_error *error,
+ struct intel_engine_cs *engine)
+{
+   return READ_ONCE(error->reset_engine_count[engine->id]);
+}
+
 struct drm_i915_gem_request *
 i915_gem_reset_prepare_engine(struct intel_engine_cs *engine);
 int i915_gem_reset_prepare(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 762685ba86da..ebd5501ec134 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -463,6 +463,7 @@ static void error_print_engine(struct 
drm_i915_error_state_buf *m,
err_printf(m, "  hangcheck action timestamp: %lu, %u ms ago\n",
   ee->hangcheck_timestamp,
   jiffies_to_msecs(jiffies - ee->hangcheck_timestamp));
+   err_printf(m, "  engine reset count: %u\n", ee->reset_count);
 
error_print_request(m, "  ELSP[0]: ", >execlist[0]);
error_print_request(m, "  ELSP[1]: ", >execlist[1]);
@@ -1244,6 +1245,8 @@ static void error_record_engine_registers(struct 
i915_gpu_state *error,
ee->hangcheck_timestamp = engine->hangcheck.action_timestamp;
ee->hangcheck_action = engine->hangcheck.action;
ee->hangcheck_stalled = engine->hangcheck.stalled;
+   ee->reset_count = i915_reset_engine_count(_priv->gpu_error,
+ engine);
 
if (USES_PPGTT(dev_priv)) {
int i;
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 01/21] drm/i915: Look for active requests earlier in the reset path

[Michel Thierry]

And store the active request so that we only search for it once.

v2: Check for request completion inside _prepare_engine, don't use
ECANCELED, remove unnecessary null checks (Chris).

v3: Capture active requests during reset_prepare and store it the
engine hangcheck obj.

v4: Rename commit, change i915_gem_reset_request to just confirm the
active_request is still incomplete, instead of engine_stalled (Chris).

v5: With style; pass the active request to gem_reset_engine, keep single
return in reset_prepare_engine (Chris).

v6: Moved before reset-engine code appears (Chris)

Suggested-by: Chris Wilson 
Reviewed-by: Chris Wilson  (v5)
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_gem.c | 14 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 31cbe78171a9..4722cd3567a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2820,7 +2820,7 @@ int i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
 
/* Ensure irq handler finishes, and not run again. */
for_each_engine(engine, dev_priv, id) {
-   struct drm_i915_gem_request *request;
+   struct drm_i915_gem_request *request = NULL;
 
/* Prevent the signaler thread from updating the request
 * state (by calling dma_fence_signal) as we are processing
@@ -2852,6 +2852,8 @@ int i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
if (request && request->fence.error == -EIO)
err = -EIO; /* Previous reset failed! */
}
+
+   engine->hangcheck.active_request = request;
}
 
i915_gem_revoke_fences(dev_priv);
@@ -2905,7 +2907,7 @@ static void engine_skip_context(struct 
drm_i915_gem_request *request)
 static bool i915_gem_reset_request(struct drm_i915_gem_request *request)
 {
/* Read once and return the resolution */
-   const bool guilty = engine_stalled(request->engine);
+   const bool guilty = !i915_gem_request_completed(request);
 
/* The guilty request will get skipped on a hung engine.
 *
@@ -2939,11 +2941,9 @@ static bool i915_gem_reset_request(struct 
drm_i915_gem_request *request)
return guilty;
 }
 
-static void i915_gem_reset_engine(struct intel_engine_cs *engine)
+static void i915_gem_reset_engine(struct intel_engine_cs *engine,
+ struct drm_i915_gem_request *request)
 {
-   struct drm_i915_gem_request *request;
-
-   request = i915_gem_find_active_request(engine);
if (request && i915_gem_reset_request(request)) {
DRM_DEBUG_DRIVER("resetting %s to restart from tail of request 
0x%x\n",
 engine->name, request->global_seqno);
@@ -2969,7 +2969,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
for_each_engine(engine, dev_priv, id) {
struct i915_gem_context *ctx;
 
-   i915_gem_reset_engine(engine);
+   i915_gem_reset_engine(engine, engine->hangcheck.active_request);
ctx = fetch_and_zero(>last_retired_context);
if (ctx)
engine->context_unpin(engine, ctx);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 6aa20ac8cde3..d33c93444c0d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -121,6 +121,7 @@ struct intel_engine_hangcheck {
unsigned long action_timestamp;
int deadlock;
struct intel_instdone instdone;
+   struct drm_i915_gem_request *active_request;
bool stalled;
 };
 
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 17/21] drm/i915: Watchdog timeout: IRQ handler for gen8+

[Michel Thierry]

*** General ***

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

The principle of the hang detection mechanism is as follows:

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

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

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

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

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

*** This patch introduces: ***

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

2. Watchdog specific register information.

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

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

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

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

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

v5: Rebased after RESET_ENGINEs flag.

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

Signed-off-by: Tomas Elf 
Signed-off-by: Ian Lister 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.h |  4 ++
 drivers/gpu/drm/i915/i915_irq.c | 19 +++--
 drivers/gpu/drm/i915/i915_reg.h |  6 +++
 drivers/gpu/drm/i915/intel_hangcheck.c  | 13 +--
 drivers/gpu/drm/i915/intel_lrc.c| 69 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 ++
 6 files changed, 108 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9869acacb548..94c7d856174c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1550,6 +1550,9 @@ struct i915_gpu_error {
 * inspect the bit and do the reset directly, otherwise the worker
 * waits for the struct_mutex.
 *
+* #I915_RESET_WATCHDOG - When hw detects a hang before us, we can use
+* I915_RESET_WATCHDOG to report the hang detection cause accurately.
+*
 * #I915_RESET_ENGINE[num_engines] - Since the driver doesn't need to
 * acquire the struct_mutex to reset an engine, we need an explicit
 * flag to prevent two concurrent reset attempts in the same engine.
@@ -1564,6 +1567,7 @@ struct i915_gpu_error {
unsigned long flags;
 #define I915_RESET_BACKOFF 0
 #define I915_RESET_HANDOFF 1
+#define 

[Intel-gfx] [PATCH v9 02/21] drm/i915: Update i915.reset to handle engine resets

[Michel Thierry]

In preparation for engine reset work update this parameter to handle more
than one type of reset. Default at the moment is still full gpu reset.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_params.c | 6 +++---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..045cadb77285 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,7 @@ struct i915_params i915 __read_mostly = {
.prefault_disable = 0,
.load_detect_test = 0,
.force_reset_modeset_test = 0,
-   .reset = true,
+   .reset = 1,
.error_capture = true,
.invert_brightness = 0,
.disable_display = 0,
@@ -115,8 +115,8 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
"Override/Ignore selection of SDVO panel mode in the VBT "
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
-module_param_named_unsafe(reset, i915.reset, bool, 0600);
-MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
+module_param_named_unsafe(reset, i915.reset, int, 0600);
+MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset 
[default], 2=engine reset)");
 
 #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
 module_param_named(error_capture, i915.error_capture, bool, 0600);
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..febbfdbd30bd 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -51,6 +51,7 @@
func(int, use_mmio_flip); \
func(int, mmio_debug); \
func(int, edp_vswing); \
+   func(int, reset); \
func(unsigned int, inject_load_failure); \
/* leave bools at the end to not create holes */ \
func(bool, alpha_support); \
@@ -60,7 +61,6 @@
func(bool, prefault_disable); \
func(bool, load_detect_test); \
func(bool, force_reset_modeset_test); \
-   func(bool, reset); \
func(bool, error_capture); \
func(bool, disable_display); \
func(bool, verbose_state_checks); \
-- 
2.11.0

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

[Intel-gfx] [PATCH v9 15/21] drm/i915/guc: Add support for reset engine using GuC commands

[Michel Thierry]

This patch adds per engine reset and recovery (TDR) support when GuC is
used to submit workloads to GPU.

In the case of i915 directly submission to ELSP, driver manages hang
detection, recovery and resubmission. With GuC submission these tasks
are shared between driver and GuC. i915 is still responsible for detecting
a hang, and when it does it only requests GuC to reset that Engine. GuC
internally manages acquiring forcewake and idling the engine before actually
resetting it.

Once the reset is successful, i915 takes over again and handles resubmission.
The scheduler in i915 knows which requests are pending so after resetting
a engine, pending workloads/requests are resubmitted again.

v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the
non-guc funtion names.

v3: Removed debug message about engine restarting from which request,
since the new baseline do it regardless of submission mode. (Chris)

Signed-off-by: Arun Siluvery 
Signed-off-by: Jeff McGee 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.c| 24 +++
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_guc_submission.c | 48 ++
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  6 
 drivers/gpu/drm/i915/intel_uc.h|  1 +
 drivers/gpu/drm/i915/intel_uncore.c|  5 
 6 files changed, 75 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 78df1477080a..32a580dc45de 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1940,11 +1940,21 @@ int i915_reset_engine(struct intel_engine_cs *engine)
 */
i915_gem_reset_engine(engine, active_request);
 
-   /* finally, reset engine */
-   ret = intel_gpu_reset(dev_priv, intel_engine_flag(engine));
-   if (ret) {
-   DRM_ERROR("Failed to reset %s, ret=%d\n", engine->name, ret);
-   goto out;
+   if (!dev_priv->guc.execbuf_client) {
+   /* finally, reset engine */
+   ret = intel_gpu_reset(dev_priv, intel_engine_flag(engine));
+   if (ret) {
+   DRM_ERROR("Failed to reset %s, ret=%d\n",
+ engine->name, ret);
+   goto out;
+   }
+   } else {
+   ret = i915_guc_reset_engine(engine);
+   if (ret) {
+   DRM_ERROR("GuC failed to reset %s, ret=%d\n",
+ engine->name, ret);
+   goto out;
+   }
}
 
i915_gem_reset_finish_engine(engine);
@@ -1958,6 +1968,10 @@ int i915_reset_engine(struct intel_engine_cs *engine)
if (ret)
goto out;
 
+   /* for guc too */
+   if (dev_priv->guc.execbuf_client)
+   i915_guc_submission_reenable_engine(engine);
+
error->reset_engine_count[engine->id]++;
 out:
return ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e657d56120d7..9869acacb548 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3105,6 +3105,7 @@ extern void i915_reset(struct drm_i915_private *dev_priv);
 extern int i915_reset_engine(struct intel_engine_cs *engine);
 extern bool intel_has_reset_engine(struct drm_i915_private *dev_priv);
 extern int intel_reset_guc(struct drm_i915_private *dev_priv);
+extern int i915_guc_reset_engine(struct intel_engine_cs *engine);
 extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine);
 extern void intel_hangcheck_init(struct drm_i915_private *dev_priv);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2bb18d24ed42..782ef09b90f5 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1362,6 +1362,25 @@ void i915_guc_submission_disable(struct drm_i915_private 
*dev_priv)
guc->execbuf_client = NULL;
 }
 
+void i915_guc_submission_reenable_engine(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   struct intel_guc *guc = _priv->guc;
+   struct i915_guc_client *client = guc->execbuf_client;
+   const int wqi_size = sizeof(struct guc_wq_item);
+   struct drm_i915_gem_request *rq;
+
+   GEM_BUG_ON(!client);
+   intel_guc_sample_forcewake(guc);
+
+   spin_lock_irq(>timeline->lock);
+   list_for_each_entry(rq, >timeline->requests, link) {
+   guc_client_update_wq_rsvd(client, wqi_size);
+   __i915_guc_submit(rq);
+   }
+   spin_unlock_irq(>timeline->lock);
+}
+
 /**
  * intel_guc_suspend() - notify GuC entering suspend state
  * @dev_priv:  i915 

[Intel-gfx] [PATCH v9 05/21] drm/i915: Add support for per engine reset recovery

[Michel Thierry]

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

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

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

v2: Rebase.
v3: s/*engine_reset*/*reset_engine*/; freeze engine and irqs before
calling i915_gem_reset_engine (Chris).
v4: Rebase, modify i915_gem_reset_prepare to use a ring mask and
reuse the function for reset_engine.
v5: intel_reset_engine_start/cancel instead of request/unrequest_reset.
v6: Clean up reset_engine function to not require mutex, i.e. no need to call
revoke/restore_fences and _retire_requests (Chris).
v7: Remove leftovers from v5, i.e. no need to disable irq, hold
forcewake or wakeup the handoff bit (Chris).
v8: engine_retire_requests should be (and it was) static; explain that
we have to re-init the engine after reset, which is why the init_hw call
is needed; check reset-in-progress flag (Chris).
v9: Rebase, include code to pass the active request to gem_reset_engine
(as it is already done in full reset). Remove unnecessary
intel_reset_engine_start/cancel, these are executed as part of the
reset.
v10: Rebase, use the right I915_RESET_ENGINE flag.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.c | 48 -
 drivers/gpu/drm/i915/i915_drv.h |  5 +++
 drivers/gpu/drm/i915/i915_gem.c | 96 +
 3 files changed, 109 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e4c4bc41c378..e8cb4617ecc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1909,11 +1909,55 @@ void i915_reset(struct drm_i915_private *dev_priv)
  *
  * Reset a specific GPU engine. Useful if a hang is detected.
  * Returns zero on successful reset or otherwise an error code.
+ *
+ * Procedure is:
+ *  - identifies the request that caused the hang and it is dropped
+ *  - reset engine (which will force the engine to idle)
+ *  - re-init/configure engine
  */
 int i915_reset_engine(struct intel_engine_cs *engine)
 {
-   /* FIXME: replace me with engine reset sequence */
-   return -ENODEV;
+   int ret;
+   struct drm_i915_private *dev_priv = engine->i915;
+   struct i915_gpu_error *error = _priv->gpu_error;
+   struct drm_i915_gem_request *active_request;
+
+   GEM_BUG_ON(!test_bit(I915_RESET_ENGINE + engine->id, >flags));
+
+   DRM_DEBUG_DRIVER("resetting %s\n", engine->name);
+
+   active_request = i915_gem_reset_prepare_engine(engine);
+   if (IS_ERR(active_request)) {
+   DRM_DEBUG_DRIVER("Previous reset failed, promote to full 
reset\n");
+   ret = PTR_ERR(active_request);
+   goto out;
+   }
+
+   /*
+* the request that caused the hang is stuck on elsp, we know the
+* active request and can drop it, adjust head to skip the offending
+* request to resume executing remaining requests in the queue.
+*/
+   i915_gem_reset_engine(engine, active_request);
+
+   /* finally, reset engine */
+   ret = intel_gpu_reset(dev_priv, intel_engine_flag(engine));
+   if (ret) {
+   DRM_ERROR("Failed to reset %s, ret=%d\n", engine->name, ret);
+   goto out;
+   }
+
+   i915_gem_reset_finish_engine(engine);
+
+   /*
+* The engine and its registers (and workarounds in case of render)
+* have been reset to their default values. Follow the init_ring
+* process to program RING_MODE, HWSP and re-enable submission.
+*/
+   ret = engine->init_hw(engine);
+
+out:
+   return ret;
 }
 
 static int i915_pm_suspend(struct device *kdev)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6101e76cc5ac..1612f4d97463 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3468,11 +3468,16 @@ static inline u32 i915_reset_count(struct 
i915_gpu_error *error)
return READ_ONCE(error->reset_count);
 }
 
+struct drm_i915_gem_request *
+i915_gem_reset_prepare_engine(struct intel_engine_cs *engine);
 int 

[Intel-gfx] [PATCH v9 00/21] Gen8+ engine-reset

[Michel Thierry]

These patches add the reset-engine feature from Gen8. This is also
referred to as Timeout detection and recovery (TDR). This complements to
the full gpu reset feature available in i915 but it only allows to reset a
particular engine instead of all engines thus providing a light weight
engine reset and recovery mechanism.

Thanks to recent changes merged, this implementation is now not only for
execlists, but for GuC based submission too; it is still limited from
Gen8 onwards. I have also included the changes for watchdog timeout
detection. The GuC related patches are functional, but can be seen as RFC.

Timeout detection relies on the existing hangcheck, which remains the same;
main changes are to the recovery mechanism. Once we detect a hang on a
particular engine we identify the request that caused the hang, skip the
request and adjust head pointers to allow the execution to proceed
normally. After some cleanup, submissions are restarted to process
remaining work queued to that engine.

If engine reset fails to recover engine correctly then we fallback to full
gpu reset.

We can argue about the effectiveness of reset-engine vs full reset when
more than one ring is hung, but the benefits of just resetting one engine
are reduced when the driver has to do it multiple times.

v2: ELSP queue request tracking and reset path changes to handle incomplete
requests during reset. Thanks to Chris Wilson for providing these patches.

v3: Let the waiter keep handling the full gpu reset if it already has the
lock; point out that GuC submission needs a different method to restart
workloads after the engine reset completes.

v4: Handle reset as 2 level resets, by first going to engine only and fall
backing to full/chip reset as needed, i.e. reset_engine will need the
struct_mutex.

v5: Rebased after reset flag split in 2, add GuC support, include watchdog
detection patches, addressing comments from prev RFC.

v6: Mutex-less reset engine. Updates in watchdog abi and guc whitelist &
register-restore fixes (including an old patch from Daniele).

v7: Removed leftovers from v5; review comments; ability to cancel the reset
if there's no active request.

v8: Moved patch looking for active request at the beginning of these series;
drop patch to request the engine's reset readinnes earlier since this is
done during the reset flow too; warn if hw fails to acknowledge reset
_readiness_.

v9: Support parallel resets (in different engines). Return type of reset
available in get-param ioctl. Watchdog timeout won't capture the error state.

Daniele Ceraolo Spurio (1):
  drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

Michel Thierry (20):
  drm/i915: Look for active requests earlier in the reset path
  drm/i915: Update i915.reset to handle engine resets
  drm/i915: Modify error handler for per engine hang recovery
  drm/i915: Include reset engine information in has_gpu_reset getparam
  drm/i915: Add support for per engine reset recovery
  drm/i915: Add engine reset count to error state
  drm/i915: Export per-engine reset count info to debugfs
  drm/i915: Carry on with reset even if hw engine is not ready
  drm/i915: Enable Engine reset and recovery support
  drm/i915: Add engine reset count in get-reset-stats ioctl
  drm/i915/selftests: reset engine self tests
  drm/i915/guc: Provide register list to be saved/restored during engine
reset
  drm/i915/guc: Rename the function that resets the GuC
  drm/i915/guc: Add support for reset engine using GuC commands
  drm/i915: Watchdog timeout: Pass GuC shared data structure during
param load
  drm/i915: Watchdog timeout: IRQ handler for gen8+
  drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+
  drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
  drm/i915: Watchdog timeout: Include threshold value in error state
  drm/i915: Watchdog timeout: Export media reset count from GuC to
debugfs

 drivers/gpu/drm/i915/i915_debugfs.c  |  43 +++
 drivers/gpu/drm/i915/i915_drv.c  |  76 +++
 drivers/gpu/drm/i915/i915_drv.h  |  92 +-
 drivers/gpu/drm/i915/i915_gem.c  | 104 +--
 drivers/gpu/drm/i915/i915_gem_context.c  | 107 +++-
 drivers/gpu/drm/i915/i915_gem_context.h  |   4 +
 drivers/gpu/drm/i915/i915_gpu_error.c|  15 ++-
 drivers/gpu/drm/i915/i915_guc_submission.c   | 138 ++--
 drivers/gpu/drm/i915/i915_irq.c  |  62 -
 drivers/gpu/drm/i915/i915_params.c   |   6 +-
 drivers/gpu/drm/i915/i915_params.h   |   2 +-
 drivers/gpu/drm/i915/i915_pci.c  |   5 +-
 drivers/gpu/drm/i915/i915_reg.h  |   6 +
 drivers/gpu/drm/i915/intel_engine_cs.c   |  65 +++---
 drivers/gpu/drm/i915/intel_guc_fwif.h|  27 +++-
 drivers/gpu/drm/i915/intel_guc_loader.c  |  11 ++
 

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

[Jani Nikula]

On Thu, 15 Jun 2017, Ander Conselvan De Oliveira  wrote:
> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
>> Hi Ander,
>> 
>> 
>> On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
>> > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
>> > > On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper  
>> > > wrote:
>> > > > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote:
>> > > > > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b.
>> > > > > 
>> > > > > New ddb allocation algorithm is a show stopper on my SKL system.
>> > > > > 
>> > > > > Besides not be able to get external DP 4k@60 (through USB type C),
>> > > > > It fully hang my screen when unplugging the USB type C.
>> > > > > 
>> > > > > Cc: Mahesh Kumar 
>> > > > > Cc: Maarten Lankhorst 
>> > > > > Cc: Matt Roper 
>> > > > > Signed-off-by: Rodrigo Vivi 
>> > > > 
>> > > > Is there a bugzilla entry with details/logs from the failure we can
>> > > > refer to?
>> > > 
>> > > nope, since I know it was working few weeks ago and then stopped
>> > > working I went directly
>> > > to bisect so I could get my system usable quickly again.
>> > > 
>> > > But yes, I need to open a proper bugzilla and provide logs.
>> > > Should we revert first and grab logs latter or we are going to try to
>> > > analyse logs and fix?
>> > > 
>> > > Anyways this is a big show stopper so I believe we revert at least
>> > > before next pull request.
>> > 
>> > This patch also causes artifacts in dual screen setups. All the scanlines 
>> > below
>> > the mouse cursor are wrong, sometimes containing a shade of gray and others
>> > repeating the image above. I've seen this in APL and GLK using DSI+HDMI,
>> > eDP+HDMI and DSI+DP. In the DP case, however, the screen goes blank and 
>> > reports
>> > lack of signal.
>> > 
>> > I've noticed fifo underrun messages. I compared the ddb allocation in GLK 
>> > with a
>> > working and non-working kernel, but they were the same.
>> 
>> your observation looks like one we observed in one of the Linux variant 
>> program.
>> There was an configuration where lower WM-level having higher DDB 
>> requirement than higher levels. Which was leading to lower WM levels 
>> getting disabled.
>> 
>> Can you please try with following patch to see if it's solving the problem.
>> 
>> https://patchwork.freedesktop.org/patch/161571/
>
> I tested that in my GLK, but it didn't help. Still getting artifacts following
> the mouse cursor.

If the revert helps the GLK case as well, please let's revert. We
generally waste too much time trying to get things fixed when the revert
and return to the drawing board is the way to go.

Rodrigo, please add the Bugzilla: reference and proper Fixes: line.

BR,
Jani.


>
> Ander
>
>> Rodrigo,
>> 
>> Can you please also check if this is the same reason for your failure. 
>> I'm arranging for a system with SKL+USB type-C DP 4K@60 & eDP. will 
>> debug this further.
>> 
>> -Mahesh
>> 
>> > 
>> > Ander
>> > > When you say you can't get DP 4k@60, are you seeing messages
>> > > > in dmesg about the setup being outside system watermark limitations or
>> > > > are you just getting a black screen?
>> > > 
>> > > just getting a blank screen on DP when plugging usb-c and a locked-up
>> > > screen on eDP when removing usb-c.
>> > > 
>> > > > 
>> > > > Matt
>> > > > 
>> > > > > ---
>> > > > >   drivers/gpu/drm/i915/intel_pm.c | 257 
>> > > > > +++-
>> > > > >   1 file changed, 98 insertions(+), 159 deletions(-)
>> > > > > 
>> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> > > > > b/drivers/gpu/drm/i915/intel_pm.c
>> > > > > index aa9d8ce..dc4275d 100644
>> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
>> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
>> > > > > @@ -4140,41 +4140,13 @@ int skl_check_pipe_max_pixel_rate(struct 
>> > > > > intel_crtc *intel_crtc,
>> > > > >minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
>> > > > >   }
>> > > > > 
>> > > > > -static void
>> > > > > -skl_enable_plane_wm_levels(const struct drm_i915_private *dev_priv,
>> > > > > -uint16_t plane_ddb,
>> > > > > -uint16_t max_level,
>> > > > > -struct skl_plane_wm *wm)
>> > > > > -{
>> > > > > - int level;
>> > > > > - /*
>> > > > > -  * Now enable all levels in WM structure which can be enabled
>> > > > > -  * using current DDB allocation
>> > > > > -  */
>> > > > > - for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
>> > > > > - struct skl_wm_level *level_wm = >wm[level];
>> > > > > -
>> > > > > - if (level > max_level || level_wm->plane_res_b == 0
>> > > > > -   || level_wm->plane_res_l >= 31
>> > > > > -   

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

[Sean Paul]

Hi Dave,
Here's this week's pull. Nothing worth noting beyond the onelines and summaries.

drm-misc-fixes-2017-06-15:
Driver Changes:
- dw-hdmi: Fix compilation error if REGMAP_MMIO not selected (Laurent)
- host1x: Fix incorrect return value (Christophe)
- tegra: Shore up idr API usage in tegra staging code (Dmitry)
- mgag200: Always use HiPri mode for G200e4v2 and limit max bandwidth (Mathieu)
- mxsfb: Ensure display can be lit up without bootloader initialization (Fabio)

Cc: Laurent Pinchart 
Cc: Christophe JAILLET 
Cc: Dmitry Osipenko 
Cc: Mathieu Larouche 
Cc: Fabio Estevam 

Cheers, Sean


The following changes since commit 6e88007e224ce51969ccf9afeec645146c638816:

  Merge branch 'vmwgfx-fixes-4.12' of 
git://people.freedesktop.org/~thomash/linux into drm-fixes (2017-06-09 13:12:02 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-06-15

for you to fetch changes up to 0f933328f018c118ded2035f12068bbdfdef399d:

  drm: mxsfb_crtc: Reset the eLCDIF controller (2017-06-15 14:26:24 -0400)


Driver Changes:
- dw-hdmi: Fix compilation error if REGMAP_MMIO not selected (Laurent)
- host1x: Fix incorrect return value (Christophe)
- tegra: Shore up idr API usage in tegra staging code (Dmitry)
- mgag200: Always use HiPri mode for G200e4v2 and limit max bandwidth (Mathieu)
- mxsfb: Ensure display can be lit up without bootloader initialization (Fabio)

Cc: Laurent Pinchart 
Cc: Christophe JAILLET 
Cc: Dmitry Osipenko 
Cc: Mathieu Larouche 
Cc: Fabio Estevam 


Christophe JAILLET (1):
  gpu: host1x: Fix error handling

Dmitry Osipenko (2):
  drm/tegra: Fix lockup on a use of staging API
  drm/tegra: Correct idr_alloc() minimum id

Fabio Estevam (1):
  drm: mxsfb_crtc: Reset the eLCDIF controller

Laurent Pinchart (1):
  drm: dw-hdmi: Fix compilation breakage by selecting REGMAP_MMIO

Mathieu Larouche (1):
  drm/mgag200: Fix to always set HiPri for G200e4 V2

 drivers/gpu/drm/bridge/synopsys/Kconfig |  1 +
 drivers/gpu/drm/mgag200/mgag200_mode.c  |  9 ++-
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c  | 42 +
 drivers/gpu/drm/tegra/drm.c | 22 -
 drivers/gpu/host1x/dev.c|  2 +-
 5 files changed, 57 insertions(+), 19 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

Re: [Intel-gfx] [PATCH IGT v2] Replace mentions of Intel GPU Tools by IGT GPU Tools

[Jani Nikula]

On Mon, 12 Jun 2017, Paul Kocialkowski  
wrote:
> Since IGT supports much more that testing for the Intel DRM driver, it
> was renamed to IGT GPU Tools instead of Intel GPU Tools.
>
> This replaces the remaining mentions of Intel GPU Tools in favor of
> IGT GPU tools.

There's still a bunch of "intel-gpu-tools" references left after this,
though not all of them need to be updated right now.

BR,
Jani.

>
> Signed-off-by: Paul Kocialkowski 
> ---
>  README   | 14 +++---
>  configure.ac |  2 +-
>  2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/README b/README
> index 26171a17..b860ca91 100644
> --- a/README
> +++ b/README
> @@ -1,18 +1,18 @@
> -Intel GPU Tools
> -===
> +IGT GPU Tools
> +=
>  
>  Description
>  ---
>  
> -Intel GPU Tools is a collection of tools for development and testing of the
> -Intel DRM driver. There are many macro-level test suites that get used 
> against
> +IGT GPU Tools is a collection of tools for development and testing of DRM
> +drivers. There are many macro-level test suites that get used against
>  the driver, including xtest, rendercheck, piglit, and oglconform, but 
> failures
>  from those can be difficult to track down to kernel changes, and many require
>  complicated build procedures or specific testing environments to get useful
> -results. Therefore, Intel GPU Tools includes low-level tools and tests
> -specifically for development and testing of the Intel DRM Driver.
> +results. Therefore, IGT GPU Tools includes low-level tools and tests
> +specifically for development and testing of DRM drivers.
>  
> -Intel GPU Tools is split into several sections:
> +IGT GPU Tools is split into several sections:
>  
>  benchmarks/
>   This is a collection of useful microbenchmarks that can be used to tune
> diff --git a/configure.ac b/configure.ac
> index 0418e605..efc81acb 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -379,7 +379,7 @@ AC_OUTPUT
>  
>  # Print a summary of the compilation
>  echo ""
> -echo "Intel GPU tools"
> +echo "IGT GPU Tools"
>  
>  echo ""
>  echo " • Tests:"

-- 
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] drm/i915: Make MMIO_PORT flexible.

[Jani Nikula]

On Tue, 13 Jun 2017, Ville Syrjälä  wrote:
> If there's lot of these and they get used a lot then I think the best
> option might be to add some kind of phy_port_offsets[] type of thing.
> Although it seems we'd need separate offsets for the group vs.
> individual lane access.

We have that for pipe_offsets, trans_offsets, palette_offsets, and
cursor_offsets in struct intel_device_info. That's fine for some things,
a bit awkward for some others. It's a bit heavy when there are just few
registers following some scheme.

> But for just a few registers that are not used that much and are
> purely CNL specific, then I guess just using _PICK for them might be
> OK.

Yes, we definitely want to avoid _PICK when ((a) + (port)*((b)-(a))) or
similar will do.

BR,
Jani.

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

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Extend PARAMS_FOR_EACH macro with more data

[Jani Nikula]

On Wed, 14 Jun 2017, Michal Wajdeczko  wrote:
> Currently our PARAMS_FOR_EACH macro contains only param type and name.
> We use this macro to define struct members, but later on we initialize
> this struct using handcrafted code, which leads in some cases to use
> mismatched value vs. type. Let's extend our root macro with param
> default value to keep them in sync. Also drop ; from the macro to allow
> more flexible usages.
>
> v2: Add unsafe tag (Chris)
> Add all other data to allow complete automation (Michal)
>
> As we now have all data in the param macro, we can automatically
> add 'default' info to the description and avoid any mismatches.
>
> v3: Fix printing default value in the description (Michal)
> v4: s/func/param and reorder items (Chris)
>
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   |   6 +-
>  drivers/gpu/drm/i915/i915_gpu_error.c |  10 +-
>  drivers/gpu/drm/i915/i915_params.c| 234 
> ++
>  drivers/gpu/drm/i915/i915_params.h| 182 +++---
>  4 files changed, 157 insertions(+), 275 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a6ba210..9fbba1e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -44,9 +44,9 @@ static __always_inline void seq_print_param(struct seq_file 
> *m,
>   seq_printf(m, "i915.%s=%s\n", name, yesno(*(const bool *)x));
>   else if (!__builtin_strcmp(type, "int"))
>   seq_printf(m, "i915.%s=%d\n", name, *(const int *)x);
> - else if (!__builtin_strcmp(type, "unsigned int"))
> + else if (!__builtin_strcmp(type, "uint"))
>   seq_printf(m, "i915.%s=%u\n", name, *(const unsigned int *)x);
> - else if (!__builtin_strcmp(type, "char *"))
> + else if (!__builtin_strcmp(type, "charp"))
>   seq_printf(m, "i915.%s=%s\n", name, *(const char **)x);
>   else
>   BUILD_BUG();
> @@ -66,7 +66,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
>  #undef PRINT_FLAG
>  
>   kernel_param_lock(THIS_MODULE);
> -#define PRINT_PARAM(T, x) seq_print_param(m, #x, #T, );
> +#define PRINT_PARAM(X, T, V, U, M, B, D) seq_print_param(m, #X, #T, );
>   I915_PARAMS_FOR_EACH(PRINT_PARAM);
>  #undef PRINT_PARAM
>   kernel_param_unlock(THIS_MODULE);
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index e18f350..000f733 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -555,9 +555,9 @@ static __always_inline void err_print_param(struct 
> drm_i915_error_state_buf *m,
>   err_printf(m, "i915.%s=%s\n", name, yesno(*(const bool *)x));
>   else if (!__builtin_strcmp(type, "int"))
>   err_printf(m, "i915.%s=%d\n", name, *(const int *)x);
> - else if (!__builtin_strcmp(type, "unsigned int"))
> + else if (!__builtin_strcmp(type, "uint"))
>   err_printf(m, "i915.%s=%u\n", name, *(const unsigned int *)x);
> - else if (!__builtin_strcmp(type, "char *"))
> + else if (!__builtin_strcmp(type, "charp"))
>   err_printf(m, "i915.%s=%s\n", name, *(const char **)x);
>   else
>   BUILD_BUG();
> @@ -566,7 +566,7 @@ static __always_inline void err_print_param(struct 
> drm_i915_error_state_buf *m,
>  static void err_print_params(struct drm_i915_error_state_buf *m,
>const struct i915_params *p)
>  {
> -#define PRINT(T, x) err_print_param(m, #x, #T, >x);
> +#define PRINT(X, T, V, U, M, B, D) err_print_param(m, #X, #T, >X);
>   I915_PARAMS_FOR_EACH(PRINT);
>  #undef PRINT
>  }
> @@ -860,7 +860,7 @@ void __i915_gpu_state_free(struct kref *error_ref)
>   kfree(error->overlay);
>   kfree(error->display);
>  
> -#define FREE(T, x) free_param(#T, >params.x);
> +#define FREE(X, T, V, U, M, B, D) free_param(#T, >params.X);
>   I915_PARAMS_FOR_EACH(FREE);
>  #undef FREE
>  
> @@ -1694,7 +1694,7 @@ static int capture(void *data)
>  error->i915->gt.last_init_time));
>  
>   error->params = i915;
> -#define DUP(T, x) dup_param(#T, >params.x);
> +#define DUP(X, T, V, U, M, B, D) dup_param(#T, >params.X);
>   I915_PARAMS_FOR_EACH(DUP);
>  #undef DUP
>  
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 6c27d33..547e517 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -26,230 +26,16 @@
>  #include "i915_drv.h"
>  
>  struct i915_params i915 __read_mostly = {
> - .modeset = -1,
> - .panel_ignore_lid = 1,
> - .semaphores = -1,
> - .lvds_channel_mode = 0,
> - .panel_use_ssc = -1,
> - .vbt_sdvo_panel_type = -1,
> - .enable_rc6 = 

Re: [Intel-gfx] Pixel-perfect frame checks in IGT Chamelium tests and CRC

[Jani Nikula]

On Thu, 15 Jun 2017, Lyude Paul  wrote:
> This being said however, I think we should have some better functions
> for the chamelium for doing frame comparisons, mainly something that
> does fuzzy frame comparisons for stuff like VGA.

Something that takes into account dithering might be of use too.

BR,
Jani.

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

[Intel-gfx] [PATCH 4.11 13/13] drm/i915: Disable decoupled MMIO

[Greg Kroah-Hartman]

4.11-stable review patch.  If anyone has any objections, please let me know.

--

From: Kai Chen 

commit 4c4c565513cca1c53a12956640b5915727431631 upstream.

The decoupled MMIO feature doesn't work as intended by HW team. Enabling
it with forcewake will only make debugging efforts more difficult, so
let's disable it.

Fixes: 85ee17ebeedd ("drm/i915/bxt: Broxton decoupled MMIO")
Cc: Zhe Wang 
Cc: Praveen Paneri 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Kai Chen 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Jani Nikula 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170523215812.18328-2-kai.c...@intel.com
(cherry picked from commit 0051c10acabb631cfd439eae73289e6e4c39b2b7)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/i915_pci.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -389,7 +389,6 @@ static const struct intel_device_info in
.has_hw_contexts = 1, \
.has_logical_ring_contexts = 1, \
.has_guc = 1, \
-   .has_decoupled_mmio = 1, \
.has_aliasing_ppgtt = 1, \
.has_full_ppgtt = 1, \
.has_full_48bit_ppgtt = 1, \


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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Actually attach the tv_format property to the SDVO connector

[Patchwork]

== Series Details ==

Series: drm/i915: Actually attach the tv_format property to the SDVO connector
URL   : https://patchwork.freedesktop.org/series/25860/
State : warning

== Summary ==

Series 25860v1 drm/i915: Actually attach the tv_format property to the SDVO 
connector
https://patchwork.freedesktop.org/api/1.0/series/25860/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup bad-nb-words-3:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup bad-pipe:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup bad-source:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup hang-read-crc-pipe-a:
fail   -> DMESG-FAIL (fi-skl-6700hq) fdo#101154 +15

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:463s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:484s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:594s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:561s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:485s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:594s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:431s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:421s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:462s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:498s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:512s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:575s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:575s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:489s
fi-skl-6700hqtotal:278  pass:224  dwarn:5   dfail:16  fail:11  skip:22  
time:470s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:512s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:498s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:508s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:627s
fi-snb-2600  total:278  pass:246  dwarn:0   dfail:0   fail:2   skip:29  
time:401s

b2e12a9ff1f20d8b4b7b2d25650858ea793396c2 drm-tip: 2017y-06m-15d-16h-45m-30s UTC 
integration manifest
364c8e8 drm/i915: Actually attach the tv_format property to the SDVO connector

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4962/
___
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: Make intel_digital_port_connected() work for any port

[Patchwork]

== Series Details ==

Series: drm/i915: Make intel_digital_port_connected() work for any port
URL   : https://patchwork.freedesktop.org/series/25859/
State : success

== Summary ==

Series 25859v1 drm/i915: Make intel_digital_port_connected() work for any port
https://patchwork.freedesktop.org/api/1.0/series/25859/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:469s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:486s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:552s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:587s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:433s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:421s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:465s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:517s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:571s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:578s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:482s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:445s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:519s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:515s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:512s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:630s
fi-snb-2600  total:278  pass:246  dwarn:0   dfail:0   fail:2   skip:29  
time:400s

b2e12a9ff1f20d8b4b7b2d25650858ea793396c2 drm-tip: 2017y-06m-15d-16h-45m-30s UTC 
integration manifest
a8a0ab9 drm/i915: Make intel_digital_port_connected() work for any port

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

[Imre Deak]

On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
> On Thu, Jun 15, 2017 at 9:30 AM, Imre Deak  wrote:
> > Yes, probably because i915 runtime PM as whole is disabled without DMC,
> > so we won't turn off display side power wells either; but D3 still won't
> > make a difference.
> >
> > The problem with not having DMC is that with that you'll prevent system
> > level power saving that is deeper package C states.
> 
> But if there are still power savings proved even without reaching the
> deeper package C states
> I believe it is worth allowing RPM to work without requiring DMC, no?!

Not if there is no good reason for not using DMC. It was decided early
on that we won't support that configuration since if you care about the
power saving provided by partially disabling things you probably also
care about the bigger power saving provided by DMC. So that is the
current state of the driver, enabling runtime PM without having DMC
loaded is not supported. Proper support for that would need to be added
after a justification why not to use the firmware.

> >
> > --Imre
> >
> > On Thu, Jun 15, 2017 at 07:16:25PM +0300, Atwood, Matthew S wrote:
> >> On ChromeOS I've tested a couple hundred thousand iterations, during
> >> their Power Load test (Google's battery claim test) an avg of 400 mW
> >> is saved when RPM is turned on with DMC missing vs both turned off, So
> >> i think D3 is definitely relevant even without DMC.
> >> 
> >> From: Deak, Imre
> >> Sent: Wednesday, June 14, 2017 1:17 PM
> >> To: Rodrigo Vivi
> >> Cc: Atwood, Matthew S; intel-gfx@lists.freedesktop.org; 
> >> marc...@google.com; Matt Atwood
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement 
> >> from DMC presence
> >>
> >> On Wed, Jun 14, 2017 at 01:02:27PM -0700, Rodrigo Vivi wrote:
> >> > On Wed, Jun 14, 2017 at 10:55 AM, Imre Deak  wrote:
> >> > > On Wed, Jun 14, 2017 at 08:40:55PM +0300, Atwood, Matthew S wrote:
> >> > >> intel_csr_load_program can fail (if not supported by SoC, or if file
> >> > >> is size 0)
> >> > >
> >> > > Those are really just sanity checks, they can't happen normally. We
> >> > > should actually convert them to be WARNs.
> >> > >
> >> > >> and theres no conditional that it succeeds before releasing
> >> > >> power_put on POWER_DOMAIN_INIT, enabling runtime PM.
> >> > >
> >> > > It can't fail during loading, HAS_CSR() is already checked in
> >> > > intel_csr_ucode_init() and dev_priv->csr.dmc_payload is checked right
> >> > > before calling intel_csr_load_program().
> >> > >
> >> > >> As long as the driver *thinks* it has a valid path to a DMC firmware
> >> > >> this will execute.
> >> > >>
> >> > >> "without DMC loaded we want to keep runtime PM disabled" - Why?
> >> > >
> >> > > There is no reason to support that configuration.
> >> >
> >> > What if someone doesn't really want to use DMC but still wants D3hot?
> >>
> >> D3 in itself won't result in power saving you need to enable DC6/9 for
> >> that. I'm not even sure if it's even valid to enter PCI D3 without
> >> enabling these states first. And for that you need the firmware.
> >>
> >> >
> >> > >
> >> > >> 
> >> > >> From: Deak, Imre
> >> > >> Sent: Wednesday, June 14, 2017 10:33 AM
> >> > >> To: Atwood, Matthew S
> >> > >> Cc: intel-gfx@lists.freedesktop.org; marc...@google.com; Matt Atwood
> >> > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM 
> >> > >> enablement from DMC presence
> >> > >>
> >> > >> On Wed, Jun 14, 2017 at 10:12:21AM -0700, matthew.s.atw...@intel.com 
> >> > >> wrote:
> >> > >> > From: Matt Atwood 
> >> > >> >
> >> > >> > Runtime PM is disabled when DMC firmware is not present. Runtime PM 
> >> > >> > is still
> >> > >> > enabled even if DMC firmware fails to load.
> >> > >>
> >> > >> Hm, that would be a bug, but I can't see how it can happen; could you
> >> > >> explain? We get a runtime PM reference in intel_csr_ucode_init() and
> >> > >> only put it if we loaded the firmware successfully.
> >> > >>
> >> > >> > This patch enables runtime PM to be enabled if DMC firmware is not 
> >> > >> > present.
> >> > >>
> >> > >> Without DMC loaded we want to keep runtime PM disabled.
> >> > >>
> >> > >> --Imre
> >> > >>
> >> > >> >
> >> > >> > Signed-off-by: Matt Atwood 
> >> > >> > 
> >> > >> > ---
> >> > >> >  drivers/gpu/drm/i915/intel_csr.c | 7 +++
> >> > >> >  1 file changed, 3 insertions(+), 4 deletions(-)
> >> > >> >
> >> > >> > diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> >> > >> > b/drivers/gpu/drm/i915/intel_csr.c
> >> > >> > index 965988f..3e4e705 100644
> >> > >> > --- a/drivers/gpu/drm/i915/intel_csr.c
> >> > >> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> >> > >> > @@ -411,8 +411,6 @@ static void csr_load_work_fn(struct work_struct 
> >> > >> > *work)
> >> > >> 

Re: [Intel-gfx] Pixel-perfect frame checks in IGT Chamelium tests and CRC

[Lyude Paul]

JFYI: Hardcoded CRCs are fine I'm pretty sure, but I might be wrong. As
well, put the chamelium in a metal box. The way the IO board is hooked
up is not really the way something running DP should be hooked up, so
it's very susceptible to electromagnetic interference. This will
usually cause CRC mismatches with DP.

This being said however, I think we should have some better functions
for the chamelium for doing frame comparisons, mainly something that
does fuzzy frame comparisons for stuff like VGA.

On Thu, 2017-06-15 at 16:57 +0300, Paul Kocialkowski wrote:
> Hi,
> 
> So far, there are two ways of testing for pixel-perfect frames using
> the
> Chamelium that are in IGT. The first one grabs a full frame from the
> Chamelium
> and compares it pixel-to-pixel with the cairo reference, which works
> well for
> DP/HDMI.
> 
> For VGA, this is probably not the case (because the link is
> analogue). In that
> case, I will look into implementing some fuzzy testing, probably
> inspired by
> what piglit (probably) does to compare output frames with references.
> 
> For pixel-perfect testing, grabbing a full frame and testing it with
> memcmp
> comes with a significant time penalty (about 2 seconds for 1080p).
> The Chamelium
> also provides a CRC mechanism that is faster and does not require
> retrieving the
> frame, that IGT currently also supports. It compares the CRC
> calculated by the
> Chamelium (implemented in the HDL) with a hardcoded reference value.
> 
> This approach currently fails for me (the values I get don't match
> the hardcoded
> reference). There are reasons why it is not really reasonable: fonts
> rendering
> may change between machines (e.g. use of anti-aliasing) and cairo
> version
> changes could introduce slight rendering changes too (not to mention
> changes in
> the test pattern itself). So instead of comparing the CRC with a
> hardcoded
> reference value, I think it would make a lot more sense to actually
> calculate
> the CRC based on the cairo image that is the actual reference (and
> that we
> should assume may change between runs/machines).
> 
> I am currently looking into the CRC calculation mechanism used by the
> Chamelium
> and trying to reproduce it in C code. Is this a known algorithm for
> which a
> reference/optimized implementation exists, or something custom that
> the folks
> over at Google came up with?
> 
> Any thoughts, comments or suggestions?
> 
> Cheers!
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Actually attach the tv_format property to the SDVO connector

[Rodrigo Vivi]

Reviewed-by: Rodrigo Vivi 

On Thu, Jun 15, 2017 at 10:23 AM,   wrote:
> From: Ville Syrjälä 
>
> Attach the tv_format property to the SDVO connector instead of passing
> a '0' in place of the pointer to the property. This got broken when
> the SDVO connector properties were converted to atomic.
>
> We can thank sparse for catching this:
> drivers/gpu/drm/i915/intel_sdvo.c:2742:75: warning: Using plain integer as 
> NULL pointer
>
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Fixes: 630d30a4ee27 ("drm/i915: Convert intel_sdvo connector properties to 
> atomic.")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index f4329d20b6f6..3f8f30b412cd 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -2739,7 +2739,8 @@ static bool intel_sdvo_tv_create_property(struct 
> intel_sdvo *intel_sdvo,
> i, 
> tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
>
> intel_sdvo_connector->base.base.state->tv.mode = 
> intel_sdvo_connector->tv_format_supported[0];
> -   drm_object_attach_property(_sdvo_connector->base.base.base, 0, 
> 0);
> +   drm_object_attach_property(_sdvo_connector->base.base.base,
> +  intel_sdvo_connector->tv_format, 0);
> return true;
>
>  }
> --
> 2.13.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Actually attach the tv_format property to the SDVO connector

[ville . syrjala]

From: Ville Syrjälä 

Attach the tv_format property to the SDVO connector instead of passing
a '0' in place of the pointer to the property. This got broken when
the SDVO connector properties were converted to atomic.

We can thank sparse for catching this:
drivers/gpu/drm/i915/intel_sdvo.c:2742:75: warning: Using plain integer as NULL 
pointer

Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Fixes: 630d30a4ee27 ("drm/i915: Convert intel_sdvo connector properties to 
atomic.")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index f4329d20b6f6..3f8f30b412cd 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2739,7 +2739,8 @@ static bool intel_sdvo_tv_create_property(struct 
intel_sdvo *intel_sdvo,
i, 
tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
 
intel_sdvo_connector->base.base.state->tv.mode = 
intel_sdvo_connector->tv_format_supported[0];
-   drm_object_attach_property(_sdvo_connector->base.base.base, 0, 0);
+   drm_object_attach_property(_sdvo_connector->base.base.base,
+  intel_sdvo_connector->tv_format, 0);
return true;
 
 }
-- 
2.13.0

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

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

[Rodrigo Vivi]

On Thu, Jun 15, 2017 at 9:30 AM, Imre Deak  wrote:
> Yes, probably because i915 runtime PM as whole is disabled without DMC,
> so we won't turn off display side power wells either; but D3 still won't
> make a difference.
>
> The problem with not having DMC is that with that you'll prevent system
> level power saving that is deeper package C states.

But if there are still power savings proved even without reaching the
deeper package C states
I believe it is worth allowing RPM to work without requiring DMC, no?!


>
> --Imre
>
> On Thu, Jun 15, 2017 at 07:16:25PM +0300, Atwood, Matthew S wrote:
>> On ChromeOS I've tested a couple hundred thousand iterations, during
>> their Power Load test (Google's battery claim test) an avg of 400 mW
>> is saved when RPM is turned on with DMC missing vs both turned off, So
>> i think D3 is definitely relevant even without DMC.
>> 
>> From: Deak, Imre
>> Sent: Wednesday, June 14, 2017 1:17 PM
>> To: Rodrigo Vivi
>> Cc: Atwood, Matthew S; intel-gfx@lists.freedesktop.org; marc...@google.com; 
>> Matt Atwood
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement 
>> from DMC presence
>>
>> On Wed, Jun 14, 2017 at 01:02:27PM -0700, Rodrigo Vivi wrote:
>> > On Wed, Jun 14, 2017 at 10:55 AM, Imre Deak  wrote:
>> > > On Wed, Jun 14, 2017 at 08:40:55PM +0300, Atwood, Matthew S wrote:
>> > >> intel_csr_load_program can fail (if not supported by SoC, or if file
>> > >> is size 0)
>> > >
>> > > Those are really just sanity checks, they can't happen normally. We
>> > > should actually convert them to be WARNs.
>> > >
>> > >> and theres no conditional that it succeeds before releasing
>> > >> power_put on POWER_DOMAIN_INIT, enabling runtime PM.
>> > >
>> > > It can't fail during loading, HAS_CSR() is already checked in
>> > > intel_csr_ucode_init() and dev_priv->csr.dmc_payload is checked right
>> > > before calling intel_csr_load_program().
>> > >
>> > >> As long as the driver *thinks* it has a valid path to a DMC firmware
>> > >> this will execute.
>> > >>
>> > >> "without DMC loaded we want to keep runtime PM disabled" - Why?
>> > >
>> > > There is no reason to support that configuration.
>> >
>> > What if someone doesn't really want to use DMC but still wants D3hot?
>>
>> D3 in itself won't result in power saving you need to enable DC6/9 for
>> that. I'm not even sure if it's even valid to enter PCI D3 without
>> enabling these states first. And for that you need the firmware.
>>
>> >
>> > >
>> > >> 
>> > >> From: Deak, Imre
>> > >> Sent: Wednesday, June 14, 2017 10:33 AM
>> > >> To: Atwood, Matthew S
>> > >> Cc: intel-gfx@lists.freedesktop.org; marc...@google.com; Matt Atwood
>> > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM 
>> > >> enablement from DMC presence
>> > >>
>> > >> On Wed, Jun 14, 2017 at 10:12:21AM -0700, matthew.s.atw...@intel.com 
>> > >> wrote:
>> > >> > From: Matt Atwood 
>> > >> >
>> > >> > Runtime PM is disabled when DMC firmware is not present. Runtime PM 
>> > >> > is still
>> > >> > enabled even if DMC firmware fails to load.
>> > >>
>> > >> Hm, that would be a bug, but I can't see how it can happen; could you
>> > >> explain? We get a runtime PM reference in intel_csr_ucode_init() and
>> > >> only put it if we loaded the firmware successfully.
>> > >>
>> > >> > This patch enables runtime PM to be enabled if DMC firmware is not 
>> > >> > present.
>> > >>
>> > >> Without DMC loaded we want to keep runtime PM disabled.
>> > >>
>> > >> --Imre
>> > >>
>> > >> >
>> > >> > Signed-off-by: Matt Atwood 
>> > >> > 
>> > >> > ---
>> > >> >  drivers/gpu/drm/i915/intel_csr.c | 7 +++
>> > >> >  1 file changed, 3 insertions(+), 4 deletions(-)
>> > >> >
>> > >> > diff --git a/drivers/gpu/drm/i915/intel_csr.c 
>> > >> > b/drivers/gpu/drm/i915/intel_csr.c
>> > >> > index 965988f..3e4e705 100644
>> > >> > --- a/drivers/gpu/drm/i915/intel_csr.c
>> > >> > +++ b/drivers/gpu/drm/i915/intel_csr.c
>> > >> > @@ -411,8 +411,6 @@ static void csr_load_work_fn(struct work_struct 
>> > >> > *work)
>> > >> >   if (dev_priv->csr.dmc_payload) {
>> > >> >   intel_csr_load_program(dev_priv);
>> > >> >
>> > >> > - intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
>> > >> > -
>> > >> >   DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
>> > >> >dev_priv->csr.fw_path,
>> > >> >CSR_VERSION_MAJOR(csr->version),
>> > >> > @@ -420,10 +418,11 @@ static void csr_load_work_fn(struct work_struct 
>> > >> > *work)
>> > >> >   } else {
>> > >> >   dev_notice(dev_priv->drm.dev,
>> > >> >  "Failed to load DMC firmware"
>> > >> > -" [" FIRMWARE_URL "],"
>> > >> > -

[Intel-gfx] [PATCH] drm/i915: Make intel_digital_port_connected() work for any port

[ville . syrjala]

From: Ville Syrjälä 

Add the missing port A handling to intel_digital_port_connected()
and also separate SPT from the CPT/LPT code a bit.

Cc: Manasi Navare 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 83 ++---
 1 file changed, 70 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 64fa774c855b..bca4ac12f950 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4418,8 +4418,6 @@ static bool ibx_digital_port_connected(struct 
drm_i915_private *dev_priv,
u32 bit;
 
switch (port->port) {
-   case PORT_A:
-   return true;
case PORT_B:
bit = SDE_PORTB_HOTPLUG;
break;
@@ -4443,8 +4441,6 @@ static bool cpt_digital_port_connected(struct 
drm_i915_private *dev_priv,
u32 bit;
 
switch (port->port) {
-   case PORT_A:
-   return true;
case PORT_B:
bit = SDE_PORTB_HOTPLUG_CPT;
break;
@@ -4454,12 +4450,28 @@ static bool cpt_digital_port_connected(struct 
drm_i915_private *dev_priv,
case PORT_D:
bit = SDE_PORTD_HOTPLUG_CPT;
break;
+   default:
+   MISSING_CASE(port->port);
+   return false;
+   }
+
+   return I915_READ(SDEISR) & bit;
+}
+
+static bool spt_digital_port_connected(struct drm_i915_private *dev_priv,
+  struct intel_digital_port *port)
+{
+   u32 bit;
+
+   switch (port->port) {
+   case PORT_A:
+   bit = SDE_PORTA_HOTPLUG_SPT;
+   break;
case PORT_E:
bit = SDE_PORTE_HOTPLUG_SPT;
break;
default:
-   MISSING_CASE(port->port);
-   return false;
+   return cpt_digital_port_connected(dev_priv, port);
}
 
return I915_READ(SDEISR) & bit;
@@ -4511,6 +4523,42 @@ static bool gm45_digital_port_connected(struct 
drm_i915_private *dev_priv,
return I915_READ(PORT_HOTPLUG_STAT) & bit;
 }
 
+static bool ilk_digital_port_connected(struct drm_i915_private *dev_priv,
+  struct intel_digital_port *port)
+{
+   if (port->port == PORT_A)
+   return I915_READ(DEISR) & DE_DP_A_HOTPLUG;
+   else
+   return ibx_digital_port_connected(dev_priv, port);
+}
+
+static bool snb_digital_port_connected(struct drm_i915_private *dev_priv,
+  struct intel_digital_port *port)
+{
+   if (port->port == PORT_A)
+   return I915_READ(DEISR) & DE_DP_A_HOTPLUG;
+   else
+   return cpt_digital_port_connected(dev_priv, port);
+}
+
+static bool ivb_digital_port_connected(struct drm_i915_private *dev_priv,
+  struct intel_digital_port *port)
+{
+   if (port->port == PORT_A)
+   return I915_READ(DEISR) & DE_DP_A_HOTPLUG_IVB;
+   else
+   return cpt_digital_port_connected(dev_priv, port);
+}
+
+static bool bdw_digital_port_connected(struct drm_i915_private *dev_priv,
+  struct intel_digital_port *port)
+{
+   if (port->port == PORT_A)
+   return I915_READ(GEN8_DE_PORT_ISR) & GEN8_PORT_DP_A_HOTPLUG;
+   else
+   return cpt_digital_port_connected(dev_priv, port);
+}
+
 static bool bxt_digital_port_connected(struct drm_i915_private *dev_priv,
   struct intel_digital_port 
*intel_dig_port)
 {
@@ -4547,16 +4595,25 @@ static bool bxt_digital_port_connected(struct 
drm_i915_private *dev_priv,
 bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
  struct intel_digital_port *port)
 {
-   if (HAS_PCH_IBX(dev_priv))
-   return ibx_digital_port_connected(dev_priv, port);
-   else if (HAS_PCH_SPLIT(dev_priv))
-   return cpt_digital_port_connected(dev_priv, port);
+   if (HAS_GMCH_DISPLAY(dev_priv)) {
+   if (IS_GM45(dev_priv))
+   return gm45_digital_port_connected(dev_priv, port);
+   else
+   return g4x_digital_port_connected(dev_priv, port);
+   }
+
+   if (IS_GEN5(dev_priv))
+   return ilk_digital_port_connected(dev_priv, port);
+   else if (IS_GEN6(dev_priv))
+   return snb_digital_port_connected(dev_priv, port);
+   else if (IS_GEN7(dev_priv))
+   return ivb_digital_port_connected(dev_priv, port);
+   else if (IS_GEN8(dev_priv))
+   return bdw_digital_port_connected(dev_priv, port);
else if (IS_GEN9_LP(dev_priv))
return bxt_digital_port_connected(dev_priv, port);
-   else if 

Re: [Intel-gfx] [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Sharma, Shashank]

Yes, we should check for features, not for some standard version that
implements some/all of those features. But not convinced we need any
featur flags for the other things you listed. Aren't we already doing
all those things anyway?


Yep, I realized you will come back with this point, while typing these 
examples :-).
Ok then, I will add a flag which sounds more like ycbcr_420_supported or 
so.


Regards
Shashank
On 6/15/2017 10:29 PM, Ville Syrjälä wrote:

On Thu, Jun 15, 2017 at 10:18:40PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 6/15/2017 9:42 PM, Ville Syrjälä wrote:

On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 6/15/2017 8:13 PM, Ville Syrjälä wrote:

On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.

These blocks are:

- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.

- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.

This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
 an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Emil Velikov 

V2: Addressed
   Review comments from Emil:
   - Use 1ULL< 64 modes in capability map block.
   - Use y420cmdb in function names and macros while dealing with vcb
 to be aligned with spec.
   - Move the display information parsing block ahead of mode parsing
 blocks.

V3: Addressed design/review comments from Ville
   - Do not add flags in video modes, else we have to expose them to user
   - There should not be a UABI change, and kernel should detect the
 choice of the output based on type of mode, and the bitmaps.
   - Use standard bitops from kernel bitmap header, instead of calculating
 bit positions manually.

Signed-off-by: Shashank Sharma 
---
drivers/gpu/drm/drm_edid.c  | 193 
++--
include/drm/drm_connector.h |  23 ++
2 files changed, 211 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6fd8a98..4953f87 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK   0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420   0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
#define EDID_BASIC_AUDIO(1 << 6)
#define EDID_CEA_YCRCB444   (1 << 5)
#define EDID_CEA_YCRCB422   (1 << 4)
@@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return newmode;
}

+/*

+ * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * CEA-861-F has added a new video block called YCBCR 420 Video
+ * Data Block (ycbcr 420 vdb). This block contains modes which
+ * support YCBCR 420 HDMI output (only YCBCR 420). This function
+ * parses the block and adds these modes into connector's mode list.

Seems a bit verbose. Maybe something like:
"Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
which contains modes which only support YCbCr 4:2:0 output."

Got it.

+ */
+static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
+  const u8 *svds, u8 svds_len)

Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
shorter and match the terminology in the spec. Same for y420cmdb.

Got it.

+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *newmode;

This variable can be moved into the loop scope.

Ok.

+   struct drm_display_info 

Re: [Intel-gfx] [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Ville Syrjälä]

On Thu, Jun 15, 2017 at 10:18:40PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/15/2017 9:42 PM, Ville Syrjälä wrote:
> > On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
> >>> On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
>  HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
>  CEA-861-F adds two new blocks in EDID's CEA extension blocks,
>  to provide information about sink's YCBCR420 output capabilities.
> 
>  These blocks are:
> 
>  - YCBCR420vdb(YCBCR 420 video data block):
>  This block contains VICs of video modes, which can be sopported only
>  in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
>  SVD block, valid for YCBCR420 modes only.
> 
>  - YCBCR420cmdb(YCBCR 420 capability map data block):
>  This block gives information about video modes which can support
>  YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
>  block contains a bitmap index of normal svd videomodes, which can
>  support YCBCR420 output too.
>  So if bit 0 from first vcb byte is set, first video mode in the svd
>  list can support YCBCR420 output too. Bit 1 means second video mode
>  from svd list can support YCBCR420 output too, and so on.
> 
>  This patch adds two bitmaps in display's hdmi_info structure, one each
>  for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
>  adds:
>  - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
>  an entry in the vdb_bitmap per vic.
>  - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
> 
>  Cc: Ville Syrjala 
>  Cc: Jose Abreu 
>  Cc: Emil Velikov 
> 
>  V2: Addressed
>    Review comments from Emil:
>    - Use 1ULL<    - Use the suggested method for updating dbmap.
>    - Add documentation for YCBCR420_vcb_map to fix kbuild warning.
> 
>    Review comments from Ville:
>    - Do not expose the YCBCR420 flags in uabi layer, keep it internal.
>    - Save a map of YCBCR420 modes for future reference.
>    - Check db length before trying to parse extended tag.
>    - Add a warning if there are > 64 modes in capability map block.
>    - Use y420cmdb in function names and macros while dealing with vcb
>  to be aligned with spec.
>    - Move the display information parsing block ahead of mode parsing
>  blocks.
> 
>  V3: Addressed design/review comments from Ville
>    - Do not add flags in video modes, else we have to expose them to 
>  user
>    - There should not be a UABI change, and kernel should detect the
>  choice of the output based on type of mode, and the bitmaps.
>    - Use standard bitops from kernel bitmap header, instead of 
>  calculating
>  bit positions manually.
> 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/drm_edid.c  | 193 
>  ++--
> include/drm/drm_connector.h |  23 ++
> 2 files changed, 211 insertions(+), 5 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>  index 6fd8a98..4953f87 100644
>  --- a/drivers/gpu/drm/drm_edid.c
>  +++ b/drivers/gpu/drm/drm_edid.c
>  @@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector 
>  *connector, struct edid *edid,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK 0x04
>  -#define VIDEO_CAPABILITY_BLOCK  0x07
>  +#define VIDEO_CAPABILITY_BLOCK 0x07
>  +#define VIDEO_DATA_BLOCK_4200x0E
>  +#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
> #define EDID_BASIC_AUDIO  (1 << 6)
> #define EDID_CEA_YCRCB444 (1 << 5)
> #define EDID_CEA_YCRCB422 (1 << 4)
>  @@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct 
>  drm_connector *connector,
>   return newmode;
> }
> 
>  +/*
>  + * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
>  + * @connector: connector corresponding to the HDMI sink
>  + * @svds: start of the data block of CEA YCBCR 420 VDB
>  + * @len: length of the CEA YCBCR 420 VDB
>  + *
>  + * CEA-861-F has added a new video block called YCBCR 420 Video
>  + * Data Block (ycbcr 420 vdb). This block contains modes which
>  + * support YCBCR 420 HDMI output (only YCBCR 420). This function
>  + * parses the block and adds these modes into connector's mode list.
> >>> Seems a bit verbose. Maybe something like:
> >>> "Parse the 

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Trim struct_mutex usage for kms

[Maarten Lankhorst]

Op 15-06-17 om 10:25 schreef Chris Wilson:
> Reduce acquisition of struct_mutex to the critical regions that must
> hold it; for KMS, we need struct_mutex currently only for the purpose of
> pinning/unpinning the framebuffer's VMA into the global GTT. This allows
> us to avoid taking the struct_mutex when disabling the CRTC (i.e. NULL
> framebuffer objects) before a reset. (Not yet achieving the full goal of
> avoiding the strut_mutex nesting, but good enough to break the first
> half of the reset deadlock.)
>
> v2: Keep pages pinning inside struct_mutex for the moment.
>
> Signed-off-by: Chris Wilson 
> Cc: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 80 
> 
>  1 file changed, 36 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f9bf0d508053..b254094c689c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> 
> - if (!obj && !old_obj)
> - return 0;
^This needs to be a bugfix commit on its own, since it harmonizes fence waiting 
with drm_atomic_helper_wait_for_fences.


>   if (old_obj) {
>   struct drm_crtc_state *crtc_state =
>   drm_atomic_get_existing_crtc_state(new_state->state,
> @@ -13399,6 +13364,33 @@ intel_prepare_plane_fb(struct drm_plane *plane,
>   if (!obj)
>   return 0;
>  
> + ret = mutex_lock_interruptible(_priv->drm.struct_mutex);
> + if (ret) {
> + i915_gem_object_unpin_pages(obj);
Should be in patch 4?

Otherwise patches look ok. I can't comment on patch 3, but with comments fixed 
and assuming kms_cursor_legacy still works.. for patch 1, 2, 4:
Reviewed-by: Maarten Lankhorst 

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

Re: [Intel-gfx] [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Sharma, Shashank]

Regards

Shashank


On 6/15/2017 9:42 PM, Ville Syrjälä wrote:

On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 6/15/2017 8:13 PM, Ville Syrjälä wrote:

On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.

These blocks are:

- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.

- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.

This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Emil Velikov 

V2: Addressed
  Review comments from Emil:
  - Use 1ULL< 64 modes in capability map block.
  - Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
  - Move the display information parsing block ahead of mode parsing
blocks.

V3: Addressed design/review comments from Ville
  - Do not add flags in video modes, else we have to expose them to user
  - There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
  - Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.

Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c  | 193 
++--
   include/drm/drm_connector.h |  23 ++
   2 files changed, 211 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6fd8a98..4953f87 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
   #define VIDEO_BLOCK 0x02
   #define VENDOR_BLOCK0x03
   #define SPEAKER_BLOCK0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420   0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
   #define EDID_BASIC_AUDIO (1 << 6)
   #define EDID_CEA_YCRCB444(1 << 5)
   #define EDID_CEA_YCRCB422(1 << 4)
@@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return newmode;
   }
   
+/*

+ * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * CEA-861-F has added a new video block called YCBCR 420 Video
+ * Data Block (ycbcr 420 vdb). This block contains modes which
+ * support YCBCR 420 HDMI output (only YCBCR 420). This function
+ * parses the block and adds these modes into connector's mode list.

Seems a bit verbose. Maybe something like:
"Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
which contains modes which only support YCbCr 4:2:0 output."

Got it.

+ */
+static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
+  const u8 *svds, u8 svds_len)

Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
shorter and match the terminology in the spec. Same for y420cmdb.

Got it.

+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *newmode;

This variable can be moved into the loop scope.

Ok.

+   struct drm_display_info *info = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi;
+
+   for (i = 0; i < svds_len; i++) {
+   u8 vic = svds[i] & 0x7f;

What's the 0x7f here? Native bit stuff? I'm thinkign we probably want
some kind of svd_to_vic() function to make sure everyone deals with
this stuff correctly.

Current VICs are 1 < VIC < 108, so seven bits required to show a VIC.
This is inspired from
drm_mode_from_cea_vic_index().

+
+   newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
+   if (!newmode)
+

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Defer cleanup of active KMS state

[Maarten Lankhorst]

Op 15-06-17 om 10:25 schreef Chris Wilson:
> During cleanup we release the VMA of the previous framebuffer. This
> requires taking a struct_mutex, and potential recursion when handling a
> reset. A simple device here is to move that locking into its own work
> and we can avoid blocking on it for the reset by waiting on the flip
> completion (and not cleanup completion) instead. Ideally this reduces
> the duration of a blocking KMS operation by offloading the cleanup. Once
> again we dream of the legendary vblank worker.
>
> Signed-off-by: Chris Wilson 
> Cc: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 53 
> +---
>  1 file changed, 43 insertions(+), 10 deletions(-)
Will this still pass the kms_cursor_legacy tests?

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

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

[Imre Deak]

Yes, probably because i915 runtime PM as whole is disabled without DMC,
so we won't turn off display side power wells either; but D3 still won't
make a difference.

The problem with not having DMC is that with that you'll prevent system
level power saving that is deeper package C states.

--Imre

On Thu, Jun 15, 2017 at 07:16:25PM +0300, Atwood, Matthew S wrote:
> On ChromeOS I've tested a couple hundred thousand iterations, during
> their Power Load test (Google's battery claim test) an avg of 400 mW
> is saved when RPM is turned on with DMC missing vs both turned off, So
> i think D3 is definitely relevant even without DMC.
> 
> From: Deak, Imre
> Sent: Wednesday, June 14, 2017 1:17 PM
> To: Rodrigo Vivi
> Cc: Atwood, Matthew S; intel-gfx@lists.freedesktop.org; marc...@google.com; 
> Matt Atwood
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement 
> from DMC presence
> 
> On Wed, Jun 14, 2017 at 01:02:27PM -0700, Rodrigo Vivi wrote:
> > On Wed, Jun 14, 2017 at 10:55 AM, Imre Deak  wrote:
> > > On Wed, Jun 14, 2017 at 08:40:55PM +0300, Atwood, Matthew S wrote:
> > >> intel_csr_load_program can fail (if not supported by SoC, or if file
> > >> is size 0)
> > >
> > > Those are really just sanity checks, they can't happen normally. We
> > > should actually convert them to be WARNs.
> > >
> > >> and theres no conditional that it succeeds before releasing
> > >> power_put on POWER_DOMAIN_INIT, enabling runtime PM.
> > >
> > > It can't fail during loading, HAS_CSR() is already checked in
> > > intel_csr_ucode_init() and dev_priv->csr.dmc_payload is checked right
> > > before calling intel_csr_load_program().
> > >
> > >> As long as the driver *thinks* it has a valid path to a DMC firmware
> > >> this will execute.
> > >>
> > >> "without DMC loaded we want to keep runtime PM disabled" - Why?
> > >
> > > There is no reason to support that configuration.
> >
> > What if someone doesn't really want to use DMC but still wants D3hot?
> 
> D3 in itself won't result in power saving you need to enable DC6/9 for
> that. I'm not even sure if it's even valid to enter PCI D3 without
> enabling these states first. And for that you need the firmware.
> 
> >
> > >
> > >> 
> > >> From: Deak, Imre
> > >> Sent: Wednesday, June 14, 2017 10:33 AM
> > >> To: Atwood, Matthew S
> > >> Cc: intel-gfx@lists.freedesktop.org; marc...@google.com; Matt Atwood
> > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM 
> > >> enablement from DMC presence
> > >>
> > >> On Wed, Jun 14, 2017 at 10:12:21AM -0700, matthew.s.atw...@intel.com 
> > >> wrote:
> > >> > From: Matt Atwood 
> > >> >
> > >> > Runtime PM is disabled when DMC firmware is not present. Runtime PM is 
> > >> > still
> > >> > enabled even if DMC firmware fails to load.
> > >>
> > >> Hm, that would be a bug, but I can't see how it can happen; could you
> > >> explain? We get a runtime PM reference in intel_csr_ucode_init() and
> > >> only put it if we loaded the firmware successfully.
> > >>
> > >> > This patch enables runtime PM to be enabled if DMC firmware is not 
> > >> > present.
> > >>
> > >> Without DMC loaded we want to keep runtime PM disabled.
> > >>
> > >> --Imre
> > >>
> > >> >
> > >> > Signed-off-by: Matt Atwood 
> > >> > 
> > >> > ---
> > >> >  drivers/gpu/drm/i915/intel_csr.c | 7 +++
> > >> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> > >> > b/drivers/gpu/drm/i915/intel_csr.c
> > >> > index 965988f..3e4e705 100644
> > >> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > >> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > >> > @@ -411,8 +411,6 @@ static void csr_load_work_fn(struct work_struct 
> > >> > *work)
> > >> >   if (dev_priv->csr.dmc_payload) {
> > >> >   intel_csr_load_program(dev_priv);
> > >> >
> > >> > - intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
> > >> > -
> > >> >   DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
> > >> >dev_priv->csr.fw_path,
> > >> >CSR_VERSION_MAJOR(csr->version),
> > >> > @@ -420,10 +418,11 @@ static void csr_load_work_fn(struct work_struct 
> > >> > *work)
> > >> >   } else {
> > >> >   dev_notice(dev_priv->drm.dev,
> > >> >  "Failed to load DMC firmware"
> > >> > -" [" FIRMWARE_URL "],"
> > >> > -" disabling runtime power management.\n");
> > >> > +" [" FIRMWARE_URL "]");
> > >> >   }
> > >> >
> > >> > + intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
> > >> > +
> > >> >   release_firmware(fw);
> > >> >  }
> > >> >
> > >> > --
> > >> > 2.7.4
> > >> >
> > >> > 

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

[Atwood, Matthew S]

On ChromeOS I've tested a couple hundred thousand iterations, during their 
Power Load test (Google's battery claim test) an avg of 400 mW is saved when 
RPM is turned on with DMC missing vs both turned off, So i think D3 is 
definitely relevant even without DMC.

From: Deak, Imre
Sent: Wednesday, June 14, 2017 1:17 PM
To: Rodrigo Vivi
Cc: Atwood, Matthew S; intel-gfx@lists.freedesktop.org; marc...@google.com; 
Matt Atwood
Subject: Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from 
DMC presence

On Wed, Jun 14, 2017 at 01:02:27PM -0700, Rodrigo Vivi wrote:
> On Wed, Jun 14, 2017 at 10:55 AM, Imre Deak  wrote:
> > On Wed, Jun 14, 2017 at 08:40:55PM +0300, Atwood, Matthew S wrote:
> >> intel_csr_load_program can fail (if not supported by SoC, or if file
> >> is size 0)
> >
> > Those are really just sanity checks, they can't happen normally. We
> > should actually convert them to be WARNs.
> >
> >> and theres no conditional that it succeeds before releasing
> >> power_put on POWER_DOMAIN_INIT, enabling runtime PM.
> >
> > It can't fail during loading, HAS_CSR() is already checked in
> > intel_csr_ucode_init() and dev_priv->csr.dmc_payload is checked right
> > before calling intel_csr_load_program().
> >
> >> As long as the driver *thinks* it has a valid path to a DMC firmware
> >> this will execute.
> >>
> >> "without DMC loaded we want to keep runtime PM disabled" - Why?
> >
> > There is no reason to support that configuration.
>
> What if someone doesn't really want to use DMC but still wants D3hot?

D3 in itself won't result in power saving you need to enable DC6/9 for
that. I'm not even sure if it's even valid to enter PCI D3 without
enabling these states first. And for that you need the firmware.

>
> >
> >> 
> >> From: Deak, Imre
> >> Sent: Wednesday, June 14, 2017 10:33 AM
> >> To: Atwood, Matthew S
> >> Cc: intel-gfx@lists.freedesktop.org; marc...@google.com; Matt Atwood
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement 
> >> from DMC presence
> >>
> >> On Wed, Jun 14, 2017 at 10:12:21AM -0700, matthew.s.atw...@intel.com wrote:
> >> > From: Matt Atwood 
> >> >
> >> > Runtime PM is disabled when DMC firmware is not present. Runtime PM is 
> >> > still
> >> > enabled even if DMC firmware fails to load.
> >>
> >> Hm, that would be a bug, but I can't see how it can happen; could you
> >> explain? We get a runtime PM reference in intel_csr_ucode_init() and
> >> only put it if we loaded the firmware successfully.
> >>
> >> > This patch enables runtime PM to be enabled if DMC firmware is not 
> >> > present.
> >>
> >> Without DMC loaded we want to keep runtime PM disabled.
> >>
> >> --Imre
> >>
> >> >
> >> > Signed-off-by: Matt Atwood 
> >> > 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_csr.c | 7 +++
> >> >  1 file changed, 3 insertions(+), 4 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> >> > b/drivers/gpu/drm/i915/intel_csr.c
> >> > index 965988f..3e4e705 100644
> >> > --- a/drivers/gpu/drm/i915/intel_csr.c
> >> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> >> > @@ -411,8 +411,6 @@ static void csr_load_work_fn(struct work_struct 
> >> > *work)
> >> >   if (dev_priv->csr.dmc_payload) {
> >> >   intel_csr_load_program(dev_priv);
> >> >
> >> > - intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
> >> > -
> >> >   DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
> >> >dev_priv->csr.fw_path,
> >> >CSR_VERSION_MAJOR(csr->version),
> >> > @@ -420,10 +418,11 @@ static void csr_load_work_fn(struct work_struct 
> >> > *work)
> >> >   } else {
> >> >   dev_notice(dev_priv->drm.dev,
> >> >  "Failed to load DMC firmware"
> >> > -" [" FIRMWARE_URL "],"
> >> > -" disabling runtime power management.\n");
> >> > +" [" FIRMWARE_URL "]");
> >> >   }
> >> >
> >> > + intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
> >> > +
> >> >   release_firmware(fw);
> >> >  }
> >> >
> >> > --
> >> > 2.7.4
> >> >
> >> > ___
> >> > Intel-gfx mailing list
> >> > Intel-gfx@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >>
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Ville Syrjälä]

On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
> > On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
> >> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> >> CEA-861-F adds two new blocks in EDID's CEA extension blocks,
> >> to provide information about sink's YCBCR420 output capabilities.
> >>
> >> These blocks are:
> >>
> >> - YCBCR420vdb(YCBCR 420 video data block):
> >> This block contains VICs of video modes, which can be sopported only
> >> in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
> >> SVD block, valid for YCBCR420 modes only.
> >>
> >> - YCBCR420cmdb(YCBCR 420 capability map data block):
> >> This block gives information about video modes which can support
> >> YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
> >> block contains a bitmap index of normal svd videomodes, which can
> >> support YCBCR420 output too.
> >> So if bit 0 from first vcb byte is set, first video mode in the svd
> >> list can support YCBCR420 output too. Bit 1 means second video mode
> >> from svd list can support YCBCR420 output too, and so on.
> >>
> >> This patch adds two bitmaps in display's hdmi_info structure, one each
> >> for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
> >> adds:
> >> - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
> >>an entry in the vdb_bitmap per vic.
> >> - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jose Abreu 
> >> Cc: Emil Velikov 
> >>
> >> V2: Addressed
> >>  Review comments from Emil:
> >>  - Use 1ULL< >>  - Use the suggested method for updating dbmap.
> >>  - Add documentation for YCBCR420_vcb_map to fix kbuild warning.
> >>
> >>  Review comments from Ville:
> >>  - Do not expose the YCBCR420 flags in uabi layer, keep it internal.
> >>  - Save a map of YCBCR420 modes for future reference.
> >>  - Check db length before trying to parse extended tag.
> >>  - Add a warning if there are > 64 modes in capability map block.
> >>  - Use y420cmdb in function names and macros while dealing with vcb
> >>to be aligned with spec.
> >>  - Move the display information parsing block ahead of mode parsing
> >>blocks.
> >>
> >> V3: Addressed design/review comments from Ville
> >>  - Do not add flags in video modes, else we have to expose them to user
> >>  - There should not be a UABI change, and kernel should detect the
> >>choice of the output based on type of mode, and the bitmaps.
> >>  - Use standard bitops from kernel bitmap header, instead of 
> >> calculating
> >>bit positions manually.
> >>
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_edid.c  | 193 
> >> ++--
> >>   include/drm/drm_connector.h |  23 ++
> >>   2 files changed, 211 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 6fd8a98..4953f87 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
> >> struct edid *edid,
> >>   #define VIDEO_BLOCK 0x02
> >>   #define VENDOR_BLOCK0x03
> >>   #define SPEAKER_BLOCK0x04
> >> -#define VIDEO_CAPABILITY_BLOCK0x07
> >> +#define VIDEO_CAPABILITY_BLOCK 0x07
> >> +#define VIDEO_DATA_BLOCK_420  0x0E
> >> +#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
> >>   #define EDID_BASIC_AUDIO (1 << 6)
> >>   #define EDID_CEA_YCRCB444(1 << 5)
> >>   #define EDID_CEA_YCRCB422(1 << 4)
> >> @@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct 
> >> drm_connector *connector,
> >>return newmode;
> >>   }
> >>   
> >> +/*
> >> + * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
> >> + * @connector: connector corresponding to the HDMI sink
> >> + * @svds: start of the data block of CEA YCBCR 420 VDB
> >> + * @len: length of the CEA YCBCR 420 VDB
> >> + *
> >> + * CEA-861-F has added a new video block called YCBCR 420 Video
> >> + * Data Block (ycbcr 420 vdb). This block contains modes which
> >> + * support YCBCR 420 HDMI output (only YCBCR 420). This function
> >> + * parses the block and adds these modes into connector's mode list.
> > Seems a bit verbose. Maybe something like:
> > "Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
> > which contains modes which only support YCbCr 4:2:0 output."
> Got it.
> >> + */
> >> +static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
> >> + const u8 *svds, u8 svds_len)
> > Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
> > shorter and match the terminology in the spec. 

Re: [Intel-gfx] [PATCH] drm/i915: fix ifnullfree.cocci warnings

[Chris Wilson]

Quoting kbuild test robot (2017-06-15 16:23:12)
> drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check 
> before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive 
> or usb_free_urb is not needed. Maybe consider reorganizing relevant code to 
> avoid passing NULL values.

It exists because it was a stepping towards the compare being not
against NULL.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Gerd Hoffmann]

  Hi,

> > +struct vfio_dmabuf_mgr_plane_info {
> > +   __u64 start;
> > +   __u64 drm_format_mod;
> > +   __u32 drm_format;
> > +   __u32 width;
> > +   __u32 height;
> > +   __u32 stride;
> > +   __u32 size;
> > +   __u32 x_pos;
> > +   __u32 y_pos;
> > +   __u32 padding;
> > +};
> > +
> 
> This structure is generic, can remove dmabuf from its name,
> vfio_plane_info or vfio_vgpu_surface_info since this will only be
> used
> by vgpu.

Agree.

> > +struct vfio_dmabuf_mgr_query_plane {
> > +   __u32 argsz;
> > +   __u32 flags;
> > +   struct vfio_dmabuf_mgr_plane_info plane_info;
> > +   __u32 plane_id;
> > +};
> > +
> > +#define VFIO_DMABUF_MGR_QUERY_PLANE _IO(VFIO_TYPE, VFIO_BASE + 15)
> > +
> 
> This same interface can be used to query surface/plane information
> for
> both, dmabuf and region, case. Here also 'DMABUF' can be removed and
> define flags if you want to differentiate query for 'dmabuf' and
> 'region'.

Hmm, any specific reason why you want use a ioctl for that?  I would
simply place a "struct vfio_dmabuf_mgr_plane_info" (or whatever the
final name will be) at the start of the region.

cheers,
  Gerd

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

[Intel-gfx] [PATCH] dim: allow setup to work with different usernames

[Lionel Landwerlin]

If your username on fd.o differs from your local username, you'll run
into issues while setting up dim.

Let's use regexp to filter remotes so it doesn't fail.

Signed-off-by: Lionel Landwerlin 
---
 dim | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/dim b/dim
index 89378033f472..a812320581c2 100755
--- a/dim
+++ b/dim
@@ -228,21 +228,22 @@ function url_to_remote # url
 {
local url remote
 
-   url="$1"
+   url=$1
+   login_url=$(echo $url | sed -e 's,ssh://,ssh://[a-zA-Z0-9]+@?,')
 
if [[ -z "$url" ]]; then
echoerr "$0 without url"
return 1
fi
 
-   remote=$(git remote -v | grep -m 1 "$url" | cut -f 1)
+   remote=$(git remote -v | grep -m 1 -E "$login_url" | cut -f 1)
 
if [[ -z "$remote" ]]; then
-   git_url=$(echo $url | sed -e 's/git\./anongit./' -e 
's/ssh:/git:/')
-   remote=$(git remote -v | grep -m 1 "$git_url" | cut -f 1)
+   git_url=$(echo $url | sed -e 's/git\./anongit./' -e 
's,ssh://[a-zA-Z0-9]+@?,git://,')
+   remote=$(git remote -v | grep -m 1 -E "$git_url" | cut -f 1)
 
if [[ -z "$remote" ]]; then
-   echoerr "No git remote for url $url or $git_url found 
in $(pwd)"
+   echoerr "No git remote for url $url, $login_url or 
$git_url found in $(pwd)"
echoerr "Please set it up using:"
echoerr "$ git remote add  $url"
echoerr "with a name of your choice."
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Sharma, Shashank]

Regards

Shashank


On 6/15/2017 8:13 PM, Ville Syrjälä wrote:

On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.

These blocks are:

- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.

- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.

This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
   an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Emil Velikov 

V2: Addressed
 Review comments from Emil:
 - Use 1ULL< 64 modes in capability map block.
 - Use y420cmdb in function names and macros while dealing with vcb
   to be aligned with spec.
 - Move the display information parsing block ahead of mode parsing
   blocks.

V3: Addressed design/review comments from Ville
 - Do not add flags in video modes, else we have to expose them to user
 - There should not be a UABI change, and kernel should detect the
   choice of the output based on type of mode, and the bitmaps.
 - Use standard bitops from kernel bitmap header, instead of calculating
   bit positions manually.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c  | 193 ++--
  include/drm/drm_connector.h |  23 ++
  2 files changed, 211 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6fd8a98..4953f87 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
  #define VIDEO_BLOCK 0x02
  #define VENDOR_BLOCK0x03
  #define SPEAKER_BLOCK 0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420   0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
  #define EDID_BASIC_AUDIO  (1 << 6)
  #define EDID_CEA_YCRCB444 (1 << 5)
  #define EDID_CEA_YCRCB422 (1 << 4)
@@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return newmode;
  }
  
+/*

+ * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * CEA-861-F has added a new video block called YCBCR 420 Video
+ * Data Block (ycbcr 420 vdb). This block contains modes which
+ * support YCBCR 420 HDMI output (only YCBCR 420). This function
+ * parses the block and adds these modes into connector's mode list.

Seems a bit verbose. Maybe something like:
"Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
which contains modes which only support YCbCr 4:2:0 output."

Got it.

+ */
+static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
+  const u8 *svds, u8 svds_len)

Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
shorter and match the terminology in the spec. Same for y420cmdb.

Got it.

+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *newmode;

This variable can be moved into the loop scope.

Ok.

+   struct drm_display_info *info = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi;
+
+   for (i = 0; i < svds_len; i++) {
+   u8 vic = svds[i] & 0x7f;

What's the 0x7f here? Native bit stuff? I'm thinkign we probably want
some kind of svd_to_vic() function to make sure everyone deals with
this stuff correctly.
Current VICs are 1 < VIC < 108, so seven bits required to show a VIC. 
This is inspired from

drm_mode_from_cea_vic_index().

+
+   newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
+   if (!newmode)
+   break;
+   /*
+* ycbcr420_vdb_modes is a fix position 128 bit bitmap.
+* Every bit here represents a VIC, 

[Intel-gfx] [PATCH] drm/i915: fix ifnullfree.cocci warnings

[kbuild test robot]

drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check before 
freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or 
usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid 
passing NULL values.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

Signed-off-by: Fengguang Wu 
---

 i915_gem_execbuffer.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -296,8 +296,7 @@ static void eb_destroy(struct i915_execb
 
i915_gem_context_put(eb->ctx);
 
-   if (eb->buckets)
-   kfree(eb->buckets);
+   kfree(eb->buckets);
 }
 
 static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [drm-intel:for-linux-next 2/3] drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   8c45cec48e5871f93e56650f7e476d4ea7174a0e
commit: d55495b4dcce2efb4656edfe211eb0bfb27c3387 [2/3] drm/i915: Use 
vma->exec_entry as our double-entry placeholder


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check 
>> before freeing functions like kfree, debugfs_remove, 
>> debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider 
>> reorganizing relevant code to avoid passing NULL values.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

Hi Dave, a GVT fix and a couple of rotation related fixes.

BR,
Jani.

The following changes since commit ef6c4d75e35345f8f362d6754bcd9a28292a897c:

  drm/i915: fix warning for unused variable (2017-06-08 17:09:44 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-06-15

for you to fetch changes up to c380f681245d7ae57f17d9ebbbe8f8f1557ee1fb:

  drm/i915: Fix GVT-g PVINFO version compatibility check (2017-06-13 11:19:22 
+0300)


drm/i915 fixes for v4.12-rc6


Ville Syrjälä (2):
  drm/i915: Fix scaling check for 90/270 degree plane rotation
  drm/i915: Fix SKL+ watermarks for 90/270 rotation

Zhenyu Wang (1):
  drm/i915: Fix GVT-g PVINFO version compatibility check

 drivers/gpu/drm/i915/i915_pvinfo.h   |  8 ++--
 drivers/gpu/drm/i915/i915_vgpu.c | 10 --
 drivers/gpu/drm/i915/intel_display.c | 14 --
 drivers/gpu/drm/i915/intel_pm.c  | 36 
 4 files changed, 38 insertions(+), 30 deletions(-)

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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Kirti Wankhede]

On 6/15/2017 1:30 PM, Xiaoguang Chen wrote:
> Here we defined a new ioctl to create a fd for a vfio device based on
> the input type. Now only one type is supported that is a dma-buf
> management fd.
> Two ioctls are defined for the dma-buf management fd: query the vfio
> vgpu's plane information and create a dma-buf for a plane.
> 

I had suggested how we can use common structures for both type of ways
to query surface on v6 version of your patch,
https://lkml.org/lkml/2017/6/1/890


> Signed-off-by: Xiaoguang Chen 
> ---
>  include/uapi/linux/vfio.h | 57 
> +++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index ae46105..7d86101 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -502,6 +502,63 @@ struct vfio_pci_hot_reset {
>  
>  #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE, VFIO_BASE + 13)
>  
> +/**
> + * VFIO_DEVICE_GET_FD - _IO(VFIO_TYPE, VFIO_BASE + 14, __u32)
> + *
> + * Create a fd for a vfio device based on the input type
> + * Vendor driver should handle this ioctl to create a fd and manage the
> + * life cycle of this fd.
> + *
> + * Return: a fd if vendor support that type, -errno if not supported
> + */
> +
> +#define VFIO_DEVICE_GET_FD   _IO(VFIO_TYPE, VFIO_BASE + 14)
> +
> +#define VFIO_DEVICE_DMABUF_MGR_FD0 /* Supported fd types */
> +
> +struct vfio_dmabuf_mgr_plane_info {
> + __u64 start;
> + __u64 drm_format_mod;
> + __u32 drm_format;
> + __u32 width;
> + __u32 height;
> + __u32 stride;
> + __u32 size;
> + __u32 x_pos;
> + __u32 y_pos;
> + __u32 padding;
> +};
> +

This structure is generic, can remove dmabuf from its name,
vfio_plane_info or vfio_vgpu_surface_info since this will only be used
by vgpu.

> +/*
> + * VFIO_DMABUF_MGR_QUERY_PLANE - _IO(VFIO_TYPE, VFIO_BASE + 15,
> + *   struct vfio_dmabuf_mgr_query_plane)
> + * Query plane information
> + */
> +struct vfio_dmabuf_mgr_query_plane {
> + __u32 argsz;
> + __u32 flags;
> + struct vfio_dmabuf_mgr_plane_info plane_info;
> + __u32 plane_id;
> +};
> +
> +#define VFIO_DMABUF_MGR_QUERY_PLANE _IO(VFIO_TYPE, VFIO_BASE + 15)
> +

This same interface can be used to query surface/plane information for
both, dmabuf and region, case. Here also 'DMABUF' can be removed and
define flags if you want to differentiate query for 'dmabuf' and 'region'.

Thanks,
Kirti

> +/*
> + * VFIO_DMABUF_MGR_CREATE_DMABUF - _IO(VFIO, VFIO_BASE + 16,
> + *   struct vfio_dmabuf_mgr_create_dmabuf)
> + *
> + * Create a dma-buf for a plane
> + */
> +struct vfio_dmabuf_mgr_create_dmabuf {
> + __u32 argsz;
> + __u32 flags;
> + struct vfio_dmabuf_mgr_plane_info plane_info;
> + __u32 plane_id;
> + __s32 fd;
> +};
> +
> +#define VFIO_DMABUF_MGR_CREATE_DMABUF _IO(VFIO_TYPE, VFIO_BASE + 16)
> +
>  /*  API for Type1 VFIO IOMMU  */
>  /**
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 02/14] drm/edid: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Thu, Jun 15, 2017 at 07:01:38PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/15/2017 6:59 PM, Ville Syrjälä wrote:
> > On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
> >> CEA-861-F specs defines new video modes to be used with
> >> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> >> 1-107.
> >>
> >> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> >> to be able to parse new CEA modes using the existing methods, we have
> >> to complete the modedb (VIC=65 onwards).
> >>
> >> This patch adds:
> >> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> >> - Newly added 4k modes (from VIC=93 to VIC=107).
> >>
> >> The patch was originaly discussed and reviewed here:
> >> https://patchwork.freedesktop.org/patch/135810/
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jose Abreu 
> >> Cc: Andrzej Hajda 
> >> Cc: Alex Deucher 
> >> Cc: Harry Wentland 
> >>
> >> V2: Rebase
> >> V3: Rebase
> > So what happend to the 'native' bit stuff again?
> Tried really hard finding that code, couldn't :(.
> Might need bit help here.

+static u8 svd_to_vic(u8 svd)
+{
+   ...;
+}
+
 static struct drm_display_mode *
 drm_display_mode_from_vic_index(struct drm_connector *connector,
const u8 *video_db, u8 video_len,
@@ -2915,7 +2920,7 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return NULL;
 
/* CEA modes are numbered 1..127 */
-   vic = (video_db[video_index] & 127);
+   vic = svd_to_vic(video_db[video_index]);
if (!drm_valid_cea_vic(vic))
return NULL;
 

or something along those lines is what I was thinking.

Actually I'm thinking that we should probably pull the svd_to_vic()
stuff outside drm_display_mode_from_vic_index() since we may anyway
want to deal with the VIC outside. But we could leave that for later.

> 
> - Shashank
> >> Reviewed-by: Jose Abreu 
> >> Reviewed-by: Alex Deucher 
> >> Acked-by: Harry Wentland 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_edid.c | 215 
> >> +
> >>   1 file changed, 215 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index d312fe1..6fd8a98 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -1006,6 +1006,221 @@ static const struct drm_display_mode 
> >> edid_cea_modes[] = {
> >>   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >>   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> >> +  /* 65 - 1280x720@24Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 66 - 1280x720@25Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> >> + 3740, 3960, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 67 - 1280x720@30Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 68 - 1280x720@50Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 69 - 1280x720@60Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> >> + 1430, 1650, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 70 - 1280x720@100Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 71 - 1280x720@120Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> >> + 1430, 1650, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> 

Re: [Intel-gfx] [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID's CEA extension blocks,
> to provide information about sink's YCBCR420 output capabilities.
> 
> These blocks are:
> 
> - YCBCR420vdb(YCBCR 420 video data block):
> This block contains VICs of video modes, which can be sopported only
> in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
> SVD block, valid for YCBCR420 modes only.
> 
> - YCBCR420cmdb(YCBCR 420 capability map data block):
> This block gives information about video modes which can support
> YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
> block contains a bitmap index of normal svd videomodes, which can
> support YCBCR420 output too.
> So if bit 0 from first vcb byte is set, first video mode in the svd
> list can support YCBCR420 output too. Bit 1 means second video mode
> from svd list can support YCBCR420 output too, and so on.
> 
> This patch adds two bitmaps in display's hdmi_info structure, one each
> for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
> adds:
> - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
>   an entry in the vdb_bitmap per vic.
> - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Emil Velikov 
> 
> V2: Addressed
> Review comments from Emil:
> - Use 1ULL< - Use the suggested method for updating dbmap.
> - Add documentation for YCBCR420_vcb_map to fix kbuild warning.
> 
> Review comments from Ville:
> - Do not expose the YCBCR420 flags in uabi layer, keep it internal.
> - Save a map of YCBCR420 modes for future reference.
> - Check db length before trying to parse extended tag.
> - Add a warning if there are > 64 modes in capability map block.
> - Use y420cmdb in function names and macros while dealing with vcb
>   to be aligned with spec.
> - Move the display information parsing block ahead of mode parsing
>   blocks.
> 
> V3: Addressed design/review comments from Ville
> - Do not add flags in video modes, else we have to expose them to user
> - There should not be a UABI change, and kernel should detect the
>   choice of the output based on type of mode, and the bitmaps.
> - Use standard bitops from kernel bitmap header, instead of calculating
>   bit positions manually.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 193 
> ++--
>  include/drm/drm_connector.h |  23 ++
>  2 files changed, 211 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6fd8a98..4953f87 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
> struct edid *edid,
>  #define VIDEO_BLOCK 0x02
>  #define VENDOR_BLOCK0x03
>  #define SPEAKER_BLOCK0x04
> -#define VIDEO_CAPABILITY_BLOCK   0x07
> +#define VIDEO_CAPABILITY_BLOCK 0x07
> +#define VIDEO_DATA_BLOCK_420 0x0E
> +#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
>  #define EDID_BASIC_AUDIO (1 << 6)
>  #define EDID_CEA_YCRCB444(1 << 5)
>  #define EDID_CEA_YCRCB422(1 << 4)
> @@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct drm_connector 
> *connector,
>   return newmode;
>  }
>  
> +/*
> + * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
> + * @connector: connector corresponding to the HDMI sink
> + * @svds: start of the data block of CEA YCBCR 420 VDB
> + * @len: length of the CEA YCBCR 420 VDB
> + *
> + * CEA-861-F has added a new video block called YCBCR 420 Video
> + * Data Block (ycbcr 420 vdb). This block contains modes which
> + * support YCBCR 420 HDMI output (only YCBCR 420). This function
> + * parses the block and adds these modes into connector's mode list.

Seems a bit verbose. Maybe something like:
"Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
which contains modes which only support YCbCr 4:2:0 output."

> + */
> +static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
> +const u8 *svds, u8 svds_len)

Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
shorter and match the terminology in the spec. Same for y420cmdb.

> +{
> + int modes = 0, i;
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *newmode;

This variable can be moved into the loop scope.

> + struct drm_display_info *info = >display_info;
> + struct drm_hdmi_info *hdmi = >hdmi;
> +
> + for (i = 0; i < svds_len; i++) {
> + u8 vic = svds[i] & 0x7f;

What's the 0x7f here? Native bit stuff? I'm thinkign we probably want
some kind of svd_to_vic() 

Re: [Intel-gfx] [passive aggressive RESEND 2/2] drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty

[Tvrtko Ursulin]

On 15/06/2017 13:38, Chris Wilson wrote:

For ease of use (i.e. avoiding a few checks and function calls), store
the object's cache coherency next to the cache is dirty bit.

Signed-off-by: Chris Wilson 
Cc: Dongwon Kim 
Cc: Matt Roper 
Tested-by: Dongwon Kim 
---
  drivers/gpu/drm/i915/i915_gem.c  | 14 +++---
  drivers/gpu/drm/i915/i915_gem_clflush.c  |  2 +-
  drivers/gpu/drm/i915/i915_gem_execbuffer.c   |  2 +-
  drivers/gpu/drm/i915/i915_gem_internal.c |  3 ++-
  drivers/gpu/drm/i915/i915_gem_object.h   |  1 +
  drivers/gpu/drm/i915/i915_gem_stolen.c   |  1 +
  drivers/gpu/drm/i915/i915_gem_userptr.c  |  3 ++-
  drivers/gpu/drm/i915/selftests/huge_gem_object.c |  3 ++-
  8 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b1504a829c6a..4ae30f74c475 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -52,7 +52,7 @@ static bool cpu_write_needs_clflush(struct 
drm_i915_gem_object *obj)
if (obj->cache_dirty)
return false;
  
-	if (!i915_gem_object_is_coherent(obj))

+   if (!obj->cache_coherent)
return true;
  
  	return obj->pin_display;

@@ -253,7 +253,7 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object 
*obj,
  
  	if (needs_clflush &&

(obj->base.read_domains & I915_GEM_DOMAIN_CPU) == 0 &&
-   !i915_gem_object_is_coherent(obj))
+   !obj->cache_coherent)
drm_clflush_sg(pages);
  
  	__start_cpu_write(obj);

@@ -856,8 +856,7 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
if (ret)
return ret;
  
-	if (i915_gem_object_is_coherent(obj) ||

-   !static_cpu_has(X86_FEATURE_CLFLUSH)) {
+   if (obj->cache_coherent || !static_cpu_has(X86_FEATURE_CLFLUSH)) {
ret = i915_gem_object_set_to_cpu_domain(obj, false);
if (ret)
goto err_unpin;
@@ -909,8 +908,7 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
if (ret)
return ret;
  
-	if (i915_gem_object_is_coherent(obj) ||

-   !static_cpu_has(X86_FEATURE_CLFLUSH)) {
+   if (obj->cache_coherent || !static_cpu_has(X86_FEATURE_CLFLUSH)) {
ret = i915_gem_object_set_to_cpu_domain(obj, true);
if (ret)
goto err_unpin;
@@ -3684,6 +3682,7 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
list_for_each_entry(vma, >vma_list, obj_link)
vma->node.color = cache_level;
obj->cache_level = cache_level;
+   obj->cache_coherent = i915_gem_object_is_coherent(obj);
obj->cache_dirty = true; /* Always invalidate stale cachelines */
  
  	return 0;

@@ -4344,7 +4343,8 @@ i915_gem_object_create(struct drm_i915_private *dev_priv, 
u64 size)
} else
obj->cache_level = I915_CACHE_NONE;
  
-	obj->cache_dirty = !i915_gem_object_is_coherent(obj);

+   obj->cache_coherent = i915_gem_object_is_coherent(obj);
+   obj->cache_dirty = !obj->cache_coherent;
  
  	trace_i915_gem_object_create(obj);
  
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c b/drivers/gpu/drm/i915/i915_gem_clflush.c

index 17b207e963c2..152f16c11878 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.c
@@ -139,7 +139,7 @@ void i915_gem_clflush_object(struct drm_i915_gem_object 
*obj,
 * snooping behaviour occurs naturally as the result of our domain
 * tracking.
 */
-   if (!(flags & I915_CLFLUSH_FORCE) && i915_gem_object_is_coherent(obj))
+   if (!(flags & I915_CLFLUSH_FORCE) && obj->cache_coherent)
return;
  
  	trace_i915_gem_object_clflush(obj);

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 2a9aed5640e2..20933a15be46 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1110,7 +1110,7 @@ eb_move_to_gpu(struct i915_execbuffer *eb)
if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
continue;
  
-		if (obj->cache_dirty)

+   if (obj->cache_dirty & ~obj->cache_coherent)


What is the explanation for this change?


i915_gem_clflush_object(obj, 0);
  
  		ret = i915_gem_request_await_object

diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c 
b/drivers/gpu/drm/i915/i915_gem_internal.c
index 58e93e87d573..568bf83af1f5 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -191,7 +191,8 @@ i915_gem_object_create_internal(struct drm_i915_private 
*i915,
obj->base.read_domains = 

Re: [Intel-gfx] [passive aggressive RESEND 1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Tvrtko Ursulin]

On 15/06/2017 13:38, Chris Wilson wrote:

Currently, we only mark the CPU cache as dirty if we skip a clflush.
This leads to some confusion where we have to ask if the object is in
the write domain or missed a clflush. If we always mark the cache as
dirty, this becomes a much simply question to answer.

The goal remains to do as few clflushes as required and to do them as
late as possible, in the hope of deferring the work to a kthread and not
block the caller (e.g. execbuf, flips).

v2: Always call clflush before GPU execution when the cache_dirty flag
is set. This may cause some extra work on llc systems that migrate dirty
buffers back and forth - but we do try to limit that by only settin


settin*g*

Subject sounded like reviewer is wanted so I thought to give it a try.


cache_dirty at the end of the gpu sequence.

v3: Always mark the cache as dirty upon a level change, as we need to
invalidate any stale cachelines due to external writes.

Reported-by: Dongwon Kim 
Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning the 
scanout")
Signed-off-by: Chris Wilson 
Cc: Dongwon Kim 
Cc: Matt Roper 
Tested-by: Dongwon Kim 
---
  drivers/gpu/drm/i915/i915_gem.c  | 76 ++--
  drivers/gpu/drm/i915/i915_gem_clflush.c  | 15 +++--
  drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 21 +++
  drivers/gpu/drm/i915/i915_gem_internal.c |  3 +-
  drivers/gpu/drm/i915/i915_gem_userptr.c  |  5 +-
  drivers/gpu/drm/i915/selftests/huge_gem_object.c |  3 +-
  6 files changed, 67 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 31cbe78171a9..b1504a829c6a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -49,7 +49,7 @@ static void i915_gem_flush_free_objects(struct 
drm_i915_private *i915);
  
  static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)

  {
-   if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
+   if (obj->cache_dirty)
return false >
if (!i915_gem_object_is_coherent(obj))
@@ -233,6 +233,14 @@ i915_gem_object_get_pages_phys(struct drm_i915_gem_object 
*obj)
return st;
  }
  
+static void __start_cpu_write(struct drm_i915_gem_object *obj)

+{
+   obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+   obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+   if (cpu_write_needs_clflush(obj))
+   obj->cache_dirty = true;


I find the logic here quite hard to understand because 
cpu_write_needs_clflush is actually consulting obj->cache_dirty so it's 
all a bit recursive.


If we start a cpu write on an object which has been clflushed, but 
otherwise needs clflushing like pin_display - what is the correct thing 
to do? Not set obj->cache_dirty to true?



+}
+
  static void
  __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
struct sg_table *pages,
@@ -248,8 +256,7 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object 
*obj,
!i915_gem_object_is_coherent(obj))
drm_clflush_sg(pages);
  
-	obj->base.read_domains = I915_GEM_DOMAIN_CPU;

-   obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+   __start_cpu_write(obj);
  }
  
  static void

@@ -684,6 +691,12 @@ i915_gem_dumb_create(struct drm_file *file,
   args->size, >handle);
  }
  
+static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)

+{
+   return !(obj->cache_level == I915_CACHE_NONE ||
+obj->cache_level == I915_CACHE_WT);


Hm, is this reversed? On LLC I would assume we don't need explicit 
clflush, but perhaps I am misunderstanding something.



+}
+
  /**
   * Creates a new mm object and returns a handle to it.
   * @dev: drm device pointer
@@ -753,6 +766,11 @@ flush_write_domain(struct drm_i915_gem_object *obj, 
unsigned int flush_domains)
case I915_GEM_DOMAIN_CPU:
i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC);
break;
+
+   case I915_GEM_DOMAIN_RENDER:
+   if (gpu_write_needs_clflush(obj))
+   obj->cache_dirty = true;
+   break;
}
  
  	obj->base.write_domain = 0;

@@ -854,7 +872,8 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
 * optimizes for the case when the gpu will dirty the data
 * anyway again before the next pread happens.
 */
-   if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU))
+   if (!obj->cache_dirty &&
+   !(obj->base.read_domains & I915_GEM_DOMAIN_CPU))
*needs_clflush = CLFLUSH_BEFORE;


Obviously I don't understand something critical here since once more I 
was expecting the reverse here - if the cache is not dirty no need to 
flush it.


  
  

Re: [Intel-gfx] [PATCH i-g-t] tests: Rename I915_MAX_PIPES to IGT_MAX_PIPES

[Leo]

On 2017-06-13 08:55 AM, Arkadiusz Hiler wrote:

On Tue, Jun 13, 2017 at 03:41:14PM +0300, Arkadiusz Hiler wrote:

On Tue, Jun 13, 2017 at 10:35:34AM +0300, Jani Nikula wrote:

On Mon, 12 Jun 2017, Harry Wentland  wrote:

The email was sent but might be stuck in the moderation queue since Leo
(Sun peng) is fairly new on the FDO mailing lists.

Jani, Daniel, can you check if Leo's IGT emails are stuck in the
moderation queue?


Done. I've whitelisted his email address on intel-gfx, but I suggest
subscribing too.

BR,
Jani.


Thanks Jani.

I'll wait with pushing this untill we run it though CI system to make
sure nothing breaks, as suggested by Petri.


To clarify - this depends on the series that changes the number to six,
and that's the one that should use some testing.


Thanks for the patch!

--
Cheers,
Arek


Thanks Jani.

Arek, regarding CI - are there any updates on the test results?

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

[Intel-gfx] Pixel-perfect frame checks in IGT Chamelium tests and CRC

[Paul Kocialkowski]

Hi,

So far, there are two ways of testing for pixel-perfect frames using the
Chamelium that are in IGT. The first one grabs a full frame from the Chamelium
and compares it pixel-to-pixel with the cairo reference, which works well for
DP/HDMI.

For VGA, this is probably not the case (because the link is analogue). In that
case, I will look into implementing some fuzzy testing, probably inspired by
what piglit (probably) does to compare output frames with references.

For pixel-perfect testing, grabbing a full frame and testing it with memcmp
comes with a significant time penalty (about 2 seconds for 1080p). The Chamelium
also provides a CRC mechanism that is faster and does not require retrieving the
frame, that IGT currently also supports. It compares the CRC calculated by the
Chamelium (implemented in the HDL) with a hardcoded reference value.

This approach currently fails for me (the values I get don't match the hardcoded
reference). There are reasons why it is not really reasonable: fonts rendering
may change between machines (e.g. use of anti-aliasing) and cairo version
changes could introduce slight rendering changes too (not to mention changes in
the test pattern itself). So instead of comparing the CRC with a hardcoded
reference value, I think it would make a lot more sense to actually calculate
the CRC based on the cairo image that is the actual reference (and that we
should assume may change between runs/machines).

I am currently looking into the CRC calculation mechanism used by the Chamelium
and trying to reproduce it in C code. Is this a known algorithm for which a
reference/optimized implementation exists, or something custom that the folks
over at Google came up with?

Any thoughts, comments or suggestions?

Cheers!

-- 
Paul Kocialkowski 
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add support for the YCbCr COLOR_RANGE property

[Sharma, Shashank]

Reviewed-by: Shashank Sharma 

Regards

Shashank

On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Add support for the COLOR_RANGE property on planes. This property
selects whether the input YCbCr data is to treated as limited range
or full range.

On most platforms this is a matter of setting the "YUV range correction
disable" bit, and on VLV/CHV we'll just have to program the color
correction logic to pass the data through unmodified.

Cc: Jyri Sarha 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/i915_reg.h  |  4 
  drivers/gpu/drm/i915/intel_display.c |  9 -
  drivers/gpu/drm/i915/intel_sprite.c  | 12 ++--
  3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bac3ec378b6e..6b16b25ba96f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5604,6 +5604,7 @@ enum {
  #define _DVSACNTR 0x72180
  #define   DVS_ENABLE  (1<<31)
  #define   DVS_GAMMA_ENABLE(1<<30)
+#define   DVS_YUV_RANGE_CORRECTION_DISABLE (1<<27)
  #define   DVS_PIXFORMAT_MASK  (3<<25)
  #define   DVS_FORMAT_YUV422   (0<<25)
  #define   DVS_FORMAT_RGBX101010   (1<<25)
@@ -5672,6 +5673,7 @@ enum {
  #define _SPRA_CTL 0x70280
  #define   SPRITE_ENABLE   (1<<31)
  #define   SPRITE_GAMMA_ENABLE (1<<30)
+#define   SPRITE_YUV_RANGE_CORRECTION_DISABLE  (1<<28)
  #define   SPRITE_PIXFORMAT_MASK   (7<<25)
  #define   SPRITE_FORMAT_YUV422(0<<25)
  #define   SPRITE_FORMAT_RGBX101010(1<<25)
@@ -5863,6 +5865,7 @@ enum {
  #define _PLANE_CTL_3_A0x70380
  #define   PLANE_CTL_ENABLE(1 << 31)
  #define   PLANE_CTL_PIPE_GAMMA_ENABLE (1 << 30)
+#define   PLANE_CTL_YUV_RANGE_CORRECTION_DISABLE   (1 << 28)
  #define   PLANE_CTL_FORMAT_MASK   (0xf << 24)
  #define   PLANE_CTL_FORMAT_YUV422 (  0 << 24)
  #define   PLANE_CTL_FORMAT_NV12   (  1 << 24)
@@ -5926,6 +5929,7 @@ enum {
  #define _PLANE_COLOR_CTL_2_A  0x702CC /* GLK+ */
  #define _PLANE_COLOR_CTL_3_A  0x703CC /* GLK+ */
  #define   PLANE_COLOR_PIPE_GAMMA_ENABLE   (1 << 30)
+#define   PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE (1 << 28)
  #define   PLANE_COLOR_PIPE_CSC_ENABLE (1 << 23)
  #define   PLANE_COLOR_CSC_MODE_BYPASS (0 << 17)
  #define   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709   (1 << 17)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ba3ad0e26043..6fe6e67eeefc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3324,6 +3324,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
*crtc_state,
  
  		if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)

plane_ctl |= PLANE_CTL_YUV_CSC_FORMAT_BT709;
+
+   if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+   plane_ctl |= PLANE_CTL_YUV_RANGE_CORRECTION_DISABLE;
}
  
  	plane_ctl |= skl_plane_ctl_format(fb->format->format);

@@ -3352,6 +3355,9 @@ u32 glk_color_ctl(const struct intel_plane_state 
*plane_state)
color_ctl |= PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
else
color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+
+   if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+   color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
}
  
  	return color_ctl;

@@ -13830,7 +13836,8 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
drm_plane_create_color_properties(>base,
  BIT(DRM_COLOR_YCBCR_BT601) |
  BIT(DRM_COLOR_YCBCR_BT709),
- 
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
+ 
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
+ 
BIT(DRM_COLOR_YCBCR_FULL_RANGE),
  DRM_COLOR_YCBCR_BT709,
  
DRM_COLOR_YCBCR_LIMITED_RANGE);
  
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c

index ba433bf40189..6276322fd8ad 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -387,7 +387,8 @@ vlv_update_clrc(const struct intel_plane_state *plane_state)
enum plane_id plane_id = plane->id;
int con, bri, sh_sin, sh_cos;
  
-	if 

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Change the COLOR_ENCODING prop default value to BT.709

[Sharma, Shashank]

ACK: Shashank Sharma 

Regards
Shashank
On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Bring us forward from the stone age and switch our default YCbCr->RGB
conversion matrix to BT.709 from BT.601. I would expect most matrial
to be BT.709 these days.

Cc: Jyri Sarha 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/intel_display.c | 2 +-
  drivers/gpu/drm/i915/intel_sprite.c  | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 810b53b0128c..ba3ad0e26043 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13831,7 +13831,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
  BIT(DRM_COLOR_YCBCR_BT601) |
  BIT(DRM_COLOR_YCBCR_BT709),
  
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
- DRM_COLOR_YCBCR_BT601,
+ DRM_COLOR_YCBCR_BT709,
  
DRM_COLOR_YCBCR_LIMITED_RANGE);
  
  	drm_plane_helper_add(>base, _plane_helper_funcs);

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index c21f43d64b00..ba433bf40189 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1249,7 +1249,7 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
  BIT(DRM_COLOR_YCBCR_BT601) |
  BIT(DRM_COLOR_YCBCR_BT709),
  BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
- DRM_COLOR_YCBCR_BT601,
+ DRM_COLOR_YCBCR_BT709,
  DRM_COLOR_YCBCR_LIMITED_RANGE);
  
  	drm_plane_helper_add(_plane->base, _plane_helper_funcs);


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

Re: [Intel-gfx] [PATCH v3 02/14] drm/edid: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Regards

Shashank


On 6/15/2017 6:59 PM, Ville Syrjälä wrote:

On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Harry Wentland 

V2: Rebase
V3: Rebase

So what happend to the 'native' bit stuff again?

Tried really hard finding that code, couldn't :(.
Might need bit help here.

- Shashank

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Acked-by: Harry Wentland 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c | 215 +
  1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d312fe1..6fd8a98 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
{
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { 

Re: [Intel-gfx] [PATCH v3 02/14] drm/edid: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new video modes to be used with
> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> 1-107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse new CEA modes using the existing methods, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
> 
> The patch was originaly discussed and reviewed here:
> https://patchwork.freedesktop.org/patch/135810/
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> 
> V2: Rebase
> V3: Rebase

So what happend to the 'native' bit stuff again?

> 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> Acked-by: Harry Wentland 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  1 file changed, 215 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d312fe1..6fd8a98 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] 
> = {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720@50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720@60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720@100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720@120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080@24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080@25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080@30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 75 - 1920x1080@50Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
> +2492, 2640, 

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Fix plane YCbCr->RGB conversion for GLK

[Sharma, Shashank]

Regards

Shashank


On 6/15/2017 6:12 PM, Ville Syrjälä wrote:

On Thu, Jun 15, 2017 at 05:57:21PM +0530, Sharma, Shashank wrote:

Regards
Shashank
On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

On GLK the plane CSC controls moved into the COLOR_CTL register.
Update the code to progam the YCbCr->RGB CSC mode correctly when
faced with an YCbCr framebuffer.

The spec is rather confusing as it calls the mode "YUV601 to RGB709".
I'm going to assume that just means it's going to use the YCbCr->RGB
matrix as specified in BT.601 and doesn't actually change the gamut.

Cc: Jyri Sarha 
Cc: Ander Conselvan de Oliveira 
Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/i915/i915_reg.h  |  5 +
   drivers/gpu/drm/i915/intel_display.c | 19 ---
   drivers/gpu/drm/i915/intel_drv.h |  2 ++
   drivers/gpu/drm/i915/intel_sprite.c  | 13 +
   4 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ce7c0dc79cf7..f4f51e7a3e83 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5924,6 +5924,11 @@ enum {
   #define _PLANE_COLOR_CTL_3_A 0x703CC /* GLK+ */
   #define   PLANE_COLOR_PIPE_GAMMA_ENABLE  (1 << 30)
   #define   PLANE_COLOR_PIPE_CSC_ENABLE(1 << 23)
+#define   PLANE_COLOR_CSC_MODE_BYPASS  (0 << 17)
+#define   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709(1 << 17)
+#define   PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709(2 << 17)
+#define   PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020  (3 << 17)
+#define   PLANE_COLOR_CSC_MODE_RGB709_TO_RGB2020   (4 << 17)
   #define   PLANE_COLOR_PLANE_GAMMA_DISABLE(1 << 13)
   #define _PLANE_BUF_CFG_1_A   0x7027c
   #define _PLANE_BUF_CFG_2_A   0x7037c
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 25390dd8e08e..e2aaaf60a969 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3335,6 +3335,21 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
*crtc_state,
return plane_ctl;
   }
   
+u32 glk_color_ctl(const struct intel_plane_state *plane_state)

+{
+   const struct drm_framebuffer *fb = plane_state->base.fb;
+   u32 color_ctl;
+
+   color_ctl = PLANE_COLOR_PIPE_GAMMA_ENABLE |
+   PLANE_COLOR_PIPE_CSC_ENABLE |
+   PLANE_COLOR_PLANE_GAMMA_DISABLE;
+
+   if (intel_format_is_yuv(fb->format->format))
+   color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;

why not YUV709_TO_RGB709 ?

To match the other platforms.
I am slightly confused. Dint we just upgrade our CSC matrix from stone 
age, to REC_709, in patch 4 ?

Shouldn't we be consistent here ? or am I missing something basic :-) ?

- Shashank

+
+   return color_ctl;
+}
+

You might want to have a look on this series from Dhanya too:

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

I think we have everything we need from there.


- Shashank


   static void skylake_update_primary_plane(struct intel_plane *plane,
 const struct intel_crtc_state 
*crtc_state,
 const struct intel_plane_state 
*plane_state)
@@ -3374,9 +3389,7 @@ static void skylake_update_primary_plane(struct 
intel_plane *plane,
   
   	if (IS_GEMINILAKE(dev_priv)) {

I915_WRITE_FW(PLANE_COLOR_CTL(pipe, plane_id),
- PLANE_COLOR_PIPE_GAMMA_ENABLE |
- PLANE_COLOR_PIPE_CSC_ENABLE |
- PLANE_COLOR_PLANE_GAMMA_DISABLE);
+ glk_color_ctl(plane_state));
}
   
   	I915_WRITE_FW(PLANE_CTL(pipe, plane_id), plane_ctl);

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 83dd40905821..e13e714b1176 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1484,6 +1484,7 @@ static inline u32 intel_plane_ggtt_offset(const struct 
intel_plane_state *state)
   
   u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,

  const struct intel_plane_state *plane_state);
+u32 glk_color_ctl(const struct intel_plane_state *plane_state);
   u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
 unsigned int rotation);
   int skl_check_plane_surface(struct intel_plane_state *plane_state);
@@ -1888,6 +1889,7 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv,
   
   
   /* intel_sprite.c */

+bool intel_format_is_yuv(u32 format);
   int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
 int usecs);
   struct intel_plane 

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Add support for the YCbCr COLOR_ENCODING property

[Sharma, Shashank]

Regards

Shashank


On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Add support for the COLOR_ENCODING plane property which selects
the matrix coefficients used for the YCbCr->RGB conversion. Our
hardware can generally handle BT.601 and BT.709.

CHV pipe B sprites have a fully programmable matrix, so in theory
we could handle anything, but it doesn't seem all that useful to
expose anything beyond BT.601 and BT.709 at this time.

GLK can supposedly do BT.2020, but let's leave enabling that for
the future as well.

Cc: Jyri Sarha 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/i915_reg.h  |  3 ++
  drivers/gpu/drm/i915/intel_display.c | 19 +--
  drivers/gpu/drm/i915/intel_sprite.c  | 61 +++-
  3 files changed, 66 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f4f51e7a3e83..bac3ec378b6e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5612,6 +5612,7 @@ enum {
  #define   DVS_PIPE_CSC_ENABLE   (1<<24)
  #define   DVS_SOURCE_KEY  (1<<22)
  #define   DVS_RGB_ORDER_XBGR  (1<<20)
+#define   DVS_YUV_CSC_FORMAT_BT709 (1<<18)
  #define   DVS_YUV_BYTE_ORDER_MASK (3<<16)
  #define   DVS_YUV_ORDER_YUYV  (0<<16)
  #define   DVS_YUV_ORDER_UYVY  (1<<16)
@@ -5758,6 +5759,7 @@ enum {
  #define   SP_FORMAT_RGBA  (0xf<<26)
  #define   SP_ALPHA_PREMULTIPLY(1<<23) /* CHV pipe B */
  #define   SP_SOURCE_KEY   (1<<22)
+#define   SP_YUV_CSC_FORMAT_BT709  (1<<18)
  #define   SP_YUV_BYTE_ORDER_MASK  (3<<16)
  #define   SP_YUV_ORDER_YUYV   (0<<16)
  #define   SP_YUV_ORDER_UYVY   (1<<16)
@@ -5876,6 +5878,7 @@ enum {
  #define   PLANE_CTL_KEY_ENABLE_DESTINATION(  2 << 21)
  #define   PLANE_CTL_ORDER_BGRX(0 << 20)
  #define   PLANE_CTL_ORDER_RGBX(1 << 20)
+#define   PLANE_CTL_YUV_CSC_FORMAT_BT709   (1 << 18)
Should we call it PLANE_CTL_CSC_YUV_FORMAT_BT709 (or similar) so that it 
would be clear that source is BT709 format.

Right now, it feels like CSC(destination) format is BT709.

  #define   PLANE_CTL_YUV422_ORDER_MASK (0x3 << 16)
  #define   PLANE_CTL_YUV422_YUYV   (  0 << 16)
  #define   PLANE_CTL_YUV422_UYVY   (  1 << 16)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e2aaaf60a969..810b53b0128c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3321,6 +3321,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
*crtc_state,
PLANE_CTL_PIPE_GAMMA_ENABLE |
PLANE_CTL_PIPE_CSC_ENABLE |
PLANE_CTL_PLANE_GAMMA_DISABLE;
+
+   if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
+   plane_ctl |= PLANE_CTL_YUV_CSC_FORMAT_BT709;
}
  
  	plane_ctl |= skl_plane_ctl_format(fb->format->format);

@@ -3344,8 +3347,12 @@ u32 glk_color_ctl(const struct intel_plane_state 
*plane_state)
PLANE_COLOR_PIPE_CSC_ENABLE |
PLANE_COLOR_PLANE_GAMMA_DISABLE;
  
-	if (intel_format_is_yuv(fb->format->format))

-   color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+   if (intel_format_is_yuv(fb->format->format)) {
+   if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
+   color_ctl |= PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
+   else
+   color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+   }
  
  	return color_ctl;

  }
@@ -13819,6 +13826,14 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
   DRM_MODE_ROTATE_0,
   supported_rotations);
  
+	if (INTEL_GEN(dev_priv) >= 9)
I am seeing few if (INTEL_GEN(dev_priv) >= 9)  checks above, would it 
make sense to reuse any of those, instead of adding

a new one ?

- Shashank

+   drm_plane_create_color_properties(>base,
+ BIT(DRM_COLOR_YCBCR_BT601) |
+ BIT(DRM_COLOR_YCBCR_BT709),
+ 
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
+ DRM_COLOR_YCBCR_BT601,
+ 
DRM_COLOR_YCBCR_LIMITED_RANGE);
+
drm_plane_helper_add(>base, _plane_helper_funcs);
  
  	return primary;

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index cc07157f2eb6..c21f43d64b00 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ 

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Pipe A quirk rework

[Ville Syrjälä]

On Thu, Jun 01, 2017 at 05:36:12PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> This series eliminates the problematic load detect abuse for the
> pipe A quirk. My main motivations were to isolate these quirks
> more from atomic to avoid regressions, and to save a bit of extra
> power. I believe I cooked this up a few years ago but never posted
> it. In the meantine we had accumulated some more regressions in
> the existing code so I tossed in some fixes up front.
> 
> Note that I'm entirely removing the few remaining pipe A quirks
> for non-830 platforms as they predate KMS and the hardware
> really shouldn't need them.
> 
> Entire series available here:
> git://github.com/vsyrjala/linux.git alm_pipe_quirk_rework_4
> 
> Ville Syrjälä (7):
>   drm/i915: Fix deadlock witha the pipe A quirk during resume
>   drm/i915: Plumb the correct acquire ctx into
> intel_crtc_disable_noatomic()
>   drm/i915: Use a loop for the "three times for luck" DPLL procedure
>   drm/i915: Add i830 "pipes power well"
>   drm/i915: Drop pipe A quirk for Toshiba Protege R205-S209
>   drm/i915: Drop pipe A quirk for Thinkapd T60
>   drm/i915: Remove pipe A quirk remnants

I pushed the entire lot to dinq as is (was too lazy to shuffle the
code around in the end). Thanks for the reviews.

> 
>  drivers/gpu/drm/i915/i915_drv.h |   2 -
>  drivers/gpu/drm/i915/intel_display.c| 209 
> +---
>  drivers/gpu/drm/i915/intel_drv.h|   2 +
>  drivers/gpu/drm/i915/intel_overlay.c|   1 -
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  64 ++
>  5 files changed, 177 insertions(+), 101 deletions(-)
> 
> -- 
> 2.10.2

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

Re: [Intel-gfx] [PATCH][drm-next] drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 02:03:05PM +0100, Tvrtko Ursulin wrote:
> 
> On 13/06/2017 14:47, Colin King wrote:
> > From: Colin Ian King 
> > 
> > The function cnl_ddi_dp_set_dpll_hw_state does not need to be in global
> > scope, so make it static.
> > 
> > Cleans up sparse warning:
> > "symbol 'cnl_ddi_dp_set_dpll_hw_state' was not declared. Should it
> >   be static?"
> > 
> > Signed-off-by: Colin Ian King 
> > ---
> >   drivers/gpu/drm/i915/intel_dpll_mgr.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index 8e669b6254ae..2f7b0e64f628 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -2292,8 +2292,9 @@ static bool cnl_ddi_hdmi_pll_dividers(struct 
> > intel_crtc *crtc,
> > return true;
> >   }
> >   
> > -bool cnl_ddi_dp_set_dpll_hw_state(int clock,
> > - struct intel_dpll_hw_state *dpll_hw_state)
> > +static bool
> > +cnl_ddi_dp_set_dpll_hw_state(int clock,
> > +struct intel_dpll_hw_state *dpll_hw_state)
> >   {
> > uint32_t cfgcr0;
> >   
> > 
> 
> Reviewed-by: Tvrtko Ursulin 

Thanks for the patch and review. Pushed to dinq.

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Don't enable backlight at setup time.

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 01:18:42PM -0700, Puthikorn Voravootivat wrote:
> I tested this on actual system and it is working fine.

Thank you everyone. Patch pushed to dinq.

> 
> On Tue, Jun 13, 2017 at 1:03 PM, Dhinakaran Pandiyan <
> dhinakaran.pandi...@intel.com> wrote:
> 
> > Maarten and Ville noticed that we are enabling backlight via DP aux very
> > early in the modeset_init path via the intel_dp_aux_setup_backlight()
> > function, since commit e7156c833903 ("drm/i915: Add Backlight Control using
> > DPCD for eDP connectors (v9)"). Looks like all we need to do during
> > _setup_backlight() is read the current brightness state instead of
> > modifying it.
> >
> > v2: Rewrote commit message.
> >
> > Cc: Ville Syrjala 
> > Cc: Maarten Lankhorst 
> > Cc: Jani Nikula 
> > Cc: Yetunde Adebisi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > Reviewed-by: Maarten Lankhorst 
> > Acked-by: Jani Nikula 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 10 --
> >  1 file changed, 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index 6cc6298..228ca06 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -80,10 +80,6 @@ static uint32_t intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> >  static void
> >  intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state,
> > u32 level)
> >  {
> > -   /*
> > -* conn_state->best_encoder is likely NULL when called from
> > -* intel_dp_aux_setup_backlight()
> > -*/
> > struct intel_connector *connector = to_intel_connector(conn_state-
> > >connector);
> > struct intel_dp *intel_dp = enc_to_intel_dp(>
> > encoder->base);
> > uint8_t vals[2] = { 0x0 };
> > @@ -106,10 +102,6 @@ static void intel_dp_aux_enable_backlight(const
> > struct intel_crtc_state *crtc_st
> >   const struct drm_connector_state
> > *conn_state)
> >  {
> > struct intel_connector *connector = to_intel_connector(conn_state-
> > >connector);
> > -   /*
> > -* conn_state->best_encoder (and crtc_state) are NULL when called
> > from
> > -* intel_dp_aux_setup_backlight()
> > -*/
> > struct intel_dp *intel_dp = enc_to_intel_dp(>
> > encoder->base);
> > uint8_t dpcd_buf = 0;
> > uint8_t edp_backlight_mode = 0;
> > @@ -156,8 +148,6 @@ static int intel_dp_aux_setup_backlight(struct
> > intel_connector *connector,
> > struct intel_dp *intel_dp = enc_to_intel_dp(>
> > encoder->base);
> > struct intel_panel *panel = >panel;
> >
> > -   intel_dp_aux_enable_backlight(NULL, connector->base.state);
> > -
> > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_
> > BYTE_COUNT)
> > panel->backlight.max = 0x;
> > else
> > --
> > 2.7.4
> >
> >

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

[Intel-gfx] [PATCH] drm/i915: Differentiate between sw write location into ring and last hw read

[Chris Wilson]

We need to keep track of the last location we ask the hw to read up to
(RING_TAIL) separately from our last write location into the ring, so
that in the event of a GPU reset we do not tell the HW to proceed into
a partially written request (which can happen if that request is waiting
for an external signal before being executed).

v2: Refactor intel_ring_reset() (Mika)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100144
Testcase: igt/gem_exec_fence/await-hang
Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to 
actual hw submission")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170425130049.26147-1-ch...@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala 
(cherry picked from commit e6ba9992de6c63fe86c028b4876338e1cb7dac34)
---
 drivers/gpu/drm/i915/i915_gem_request.c|  2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |  4 +--
 drivers/gpu/drm/i915/intel_lrc.c   |  6 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c| 41 --
 drivers/gpu/drm/i915/intel_ringbuffer.h| 19 --
 5 files changed, 48 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 5ddbc9499775..a74d0ac737cb 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -623,7 +623,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 * GPU processing the request, we never over-estimate the
 * position of the head.
 */
-   req->head = req->ring->tail;
+   req->head = req->ring->emit;
 
/* Check that we didn't interrupt ourselves with a new request */
GEM_BUG_ON(req->timeline->seqno != req->fence.seqno);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 1642fff9cf13..ab5140ba108d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -480,9 +480,7 @@ static void guc_wq_item_append(struct i915_guc_client 
*client,
GEM_BUG_ON(freespace < wqi_size);
 
/* The GuC firmware wants the tail index in QWords, not bytes */
-   tail = rq->tail;
-   assert_ring_tail_valid(rq->ring, rq->tail);
-   tail >>= 3;
+   tail = intel_ring_set_tail(rq->ring, rq->tail) >> 3;
GEM_BUG_ON(tail > WQ_RING_TAIL_MAX);
 
/* For now workqueue item is 4 DWs; workqueue buffer is 2 pages. So we
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c8f7c631fc1f..10c63dbd617c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -326,8 +326,7 @@ static u64 execlists_update_context(struct 
drm_i915_gem_request *rq)
rq->ctx->ppgtt ?: rq->i915->mm.aliasing_ppgtt;
u32 *reg_state = ce->lrc_reg_state;
 
-   assert_ring_tail_valid(rq->ring, rq->tail);
-   reg_state[CTX_RING_TAIL+1] = rq->tail;
+   reg_state[CTX_RING_TAIL+1] = intel_ring_set_tail(rq->ring, rq->tail);
 
/* True 32b PPGTT with dynamic page allocation: update PDP
 * registers and point the unallocated PDPs to scratch page.
@@ -2036,8 +2035,7 @@ void intel_lr_context_resume(struct drm_i915_private 
*dev_priv)
ce->state->obj->mm.dirty = true;
i915_gem_object_unpin_map(ce->state->obj);
 
-   ce->ring->head = ce->ring->tail = 0;
-   intel_ring_update_space(ce->ring);
+   intel_ring_reset(ce->ring, 0);
}
}
 }
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 66a2b8b83972..513a0f4b469b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -49,7 +49,7 @@ static int __intel_ring_space(int head, int tail, int size)
 
 void intel_ring_update_space(struct intel_ring *ring)
 {
-   ring->space = __intel_ring_space(ring->head, ring->tail, ring->size);
+   ring->space = __intel_ring_space(ring->head, ring->emit, ring->size);
 }
 
 static int
@@ -774,8 +774,8 @@ static void i9xx_submit_request(struct drm_i915_gem_request 
*request)
 
i915_gem_request_submit(request);
 
-   assert_ring_tail_valid(request->ring, request->tail);
-   I915_WRITE_TAIL(request->engine, request->tail);
+   I915_WRITE_TAIL(request->engine,
+   intel_ring_set_tail(request->ring, request->tail));
 }
 
 static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req, u32 *cs)
@@ -1316,11 +1316,23 @@ int intel_ring_pin(struct intel_ring *ring, unsigned 
int offset_bias)
return PTR_ERR(addr);
 }
 
+void 

Re: [Intel-gfx] [PATCH 33/37] drm/tegra: Drop drm_vblank_cleanup

[Thierry Reding]

On Wed, May 24, 2017 at 04:52:08PM +0200, Daniel Vetter wrote:
> Again, doesn't seem to serve a purpose.
> 
> Cc: Thierry Reding 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tegra/drm.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)

I'm assuming that you want to apply the whole batch at once? From what I
can tell the driver patches should be fine to apply independently, but
it's probably a good idea to keep all of these together for coherence.

Thierry


signature.asc
Description: PGP signature
___
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 [passive,aggressive,RESEND,1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Patchwork]

== Series Details ==

Series: series starting with [passive,aggressive,RESEND,1/2] drm/i915: Mark CPU 
cache as dirty on every transition for CPU writes
URL   : https://patchwork.freedesktop.org/series/25841/
State : success

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215 +1

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:466s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:485s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:587s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:550s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:590s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:420s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:462s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:502s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:514s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:482s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:572s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:577s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:483s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:447s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:511s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:506s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:510s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:626s
fi-snb-2600  total:278  pass:246  dwarn:0   dfail:0   fail:2   skip:29  
time:404s

94b0761a394e3d61e51bc920d0201364c21690d6 drm-tip: 2017y-06m-15d-10h-05m-24s UTC 
integration manifest
502a2ef drm/i915: Store i915_gem_object_is_coherent() as a bit next to 
cache-dirty
ad420fb drm/i915: Mark CPU cache as dirty on every transition for CPU writes

== Logs ==

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

Re: [Intel-gfx] [PATCH 10/37] drm/doc: vblank cleanup

[Thierry Reding]

On Wed, May 24, 2017 at 04:51:45PM +0200, Daniel Vetter wrote:
[...]
> -Resources allocated by :c:func:`drm_vblank_init()` must be freed
> -with a call to :c:func:`drm_vblank_cleanup()` in the driver unload
> -operation handler.

I think perhaps this is the reason why this was cargo-culted. It's
confusing to have the documentation say drivers have to call it, when in
fact the core already does.

> @@ -396,6 +436,8 @@ EXPORT_SYMBOL(drm_vblank_cleanup);
>   * @num_crtcs: number of CRTCs supported by @dev
>   *
>   * This function initializes vblank support for @num_crtcs display pipelines.
> + * Drivers do not need to call drm_vblank_cleanup(), cleanup is already 
> handled
> + * by the DRM core.

This is key, I think, in understanding why the patch series is correct.
Maybe this should go into the cover letter to provide more context.

That said, there is one case where the core wouldn't be calling the
drm_vblank_cleanup() as part of teardown, and that is when the driver
implements a ->release() callback. From a very cursory look i915 is the
only driver that does so, and it ends up calling drm_dev_fini() and
therefore drm_vblank_cleanup().

Given all of the above, for the series:

Acked-by: Thierry Reding 


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

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

[Ville Syrjälä]

On Thu, Jun 15, 2017 at 06:08:43PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Turns out the VLV/CHV fixed function sprite CSC expects full range
> > data as input. We've been feeding it limited range data to it all
> > along. To expand the data out to full range we'll use the color
> > correction registers (brightness, contrast, and saturation).
> >
> > On CHV pipe B we were actually doing the right thing already because we
> > progammed the custom CSC matrix to do expect limited range input. Now
> > that well pre-expand the data out with the color correction unit, we
> > need to change the CSC matrix to operate with full range input instead.
> >
> > This should make the sprite output of the other pipes match the sprite
> > output of pipe B reasonably well. Looking at the resulting pipe CRCs,
> > there can be a slight difference in the output, but as I don't know
> > the formula used by the fixed function CSC of the other pipes, I don't
> > think it's worth the effort to try to match the output exactly. It
> > might not even be possible due to difference in internal precision etc.
> >
> > One slight caveat here is that the color correction registers are single
> > bufferred, so we should really be updating them during vblank, but we
> > still don't have a mechanism for that, so just toss in another FIXME.
> >
> > v2: Rebase
> >
> > Cc: Jyri Sarha 
> > Cc: "Tang, Jun" 
> > Reported-by: "Tang, Jun" 
> > Cc: sta...@vger.kernel.org
> > Fixes: 7f1f3851feb0 ("drm/i915: sprite support for ValleyView v4")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/i915_reg.h | 10 +
> >   drivers/gpu/drm/i915/intel_sprite.c | 74 
> > -
> >   2 files changed, 66 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index b6d69e289974..ce7c0dc79cf7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5777,6 +5777,12 @@ enum {
> >   #define _SPATILEOFF   (VLV_DISPLAY_BASE + 0x721a4)
> >   #define _SPACONSTALPHA(VLV_DISPLAY_BASE + 0x721a8)
> >   #define   SP_CONST_ALPHA_ENABLE   (1<<31)
> > +#define _SPACLRC0  (VLV_DISPLAY_BASE + 0x721d0)
> > +#define   SP_CONTRAST(x)   ((x) << 18) /* u3.6 */
> > +#define   SP_BRIGHTNESS(x) ((x) & 0xff) /* s8 */
> > +#define _SPACLRC1  (VLV_DISPLAY_BASE + 0x721d4)
> > +#define   SP_SH_SIN(x) (((x) & 0x7ff) << 16) /* s4.7 */
> > +#define   SP_SH_COS(x) (x) /* u3.7 */
> >   #define _SPAGAMC  (VLV_DISPLAY_BASE + 0x721f4)
> >   
> >   #define _SPBCNTR  (VLV_DISPLAY_BASE + 0x72280)
> > @@ -5790,6 +5796,8 @@ enum {
> >   #define _SPBKEYMAXVAL (VLV_DISPLAY_BASE + 0x722a0)
> >   #define _SPBTILEOFF   (VLV_DISPLAY_BASE + 0x722a4)
> >   #define _SPBCONSTALPHA(VLV_DISPLAY_BASE + 0x722a8)
> > +#define _SPBCLRC0  (VLV_DISPLAY_BASE + 0x722d0)
> > +#define _SPBCLRC1  (VLV_DISPLAY_BASE + 0x722d4)
> >   #define _SPBGAMC  (VLV_DISPLAY_BASE + 0x722f4)
> >   
> >   #define _MMIO_VLV_SPR(pipe, plane_id, reg_a, reg_b) \
> > @@ -5806,6 +5814,8 @@ enum {
> >   #define SPKEYMAXVAL(pipe, plane_id)   _MMIO_VLV_SPR((pipe), 
> > (plane_id), _SPAKEYMAXVAL, _SPBKEYMAXVAL)
> >   #define SPTILEOFF(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id), 
> > _SPATILEOFF, _SPBTILEOFF)
> >   #define SPCONSTALPHA(pipe, plane_id)  _MMIO_VLV_SPR((pipe), 
> > (plane_id), _SPACONSTALPHA, _SPBCONSTALPHA)
> > +#define SPCLRC0(pipe, plane_id)_MMIO_VLV_SPR((pipe), 
> > (plane_id), _SPACLRC0, _SPBCLRC0)
> > +#define SPCLRC1(pipe, plane_id)_MMIO_VLV_SPR((pipe), 
> > (plane_id), _SPACLRC1, _SPBCLRC1)
> >   #define SPGAMC(pipe, plane_id)_MMIO_VLV_SPR((pipe), 
> > (plane_id), _SPAGAMC, _SPBGAMC)
> >   
> >   /*
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 0c650c2cbca8..2ce3b3c6ffa8 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -325,44 +325,80 @@ skl_disable_plane(struct intel_plane *plane, struct 
> > intel_crtc *crtc)
> >   }
> >   
> >   static void
> > -chv_update_csc(struct intel_plane *plane, uint32_t format)
> > +chv_update_csc(const struct intel_plane_state *plane_state)
> >   {
> > +   struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> > struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > +   const struct drm_framebuffer *fb = plane_state->base.fb;
> > enum plane_id plane_id = plane->id;
> >   
> > /* Seems RGB data bypasses the CSC always */
> > -   if