Re: [Intel-gfx] [PATCH] drm/i915: Do not drop pagetables when empty

[Jani Nikula]

On Thu, 15 Jun 2017, Greg KH  wrote:
> Ugh, this one flew right by me, and I never even caught it.  And that
> was because it was sent To: the intel-gfx list, and only had a cc: for
> stable, much like all of the other i915 stable patches that you all want
> in stable trees, but are not yet included in your tree.

I presume this is because git send-email automatically adds Cc's from
the patches, and Cc: stable is not an exception. Are you suggesting the
backport should've been sent To: stable, or that we should avoid Cc'ing
stable altogether when sending patches?

I feel like you're having a grumpy bias towards i915, and everything
about us ticks you off now. :(

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] Revert "drm/i915/skl: New ddb allocation algorithm"

[Ander Conselvan De Oliveira]

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.

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->wm[level];
> > > > > -
> > > > > - if (level > max_level || level_wm->plane_res_b == 0
> > > > > -   || level_wm->plane_res_l >= 31
> > > > > -   || level_wm->plane_res_b >= 
> > > > > plane_ddb) {
> > > > > - level_wm->plane_en = false;
> > > > > - level_wm->plane_res_b = 0;
> > > > > - level_wm->plane_res_l = 0;
> > > > > - } else {
> > > > > - level_wm->plane_en = true;
> > > > > - }
> > > > > - }
> > > > > -}
> > > > > -
> > > > >   static int
> > > > >   skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> > > > > -   struct skl_pipe_wm *pipe_wm,
> > > > >  struct skl_ddb_allocation *d

[Intel-gfx] Patch "drm/i915: Do not drop pagetables when empty" has been added to the 4.11-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

drm/i915: Do not drop pagetables when empty

to the 4.11-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 drm-i915-do-not-drop-pagetables-when-empty.patch
and it can be found in the queue-4.11 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


From daniel.vet...@ffwll.ch  Thu Jun 15 08:32:03 2017
From: Daniel Vetter 
Date: Fri, 26 May 2017 10:29:06 +0200
Subject: drm/i915: Do not drop pagetables when empty
To: Intel Graphics Development 
Cc: Chris Wilson , Michel Thierry 
, Mika Kuoppala , Joonas 
Lahtinen , Michał Winiarski 
, Daniel Vetter , Jani 
Nikula , "# v4 . 10+" 
Message-ID: <20170526082906.8982-1-daniel.vet...@ffwll.ch>


From: Chris Wilson 

This is the minimal backport for stable of the upstream commit:

commit dd19674bacba227ae5d3ce680cbc5668198894dc
Author: Chris Wilson 
Date:   Wed Feb 15 08:43:46 2017 +

drm/i915: Remove bitmap tracking for used-ptes

Due to a race with the shrinker, when we try to allocate a pagetable, we
may end up shrinking it instead. This comes as a nasty surprise as we
try to dereference it to fill in the pagetable entries for the object.

In linus/master this is fixed by pinning the pagetables prior to
allocation, but that backport is roughly
 drivers/gpu/drm/i915/i915_gem_gtt.c |   10 --
 1 file changed, 10 deletions(-)
i.e. unsuitable for stable. Instead we neuter the code that tried to
free the pagetables.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99295
Fixes: 2ce5179fe826 ("drm/i915/gtt: Free unused lower-level page tables")
Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Mika Kuoppala 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michał Winiarski 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.10+
Tested-by: Maël Lavault 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman 

--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -755,10 +755,6 @@ static bool gen8_ppgtt_clear_pt(struct i
GEM_BUG_ON(pte_end > GEN8_PTES);
 
bitmap_clear(pt->used_ptes, pte, num_entries);
-   if (USES_FULL_PPGTT(vm->i915)) {
-   if (bitmap_empty(pt->used_ptes, GEN8_PTES))
-   return true;
-   }
 
pt_vaddr = kmap_px(pt);
 
@@ -798,9 +794,6 @@ static bool gen8_ppgtt_clear_pd(struct i
}
}
 
-   if (bitmap_empty(pd->used_pdes, I915_PDES))
-   return true;
-
return false;
 }
 
@@ -829,9 +822,6 @@ static bool gen8_ppgtt_clear_pdp(struct
 
mark_tlbs_dirty(ppgtt);
 
-   if (bitmap_empty(pdp->used_pdpes, I915_PDPES_PER_PDP(dev_priv)))
-   return true;
-
return false;
 }
 


Patches currently in stable-queue which might be from daniel.vet...@ffwll.ch are

queue-4.11/drm-i915-do-not-drop-pagetables-when-empty.patch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do not drop pagetables when empty

[Greg KH]

On Thu, Jun 15, 2017 at 08:51:34AM +0300, Jani Nikula wrote:
> On Wed, 14 Jun 2017, Eric Blau  wrote:
> > Can the following patch please be included in the next stable release?
> > It looks like it was submitted previously by Daniel Vetter, but has not
> > been included in 4.11.y yet. Thanks.
> 
> The previous submission would be [1]. Please reference that instead of
> resending patches with incomplete upstream references. Thank you.
> 
> BR,
> Jani.
> 
> 
> [1] 20170526082906.8982-1-daniel.vetter@ffwll.ch">http://mid.mail-archive.com/20170526082906.8982-1-daniel.vetter@ffwll.ch

Ugh, this one flew right by me, and I never even caught it.  And that
was because it was sent To: the intel-gfx list, and only had a cc: for
stable, much like all of the other i915 stable patches that you all want
in stable trees, but are not yet included in your tree.

So thanks for the reminder, I'll go pull the original one in now.

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

Re: [Intel-gfx] [PATCH 0/3] Reviving the PWM_LPSS patches yet again

[Kumar, Shobhit]

Hi Jani,

On Wednesday 31 May 2017 02:57 PM, Shobhit Kumar wrote:

Hi All,
Its been long since I have been sitting on these after I had received Tested-by
for the same by Lluís for atleast the backlight working fine. The related bugs


Can you have a look at these patches.

Regards
Shobhit


are -

https://bugs.freedesktop.org/show_bug.cgi?id=96571
https://bugs.freedesktop.org/show_bug.cgi?id=90075

Rebased the code on latest code and sending again. Still display was not working
on devices referenced in these bugs but backlight control was tested to be 
working
at that time. DSI issues of panel display not comming up is tracked separately 
at -
https://bugs.freedesktop.org/show_bug.cgi?id=96923 and should be again tested 
with
latest drm-tip.

Module ordering problem remains still and for testing we should for now enable
LPSS_PWM as in built with i915 as module.

Regards
Shobhit

Shobhit Kumar (3):
   drm/i915: Encapsulate the pwm_device in a pwm_info structure
   pwm: lpss: Add intel-gfx as consumer device in lookup table
   drm/i915: Add support for LPSS PWM on devices that support it

  drivers/gpu/drm/i915/intel_drv.h   |  8 -
  drivers/gpu/drm/i915/intel_panel.c | 61 +++---
  drivers/pwm/pwm-lpss-platform.c| 12 
  3 files changed, 62 insertions(+), 19 deletions(-)


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

Re: [Intel-gfx] [PATCH] drm/i915: Do not drop pagetables when empty

[Jani Nikula]

On Wed, 14 Jun 2017, Eric Blau  wrote:
> Can the following patch please be included in the next stable release?
> It looks like it was submitted previously by Daniel Vetter, but has not
> been included in 4.11.y yet. Thanks.

The previous submission would be [1]. Please reference that instead of
resending patches with incomplete upstream references. Thank you.

BR,
Jani.


[1] 20170526082906.8982-1-daniel.vetter@ffwll.ch">http://mid.mail-archive.com/20170526082906.8982-1-daniel.vetter@ffwll.ch

> From 64b1d89f358df34701d92471b65f99f4eff1b384 Mon Sep 17 00:00:00 2001
> From: Chris Wilson 
> Date: Thu, 18 May 2017 11:00:15 +0100
> Subject: [PATCH] drm/i915: Do not drop pagetables when empty
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Due to a race with the shrinker, when we try to allocate a pagetable, we
> may end up shrinking it instead. This comes as a nasty surprise as we
> try to dereference it to fill in the pagetable entries for the object.
>
> In linus/master this is fixed by pinning the pagetables prior to
> allocation, but that backport is roughly
>  drivers/gpu/drm/i915/i915_debugfs.c   |2 +-
>  drivers/gpu/drm/i915/i915_gem_evict.c |   12 +-
>  drivers/gpu/drm/i915/i915_gem_gtt.c   | 2017 
> ++---
>  drivers/gpu/drm/i915/i915_gem_gtt.h   |  123 +-
>  drivers/gpu/drm/i915/i915_trace.h |  104 --
>  drivers/gpu/drm/i915/i915_vgpu.c  |9 +-
>  drivers/gpu/drm/i915/i915_vma.c   |9 -
>  drivers/gpu/drm/i915/intel_lrc.c  |4 +-
>  8 files changed, 946 insertions(+), 1334 deletions(-)
> i.e. unsuitable for stable. Instead we neuter the code that tried to
> free the pagetables.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99295
> Fixes: 2ce5179fe826 ("drm/i915/gtt: Free unused lower-level page tables")
> Signed-off-by: Chris Wilson 
> Cc: Michel Thierry 
> Cc: Mika Kuoppala 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michał Winiarski 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: intel-gfx@lists.freedesktop.org
> Cc:  # v4.10+
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 96e45a4d5441..4f581adf2fcf 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -755,10 +755,6 @@ static bool gen8_ppgtt_clear_pt(struct 
> i915_address_space *vm,
>   GEM_BUG_ON(pte_end > GEN8_PTES);
>  
>   bitmap_clear(pt->used_ptes, pte, num_entries);
> - if (USES_FULL_PPGTT(vm->i915)) {
> - if (bitmap_empty(pt->used_ptes, GEN8_PTES))
> - return true;
> - }
>  
>   pt_vaddr = kmap_px(pt);
>  
> @@ -798,9 +794,6 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space 
> *vm,
>   }
>   }
>  
> - if (bitmap_empty(pd->used_pdes, I915_PDES))
> - return true;
> -
>   return false;
>  }
>  
> @@ -829,9 +822,6 @@ static bool gen8_ppgtt_clear_pdp(struct 
> i915_address_space *vm,
>  
>   mark_tlbs_dirty(ppgtt);
>  
> - if (bitmap_empty(pdp->used_pdpes, I915_PDPES_PER_PDP(dev_priv)))
> - return true;
> -
>   return false;
>  }
>  
>

-- 
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 01/14] drm: add HDMI 2.0 VIC support for AVI info-frames

[Sharma, Shashank]

Hello Thierry,

Thanks for the comments.

In fact, that was the plan earlier, but the problem is, this function is 
being called from several drivers, and not all of them have
the drm_connector readily available with their caller function. For few 
drivers, I might have to go up two to three levels in stack,
to get and pass the drm_connector, which means, I have to modify those 
drivers up to two-to-three levels.

It dint seem right, so we decided to call it with a bool.

Regards
Shashank
On 6/15/2017 1:50 AM, Thierry Reding wrote:

On Wed, Jun 14, 2017 at 11:17:32PM +0530, Shashank Sharma wrote:
[...]

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2e55599..d312fe1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4334,12 +4334,14 @@ EXPORT_SYMBOL(drm_set_preferred_mode);
   *  data from a DRM display mode
   * @frame: HDMI AVI infoframe
   * @mode: DRM display mode
+ * @is_hdmi2_sink: Sink is HDMI 2.0 compliant
   *
   * Return: 0 on success or a negative error code on failure.
   */
  int
  drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
-const struct drm_display_mode *mode)
+const struct drm_display_mode *mode,
+bool is_hdmi2_sink)

Perhaps instead of passing a boolean flag here we could pass a const
struct drm_hdmi_info *. That way the checks could be made more explicit
and it becomes more obvious what to pass into the function. Also, as it
is every driver will have to derive is_hdmi2_sink by itself, and they're
likely to have to do the same thing as i915 anyway.

Thierry


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

[Mahesh Kumar]

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/

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->wm[level];
-
- if (level > max_level || level_wm->plane_res_b == 0
-   || level_wm->plane_res_l >= 31
-   || level_wm->plane_res_b >= plane_ddb) {
- level_wm->plane_en = false;
- level_wm->plane_res_b = 0;
- level_wm->plane_res_l = 0;
- } else {
- level_wm->plane_en = true;
- }
- }
-}
-
  static int
  skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
-   struct skl_pipe_wm *pipe_wm,
 struct skl_ddb_allocation *ddb /* out */)
  {
   struct drm_atomic_state *state = cstate->base.state;
   struct drm_crtc *crtc = cstate->base.crtc;
   struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
   enum pipe pipe = intel_crtc->pipe;
   struct skl_ddb_entry *alloc = &cstate->wm.skl.ddb;
@@ -4187,9 +4159,6 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
*intel_crtc,
   unsigned plane_data_rate[I915_MAX_PLANES] = {};
   unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
   uint16_t total_min_blocks = 0;
- uint16_t total_level_ddb;
- uint16_t plane_blocks = 0;
- int max_level, level;

   /* Clear the partitioning for disabled planes. */
   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
@@ -4228,48 +4197,10 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
*intel_crtc,
   return -EINVAL;
   }

- alloc_size -= minimum[PLANE_CURSO

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

[Anuar, Nuhairi]

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.



From: Anuar, Nuhairi
Sent: Wednesday, June 14, 2017 10:55 PM
To: Ville Syrjälä ; He, Min 
Cc: intel-gfx@lists.freedesktop.org; Mustaffa, Mustamin B 

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

For a virtualized boot, it is possible for port A to be tied to DP.

Min He any additional comment?

On Jun 14, 2017 9:38 PM, Ville Syrjälä 
mailto:ville.syrj...@linux.intel.com>> wrote:
On Wed, Jun 14, 2017 at 01:47:30PM +0800, Mustamin B Mustaffa wrote:
> From: "Anuar, Nuhairi" 
> mailto:nuhairi.an...@intel.com>>
>
> In GVT guest, when port A is DP, i915 will force it as an EDP panel,
> which
> will cause DP-1 not working in GVT guest.
> This patch fixed this issue by check intel_vgpu_active() in
> intel_ddi_compute_config().
>
> Signed-off-by: Min He mailto:min...@intel.com>>
> Signed-off-by: Nuhairi Anuar 
> mailto:nuhairi.an...@intel.com>>
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 66b367d..1110cbc 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2069,7 +2069,7 @@ static bool intel_ddi_compute_config(struct 
> intel_encoder *encoder,
>
>WARN(type == INTEL_OUTPUT_UNKNOWN, "compute_config() on unknown 
> output!\n");
>
> - if (port == PORT_A)
> + if (port == PORT_A && !intel_vgpu_active(dev_priv))
>pipe_config->cpu_transcoder = TRANSCODER_EDP;

And why exactly are you trying to register DP on port A?

>
>if (type == INTEL_OUTPUT_HDMI)
> --
> 1.9.1
>
> ___
> 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

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

[Patchwork]

== Series Details ==

Series: drm: add asynchrounous plane update
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] 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.

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

Only build tested!

 drivers/gpu/drm/vc4/vc4_kms.c   | 20 +
 drivers/gpu/drm/vc4/vc4_plane.c | 99 +++--
 2 files changed, 55 insertions(+), 64 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(&vc4->async_modeset);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_prepare_planes(dev, state);
+   if (ret) {
+   up(&vc4->async_modeset);
+   return ret;
+   }
+
+   drm_atomic_helper_async_commit(dev, state);
+
+   drm_atomic_helper_cleanup_planes(dev, state);
+
+   up(&vc4->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..44d3a01 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -736,70 +736,38 @@ 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;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
 
-   /* Update the display list based on the new crtc_x/y. */
-   vc4_plane_atomic_check(plane,

[Intel-gfx] [PATCH v2 5/6] drm/msm: remove mdp5_cursor_plane_funcs

[Gustavo Padovan]

From: Gustavo Padovan 

After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.

Cc: Rob Clark 
Cc: Archit Taneja 
Signed-off-by: Gustavo Padovan 
Tested-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
 1 file changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index bb5ee03..e6bf21d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -247,19 +247,6 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
.atomic_print_state = mdp5_plane_atomic_print_state,
 };
 
-static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = mdp5_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_set_property = mdp5_plane_atomic_set_property,
-   .atomic_get_property = mdp5_plane_atomic_get_property,
-   .reset = mdp5_plane_reset,
-   .atomic_duplicate_state = mdp5_plane_duplicate_state,
-   .atomic_destroy_state = mdp5_plane_destroy_state,
-   .atomic_print_state = mdp5_plane_atomic_print_state,
-};
-
 static int mdp5_plane_prepare_fb(struct drm_plane *plane,
 struct drm_plane_state *new_state)
 {
@@ -,16 +1098,9 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
 
spin_lock_init(&mdp5_plane->pipe_lock);
 
-   if (type == DRM_PLANE_TYPE_CURSOR)
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   &mdp5_cursor_plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
-   else
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   &mdp5_plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
+   ret = drm_universal_plane_init(dev, plane, 0xff, &mdp5_plane_funcs,
+  mdp5_plane->formats,
+  mdp5_plane->nformats, type, NULL);
if (ret)
goto fail;
 
-- 
2.9.4

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

[Intel-gfx] [PATCH v2 4/6] drm/msm: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

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

v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja)

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

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

Cc: Rob Clark 
Cc: Archit Taneja 
Signed-off-by: Gustavo Padovan 
Tested-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +-
 drivers/gpu/drm/msm/msm_atomic.c  |   6 ++
 2 files changed, 69 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 5e7d9af..bb5ee03 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -33,15 +33,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);
 
-static int mdp5_update_cursor_plane_legacy(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 struct mdp5_kms *get_kms(struct drm_plane *plane)
 {
struct msm_drm_private *priv = plane->dev->dev_private;
@@ -257,7 +248,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
 };
 
 static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = mdp5_update_cursor_plane_legacy,
+   .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = mdp5_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
@@ -484,11 +475,73 @@ static void mdp5_plane_atomic_update(struct drm_plane 
*plane,
}
 }
 
+static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+   state->crtc);
+   if (WARN_ON(!crtc_state))
+   return -EINVAL;
+
+   if (!crtc_state->active)
+   return -EINVAL;
+
+   mdp5_state = to_mdp5_plane_state(state);
+
+   /* don't use fast path if we don't have a hwpipe allocated yet */
+   if (!mdp5_state->hwpipe)
+   return -EINVAL;
+
+   /* only allow changing of position(crtc x/y or src x/y) in fast path */
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb ||
+   plane->state->fb != state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+  struct drm_plane_state *new_state)
+{
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+
+   if (plane_enabled(new_state)) {
+   struct mdp5_ctl *ctl;
+   struct mdp5_pipeline *pipeline =
+   mdp5_crtc_get_pipeline(plane->crtc);
+   int ret;
+
+   ret = mdp5_plane_mode_set(plane, new_state->crtc, new_state->fb,
+   &new_state->src, &new_state->dst);
+   WARN_ON(ret < 0);
+
+   ctl = mdp5_crtc_get_ctl(new_state->crtc);
+
+   mdp5_ctl_commit(ctl, pipeline, mdp5_plane_get_flush(plane));
+   }
+
+   *to_mdp5_plane_state(plane->state) =
+   *to_mdp5_plane_state(new_state);
+}
+
 static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
.prepare_fb = mdp5_plane_prepare_fb,
.cleanup_fb = mdp5_plane_cleanup_fb,
.atomic_check = mdp5_plane_atomic_check,
.atomic_update = mdp5_plane_atomic_update,
+   .atomic_async_check = mdp5_plane_atomic_async_check,
+   .atomic_async_update = mdp5_plane_atomic_async_update,
 };
 
 static void set_scanout_locked(struct mdp5_kms *mdp5_kms,
@@ -997,84 +1050,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
re

[Intel-gfx] [PATCH v2 0/6] drm: add asynchrounous plane update

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

Another iteration on this patchset. Added some a-b and r-b tags to
it and fixed issues in patch 6 reported by Eric. That patch still needs
testing but the rest is tested and working, looking to be already in a good
shape. More info in the email from the previous version:

https://www.spinics.net/lists/dri-devel/msg142522.html

Please let me know what you think. Thanks.

Gustavo

--
Gustavo Padovan (6):
  drm/atomic: initial support for asynchronous plane update
  drm/i915: update cursors asynchronously through atomic
  drm/i915: remove intel_cursor_plane_funcs
  drm/msm: update cursors asynchronously through atomic
  drm/msm: remove mdp5_cursor_plane_funcs
  drm/vc4: update cursors asynchronously through atomic

 drivers/gpu/drm/drm_atomic.c  |  70 
 drivers/gpu/drm/drm_atomic_helper.c   |  35 ++
 drivers/gpu/drm/i915/intel_atomic_plane.c |  73 +
 drivers/gpu/drm/i915/intel_display.c  | 160 ---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 175 +++---
 drivers/gpu/drm/msm/msm_atomic.c  |   6 +
 drivers/gpu/drm/vc4/vc4_kms.c |  20 
 drivers/gpu/drm/vc4/vc4_plane.c   |  99 ++---
 include/drm/drm_atomic.h  |   2 +
 include/drm/drm_atomic_helper.h   |   2 +
 include/drm/drm_modeset_helper_vtables.h  |  50 +
 11 files changed, 382 insertions(+), 310 deletions(-)

-- 
2.9.4

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

[Intel-gfx] [PATCH v2 2/6] drm/i915: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

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

v3:
- set correct vma to new state for cleanup
- move size checks back to drivers (Ville Syrjälä)

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

Cc: Daniel Vetter 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  73 +++
 drivers/gpu/drm/i915/intel_display.c  | 149 +-
 2 files changed, 97 insertions(+), 125 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index a40c82c..1737b8a 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -246,11 +246,84 @@ static void intel_plane_atomic_update(struct drm_plane 
*plane,
}
 }
 
+static int intel_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+   struct drm_crtc *crtc = plane->state->crtc;
+   struct drm_crtc_state *crtc_state = crtc->state;
+
+   if (plane->type != DRM_PLANE_TYPE_CURSOR)
+   return -EINVAL;
+
+   /*
+* When crtc is inactive or there is a modeset pending,
+* wait for it to complete in the slowpath
+*/
+   if (!crtc_state->active || to_intel_crtc_state(crtc_state)->update_pipe)
+   return -EINVAL;
+
+   /*
+* If any parameters change that may affect watermarks,
+* take the slowpath. Only changing fb or position should be
+* in the fastpath.
+*/
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb != !state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void intel_plane_atomic_async_update(struct drm_plane *plane,
+   struct drm_plane_state *new_state)
+{
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   struct drm_crtc *crtc = plane->state->crtc;
+   struct drm_framebuffer *old_fb;
+   struct i915_vma *old_vma;
+
+   old_vma = to_intel_plane_state(plane->state)->vma;
+   old_fb = plane->state->fb;
+
+   i915_gem_track_fb(intel_fb_obj(old_fb), intel_fb_obj(new_state->fb),
+ intel_plane->frontbuffer_bit);
+
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+   plane->state->fb = new_state->fb;
+   *to_intel_plane_state(plane->state) = *to_intel_plane_state(new_state);
+
+   to_intel_plane_state(new_state)->vma = old_vma;
+   new_state->fb = old_fb;
+
+   if (plane->state->visible) {
+   trace_intel_update_plane(plane, to_intel_crtc(crtc));
+   intel_plane->update_plane(plane,
+ to_intel_crtc_state(crtc->state),
+ to_intel_plane_state(plane->state));
+   } else {
+   trace_intel_disable_plane(plane, to_intel_crtc(crtc));
+   intel_plane->disable_plane(plane, crtc);
+   }
+
+   mutex_lock(&plane->dev->struct_mutex);
+   intel_cleanup_plane_fb(plane, new_state);
+   mutex_unlock(&plane->dev->struct_mutex);
+}
+
 const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
.atomic_check = intel_plane_atomic_check,
.atomic_update = intel_plane_atomic_update,
+   .atomic_async_check = intel_plane_atomic_async_check,
+   .atomic_async_update = intel_plane_atomic_async_update,
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e6e2670..bc24fc4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13004,6 +13004,26 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
 
+   /*
+* The atomic async update fast path takes care
+* of avoiding the vblank waits for simple cursor
+* movement and flips. For cursor on/off and size changes,
+* we want to perform the vblank waits so that watermark
+* updates happen during the correct frames. Gen9+ have
+* double buffered watermarks and so shouldn't need this.
+*/
+   if (state->async_update) {
+   ret = mutex_lock_interruptible(&dev->struct_mutex);
+   if (

[Intel-gfx] [PATCH v2 1/6] drm/atomic: initial support for asynchronous plane update

[Gustavo Padovan]

From: Gustavo Padovan 

In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we update the
cursor synchronously through the atomic API it will cause significant
delays that would even be noticed by the final user.

This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic steps in
drm_atomic_helper_commit(). We take this path for legacy cursor updates.

For now only single plane updates are supported, but we plan to support
multiple planes updates and async PageFlips through this interface as well
in the near future.

v5:
- improve comments (Eric Anholt)

v4:
- fix state->crtc NULL check (Archit Taneja)

v3:
- fix iteration on the wrong crtc state
- put back code to forbid updates if there is a queued update for
the same plane (Ville Syrjälä)
- move size checks back to drivers (Ville Syrjälä)
- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)

v2:
- allow updates even if there is a queued update for the same
plane.
- fixes on the documentation (Emil Velikov)
- unconditionally call ->atomic_async_update (Emil Velikov)
- check for ->atomic_async_update earlier (Daniel Vetter)
- make ->atomic_async_check() the last step (Daniel Vetter)
- add ASYNC_UPDATE flag (Eric Anholt)
- update state in core after ->atomic_async_update (Eric Anholt)
- update docs (Eric Anholt)

Cc: Daniel Vetter 
Cc: Rob Clark 
Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Archit Taneja 
Acked-by: Eric Anholt 
---
 drivers/gpu/drm/drm_atomic.c | 70 
 drivers/gpu/drm/drm_atomic_helper.c  | 35 
 include/drm/drm_atomic.h |  2 +
 include/drm/drm_atomic_helper.h  |  2 +
 include/drm/drm_modeset_helper_vtables.h | 50 +++
 5 files changed, 159 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 77dcef0..c25d359 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -643,6 +643,73 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return 0;
 }
 
+static bool drm_atomic_async_check(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_commit *commit;
+   struct drm_plane *__plane, *plane = NULL;
+   struct drm_plane_state *__plane_state, *plane_state = NULL;
+   const struct drm_plane_helper_funcs *funcs;
+   int i, j, n_planes = 0;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   return false;
+   }
+
+   for_each_new_plane_in_state(state, __plane, __plane_state, i) {
+   n_planes++;
+   plane = __plane;
+   plane_state = __plane_state;
+   }
+
+   /* FIXME: we support only single plane updates for now */
+   if (!plane || n_planes != 1)
+   return false;
+
+   if (!plane_state->crtc)
+   return false;
+
+   funcs = plane->helper_private;
+   if (!funcs->atomic_async_update)
+   return false;
+
+   if (plane_state->fence)
+   return false;
+
+   /*
+* Don't do an async update if there is an outstanding commit modifying
+* the plane.  This prevents our async update's changes from getting
+* overridden by a previous synchronous update's state.
+*/
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (plane->crtc != crtc)
+   continue;
+
+   spin_lock(&crtc->commit_lock);
+   commit = list_first_entry_or_null(&crtc->commit_list,
+ struct drm_crtc_commit,
+ commit_entry);
+   if (!commit) {
+   spin_unlock(&crtc->commit_lock);
+   continue;
+   }
+   spin_unlock(&crtc->commit_lock);
+
+   if (!crtc->state->state)
+   continue;
+
+   for_each_plane_in_state(crtc->state->state, __plane,
+   __plane_state, j) {
+   if (__plane == plane)
+   return false;
+   }
+   }
+
+   return !funcs->atomic_async_check(plane, plane_state);
+}
+
 static void drm_atomic_crtc_print_state(struct drm_printer *p,
const struct drm_crtc_state *state)
 {
@@ -1664,6 +1731,9 @@ int drm_atomic_c

[Intel-gfx] [PATCH v2 3/6] drm/i915: remove intel_cursor_plane_funcs

[Gustavo Padovan]

From: Gustavo Padovan 

After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.

Cc: Daniel Vetter 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bc24fc4..315c6e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13412,17 +13412,6 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_destroy_state = intel_plane_destroy_state,
 };
 
-static const struct drm_plane_funcs intel_cursor_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = intel_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_get_property = intel_plane_atomic_get_property,
-   .atomic_set_property = intel_plane_atomic_set_property,
-   .atomic_duplicate_state = intel_plane_duplicate_state,
-   .atomic_destroy_state = intel_plane_destroy_state,
-};
-
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13669,7 +13658,7 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
cursor->disable_plane = intel_disable_cursor_plane;
 
ret = drm_universal_plane_init(&dev_priv->drm, &cursor->base,
-  0, &intel_cursor_plane_funcs,
+  0, &intel_plane_funcs,
   intel_cursor_formats,
   ARRAY_SIZE(intel_cursor_formats),
   DRM_PLANE_TYPE_CURSOR,
-- 
2.9.4

___
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

[Zhang, Xiong Y]

> On Thu, Jun 15, 2017 at 11:11:45AM +0800, 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 
> 
> Looks ok to me, this is the assumption of the non-passthrough case
> anyway:
> Reviewed-by: Imre Deak 
> 
> I noticed a few issues in the surrounding code: SPT/SPT_LP and
> CNP/CNP_LP have the same problem, although we don't need to distinguish
> between them atm. I think a cleaner way would be to adjust id and ext_id
> in the pass-through case in intel_detect_pch() upfront and set
> dev_priv->pch_type accordingly the same way as it's done in the
> non-passthrough case.
[Zhang, Xiong Y] Thanks for your suggestion.
pch_id in passthrough is guessed and isn't fully accurate,  so I don't add it to
SPT and CNP. Currently we are seeking acceptable method to pass pch id from
host to guest, once this decided, we will follow your suggestion.
> 
> Also, unrelated to the pass-through case, the HAS_PCH_CNP_LP() macro
> looks bogus, it checks only 8 bits of the PCI device ID instead of 9, so
> it'll be false on CNP_LP platforms (and true on SPT_LP).
[Zhang, Xiong Y] Please help fix it although HAS_PCH_CNP_LP() isn't used atm.
> 
> --Imre
> 
> > ---
> >  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;
> > --
> > 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Set value of fake mst encoder's hpd pin

[Patchwork]

== Series Details ==

Series: drm/i915: Set value of fake mst encoder's hpd pin
URL   : https://patchwork.freedesktop.org/series/25810/
State : success

== Summary ==

Series 25810v1 drm/i915: Set value of fake mst encoder's hpd pin
https://patchwork.freedesktop.org/api/1.0/series/25810/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test kms_busy:
Subgroup basic-flip-default-b:
dmesg-warn -> FAIL   (fi-skl-6700hq) fdo#101144
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#100461

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
fdo#100461 https://bugs.freedesktop.org/show_bug.cgi?id=100461

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:445s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
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:505s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:490s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:589s
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:414s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:418s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:489s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
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:581s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:460s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:405s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:484s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:0   skip:29  
time:403s

cafd1e4df1e6e039268c4e4b1a55c88915d21f2e drm-tip: 2017y-06m-14d-19h-56m-24s UTC 
integration manifest
4e64830 drm/i915: Set value of fake mst encoder's hpd pin

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Set value of fake mst encoder's hpd pin

[Ethan Hsieh]

We receive hotplug event, but do not handle it. Set value of fake mst
encoder's hpd pin to handle hotplug event.

Before applying the patch:
[   36.595058] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 
0x0020, dig 0x10101012, pins 0x0020
[   36.595172] [drm:i915_hotplug_work_func [i915]] running encoder hotplug 
functions

After applying the patch:
[   29.807410] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 
0x0020, dig 0x10101012, pins 0x0020
[   29.807524] [drm:i915_hotplug_work_func [i915]] running encoder hotplug 
functions
[   30.086098] [drm:i915_hotplug_work_func [i915]] Connector DP-4 (pin 5) 
received hotplug event.
[   30.086123] [drm:i915_hotplug_work_func [i915]] [CONNECTOR:74:DP-4] status 
updated from connected to disconnected
[   30.086181] [drm:intel_dp_destroy_mst_connector [i915]]
[   30.087752] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
[CONNECTOR:74:DP-4] disconnected
[   30.091979] [drm:drm_mode_setcrtc [drm]] [CRTC:39:pipe B]

Signed-off-by: Ethan Hsieh 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3715386..2ef9f18 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -563,6 +563,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port 
*intel_dig_port, enum
intel_encoder->type = INTEL_OUTPUT_DP_MST;
intel_encoder->power_domain = intel_dig_port->base.power_domain;
intel_encoder->port = intel_dig_port->port;
+   intel_encoder->hpd_pin = intel_dig_port->base.hpd_pin;
intel_encoder->crtc_mask = 0x7;
intel_encoder->cloneable = 0;
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH RESEND v11 0/3] Enhancement to intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

Friendly ping.

Is this patch set good to go now?

On Mon, Jun 5, 2017 at 2:56 PM, Puthikorn Voravootivat 
wrote:

> This patch set contain 3 patches which are already reviewed by DK.
> Another 6 patches in previous version was already merged in v7 and v9.
> - First patch sets the PWM freqency to match data in panel vbt.
> - Next patch adds heuristic to determine whether we should use AUX
>   or PWM pin to adjust panel backlight brightness.
> - Last patch adds support for dynamic brightness.
>
> Change log:
> v11:
> - Reorder patches in v10 to make the last patch come first
> - Fix nits
>
> v10:
> - Add heuristic in patch #1
> - Add _unsafe mod option in patch #1, #2
> - handle frequency set error in patch #3
>
> v9:
> - Fix nits in v8
>
> v8:
> - Drop 4 patches that was already merged
> - Move DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check to patch #2 to avoid
>   behavior change if only apply patch #1
> - Add TODO to warn about enable backlight twice in patch #2
> - Use DIV_ROUND_CLOSEST instead of just "/" in patch #5
> - Fix bug calculate pn in patch #5
> - Clarify commit  message / code comment in patch #5
>
> v7:
> - Add check in intel_dp_pwm_pin_display_control_capable in patch #4
> - Add option in patch #6 to enable DPCD or not
> - Change definition in patch #8 and implementation in #9 to use Khz
> - Fix compiler warning from build bot in patch #9
>
> v6:
> - Address review from Dhinakaran
> - Make PWM frequency to have highest value of Pn that make the
>   frequency still within 25% of desired frequency.
>
> v5:
> - Split first patch in v4 to 3 patches
> - Bump priority for "Correctly enable backlight brightness adjustment via
> DPCD"
> - Make logic clearer for the case that both PWM pin and AUX are supported
> - Add more log when write to register fail
> - Add log when enable DBC
>
> v4:
> - Rebase / minor typo fix.
>
> v3:
> - Add new implementation of PWM frequency patch
>
> v2:
> - Drop PWM frequency patch
> - Address suggestion from Jani Nikula
>
> Puthikorn Voravootivat (3):
>   drm/i915: Set PWM divider to match desired frequency in vbt
>   drm/i915: Add heuristic to determine better way to adjust brightness
>   drm/i915: Add option to support dynamic backlight via DPCD
>
>  drivers/gpu/drm/i915/i915_params.c|  12 +-
>  drivers/gpu/drm/i915/i915_params.h|   5 +-
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 185
> --
>  3 files changed, 186 insertions(+), 16 deletions(-)
>
> --
> 2.13.0.506.g27d5fe0cd-goog
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Set output pipe after mode change to refresh output

[Lyude Paul]

On Wed, 2017-06-14 at 14:47 +0300, Paul Kocialkowski wrote:
> This adds a call to igt_output_set_pipe in orde to refresh output via
> igt_output_refresh and ensure that mode override can take effect.
> 
> Without this change, using a lower resolution during frame dumps
> series with mode changes (e.g. test_display_frame_dump) would not
> commit the mode change to the output and leave it with a framebuffer
> too small for the previously-commited resolution.
> 
> This would cause the test to fail. This allows it to pass.
> 
> Signed-off-by: Paul Kocialkowski 
Reviewed-by: Lyude Paul 

Thanks for the important fix! This must have gotten broken with some
igt rework someone did down the line while I was gone. Will push in a
moment :).

> ---
>  tests/chamelium.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tests/chamelium.c b/tests/chamelium.c
> index 2e14ccb9..76b14e95 100644
> --- a/tests/chamelium.c
> +++ b/tests/chamelium.c
> @@ -322,6 +322,8 @@ enable_output(data_t *data,
>   igt_plane_set_fb(primary, fb);
>   igt_output_override_mode(output, mode);
>  
> + igt_output_set_pipe(output, output->config.pipe);
> +
>   /* Clear any color correction values that might be enabled
> */
>   igt_pipe_set_degamma_lut(primary->pipe, NULL, 0);
>   igt_pipe_set_gamma_lut(primary->pipe, NULL, 0);
-- 
Cheers,
Lyude
___
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"

[Matt Roper]

On Wed, Jun 14, 2017 at 02:47:06PM +0300, 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.
> 
> Ander

Acknowledged-by: Matt Roper 

for the revert, unless Mahesh or Maarten have an idea for an immediate
fix that can be merged instead.

Let us know when you've had a chance to file a bugzilla with logs and
such so that we can investigate in more detail.


Matt

> 
> > 
> > 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->wm[level];
> > > > -
> > > > - if (level > max_level || level_wm->plane_res_b == 0
> > > > -   || level_wm->plane_res_l >= 31
> > > > -   || level_wm->plane_res_b >= 
> > > > plane_ddb) {
> > > > - level_wm->plane_en = false;
> > > > - level_wm->plane_res_b = 0;
> > > > - level_wm->plane_res_l = 0;
> > > > - } else {
> > > > - level_wm->plane_en = true;
> > > > - }
> > > > - }
> > > > -}
> > > > -
> > > >  static int
> > > >  skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> > > > -   struct skl_pipe_wm *pipe_wm,
> > > > struct skl_ddb_allocation *ddb /* out */)
> > > >  {
> > > >   struct drm_atomic_state *state = cstate->base.state;
> > > >   struct drm_crtc *crtc = cstate->base.crtc;
> > > >   struct drm_device *dev = crtc->dev;
> > > > - struct drm_i915_private *dev_priv = to_i915(dev);
> > > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > >   enum pipe pipe = intel_crtc->pipe;
> > > >   struct skl_ddb_entry *alloc = &cstate->wm.skl.ddb;
> > > > @@ -4187,9 +4159,6 @@ int skl_check_pipe_max_pixel_rate(struct 
> > > > intel_crtc *intel_crtc,
> > > >   unsigned plane_data_rate[I915_MAX_PLANES] = {};
> > > >   unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
> > > >

Re: [Intel-gfx] [PATCH v3 01/14] drm: add HDMI 2.0 VIC support for AVI info-frames

[Thierry Reding]

On Wed, Jun 14, 2017 at 11:17:32PM +0530, Shashank Sharma wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 2e55599..d312fe1 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4334,12 +4334,14 @@ EXPORT_SYMBOL(drm_set_preferred_mode);
>   *  data from a DRM display mode
>   * @frame: HDMI AVI infoframe
>   * @mode: DRM display mode
> + * @is_hdmi2_sink: Sink is HDMI 2.0 compliant
>   *
>   * Return: 0 on success or a negative error code on failure.
>   */
>  int
>  drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
> -  const struct drm_display_mode *mode)
> +  const struct drm_display_mode *mode,
> +  bool is_hdmi2_sink)

Perhaps instead of passing a boolean flag here we could pass a const
struct drm_hdmi_info *. That way the checks could be made more explicit
and it becomes more obvious what to pass into the function. Also, as it
is every driver will have to derive is_hdmi2_sink by itself, and they're
likely to have to do the same thing as i915 anyway.

Thierry


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] drm/i915: Don't enable backlight at setup time.

[Puthikorn Voravootivat]

I tested this on actual system and it is working fine.

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(&connector->
> 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(&connector->
> 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(&connector->
> encoder->base);
> struct intel_panel *panel = &connector->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
>
>
___
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 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] drm/i915: decouple runtime PM enablement from DMC presence

[Atwood, Matthew S]

"dmc_payload is checked right before..." You are correct, there is no bug. It 
was my misunderstanding.

"What if someone doesn't really want to use DMC but still wants D3hot?"  or 
other great stuff that RPM can do without DMC firmware support?

From: Rodrigo Vivi [rodrigo.v...@gmail.com]
Sent: Wednesday, June 14, 2017 1:02 PM
To: Deak, Imre
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 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?

>
>> 
>> 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] drm/i915: decouple runtime PM enablement from DMC presence

[Rodrigo Vivi]

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?

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

[Intel-gfx] [igt PATCH] igt/pm_rps: Remove remaining assert on CUR <= MAX

[jeff . mcgee]

From: Jeff McGee 

This completes the change started by:

commit 39cccab83b7c515a2b57abe679a8cb304c8933ef
Author: Chris Wilson 
Date:   Fri May 19 09:41:40 2017 +0100

igt/pm_rps: Allow CUR to be greater than MAX (overclocking)

Cc: Chris Wilson 
Signed-off-by: Jeff McGee 
---
 tests/pm_rps.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index f0455e78..1a322459 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -145,7 +145,6 @@ static int do_writeval(FILE *filp, int val, int lerrno, 
bool readback_check)
 static void checkit(const int *freqs)
 {
igt_assert_lte(freqs[MIN], freqs[MAX]);
-   igt_assert_lte(freqs[CUR], freqs[MAX]);
igt_assert_lte(freqs[RPn], freqs[CUR]);
igt_assert_lte(freqs[RPn], freqs[MIN]);
igt_assert_lte(freqs[MAX], freqs[RP0]);
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 08:11:18PM +0200, Maarten Lankhorst wrote:
> Op 14-06-17 om 16:52 schreef Ville Syrjälä:
> > On Wed, Jun 14, 2017 at 11:08:41AM +0200, Maarten Lankhorst wrote:
> >> Moving the wait to a helper allows callers outside of the core to
> >> wait for pending updates to complete.
> >>
> >> This can be used to prevent races against nonblocking modesets.
> >> Only the hw_done call in swap_state is moved to a helper, doing
> >> it for the other callers requires too many changes and I think this
> >> is the only useful one to export.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/drm_atomic_helper.c | 51 
> >> +++--
> >>  include/drm/drm_atomic_helper.h |  1 +
> >>  2 files changed, 38 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 86d3093c6c9b..1b068ce1aea9 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -2067,6 +2067,41 @@ void drm_atomic_helper_cleanup_planes(struct 
> >> drm_device *dev,
> >>  EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
> >>  
> >>  /**
> >> + * drm_atomic_helper_wait_for_hw_done - wait for all previous hw updates 
> >> to complete.
> >> + * @crtc: crtc to wait on.
> >> + *
> >> + * This function waits for all previous hardware updates queued on @crtc
> >> + * to complete.
> >> + *
> >> + * Returns:
> >> + * 0 on success, negative error code on failure.
> >> + */
> >> +int drm_atomic_helper_wait_for_hw_done(struct drm_crtc *crtc)
> >> +{
> >> +  struct drm_crtc_commit *commit;
> >> +  long ret;
> >> +
> >> +  spin_lock(&crtc->commit_lock);
> >> +  commit = list_first_entry_or_null(&crtc->commit_list,
> >> +  struct drm_crtc_commit, commit_entry);
> >> +  if (commit)
> >> +  drm_crtc_commit_get(commit);
> >> +  spin_unlock(&crtc->commit_lock);
> >> +
> >> +  if (!commit)
> >> +  return 0;
> >> +
> >> +  ret = wait_for_completion_timeout(&commit->hw_done, 10 * HZ);
> >> +  drm_crtc_commit_put(commit);
> >> +
> >> +  if (ret == 0)
> >> +  return -EBUSY;
> > -ETIMEDOUT ?
> ETIMEDOUT -> /* Connection timed out */

It's the standard "something timed out" errno. Used all over drm.

> 
> No I don't think that would match.

-- 
Ville Syrjälä
Intel OTC
___
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: Misc improvements around module params (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Misc improvements around module params (rev3)
URL   : https://patchwork.freedesktop.org/series/25482/
State : success

== Summary ==

Series 25482v3 drm/i915: Misc improvements around module params
https://patchwork.freedesktop.org/api/1.0/series/25482/revisions/3/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#100461

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:443s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:430s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:583s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:507s
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:480s
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:435s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
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:576s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:463s
fi-skl-6700hqtotal:278  pass:227  dwarn:2   dfail:0   fail:27  skip:22  
time:401s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:467s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:480s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:435s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:400s

66555696fc0f33fc19eca5068783b95ecc8a91d5 drm-tip: 2017y-06m-14d-09h-56m-45s UTC 
integration manifest
a3d6b09 drm/i915/debugfs: Highlight modified i915 params
8f57486 drm/i915: Highlight modified i915 params in gpu error state
4eafbce drm/i915: Extend PARAMS_FOR_EACH macro with more data
377978d drm/i915: Rename lvds_use_ssc modparam to panel_use_ssc

== Logs ==

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

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

[Michal Wajdeczko]

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, &i915.x);
+#define PRINT_PARAM(X, T, V, U, M, B, D) seq_print_param(m, #X, #T, &i915.X);
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, &p->x);
+#define PRINT(X, T, V, U, M, B, D) err_print_param(m, #X, #T, &p->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, &error->params.x);
+#define FREE(X, T, V, U, M, B, D) free_param(#T, &error->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, &error->params.x);
+#define DUP(X, T, V, U, M, B, D) dup_param(#T, &error->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 = -1,
-   .enable_dc = -1,
-   .enable_fbc = -1,
-   .enable_execlists = -1,
-   .enable_hangcheck = true,
-   .enable_ppgtt = -1,
-   .enable_psr = -1,
-   .alpha_support = IS_ENABLED(CONFIG_DRM_I915_A

[Intel-gfx] [PATCH v3 0/4] drm/i915: Misc improvements around module params

[Michal Wajdeczko]

Earlier RFC proposed to extend param macros with default values.
This series goes step further.

v2: rename modparam instead of i915_params field
v3: refactor master macro and debugfs/error printers

Michal Wajdeczko (4):
  drm/i915: Rename lvds_use_ssc modparam to panel_use_ssc
  drm/i915: Extend PARAMS_FOR_EACH macro with more data
  drm/i915: Highlight modified i915 params in gpu error state
  drm/i915/debugfs: Highlight modified i915 params

 drivers/gpu/drm/i915/i915_debugfs.c   |  38 +++---
 drivers/gpu/drm/i915/i915_drv.h   |  20 +++
 drivers/gpu/drm/i915/i915_gpu_error.c |  34 +++--
 drivers/gpu/drm/i915/i915_params.c| 234 ++
 drivers/gpu/drm/i915/i915_params.h| 182 +++---
 5 files changed, 207 insertions(+), 301 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v3 4/4] drm/i915/debugfs: Highlight modified i915 params

[Michal Wajdeczko]

We know default values for all params and we know which params are safe
to change. Mark params that were changed when dumping them in debugfs.

v2: simplify is_default calculation for strings (Chris)
v3: rebased and switched into custom seq_print macros (Michal)

Suggested-by: Chris Wilson 
Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Reviewed-by: Lukasz Fiedorowicz  #2
---
 drivers/gpu/drm/i915/i915_debugfs.c | 38 +
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9fbba1e..bb71ff4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -35,21 +35,21 @@ static inline struct drm_i915_private *node_to_i915(struct 
drm_info_node *node)
return to_i915(node->minor->dev);
 }
 
-static __always_inline void seq_print_param(struct seq_file *m,
-   const char *name,
-   const char *type,
-   const void *x)
-{
-   if (!__builtin_strcmp(type, "bool"))
-   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, "uint"))
-   seq_printf(m, "i915.%s=%u\n", name, *(const unsigned int *)x);
-   else if (!__builtin_strcmp(type, "charp"))
-   seq_printf(m, "i915.%s=%s\n", name, *(const char **)x);
-   else
-   BUILD_BUG();
+#define seq_print_param_bool(m, name, x, tags) \
+   seq_printf(m, "i915.%s=%s%s\n", name, yesno(x), tags)
+#define seq_print_param_int(m, name, x, tags) \
+   seq_printf(m, "i915.%s=%d%s\n", name, x, tags)
+#define seq_print_param_uint(m, name, x, tags) \
+   seq_printf(m, "i915.%s=%u%s\n", name, x, tags)
+#define seq_print_param_charp(m, name, x, tags) \
+   seq_printf(m, "i915.%s=%s%s\n", name, x, tags)
+
+static inline const char *param_tags(bool is_default, bool is_unsafe)
+{
+   if (is_default)
+   return "";
+
+   return is_unsafe ? " [modified *unsafe*]": " [modified]";
 }
 
 static int i915_capabilities(struct seq_file *m, void *data)
@@ -66,9 +66,15 @@ static int i915_capabilities(struct seq_file *m, void *data)
 #undef PRINT_FLAG
 
kernel_param_lock(THIS_MODULE);
-#define PRINT_PARAM(X, T, V, U, M, B, D) seq_print_param(m, #X, #T, &i915.X);
+#define FLAG false
+#define FLAG_unsafe true
+#define PRINT_PARAM(X, T, V, U, M, B, D) \
+   seq_print_param_##T(m, #X, i915.X, \
+   param_tags(is_equal_##T(i915.X, V), FLAG##U));
I915_PARAMS_FOR_EACH(PRINT_PARAM);
 #undef PRINT_PARAM
+#undef FLAG
+#undef FLAG_unsafe
kernel_param_unlock(THIS_MODULE);
 
return 0;
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 1/4] drm/i915: Rename lvds_use_ssc modparam to panel_use_ssc

[Michal Wajdeczko]

This modparam affects not only LVDS but also eDP panels. Additionally
with this rename we will keep modparam and i915_params field name in sync.
Finally this patch will unblock us with further improvements around params defs.

Suggested-by: Ville Syrjala 
Signed-off-by: Michal Wajdeczko 
Cc: Ville Syrjala 
Cc: Chris Wilson 
---
 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 b6a7e36..6c27d33 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -105,8 +105,8 @@ MODULE_PARM_DESC(lvds_channel_mode,
 "Specify LVDS channel mode "
 "(0=probe BIOS [default], 1=single-channel, 2=dual-channel)");
 
-module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, 0600);
-MODULE_PARM_DESC(lvds_use_ssc,
+module_param_named_unsafe(panel_use_ssc, i915.panel_use_ssc, int, 0600);
+MODULE_PARM_DESC(panel_use_ssc,
"Use Spread Spectrum Clock with panels [LVDS/eDP] "
"(default: auto from VBT)");
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 3/4] drm/i915: Highlight modified i915 params in gpu error state

[Michal Wajdeczko]

We now know types and default values for all params.
Use dedicated err_print macros to dump them in gpu error state
and flag any that was modified.

Suggested-by: Chris Wilson 
Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h   | 20 
 drivers/gpu/drm/i915/i915_gpu_error.c | 30 ++
 2 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 38ef734..8bd6234 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -252,6 +252,26 @@ static inline const char *enableddisabled(bool v)
return v ? "enabled" : "disabled";
 }
 
+static inline bool is_equal_int(int a, int b)
+{
+   return a == b;
+}
+
+static inline bool is_equal_uint(unsigned int a, unsigned int b)
+{
+   return a == b;
+}
+
+static inline bool is_equal_bool(bool a, bool b)
+{
+   return a == b;
+}
+
+static inline bool is_equal_charp(const char *a, const char *b)
+{
+   return a && b ? !strcmp(a, b) : a == b;
+}
+
 enum pipe {
INVALID_PIPE = -1,
PIPE_A = 0,
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 000f733..3e388b3 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -546,27 +546,25 @@ static void err_print_capabilities(struct 
drm_i915_error_state_buf *m,
 #undef PRINT_FLAG
 }
 
-static __always_inline void err_print_param(struct drm_i915_error_state_buf *m,
-   const char *name,
-   const char *type,
-   const void *x)
-{
-   if (!__builtin_strcmp(type, "bool"))
-   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, "uint"))
-   err_printf(m, "i915.%s=%u\n", name, *(const unsigned int *)x);
-   else if (!__builtin_strcmp(type, "charp"))
-   err_printf(m, "i915.%s=%s\n", name, *(const char **)x);
-   else
-   BUILD_BUG();
+#define err_print_param_int(m, name, x, flag) \
+   err_printf(m, "i915.%s=%d%s\n", name, x, flag);
+#define err_print_param_uint(m, name, x, flag) \
+   err_printf(m, "i915.%s=%u%s\n", name, x, flag);
+#define err_print_param_bool(m, name, x, flag) \
+   err_printf(m, "i915.%s=%s%s\n", name, yesno(x), flag);
+#define err_print_param_charp(m, name, x, flag) \
+   err_printf(m, "i915.%s=%s%s\n", name, x, flag);
+
+static inline const char *param_flag(bool modified)
+{
+   return modified ? " [modified]" : "";
 }
 
 static void err_print_params(struct drm_i915_error_state_buf *m,
 const struct i915_params *p)
 {
-#define PRINT(X, T, V, U, M, B, D) err_print_param(m, #X, #T, &p->X);
+#define PRINT(X, T, V, U, M, B, D) \
+   err_print_param_##T(m, #X, p->X, param_flag(!is_equal_##T(V, p->X)));
I915_PARAMS_FOR_EACH(PRINT);
 #undef PRINT
 }
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

[Maarten Lankhorst]

Op 14-06-17 om 16:52 schreef Ville Syrjälä:
> On Wed, Jun 14, 2017 at 11:08:41AM +0200, Maarten Lankhorst wrote:
>> Moving the wait to a helper allows callers outside of the core to
>> wait for pending updates to complete.
>>
>> This can be used to prevent races against nonblocking modesets.
>> Only the hw_done call in swap_state is moved to a helper, doing
>> it for the other callers requires too many changes and I think this
>> is the only useful one to export.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c | 51 
>> +++--
>>  include/drm/drm_atomic_helper.h |  1 +
>>  2 files changed, 38 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 86d3093c6c9b..1b068ce1aea9 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -2067,6 +2067,41 @@ void drm_atomic_helper_cleanup_planes(struct 
>> drm_device *dev,
>>  EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
>>  
>>  /**
>> + * drm_atomic_helper_wait_for_hw_done - wait for all previous hw updates to 
>> complete.
>> + * @crtc: crtc to wait on.
>> + *
>> + * This function waits for all previous hardware updates queued on @crtc
>> + * to complete.
>> + *
>> + * Returns:
>> + * 0 on success, negative error code on failure.
>> + */
>> +int drm_atomic_helper_wait_for_hw_done(struct drm_crtc *crtc)
>> +{
>> +struct drm_crtc_commit *commit;
>> +long ret;
>> +
>> +spin_lock(&crtc->commit_lock);
>> +commit = list_first_entry_or_null(&crtc->commit_list,
>> +struct drm_crtc_commit, commit_entry);
>> +if (commit)
>> +drm_crtc_commit_get(commit);
>> +spin_unlock(&crtc->commit_lock);
>> +
>> +if (!commit)
>> +return 0;
>> +
>> +ret = wait_for_completion_timeout(&commit->hw_done, 10 * HZ);
>> +drm_crtc_commit_put(commit);
>> +
>> +if (ret == 0)
>> +return -EBUSY;
> -ETIMEDOUT ?
ETIMEDOUT -> /* Connection timed out */

No I don't think that would match.
___
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 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.

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for HDMI YCBCR output handling in DRM layer (rev3)

[Sharma, Shashank]

This is just missing the EXPORT_SYMBOL(drm_find_hdmi_output_type);
Will handle this. 

Regards
Shashank
-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org] 
Sent: Wednesday, June 14, 2017 11:22 PM
To: Sharma, Shashank 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for HDMI YCBCR output handling in DRM layer (rev3)

== Series Details ==

Series: HDMI YCBCR output handling in DRM layer (rev3)
URL   : https://patchwork.freedesktop.org/series/22684/
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
  CHK include/generated/uapi/linux/version.h
  DATAREL arch/x86/boot/compressed/vmlinux
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 99 modules
ERROR: "drm_find_hdmi_output_type" [drivers/gpu/drm/i915/i915.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1212: recipe for target 'modules' failed
make: *** [modules] Error 2

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for HDMI YCBCR output handling in DRM layer (rev3)

[Patchwork]

== Series Details ==

Series: HDMI YCBCR output handling in DRM layer (rev3)
URL   : https://patchwork.freedesktop.org/series/22684/
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
  CHK include/generated/uapi/linux/version.h
  DATAREL arch/x86/boot/compressed/vmlinux
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 99 modules
ERROR: "drm_find_hdmi_output_type" [drivers/gpu/drm/i915/i915.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1212: recipe for target 'modules' failed
make: *** [modules] Error 2

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

[Intel-gfx] [PATCH v3 13/14] drm/i915: set colorspace for ycbcr outputs

[Shashank Sharma]

When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 313918c..e1fc4ef 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -472,6 +472,14 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
return;
}
 
+   ret = drm_hdmi_avi_infoframe_set_colorspace(&frame.avi,
+   adjusted_mode,
+   crtc_state->hdmi_output);
+   if (ret < 0) {
+   DRM_ERROR("couldn't fill AVI colorspace\n");
+   return;
+   }
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode,
   crtc_state->limited_color_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 14/14] drm/i915/glk: set HDMI 2.0 identifier

[Shashank Sharma]

This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index e1fc4ef..429ff0f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1979,6 +1979,9 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
connector->doublescan_allowed = 0;
connector->stereo_allowed = 1;
 
+   if (IS_GEMINILAKE(dev_priv))
+   connector->is_hdmi2_src = true;
+
intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
 
switch (port) {
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 12/14] drm/i915: prepare csc unit for YCBCR HDMI output

[Shashank Sharma]

To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.

Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.

This function adds a csc handler, to perform RGB->YCBCR conversion
as per recommended spec values.

V2: Rebase
V3: Rebase

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_color.c   | 47 +++-
 drivers/gpu/drm/i915/intel_display.c | 32 
 2 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 306c6b0..12d5f21 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,19 @@
 
 #define LEGACY_LUT_LENGTH  (sizeof(struct drm_color_lut) * 256)
 
+/* Post offset values for RGB->YCBCR conversion */
+#define POSTOFF_RGB_TO_YUV_HI 0x800
+#define POSTOFF_RGB_TO_YUV_ME 0x100
+#define POSTOFF_RGB_TO_YUV_LO 0x800
+
+/* Direct spec values for RGB->YUV conversion matrix */
+#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
+#define CSC_RGB_TO_YUV_BU 0x37e8
+#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
+#define CSC_RGB_TO_YUV_BY 0xb528
+#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
+#define CSC_RGB_TO_YUV_BV 0x1e08
+
 /*
  * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
  * format). This macro takes the coefficient we want transformed and the
@@ -91,6 +104,35 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t 
*input)
}
 }
 
+void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
+{
+   int pipe = intel_crtc->pipe;
+   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+
+   /* We don't use high values for conversion */
+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   /* Program direct spec values for RGB to YCBCR conversion matrix */
+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
+
+   /* Spec postoffset values */
+   I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
+   I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
+   I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
+
+   /* CSC mode before gamma */
+   I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+}
+
 /* Set up the pipe CSC unit. */
 static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
 {
@@ -101,7 +143,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state 
*crtc_state)
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state = 
to_intel_crtc_state(crtc_state);
 
-   if (crtc_state->ctm) {
+   if (intel_crtc_state->hdmi_output > DRM_HDMI_OUTPUT_DEFAULT_RGB) {
+   i9xx_load_ycbcr_conversion_matrix(intel_crtc);
+   return;
+   } else if (crtc_state->ctm) {
struct drm_color_ctm *ctm =
(struct drm_color_ctm *)crtc_state->ctm->data;
uint64_t input[9] = { 0, };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 71fd19e..96ff2a0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6261,6 +6261,29 @@ static void intel_crtc_compute_pixel_rate(struct 
intel_crtc_state *crtc_state)
ilk_pipe_pixel_rate(crtc_state);
 }
 
+static int intel_crtc_ycbcr_config(struct intel_crtc_state *state)
+{
+   struct drm_crtc_state *drm_state = &state->base;
+   struct drm_i915_private *dev_priv = to_i915(drm_state->crtc->dev);
+
+   /* YCBCR420 is supported only in HDMI 2.0 controllers */
+   if ((state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420) &&
+   !IS_GEMINILAKE(dev_priv)) {
+   DRM_ERROR("YCBCR420 output is not supported\n");
+   return -EINVAL;
+   }
+
+   /* We need CSC for output conversion from RGB->YCBCR */
+   if (drm_state->ctm) {
+   DRM_ERROR("YCBCR output and CTM is not possible together\n");
+   return -EINVAL;
+   }
+
+   DRM_DEBUG_DRIVER("Output %s can be supported\n",
+drm_get_hdmi_output_name(state->hdmi_output));
+   return 0;
+}
+
 static int intel_crtc_compute_config(struct intel_crtc *crtc,
 struct intel_crtc_state *pipe_config)
 {
@@ 

[Intel-gfx] [PATCH v3 10/14] drm/i915: prepare scaler for YCBCR420 modeset

[Shashank Sharma]

To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.

This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
  scaler framework. This output type is identified using bit
  30 of the scaler users bitmap.

V2: rebase
V3: rebase

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
 drivers/gpu/drm/i915/intel_display.c | 26 ++
 drivers/gpu/drm/i915/intel_drv.h | 10 +-
 drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
 drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
 5 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e63..a8c9ac5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
 
/* panel fitter case: assign as a crtc scaler */
scaler_id = &scaler_state->scaler_id;
+   } else if (i == SKL_HDMI_OUTPUT_INDEX) {
+   name = "HDMI-OUTPUT";
+   idx = intel_crtc->base.base.id;
+
+   /* hdmi output case: needs a pipe scaler */
+   scaler_id = &scaler_state->scaler_id;
} else {
name = "PLANE";
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index da29536..983f581 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 */
need_scaling = src_w != dst_w || src_h != dst_h;
 
+   if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
+   && scaler_user == SKL_HDMI_OUTPUT_INDEX)
+   /* YCBCR 444 -> 420 conversion needs a scaler */
+   need_scaling = true;
+
/*
 * if plane is being disabled or scaler is no more required or force 
detach
 *  - free scaler binded to this plane/crtc
@@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 }
 
 /**
+ * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
+ * HDMI YCBCR 420 output needs a scaler, for downsampling.
+ *
+ * @state: crtc's scaler state
+ *
+ * Return
+ * 0 - scaler_usage updated successfully
+ *error - requested scaling cannot be supported or other error condition
+ */
+int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
+{
+   const struct drm_display_mode *mode = &state->base.adjusted_mode;
+
+   return skl_update_scaler(state, !state->base.active,
+   SKL_HDMI_OUTPUT_INDEX, &state->scaler_state.scaler_id,
+   state->pipe_src_w, state->pipe_src_h,
+   mode->crtc_hdisplay, mode->crtc_vdisplay);
+}
+
+/**
  * skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
  *
  * @state: crtc's scaler state
@@ -8058,6 +8083,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum drm_hdmi_output_type hdmi_out = intel_crtc->config->hdmi_output;
 
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 38fe56c..2206aa8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
 *
 * If a bit is set, a user is using a scaler.
 * Here user can be a plane or crtc as defined below:
-*   bits 0-30 - plane (bit position is index from drm_plane_index)
+*   bits 0-29 - plane (bit position is index from drm_plane_index)
+*   bit 30- hdmi output
 *   bit 31- crtc
 *
 * Instead of creating a new index to cover planes and crtc, using
@@ -484,6 +485,12 @@ struct intel_crtc_scaler_state {
 * avilability.
 */
 #define SKL_CRTC_INDEX 31
+
+   /*
+* HDMI YCBCR 420 output consume a scaler. So adding a user
+* for HDMI output 420 requirement.
+*/
+#define SKL_HDMI_OUTPUT_INDEX 30
unsigned scaler_users;
 
/* scaler used by crtc for panel fitting purpose */
@@ -1481,6 +1488,7 @@ void intel_mode_from_pipe_config(struct drm_display_mode 
*mode,
 struct intel_crtc_state *pipe_config);
 
 int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state);
+i

[Intel-gfx] [PATCH v3 11/14] drm/i915: prepare pipe for YCBCR output

[Shashank Sharma]

To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
  blend mode to use the scaler in 5x3 ratio (bits 26 and 27)

This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR outputs.

V2: rebase
V3: rebase

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/i915_reg.h  | 3 +++
 drivers/gpu/drm/i915/intel_display.c | 9 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 88e4707..77921ec 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5196,6 +5196,9 @@ enum {
 
 #define _PIPE_MISC_A   0x70030
 #define _PIPE_MISC_B   0x71030
+#define   PIPEMISC_YCBCR420_ENABLE (1<<27)
+#define   PIPEMISC_YCBCR420_MODE_BLEND (1<<26)
+#define   PIPEMISC_OUTPUT_YCBCR(1<<11)
 #define   PIPEMISC_DITHER_BPC_MASK (7<<5)
 #define   PIPEMISC_DITHER_8_BPC(0<<5)
 #define   PIPEMISC_DITHER_10_BPC   (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 983f581..71fd19e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8109,6 +8109,15 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
 
+   if (hdmi_out > DRM_HDMI_OUTPUT_DEFAULT_RGB) {
+   val |= PIPEMISC_OUTPUT_YCBCR;
+
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+   val |= PIPEMISC_YCBCR420_ENABLE |
+  PIPEMISC_YCBCR420_MODE_BLEND;
+   }
+   }
+
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
 }
-- 
2.7.4

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

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

[Shashank Sharma]

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.
+ */
+static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
+  const u8 *svds, u8 svds_len)
+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *newmode;
+   struct drm_display_info *info = &connector->display_info;
+   struct drm_hdmi_info *hdmi = &info->hdmi;
+
+   for (i = 0; i < svds_len; i++) {
+   u8 vic = svds[i] & 0x7f;
+
+   newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
+   if (!newmode)
+   break;
+   /*
+* ycbcr420_vdb_modes is a fix position 128 bit bitmap.
+* Every bit here represents a VIC, from CEA-861-F list.
+* So if bit[n] is set, it indicates vic[n+1] supports
+* YCBCR420 output. Bit 0 is dummy, as VICs start at 1.
+* ycbcr420_vcb_modes[0] = |VIC=64 |VIC=63 |.|VIC=2 |VIC=1 |
+* ycbcr420_vcb_modes[1] = |VIC=128|VIC=127|.|VIC=66|VIC=65|
+*/
+   bitmap_set(hdmi->ycbcr420_vdb_modes, vic, 1);
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+
+   if (modes > 0)
+   info->color_formats |= DRM_COLOR_FORMAT_YCRCB420;
+   return modes;
+}
+
+/*
+ * drm_add_vcb_modes - Add a YCBCR 420 mode into bitmap
+ * @connector: connector corresponding to the HDMI sink
+ * @vic: CEA vic for the video mode to be added in the map
+ *
+ * Makes an entry for a videomode in the YCBCR 420 bitmap
+ */
+static void
+drm_add_vcb_modes(s

[Intel-gfx] [PATCH v3 05/14] drm: parse ycbcr 420 deep color information

[Shashank Sharma]

CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.

V2: Rebase
V3: Rebase

Cc: Ville Syrjälä 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 15 +++
 include/drm/drm_edid.h |  5 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4953f87..0f542f3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4213,6 +4213,19 @@ drm_default_rgb_quant_range(const struct 
drm_display_mode *mode)
 }
 EXPORT_SYMBOL(drm_default_rgb_quant_range);
 
+static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
+const u8 *db)
+{
+   struct drm_hdmi_info *info = &connector->display_info.hdmi;
+
+   if (db[7] & DRM_EDID_YCBCR420_DC_48)
+   info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_48;
+   if (db[7] & DRM_EDID_YCBCR420_DC_36)
+   info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_36;
+   if (db[7] & DRM_EDID_YCBCR420_DC_30)
+   info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_30;
+}
+
 static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
 {
@@ -4253,6 +4266,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
scdc->scrambling.low_rates = true;
}
}
+
+   drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
 }
 
 static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 89c0062..d4ff17c 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -213,6 +213,11 @@ struct detailed_timing {
 #define DRM_EDID_HDMI_DC_30   (1 << 4)
 #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
 
+/* YCBCR 420 deep color modes */
+#define DRM_EDID_YCBCR420_DC_48  (1 << 6)
+#define DRM_EDID_YCBCR420_DC_36  (1 << 5)
+#define DRM_EDID_YCBCR420_DC_30  (1 << 4)
+
 /* ELD Header Block */
 #define DRM_ELD_HEADER_BLOCK_SIZE  4
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 06/14] drm: create hdmi output property

[Shashank Sharma]

HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
 - RGB
 - YCBCR 444
 - YCBCR 422
 - YCBCR 420

This patch adds a drm property "hdmi_output_format", using which,
a user can specify its preference, for the HDMI output type. The
output type enums are similar to the mentioned outputs above. To
handle various subsampling of YCBCR output types, this property
allows two special cases:
 - DRM_HDMI_OUTPUT_YCBCR_HQ
   This indicates preferred output should be YCBCR output, with highest
   subsampling rate by the source/sink, which can be typically:
- ycbcr444
- ycbcr422
- ycbcr420
 - DRM_HDMI_OUTPUT_YCBCR_LQ
   This indicates preferred output should be YCBCR output, with lowest
   subsampling rate supported by source/sink, which can be:
- ycbcr420
- ycbcr422
- ycbcr444

Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.

PS: While doing modeset for YCBCR 420 only modes, this property is
ignored, as those timings can be supported only in YCBCR 420
output mode.

V2: Added description for the new variable to address build warning
V3: Rebase

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_atomic.c|  2 ++
 drivers/gpu/drm/drm_atomic_helper.c |  4 
 drivers/gpu/drm/drm_connector.c | 32 
 include/drm/drm_connector.h | 18 ++
 include/drm/drm_mode_config.h   |  5 +
 5 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 77dcef0..9f1d46d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == config->hdmi_output_property) {
+   state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 86d3093..1356b3f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -637,6 +637,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->hdmi_output !=
+   new_connector_state->hdmi_output)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..f3c5928 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -227,6 +227,11 @@ int drm_connector_init(struct drm_device *dev,
  config->edid_property,
  0);
 
+   if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
+   drm_object_attach_property(&connector->base,
+  config->hdmi_output_property,
+  0);
+
drm_object_attach_property(&connector->base,
  config->dpms_property, 0);
 
@@ -617,6 +622,26 @@ static const struct drm_prop_enum_list 
drm_link_status_enum_list[] = {
 };
 DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
 
+static const struct drm_prop_enum_list drm_hdmi_output_enum_list[] = {
+   { DRM_HDMI_OUTPUT_DEFAULT_RGB, "output_rgb" },
+   { DRM_HDMI_OUTPUT_YCBCR444, "output_ycbcr444" },
+   { DRM_HDMI_OUTPUT_YCBCR422, "output_ycbcr422" },
+   { DRM_HDMI_OUTPUT_YCBCR420, "output_ycbcr420" },
+   { DRM_HDMI_OUTPUT_YCBCR_HQ, "output_ycbcr_high_subsampling" },
+   { DRM_HDMI_OUTPUT_YCBCR_LQ, "output_ycbcr_low_subsampling" },
+   { DRM_HDMI_OUTPUT_INVALID, "invalid_output" },
+};
+
+/**
+ * drm_get_hdmi_output_name - return a string for a given hdmi output enum
+ * @type: enum of output type
+ */
+const char *drm_get_hdmi_output_name(enum drm_hdmi_output_type type)
+{
+   return drm_hdmi_output_enum_list[type].name;
+}
+EXPORT_SYMBOL(drm_get_hdmi_output_name);
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -789,6 +814,13 @@ int drm_connector_create_standard_properties(struc

[Intel-gfx] [PATCH v3 09/14] drm/i915: add compute_config for YCBCR outputs

[Shashank Sharma]

This patch checks encoder level support for HDMI YCBCR outputs.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.

V2: Split the patch into two, kept helper functions in DRM layer.
V3: Changed the compute_config function based on new DRM API.

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_display.c |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  3 ++
 drivers/gpu/drm/i915/intel_hdmi.c| 93 ++--
 3 files changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f9bf0d5..da29536 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
PIPE_CONF_CHECK_I(hdmi_scrambling);
PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
PIPE_CONF_CHECK_I(has_infoframe);
+   PIPE_CONF_CHECK_I(hdmi_output);
 
PIPE_CONF_CHECK_I(has_audio);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1727350..38fe56c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -780,6 +780,9 @@ struct intel_crtc_state {
 
/* HDMI High TMDS char rate ratio */
bool hdmi_high_tmds_clock_ratio;
+
+   /* HDMI output type */
+   enum drm_hdmi_output_type hdmi_output;
 };
 
 struct intel_crtc {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 170abc4..d475cfb 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1317,7 +1317,8 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
return status;
 }
 
-static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
+static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
+   enum drm_hdmi_output_type hdmi_out)
 {
struct drm_i915_private *dev_priv =
to_i915(crtc_state->base.crtc->dev);
@@ -1329,6 +1330,16 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
if (HAS_GMCH_DISPLAY(dev_priv))
return false;
 
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR422) {
+   /*
+* HDMI spec says YCBCR422 is 12bpc, but its not a deep
+* color format. So respect the spec, and not allow this
+* to be deep color
+*/
+   DRM_DEBUG_KMS("Not allowing deep color for YCBCR422 output\n");
+   return false;
+   }
+
/*
 * HDMI 12bpc affects the clocks, so it's only possible
 * when not cloning with other encoder types.
@@ -1342,6 +1353,12 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
if (connector_state->crtc != crtc_state->base.crtc)
continue;
 
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+   if (!(info->hdmi.ycbcr420_dc_modes &
+   DRM_EDID_YCBCR420_DC_36))
+   return false;
+   }
+
if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
return false;
}
@@ -1354,6 +1371,65 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
return true;
 }
 
+static u8
+intel_hdmi_get_src_output_support(struct drm_connector *connector)
+{
+   struct drm_i915_private *dev_priv = connector->dev->dev_private;
+   u8 supported_outputs = DRM_COLOR_FORMAT_RGB444;
+
+   if (dev_priv->info.gen < 7)
+   return supported_outputs;
+
+   /* Gen 7 and above support HDMI 1.4b outputs */
+   supported_outputs |= (DRM_COLOR_FORMAT_YCRCB444 |
+   DRM_COLOR_FORMAT_YCRCB422);
+
+   if (IS_GEMINILAKE(dev_priv))
+   supported_outputs |= DRM_COLOR_FORMAT_YCRCB420;
+
+   return supported_outputs;
+}
+
+static enum drm_hdmi_output_type
+intel_hdmi_compute_ycbcr_config(struct drm_connector_state *conn_state,
+  struct intel_crtc_state *config,
+  int *clock_12bpc, int *clock_8bpc)
+{
+   struct drm_connector *connector = conn_state->connector;
+   struct drm_display_mode *mode = &config->base.adjusted_mode;
+   enum drm_hdmi_output_type type = conn_state->hdmi_output;
+   u8 src_output_cap = intel_hdmi_get_src_output_support(connector);
+
+   /*
+* Can we support any YCBCR output based on these parameters ?
+* current source capabilities +
+* current sink capabilities +
+* given video

[Intel-gfx] [PATCH v3 07/14] drm: set output colorspace in AVI infoframe

[Shashank Sharma]

HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.

As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI infoframes.

V2: Rebase
V3: Rebase

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 40 
 include/drm/drm_edid.h |  5 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0f542f3..fe1b3bf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4799,6 +4799,46 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
 
 /**
+ * drm_hdmi_avi_infoframe_set_colorspace - fill an HDMI AVI infoframe with
+ * colorspace data of the output type
+ *
+ * @frame: HDMI AVI infoframe
+ * @mode: DRM display mode
+ * @hdmi_output: HDMI output colorspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output)
+{
+   switch (hdmi_output) {
+   case DRM_HDMI_OUTPUT_YCBCR444:
+   frame->colorspace = HDMI_COLORSPACE_YUV444;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR422:
+   frame->colorspace = HDMI_COLORSPACE_YUV422;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR420:
+   frame->colorspace = HDMI_COLORSPACE_YUV420;
+   frame->pixel_repeat = 0;
+   break;
+   case DRM_HDMI_OUTPUT_DEFAULT_RGB:
+   frame->colorspace = HDMI_COLORSPACE_RGB;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR_HQ:
+   case DRM_HDMI_OUTPUT_YCBCR_LQ:
+   case DRM_HDMI_OUTPUT_INVALID:
+   DRM_ERROR("Invalid HDMI output type\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
+
+/**
  * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
  *quantization range information
  * @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index d4ff17c..3ea833f 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -329,6 +329,7 @@ struct cea_sad {
 struct drm_encoder;
 struct drm_connector;
 struct drm_display_mode;
+enum drm_hdmi_output_type;
 
 void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
 int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -351,6 +352,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink);
 int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output);
+int
 drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe 
*frame,
const struct drm_display_mode 
*mode);
 void
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 08/14] drm: add helper functions for YCBCR output handling

[Shashank Sharma]

This patch adds set of helper functions for YCBCR HDMI output
handling. These functions provide functionality like:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 mode.
- get the highest subsamled ycbcr output.
- get the lowest subsamled ycbcr output.
- check if a given source and sink combination can support any
  YCBCR HDMI output.
- check if a given source and sink combination can support a particular
  YCBCR HDMI output.

Currently all these helpers are kept static, and only one wrapper function
is exposed to callers, which is "drm_find_hdmi_output_type". This function
takes inputs as current mode, user preference and src + sink capabilities,
and provides the most suitable HDMI output format to match all of these
inputs.

This wrapper function will be used in next few patches in this
series from I915 driver.

V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling for YCBCR-420 only modes too.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  |   2 +-
 drivers/gpu/drm/drm_modes.c | 306 
 include/drm/drm_edid.h  |   1 +
 include/drm/drm_modes.h |   5 +
 4 files changed, 313 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fe1b3bf..3be0afa 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2949,7 +2949,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
 }
 EXPORT_SYMBOL(drm_match_cea_mode);
 
-static bool drm_valid_cea_vic(u8 vic)
+bool drm_valid_cea_vic(u8 vic)
 {
return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
 }
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f2493b9..9c3542c 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1576,3 +1576,309 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
 out:
return ret;
 }
+
+/**
+ * drm_mode_is_420_only - if a given videomode can be only supported in 
YCBCR420
+ * output format
+ *
+ * @connector: drm connector under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can support YCBCR420 output
+ * false if not.
+ */
+static bool drm_mode_is_420_only(struct drm_display_info *display,
+   struct drm_display_mode *mode)
+{
+   u8 vic = drm_match_cea_mode(mode);
+
+   /*
+* Requirements of a 420_only mode:
+* must be a valid cea mode
+* entry in 420_only bitmap
+*/
+   if (!drm_valid_cea_vic(vic))
+   return false;
+
+   return test_bit(vic, display->hdmi.ycbcr420_vdb_modes);
+}
+
+/**
+ * drm_mode_is_420_also - if a given videomode can be supported in YCBCR420
+ * output format also (along with RGB/YCBCR444/422)
+ *
+ * @display: display under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can support YCBCR420 output
+ * false if not.
+ */
+static bool drm_mode_is_420_also(struct drm_display_info *display,
+   struct drm_display_mode *mode)
+{
+   u8 vic = drm_match_cea_mode(mode);
+
+   /*
+* Requirements of a 420_also mode:
+* must be a valid cea mode
+* entry in 420_also bitmap
+*/
+   if (!drm_valid_cea_vic(vic))
+   return false;
+
+   return test_bit(vic, display->hdmi.ycbcr420_vcb_modes);
+}
+
+
+static bool drm_mode_is_420(struct drm_display_info *display,
+   struct drm_display_mode *mode)
+{
+   return drm_mode_is_420_only(display, mode) ||
+   drm_mode_is_420_also(display, mode);
+}
+
+/**
+ * drm_can_support_this_ycbcr_output - can a given source and sink combination
+ * support a particular YCBCR output type.
+ *
+ * @display: sink information.
+ * @mode: video mode from modeset
+ * @type: enum indicating YCBCR output type
+ * @source_outputs: bitmap of source supported HDMI output formats.
+ *
+ * Returns:
+ * true on success.
+ * false on failure.
+ */
+static bool drm_can_support_this_ycbcr_output(struct drm_display_info *display,
+   struct drm_display_mode *mode,
+   enum drm_hdmi_output_type type,
+   u32 source_outputs)
+{
+   /* YCBCR420 output support can be per mode basis */
+   if (type == DRM_HDMI_OUTPUT_YCBCR420 &&
+   !drm_mode_is_420(display, mode))
+   return false;
+
+   return display->color_formats & source_outputs & type;
+}
+
+/**
+ * drm_can_support_ycbcr_output - can a given source and sink combination
+ * support any YCBCR outputs ?
+ *
+ * @display: sink information.
+ * @source_outputs: bitmap of source supported HDMI output formats.
+ *
+ * Returns:
+ * true on success.
+ * false on failure.
+ */
+static bool drm_can_support_ycbcr

[Intel-gfx] [PATCH v3 03/14] drm: add hdmi 2.0 source identifier

[Shashank Sharma]

This patch adds a bool variable (is_hdmi2_src) in the drm connector
structure. While handling the EDID for HDMI 2.0 sinks, its important
to know if the source is HDMI 2.0 capable or not, so that a lot of
work can be done/bypassed based on this information. One such example
is adding YCBCR420 only modes.

If the driver knows that this source is not HDMI 2.0 capable, it will
not add YCBCR420-only modes while adding EDID modes, and will prevent
any runtime modeset failures.

This variable will be initialized from I915 driver in the next patch
and will be used in the EDID handling for HDMI 2.0 specific features,
in this same series.

Signed-off-by: Shashank Sharma 
---
 include/drm/drm_connector.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index d8bb25f..390319c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -728,6 +728,15 @@ struct drm_connector {
bool interlace_allowed;
bool doublescan_allowed;
bool stereo_allowed;
+
+   /**
+* @is_hdmi2_src : This bool indicates if this connector is a HDMI 2.0
+* capable source. While handling the EDID functions (specially HDMI
+* 2.0 specific capabilities like YCBCR420 handling), its important to
+* know if the source is capable of driving a HDMI 2.0 display.
+*/
+   bool is_hdmi2_src;
+
/**
 * @registered: Is this connector exposed (registered) with userspace?
 * Protected by @mutex.
-- 
2.7.4

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

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

[Shashank Sharma]

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

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, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080@60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefre

[Intel-gfx] [PATCH v3 01/14] drm: add HDMI 2.0 VIC support for AVI info-frames

[Shashank Sharma]

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
- VIC for 4K modes for HDMI 1.4 sinks
- S3D information for S3D modes
  As CEA-861-F has already defined VICs for 4K videomodes, this
  patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
  until the mode is 3D.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
- Do not send VICs in both AVI-IF and HDMI-IF
  send only one of it.

Reviewed-by: Andrzej Hajda 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
 drivers/gpu/drm/bridge/sii902x.c  |  2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
 drivers/gpu/drm/drm_edid.c| 12 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c | 17 -
 drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
 drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
 drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
 drivers/gpu/drm/tegra/hdmi.c  |  2 +-
 drivers/gpu/drm/tegra/sor.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
 drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
 include/drm/drm_edid.h|  3 ++-
 21 files changed, 50 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 3c62c45..4923ddc 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index c8ed0fa..4101684 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 3e90c19..a7f6b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index 9006578..a083211 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
*bridg

[Intel-gfx] [PATCH v3 00/14] HDMI YCBCR output handling in DRM layer

[Shashank Sharma]

This patch series adds support for YCBCR HDMI output handling in DRM layer.
The main aim of this patch series was to handle YCBCR 4:2:0 output for
HDMI 2.0 displays. But while providing a framework to handle non-RGB
outputs, support for YCBCR 4:4:4 and 4:2:2 was also added.

First 2 patches, complete the CEA mode-db in drm driver, by adding
new 4k modes. Current CEA mode-db contains 64 modes only (VIC 1-64),
whereas CEA-861-F defined VICs up to 107, including 4k modes, from VIC range
93-107. First patch makes sure that inclusion of these modes doesn't break
existing HDMI 1.4 monitors, across various drivers.

Next 3 patches focus on parsing new YCBCR 4:2:0 EDID blocks, and adding
YCBCR 4:2:0 modes in connector (only for connectors who declare themselves
as HDMI 2.0 compliant during init)

Next 6 patch create a property (hdmi_output_format) and add the framework
to handle the HDMI output type defined in the property. There are also some
helper functions provided, to help with the YCBCR HDMI output, like adding
deep color information, set color space and get the appropriate YCBCR output
based on source + sink capabilities.

A User can set the HDMI output property, and select the desired output
from YCBCR 4:4:4, 4:2:2 or 4:2:0. A driver can use framework's helper
functions to check if this source + sink + mode combination can drive
the desired output, or what would be the best suitable output.

By default the value of the property is default RGB, so if you don't
set the property, there is no change in the regular functionality of
an existing source.

More details are available with respective patches.

Last 6 patches add the I915 core implementation of the HDMI output handling.
This patch series was tested with a GLK device, ACER S277HK monitor and
ASTRO VA-1844A HDMI analyzer.

Shashank Sharma (14):
  drm: add HDMI 2.0 VIC support for AVI info-frames
  drm/edid: Complete CEA modedb(VIC 1-107)
  drm: add hdmi 2.0 source identifier
  drm/edid: parse YCBCR 420 videomodes from EDID
  drm: parse ycbcr 420 deep color information
  drm: create hdmi output property
  drm: set output colorspace in AVI infoframe
  drm: add helper functions for YCBCR output handling
  drm/i915: add compute_config for YCBCR outputs
  drm/i915: prepare scaler for YCBCR420 modeset
  drm/i915: prepare pipe for YCBCR output
  drm/i915: prepare csc unit for YCBCR HDMI output
  drm/i915: set colorspace for ycbcr outputs
  drm/i915/glk: set HDMI 2.0 identifier

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |   2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c |   3 +-
 drivers/gpu/drm/bridge/sii902x.c  |   2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |   2 +-
 drivers/gpu/drm/drm_atomic.c  |   2 +
 drivers/gpu/drm/drm_atomic_helper.c   |   4 +
 drivers/gpu/drm/drm_connector.c   |  32 ++
 drivers/gpu/drm/drm_edid.c| 477 +-
 drivers/gpu/drm/drm_modes.c   | 306 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |   2 +-
 drivers/gpu/drm/i915/i915_reg.h   |   3 +
 drivers/gpu/drm/i915/intel_atomic.c   |   6 +
 drivers/gpu/drm/i915/intel_color.c|  47 ++-
 drivers/gpu/drm/i915/intel_display.c  |  68 +
 drivers/gpu/drm/i915/intel_drv.h  |  13 +-
 drivers/gpu/drm/i915/intel_hdmi.c | 131 +++-
 drivers/gpu/drm/i915/intel_panel.c|   3 +-
 drivers/gpu/drm/i915/intel_sdvo.c |   3 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |   2 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c|   3 +-
 drivers/gpu/drm/radeon/radeon_audio.c |   2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |   2 +-
 drivers/gpu/drm/sti/sti_hdmi.c|   2 +-
 drivers/gpu/drm/tegra/hdmi.c  |   2 +-
 drivers/gpu/drm/tegra/sor.c   |   2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|   2 +-
 drivers/gpu/drm/zte/zx_hdmi.c |   2 +-
 include/drm/drm_connector.h   |  50 
 include/drm/drm_edid.h|  14 +-
 include/drm/drm_mode_config.h |   5 +
 include/drm/drm_modes.h   |   5 +
 34 files changed, 1172 insertions(+), 33 deletions(-)

-- 
2.7.4

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: decouple runtime PM enablement from DMC presence

[Patchwork]

== Series Details ==

Series: drm/i915: decouple runtime PM enablement from DMC presence
URL   : https://patchwork.freedesktop.org/series/25787/
State : failure

== Summary ==

Series 25787v1 drm/i915: decouple runtime PM enablement from DMC presence
https://patchwork.freedesktop.org/api/1.0/series/25787/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> FAIL   (fi-bdw-5557u)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#100461

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

fi-bdw-5557u total:278  pass:266  dwarn:0   dfail:0   fail:1   skip:11  
time:442s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:439s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:579s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:585s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:428s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:415s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:569s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:576s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:459s
fi-skl-6700hqtotal:278  pass:227  dwarn:2   dfail:0   fail:27  skip:22  
time:403s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:475s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:401s

66555696fc0f33fc19eca5068783b95ecc8a91d5 drm-tip: 2017y-06m-14d-09h-56m-45s UTC 
integration manifest
3d9846d drm/i915: decouple runtime PM enablement from DMC presence

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4951/
___
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

[Atwood, Matthew S]

intel_csr_load_program can fail (if not supported by SoC, or if file is size 0) 
and theres no conditional that it succeeds before releasing power_put on 
POWER_DOMAIN_INIT, enabling runtime PM. 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?

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

Re: [Intel-gfx] [PATCH 7/7] drm/i915: extract a _PICK2 macro

[Rodrigo Vivi]

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

?

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



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

[Paulo Zanoni]

Em Qua, 2017-06-14 às 18:16 +0300, Ville Syrjälä escreveu:
> 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)
> >  }
> >  
> >  #define _PICK(__index, a, b) ((a) + (__index) * ((b) - (a)))
> > +#define _PICK2(__index, __offsets, a) (__offsets[__index] -
> > __offsets[0] + \
> > +      (a) + dev_priv-
> > >info.display_mmio_offset)
> >  #define _PICK3(__index, ...) (((const u32 []){ __VA_ARGS__
> > })[__index])
> >  
> >  #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?

I missed them. _CURSOR definitely fits the model. I'll see what we can
do with PALLETTE.

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

Re: [Intel-gfx] [PATCH 3/7] drm/i915: use variable arguments for the macros that call _PICK

[Rodrigo Vivi]

On Tue, Jun 13, 2017 at 12:33 PM, Paulo Zanoni  wrote:
> There's no need to create a new macro every time the number of
> parameters change.

fully agree

>
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1983b75..1d5a0f8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -52,7 +52,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>
>  #define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
>  #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
> -#define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> +#define _MMIO_PIPE3(pipe, ...) _MMIO(_PICK(pipe, __VA_ARGS__))
>
>  #define _PLANE(plane, a, b) _PIPE(plane, a, b)
>  #define _MMIO_PLANE(plane, a, b) _MMIO_PIPE(plane, a, b)
> @@ -62,8 +62,8 @@ 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, a, b, c) _MMIO(_PICK(port, a, b, c))
> -#define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PICK(port, a, b, c, d, e, 
> f))
> +#define _MMIO_PORT3(port, ...) _MMIO(_PICK(port, __VA_ARGS__))
> +#define _MMIO_PORT6(port, ...) _MMIO(_PICK(port, __VA_ARGS__))

so, what about unifying MMIO_PORT3 and MMIO_PORT6 at least?

MMIO_PORTS, MMIO_PICK?

>  #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)))
>
> @@ -71,7 +71,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
>
>  #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
> -#define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
> +#define _MMIO_PHY3(phy, ...) _MMIO(_PHY3(phy, __VA_ARGS__))
>
>  #define _MASKED_FIELD(mask, value) ({ \
> if (__builtin_constant_p(mask))\
> --
> 2.9.4
>
> ___
> 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 2/7] drm/i915: _MMIO_PORT3 takes a port as an argument

[Rodrigo Vivi]

Although I'd prefer to kill it, this patch is right, so

Reviewed-by: Rodrigo Vivi 


On Tue, Jun 13, 2017 at 12:33 PM, Paulo Zanoni  wrote:
> The macro takes a port as an argument, not a pipe.
>
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a1d3cca..1983b75 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -62,7 +62,7 @@ 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(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> +#define _MMIO_PORT3(port, a, b, c) _MMIO(_PICK(port, a, b, c))
>  #define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PICK(port, a, b, c, d, e, 
> f))
>  #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)))
> --
> 2.9.4
>
> ___
> 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 1/7] drm/i915: reorder the register picking macros

[Rodrigo Vivi]

Reviewed-by: Rodrigo Vivi 

On Tue, Jun 13, 2017 at 12:33 PM, Paulo Zanoni  wrote:
> We currently have pipe, plane, trans, port, pll and phy versions of
> these macros. Reorder their definitions so all macros of each type are
> in their own group, separated by blank lines.
>
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 88e4707..a1d3cca 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -52,19 +52,24 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>
>  #define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
>  #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
> +#define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> +
>  #define _PLANE(plane, a, b) _PIPE(plane, a, b)
>  #define _MMIO_PLANE(plane, a, b) _MMIO_PIPE(plane, a, b)
> +
>  #define _TRANS(tran, a, b) ((a) + (tran)*((b)-(a)))
>  #define _MMIO_TRANS(tran, a, b) _MMIO(_TRANS(tran, a, b))
> +
>  #define _PORT(port, a, b) ((a) + (port)*((b)-(a)))
>  #define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b))
> -#define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
>  #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> -#define _PLL(pll, a, b) ((a) + (pll)*((b)-(a)))
> -#define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
>  #define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PICK(port, a, b, c, d, e, 
> f))
>  #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 _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 _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>
> --
> 2.9.4
>
> ___
> 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: decouple runtime PM enablement from DMC presence

[matthew . s . atwood]

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. This patch enables runtime PM to
be enabled if DMC firmware is not present.

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] [PATCH] drm/i915: Do not drop pagetables when empty

[Eric Blau]

Can the following patch please be included in the next stable release?
It looks like it was submitted previously by Daniel Vetter, but has not
been included in 4.11.y yet. Thanks.


From 64b1d89f358df34701d92471b65f99f4eff1b384 Mon Sep 17 00:00:00 2001
From: Chris Wilson 
Date: Thu, 18 May 2017 11:00:15 +0100
Subject: [PATCH] drm/i915: Do not drop pagetables when empty
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Due to a race with the shrinker, when we try to allocate a pagetable, we
may end up shrinking it instead. This comes as a nasty surprise as we
try to dereference it to fill in the pagetable entries for the object.

In linus/master this is fixed by pinning the pagetables prior to
allocation, but that backport is roughly
 drivers/gpu/drm/i915/i915_debugfs.c   |2 +-
 drivers/gpu/drm/i915/i915_gem_evict.c |   12 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 2017 ++---
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  123 +-
 drivers/gpu/drm/i915/i915_trace.h |  104 --
 drivers/gpu/drm/i915/i915_vgpu.c  |9 +-
 drivers/gpu/drm/i915/i915_vma.c   |9 -
 drivers/gpu/drm/i915/intel_lrc.c  |4 +-
 8 files changed, 946 insertions(+), 1334 deletions(-)
i.e. unsuitable for stable. Instead we neuter the code that tried to
free the pagetables.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99295
Fixes: 2ce5179fe826 ("drm/i915/gtt: Free unused lower-level page tables")
Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Mika Kuoppala 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michał Winiarski 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.10+
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 96e45a4d5441..4f581adf2fcf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -755,10 +755,6 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space 
*vm,
GEM_BUG_ON(pte_end > GEN8_PTES);
 
bitmap_clear(pt->used_ptes, pte, num_entries);
-   if (USES_FULL_PPGTT(vm->i915)) {
-   if (bitmap_empty(pt->used_ptes, GEN8_PTES))
-   return true;
-   }
 
pt_vaddr = kmap_px(pt);
 
@@ -798,9 +794,6 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space 
*vm,
}
}
 
-   if (bitmap_empty(pd->used_pdes, I915_PDES))
-   return true;
-
return false;
 }
 
@@ -829,9 +822,6 @@ static bool gen8_ppgtt_clear_pdp(struct i915_address_space 
*vm,
 
mark_tlbs_dirty(ppgtt);
 
-   if (bitmap_empty(pdp->used_pdpes, I915_PDPES_PER_PDP(dev_priv)))
-   return true;
-
return false;
 }
 

___
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

[Ville Syrjälä]

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)
>  }
>  
>  #define _PICK(__index, a, b) ((a) + (__index) * ((b) - (a)))
> +#define _PICK2(__index, __offsets, a) (__offsets[__index] - __offsets[0] + \
> +(a) + dev_priv->info.display_mmio_offset)
>  #define _PICK3(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
>  
>  #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

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

[Anuar, Nuhairi]

For a virtualized boot, it is possible for port A to be tied to DP.

Min He any additional comment?

On Jun 14, 2017 9:38 PM, Ville Syrjälä  wrote:
On Wed, Jun 14, 2017 at 01:47:30PM +0800, Mustamin B Mustaffa wrote:
> From: "Anuar, Nuhairi" 
>
> In GVT guest, when port A is DP, i915 will force it as an EDP panel,
> which
> will cause DP-1 not working in GVT guest.
> This patch fixed this issue by check intel_vgpu_active() in
> intel_ddi_compute_config().
>
> Signed-off-by: Min He 
> Signed-off-by: Nuhairi Anuar 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 66b367d..1110cbc 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2069,7 +2069,7 @@ static bool intel_ddi_compute_config(struct 
> intel_encoder *encoder,
>
>WARN(type == INTEL_OUTPUT_UNKNOWN, "compute_config() on unknown 
> output!\n");
>
> - if (port == PORT_A)
> + if (port == PORT_A && !intel_vgpu_active(dev_priv))
>pipe_config->cpu_transcoder = TRANSCODER_EDP;

And why exactly are you trying to register DP on port A?

>
>if (type == INTEL_OUTPUT_HDMI)
> --
> 1.9.1
>
> ___
> 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

Re: [Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 11:08:41AM +0200, Maarten Lankhorst wrote:
> Moving the wait to a helper allows callers outside of the core to
> wait for pending updates to complete.
> 
> This can be used to prevent races against nonblocking modesets.
> Only the hw_done call in swap_state is moved to a helper, doing
> it for the other callers requires too many changes and I think this
> is the only useful one to export.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 51 
> +++--
>  include/drm/drm_atomic_helper.h |  1 +
>  2 files changed, 38 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 86d3093c6c9b..1b068ce1aea9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2067,6 +2067,41 @@ void drm_atomic_helper_cleanup_planes(struct 
> drm_device *dev,
>  EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
>  
>  /**
> + * drm_atomic_helper_wait_for_hw_done - wait for all previous hw updates to 
> complete.
> + * @crtc: crtc to wait on.
> + *
> + * This function waits for all previous hardware updates queued on @crtc
> + * to complete.
> + *
> + * Returns:
> + * 0 on success, negative error code on failure.
> + */
> +int drm_atomic_helper_wait_for_hw_done(struct drm_crtc *crtc)
> +{
> + struct drm_crtc_commit *commit;
> + long ret;
> +
> + spin_lock(&crtc->commit_lock);
> + commit = list_first_entry_or_null(&crtc->commit_list,
> + struct drm_crtc_commit, commit_entry);
> + if (commit)
> + drm_crtc_commit_get(commit);
> + spin_unlock(&crtc->commit_lock);
> +
> + if (!commit)
> + return 0;
> +
> + ret = wait_for_completion_timeout(&commit->hw_done, 10 * HZ);
> + drm_crtc_commit_put(commit);
> +
> + if (ret == 0)
> + return -EBUSY;

-ETIMEDOUT ?

> +
> + return ret > 0 ? 0 : ret;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_wait_for_hw_done);
> +
> +/**
>   * drm_atomic_helper_swap_state - store atomic state into current sw state
>   * @state: atomic state
>   * @stall: stall for proceeding commits
> @@ -2107,28 +2142,16 @@ void drm_atomic_helper_swap_state(struct 
> drm_atomic_state *state,
>   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
>   struct drm_plane *plane;
>   struct drm_plane_state *old_plane_state, *new_plane_state;
> - struct drm_crtc_commit *commit;
>   void *obj, *obj_state;
>   const struct drm_private_state_funcs *funcs;
>  
>   if (stall) {
>   for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> - spin_lock(&crtc->commit_lock);
> - commit = list_first_entry_or_null(&crtc->commit_list,
> - struct drm_crtc_commit, commit_entry);
> - if (commit)
> - drm_crtc_commit_get(commit);
> - spin_unlock(&crtc->commit_lock);
> + ret = drm_atomic_helper_wait_for_hw_done(crtc);
>  
> - if (!commit)
> - continue;
> -
> - ret = wait_for_completion_timeout(&commit->hw_done,
> -   10*HZ);
> - if (ret == 0)
> + if (ret < 0)
>   DRM_ERROR("[CRTC:%d:%s] hw_done timed out\n",
> crtc->base.id, crtc->name);
> - drm_crtc_commit_put(commit);
>   }
>   }
>  
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index f0a8678ae98e..175a1a3fed36 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -77,6 +77,7 @@ void
>  drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state 
> *old_crtc_state,
>bool atomic);
>  
> +int drm_atomic_helper_wait_for_hw_done(struct drm_crtc *crtc);
>  void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
> bool stall);
>  
> -- 
> 2.11.0
> 
> ___
> 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

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

[Imre Deak]

On Thu, Jun 15, 2017 at 11:11:45AM +0800, 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 

Looks ok to me, this is the assumption of the non-passthrough case
anyway:
Reviewed-by: Imre Deak 

I noticed a few issues in the surrounding code: SPT/SPT_LP and
CNP/CNP_LP have the same problem, although we don't need to distinguish
between them atm. I think a cleaner way would be to adjust id and ext_id
in the pass-through case in intel_detect_pch() upfront and set
dev_priv->pch_type accordingly the same way as it's done in the
non-passthrough case.

Also, unrelated to the pass-through case, the HAS_PCH_CNP_LP() macro
looks bogus, it checks only 8 bits of the PCI device ID instead of 9, so
it'll be false on CNP_LP platforms (and true on SPT_LP).

--Imre

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Wait for pending modesets to complete before trying link training, v2.

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 11:08:42AM +0200, Maarten Lankhorst wrote:
> The nonblocking modeset tests were failing on systems with a DP output,
> because lijnk training could occur during the modeset.
> 
> With normal modesets we're protected by the connection_mutex lock,
> but nonblocking modesets drop locks before completing. To get around
> that, check if the most recent crtc_state has a modeset, and if this
> is the case, wait for all outstanding atomic updates on that crtc
> to complete.
> 
> This fixes the following spew when running nonblocking tests:
> [ 1061.653778] [ cut here ]
> [ 1061.653781] WARNING: CPU: 1 PID: 8165 at
> drivers/gpu/drm/drm_irq.c:1217 drm_wait_one_vblank+0x165/0x1a0
> [ 1061.653782] vblank not available on crtc 0, ret=-22
> [ 1061.653783] Modules linked in: vgem snd_hda_intel i915
> snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
> x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
> crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core
> snd_pcm mei_me mei e1000e ptp pps_core i2c_hid [last unloaded: vgem]
> [ 1061.653796] CPU: 1 PID: 8165 Comm: kworker/1:3 Tainted: G U  W
> 4.10.0-rc1-CI-Custom_114+ #1
> [ 1061.653797] Hardware name: GIGABYTE GB-BKi5A-7200/MFLP5AP-00, BIOS F1
> 07/27/2016
> [ 1061.653812] Workqueue: events i915_hpd_poll_init_work [i915]
> [ 1061.653813] Call Trace:
> [ 1061.653816]  dump_stack+0x67/0x92
> [ 1061.653818]  __warn+0xc6/0xe0
> [ 1061.653819]  warn_slowpath_fmt+0x4a/0x50
> [ 1061.653820]  ? drm_vblank_get+0x74/0xc0
> [ 1061.653821]  drm_wait_one_vblank+0x165/0x1a0
> [ 1061.653823]  ? drm_dp_dpcd_write+0x16/0x20
> [ 1061.653837]  ? intel_dp_set_link_train+0x44/0xe0 [i915]
> [ 1061.653851]  intel_dp_check_link_status+0x113/0x1a0 [i915]
> [ 1061.653864]  intel_dp_detect+0x5a1/0xa40 [i915]
> [ 1061.653866]  drm_helper_hpd_irq_event+0x8d/0x110
> [ 1061.653880]  i915_hpd_poll_init_work+0xab/0xd0 [i915]
> [ 1061.653882]  process_one_work+0x1f4/0x6d0
> [ 1061.653883]  ? process_one_work+0x16e/0x6d0
> [ 1061.653885]  worker_thread+0x49/0x4a0
> [ 1061.653886]  kthread+0x107/0x140
> [ 1061.653888]  ? process_one_work+0x6d0/0x6d0
> [ 1061.653889]  ? kthread_create_on_node+0x40/0x40
> [ 1061.653891]  ret_from_fork+0x27/0x40
> [ 1061.653892] ---[ end trace f6037618668d4cbc ]---
> [ 1061.656353] [drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out 
> waiting for DP idle patterns
> 
> Changes since v1:
> - intel_dp_detect() now holds connection_mutex and has an acquire_ctx,
>   rewrite patch to take advantage of it.
> 
> Signed-off-by: Maarten Lankhorst 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
> Testcase: kms_atomic_transitions.1x-modeset-transitions-nonblocking
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 72 
> ++---
>  1 file changed, 60 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 64fa774c855b..c7a66883e453 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4243,21 +4243,32 @@ static void
>  intel_dp_check_link_status(struct intel_dp *intel_dp)
>  {
>   struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
> - struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   u8 link_status[DP_LINK_STATUS_SIZE];
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct drm_crtc *crtc;
>  
> - WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
> -
> - if (!intel_dp_get_link_status(intel_dp, link_status)) {
> - DRM_ERROR("Failed to get link status\n");
> + crtc = intel_connector->base.state->crtc;
> + if (!crtc)
>   return;
> - }
>  
> - if (!intel_encoder->base.crtc)
> + WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
> +
> + if (!crtc->state->active)
>   return;
>  
> - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> + if (drm_atomic_crtc_needs_modeset(crtc->state)) {
> + int ret;
> +
> + /* wait for atomic modeset to complete */
> + ret = drm_atomic_helper_wait_for_hw_done(crtc);
> + if (ret < 0)
> + DRM_ERROR("Waiting for hw_done timed out\n");
> + }
> +
> + if (!intel_dp_get_link_status(intel_dp, link_status)) {
> + DRM_ERROR("Failed to get link status\n");
>   return;
> + }
>  
>   /*
>* Validate the cached values of intel_dp->link_rate and
> @@ -4291,7 +4302,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>  static bool
>  intel_dp_short_pulse(struct intel_dp *intel_dp)
>  {
> - struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
>   u8 sink_irq_vector = 0;
>   u8 old_sink_count = intel_dp->sink_count;
> @@ -4331,9 +4341,8 @@ intel_dp_shor

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

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 01:47:30PM +0800, Mustamin B Mustaffa wrote:
> From: "Anuar, Nuhairi" 
> 
> In GVT guest, when port A is DP, i915 will force it as an EDP panel,
> which
> will cause DP-1 not working in GVT guest.
> This patch fixed this issue by check intel_vgpu_active() in
> intel_ddi_compute_config().
> 
> Signed-off-by: Min He 
> Signed-off-by: Nuhairi Anuar 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 66b367d..1110cbc 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2069,7 +2069,7 @@ static bool intel_ddi_compute_config(struct 
> intel_encoder *encoder,
>  
>   WARN(type == INTEL_OUTPUT_UNKNOWN, "compute_config() on unknown 
> output!\n");
>  
> - if (port == PORT_A)
> + if (port == PORT_A && !intel_vgpu_active(dev_priv))
>   pipe_config->cpu_transcoder = TRANSCODER_EDP;

And why exactly are you trying to register DP on port A?

>  
>   if (type == INTEL_OUTPUT_HDMI)
> -- 
> 1.9.1
> 
> ___
> 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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Setting pch_id for HSW/BDW in virtual environment

[Joonas Lahtinen]

On ke, 2017-06-14 at 11:27 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Setting pch_id for HSW/BDW in virtual environment
> URL   : https://patchwork.freedesktop.org/series/25772/
> State : success

Janie & Daniel,

This patch could be considered for the CI topic branch, because it'll
do the detection right for the machines in the CI, but might worsen
situation for others.

Regards, Joonas

> 
> == Summary ==
> 
> Series 25772v1 drm/i915: Setting pch_id for HSW/BDW in virtual environment
> https://patchwork.freedesktop.org/api/1.0/series/25772/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (fi-bdw-gvtdvm) fdo#99938 +7
> Subgroup basic-s4-devices:
> pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> 
> fdo#99938 https://bugs.freedesktop.org/show_bug.cgi?id=99938
> 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:447s
> fi-bdw-gvtdvmtotal:278  pass:264  dwarn:0   dfail:0   fail:0   skip:14  
> time:432s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:576s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:511s
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:481s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:480s
> fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:591s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:432s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:412s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:420s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:491s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:471s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:467s
> fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
> time:570s
> fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
> time:586s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:471s
> fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
> time:408s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:468s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:476s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:431s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:529s
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
> time:400s
> 
> 66555696fc0f33fc19eca5068783b95ecc8a91d5 drm-tip: 2017y-06m-14d-09h-56m-45s 
> UTC integration manifest
> f30e349 drm/i915: Setting pch_id for HSW/BDW in virtual environment
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4950/
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
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

[Tvrtko Ursulin]

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 

Regards,

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Setting pch_id for HSW/BDW in virtual environment

[Saarinen, Jani]

HI, 
> -Original Message-
> == Series Details ==
> 
> Series: drm/i915: Setting pch_id for HSW/BDW in virtual environment
> URL   : https://patchwork.freedesktop.org/series/25772/
> State : success
> 
> == Summary ==
> 
> Series 25772v1 drm/i915: Setting pch_id for HSW/BDW in virtual
> environment
> https://patchwork.freedesktop.org/api/1.0/series/25772/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (fi-bdw-gvtdvm) fdo#99938 +7
> Subgroup basic-s4-devices:
> pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> 
> fdo#99938 https://bugs.freedesktop.org/show_bug.cgi?id=99938
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> 
Does what is expected:
This: fi-bdw-gvtdvmtotal:278  pass:264  dwarn:0   dfail:0   fail:0   
skip:14  time:432s
Old:  fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   
skip:14  time:432s
So with this fixes issues at least. 

> 
> 66555696fc0f33fc19eca5068783b95ecc8a91d5 drm-tip: 2017y-06m-14d-
> 09h-56m-45s UTC integration manifest
> f30e349 drm/i915: Setting pch_id for HSW/BDW in virtual environment
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4950/


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

[Intel-gfx] [PATCH i-g-t] tests/chamelium: Set output pipe after mode change to refresh output

[Paul Kocialkowski]

This adds a call to igt_output_set_pipe in orde to refresh output via
igt_output_refresh and ensure that mode override can take effect.

Without this change, using a lower resolution during frame dumps
series with mode changes (e.g. test_display_frame_dump) would not
commit the mode change to the output and leave it with a framebuffer
too small for the previously-commited resolution.

This would cause the test to fail. This allows it to pass.

Signed-off-by: Paul Kocialkowski 
---
 tests/chamelium.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/chamelium.c b/tests/chamelium.c
index 2e14ccb9..76b14e95 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -322,6 +322,8 @@ enable_output(data_t *data,
igt_plane_set_fb(primary, fb);
igt_output_override_mode(output, mode);
 
+   igt_output_set_pipe(output, output->config.pipe);
+
/* Clear any color correction values that might be enabled */
igt_pipe_set_degamma_lut(primary->pipe, NULL, 0);
igt_pipe_set_gamma_lut(primary->pipe, NULL, 0);
-- 
2.13.1

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

[Ander Conselvan De Oliveira]

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.

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->wm[level];
> > > -
> > > - if (level > max_level || level_wm->plane_res_b == 0
> > > -   || level_wm->plane_res_l >= 31
> > > -   || level_wm->plane_res_b >= 
> > > plane_ddb) {
> > > - level_wm->plane_en = false;
> > > - level_wm->plane_res_b = 0;
> > > - level_wm->plane_res_l = 0;
> > > - } else {
> > > - level_wm->plane_en = true;
> > > - }
> > > - }
> > > -}
> > > -
> > >  static int
> > >  skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> > > -   struct skl_pipe_wm *pipe_wm,
> > > struct skl_ddb_allocation *ddb /* out */)
> > >  {
> > >   struct drm_atomic_state *state = cstate->base.state;
> > >   struct drm_crtc *crtc = cstate->base.crtc;
> > >   struct drm_device *dev = crtc->dev;
> > > - struct drm_i915_private *dev_priv = to_i915(dev);
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > >   enum pipe pipe = intel_crtc->pipe;
> > >   struct skl_ddb_entry *alloc = &cstate->wm.skl.ddb;
> > > @@ -4187,9 +4159,6 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
> > > *intel_crtc,
> > >   unsigned plane_data_rate[I915_MAX_PLANES] = {};
> > >   unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
> > >   uint16_t total_min_blocks = 0;
> > > - uint16_t total_level_ddb;
> > > - uint16_t plane_blocks = 0;
> > > - int max_level, level;
> > > 
> > >   /* Clear the partitioning for disabled planes. */
> > >   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> > > @@ -4228,48 +4197,10 @@ int skl_check_pipe_max_pixel_rate(struct 
> > > intel_crtc *intel_crtc,
> > >   return -EINVAL;
> > >   }
> > > 
> > > - alloc_size -= minimum[PLANE_CURSOR];
> > > - ddb->plane[pipe][PLANE_CURSOR].start = alloc->end -
> > > -   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Setting pch_id for HSW/BDW in virtual environment

[Patchwork]

== Series Details ==

Series: drm/i915: Setting pch_id for HSW/BDW in virtual environment
URL   : https://patchwork.freedesktop.org/series/25772/
State : success

== Summary ==

Series 25772v1 drm/i915: Setting pch_id for HSW/BDW in virtual environment
https://patchwork.freedesktop.org/api/1.0/series/25772/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-bdw-gvtdvm) fdo#99938 +7
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#99938 https://bugs.freedesktop.org/show_bug.cgi?id=99938
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:447s
fi-bdw-gvtdvmtotal:278  pass:264  dwarn:0   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:576s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:591s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:491s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:570s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:586s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:471s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:408s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:468s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:476s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:431s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:400s

66555696fc0f33fc19eca5068783b95ecc8a91d5 drm-tip: 2017y-06m-14d-09h-56m-45s UTC 
integration manifest
f30e349 drm/i915: Setting pch_id for HSW/BDW in virtual environment

== Logs ==

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

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

[Xiong Zhang]

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

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

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Require HPD storm control for basic hotplug test

[Paul Kocialkowski]

On Wed, 2017-06-14 at 10:51 +0300, Paul Kocialkowski wrote:
> On Wed, 2017-06-14 at 10:47 +0300, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Tue, 2017-06-13 at 14:20 -0400, Lyude Paul wrote:
> > > NAK, igt_hpd_storm_set_threshold is expected to be called in both
> > > situations with and without hpd storm control support. The function
> > > should be able to notice when the host doesn't have the debugfs nodes
> > > for hpd storm control, and just return without doing anything in that
> > > case:
> > > 
> > > void igt_hpd_storm_set_threshold(int drm_fd, unsigned int threshold)
> > > {
> > >   int fd = igt_debugfs_open(drm_fd, "i915_hpd_storm_ctl", O_WRONLY);
> > >   char buf[16];
> > > 
> > >   /* Right here is where we should be exiting if we don't have the debugfs
> > > file present */
> > >   if (fd < 0)
> > >   return;
> > > 
> > >   igt_debug("Setting HPD storm threshold to %d\n", threshold);
> > >   snprintf(buf, sizeof(buf), "%d", threshold);
> > >   igt_assert_eq(write(fd, buf, strlen(buf)), strlen(buf));
> > > 
> > >   close(fd);
> > >   igt_install_exit_handler(igt_hpd_storm_exit_handler);
> > > }
> > > 
> > > The igt asserts that come after that are there because if we do have
> > > the i915_hpd_storm_ctl file but it doesn't do what we expect it to,
> > > then that's probably an error. This being said, adding a call to
> > > igt_require_hpd_storm_ctl(data->drm_fd); will result in the hotplugging
> > > tests being skipped on every non-intel platform.
> > 
> > That is the expected behavior, the test should definitely be skipped when
> > the
> > debugfs node is not available. Without requiring hpd storm ctl,
> > test_basic_hotplug will fail at reprobe_connector according to the following
> > log:
> 
> Ah wait, I just thought twice about this. This is a basic HPD test, so it
> should
>  work regardless of the storm detect feature, I suppose.
> 
> I guess this means there is another issue there then. I will look into it.

Okay, looks like this was a regression with i915 that occurs with 4.11 but was
fixed in 4.12-rc, so let's forget about this patch.

I thought the failure was related to the debugfs node, but it obviously is not.

> > IGT-Version: 1.19-g5d494bda (x86_64) (Linux: 4.11.3-1-ARCH x86_64)
> > (chamelium:523) CRITICAL: Test assertion failure function
> > test_basic_hotplug,
> > file chamelium.c:166:
> > (chamelium:523) CRITICAL: Failed assertion: reprobe_connector(data, port) ==
> > DRM_MODE_CONNECTED
> > (chamelium:523) CRITICAL: error: 2 != 1
> > Stack trace:
> >   #0 [__igt_fail_assert+0xef]
> >   #1 [test_basic_hotplug.constprop.20+0x157]
> >   #2 [__real_main588+0xe88]
> >   #3 [main+0x33]
> >   #4 [__libc_start_main+0xea]
> >   #5 [_start+0x2a]
> > Subtest dp-hpd failed.
> >  DEBUG 
> > (chamelium:523) igt-chamelium-DEBUG: Resetting the chamelium
> > (chamelium:523) DEBUG: Waiting for DP-1 to disconnect...
> > (chamelium:523) DEBUG: Reprobing DP-1...
> > (chamelium:523) igt-debugfs-DEBUG: Opening debugfs directory
> > '/sys/kernel/debug/dri/0'
> > (chamelium:523) igt-chamelium-DEBUG: Plugging DP-1
> > (chamelium:523) DEBUG: Reprobing DP-1...
> > (chamelium:523) CRITICAL: Test assertion failure function
> > test_basic_hotplug,
> > file chamelium.c:166:
> > (chamelium:523) CRITICAL: Failed assertion: reprobe_connector(data, port) ==
> > DRM_MODE_CONNECTED
> > (chamelium:523) CRITICAL: error: 2 != 1
> >   END  
> > Subtest dp-hpd: FAIL (1.383s)
> > Test requirement not met in function require_connector_present, file
> > chamelium.c:99:
> > Test requirement: found
> > No port of type HDMI-A was found
> > Test requirement not met in function require_connector_present, file
> > chamelium.c:99:
> > Test requirement: found
> > No port of type VGA was found
> > 
> > > Are these tests no longer working on systems without hpd storm control?
> > > The last time I tested it I didn't see any issues, but that was a while
> > > ago.
> > > 
> > > On Tue, 2017-06-13 at 15:46 +0300, Paul Kocialkowski wrote:
> > > > On Tue, 2017-06-13 at 15:44 +0300, Paul Kocialkowski wrote:
> > > > > The basic hotplug test (test_basic_hotplug) makes calls to
> > > > > igt_hpd_storm_set_threshold, which requires HPD storm control.
> > > > > 
> > > > > This adds a check for that control, since it was missing.
> > > > 
> > > > This is a resend of yesterday's patch with the right subject prefix
> > > > so that
> > > > patchwork can pick it up.
> > > > 
> > > > > Signed-off-by: Paul Kocialkowski  > > > > > 
> > > > > 
> > > > > ---
> > > > >  tests/chamelium.c | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > > > 
> > > > > diff --git a/tests/chamelium.c b/tests/chamelium.c
> > > > > index 2e14ccb9..bd7772f8 100644
> > > > > --- a/tests/chamelium.c
> > > > > +++ b/tests/chamelium.c
> > > > > @@ -153,6 +153,8 @@ test_basic_hotplug(data_t *data, struct
> > > > > chamelium_port
> > > > > *port)
> > > > >   struct udev_monitor *mon = igt_watch_hotplug();
> > > > >   int i;
> > > > >  
> > >

[Intel-gfx] [i-g-t PATCH v4 2/2] Convert tools shell tests to C version

[Abdiel Janulgue]

v4: Go thru /dev/kmsg instead of doing "dmesg | grep ..." (Arek).
Split conversion to couple of patches.

Converted:
 - sysfs_l3_parity
 - test_rte_check  (same as check_drm_clients)
 - tools_test
 - ZZ_check_dmesg

Signed-off-by: Abdiel Janulgue 
Cc: Cc: Arkadiusz Hiler 
---
 tests/Makefile.sources  |   8 +--
 tests/ZZ_check_dmesg|  11 
 tests/check_drm_clients |   6 --
 tests/sysfs_l3_parity   |  22 
 tests/test_rte_check|   6 --
 tests/tools_test|  16 --
 tests/tools_test.c  | 146 
 7 files changed, 147 insertions(+), 68 deletions(-)
 delete mode 100755 tests/ZZ_check_dmesg
 delete mode 100755 tests/check_drm_clients
 delete mode 100755 tests/sysfs_l3_parity
 delete mode 100755 tests/test_rte_check
 delete mode 100755 tests/tools_test
 create mode 100644 tests/tools_test.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c40b2ab..b0b2f22 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -232,18 +232,13 @@ TESTS_progs = \
vgem_basic \
vgem_slow \
debugfs_test \
+   tools_test \
$(NULL)
 
 TESTS_progs_X = \
 gem_concurrent_all \
 $(NULL)
 
-TESTS_scripts = \
-   sysfs_l3_parity \
-   test_rte_check \
-   tools_test \
-   $(NULL)
-
 kernel_tests = \
$(TESTS_progs) \
$(TESTS_scripts) \
@@ -273,7 +268,6 @@ HANG = \
$(NULL)
 
 scripts = \
-   check_drm_clients \
ddx_intel_after_fbdev \
drm_lib.sh \
drm_getopt.sh \
diff --git a/tests/ZZ_check_dmesg b/tests/ZZ_check_dmesg
deleted file mode 100755
index e28ba35..000
--- a/tests/ZZ_check_dmesg
+++ /dev/null
@@ -1,11 +0,0 @@
-#!/bin/sh
-
-if dmesg | grep '\*ERROR\*'  > /dev/null ; then
-   echo "DRM_ERROR dirt in dmesg"
-   exit 1
-fi
-
-if dmesg | grep -- '--\[ cut here \]' > /dev/null  ; then
-   echo "found a backtrace in dmesg"
-   exit 1
-fi
diff --git a/tests/check_drm_clients b/tests/check_drm_clients
deleted file mode 100755
index 2a891b8..000
--- a/tests/check_drm_clients
+++ /dev/null
@@ -1,6 +0,0 @@
-#!/bin/bash
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-exit $IGT_EXIT_SUCCESS
diff --git a/tests/sysfs_l3_parity b/tests/sysfs_l3_parity
deleted file mode 100755
index d5f3284..000
--- a/tests/sysfs_l3_parity
+++ /dev/null
@@ -1,22 +0,0 @@
-#!/bin/bash
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-$SOURCE_DIR/../tools/intel_l3_parity -r 0 -b 0 -s 0 -e || exit $?
-
-#Check that we can remap a row
-$SOURCE_DIR/../tools/intel_l3_parity -r 0 -b 0 -s 0 -d
-disabled=`$SOURCE_DIR/../tools/intel_l3_parity -l | grep -c 'Row 0, Bank 0, 
Subbank 0 is disabled'`
-if [ "$disabled" != "1" ] ; then
-   echo "Fail"
-   exit $IGT_EXIT_FAILURE
-fi
-
-$SOURCE_DIR/../tools/intel_l3_parity -r 0 -b 0 -s 0 -e
-
-#Check that we can clear remaps
-if [ `$SOURCE_DIR/../tools/intel_l3_parity -l | wc -l` != 1 ] ; then
-   echo "Fail 2"
-   exit $IGT_EXIT_FAILURE
-fi
diff --git a/tests/test_rte_check b/tests/test_rte_check
deleted file mode 100755
index 2a891b8..000
--- a/tests/test_rte_check
+++ /dev/null
@@ -1,6 +0,0 @@
-#!/bin/bash
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-exit $IGT_EXIT_SUCCESS
diff --git a/tests/tools_test b/tests/tools_test
deleted file mode 100755
index a27fb87..000
--- a/tests/tools_test
+++ /dev/null
@@ -1,16 +0,0 @@
-#!/bin/bash
-# Test some of the most critical tools we have accidentally broken before.
-# TODO: Possibly make tests parse output
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-# ARB_MODE has existed for many gens
-PATH=$SOURCE_DIR/../tools:$PATH
-do_or_die "intel_reg read 0x4030"
-do_or_die "intel_reg dump"
-
-# TODO: Add more tests
-
-exit $IGT_EXIT_SUCCESS
-
diff --git a/tests/tools_test.c b/tests/tools_test.c
new file mode 100644
index 000..b3f57db
--- /dev/null
+++ b/tests/tools_test.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL

[Intel-gfx] [i-g-t v4 PATCH 1/2] Convert debugfs shell tests to C version

[Abdiel Janulgue]

v4: Rename get_sysfs_entry -> read_and_discard_sysfs_entry,
assert on null igt_sysfs_get() (Arek).

v3: Drop redundant test covered by drv_hangman/basic. Descend thru
debugfs path when reading sysfs entries (Chris).

v2: Use internal igt_debugfs functions instead of cat and document
debugfs tests.
Convert sysfs_l3_parity properly.
Rename redundant names in tests.

Converted:
 - debugfs_emon_crash
 - debugfs_wedged
 - drv_debugfs_reader

Cc: Arkadiusz Hiler 
Signed-off-by: Abdiel Janulgue 
---
 tests/Makefile.sources   |  4 +-
 tests/debugfs_emon_crash | 16 
 tests/debugfs_test.c | 98 
 tests/debugfs_wedged | 10 -
 tests/drv_debugfs_reader |  9 -
 5 files changed, 99 insertions(+), 38 deletions(-)
 delete mode 100755 tests/debugfs_emon_crash
 create mode 100644 tests/debugfs_test.c
 delete mode 100755 tests/debugfs_wedged
 delete mode 100755 tests/drv_debugfs_reader

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index dafb028..c40b2ab 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -231,6 +231,7 @@ TESTS_progs = \
template \
vgem_basic \
vgem_slow \
+   debugfs_test \
$(NULL)
 
 TESTS_progs_X = \
@@ -238,8 +239,6 @@ TESTS_progs_X = \
 $(NULL)
 
 TESTS_scripts = \
-   debugfs_emon_crash \
-   drv_debugfs_reader \
sysfs_l3_parity \
test_rte_check \
tools_test \
@@ -276,7 +275,6 @@ HANG = \
 scripts = \
check_drm_clients \
ddx_intel_after_fbdev \
-   debugfs_wedged \
drm_lib.sh \
drm_getopt.sh \
$(NULL)
diff --git a/tests/debugfs_emon_crash b/tests/debugfs_emon_crash
deleted file mode 100755
index 1dbfcb2..000
--- a/tests/debugfs_emon_crash
+++ /dev/null
@@ -1,16 +0,0 @@
-#!/bin/bash
-#
-# This check if we can crash the kernel with segmentation-fault
-# by reading /sys/kernel/debug/dri/0/i915_emon_status too quickly
-#
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-for z in $(seq 1 1000); do
-   cat $i915_dfs_path/i915_emon_status > /dev/null 2&>1
-done
-
-# If we got here, we haven't crashed
-
-exit $IGT_EXIT_SUCCESS
diff --git a/tests/debugfs_test.c b/tests/debugfs_test.c
new file mode 100644
index 000..6a4b871
--- /dev/null
+++ b/tests/debugfs_test.c
@@ -0,0 +1,98 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+#include "igt.h"
+#include "igt_sysfs.h"
+#include 
+#include 
+#include 
+
+static void read_and_discard_sysfs_entry(int path_fd)
+{
+   struct dirent *dirent;
+   DIR *dir;
+
+   dir = fdopendir(path_fd);
+   if (!dir)
+   return;
+
+   while ((dirent = readdir(dir))) {
+   if (!strcmp(dirent->d_name, ".") ||
+   !strcmp(dirent->d_name, ".."))
+   continue;
+   if (dirent->d_type == DT_DIR) {
+   int sub_fd = -1;
+   igt_assert((sub_fd =
+   openat(path_fd, dirent->d_name, O_RDONLY |
+  O_DIRECTORY)) > 0);
+   read_and_discard_sysfs_entry(sub_fd);
+   close(sub_fd);
+   } else {
+   char *buf = igt_sysfs_get(path_fd, dirent->d_name);
+   igt_assert(buf);
+   free(buf);
+   }
+   }
+   closedir(dir);
+}
+
+igt_main
+{
+   int fd = -1, debugfs;
+   igt_skip_on_simulation();
+
+   igt_fixture {
+   fd = drm_open_driver_master(DRIVER_INTEL);
+   igt_require_gem(fd);
+   debugfs = igt_debugfs_dir(fd);
+   }
+
+   igt_subtest("drv_reader") {
+   read_and_discard_sysf

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Start writeback from the shrinker

[Chris Wilson]

Quoting Joonas Lahtinen (2017-06-13 15:07:04)
> On pe, 2017-06-09 at 12:03 +0100, Chris Wilson wrote:
> > When we are called to relieve mempressue via the shrinker, the only way
> > we can make progress is either by discarding unwanted pages (those
> > objects that userspace has marked MADV_DONTNEED) or by reclaiming the
> > dirty objects via swap. As we know that is the only way to make further
> > progress, we can initiate the writeback as we invalidate the objects.
> > This means the objects we put onto the inactive anon lru list are
> > already marked for reclaim+writeback and so will trigger a wait upon the
> > writeback inside direct reclaim, greatly improving the success rate of
> > direct reclaim on i915 objects.
> > 
> > The corollary is that we may start a slow swap on opportunistic
> > mempressure from the likes of the compaction + migration kthreads. This
> > is limited by those threads only being allowed to shrink idle pages, but
> > also that if we reactivate the page before it is swapped out by gpu
> > activity, we only page the cost of repinning the page. The cost is most
> > felt when an object is reused after mempressure, which hopefully
> > excludes the latency sensitive tasks (as we are just extending the
> > impact of swap thrashing to them).
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Joonas Lahtinen 
> > Cc: Tvrtko Ursulin 
> > Cc: Matthew Auld 
> > Cc: Daniel Vetter 
> > Cc: Michal Hocko 
> 
> 
> 
> > +static void __start_writeback(struct drm_i915_gem_object *obj)
> > +{
> 
> 
> 
> > + /* Force any other users of this object to refault */
> > + mapping = obj->base.filp->f_mapping;
> > + unmap_mapping_range(mapping, 0, (loff_t)-1, 0);
> > +
> > + /* Begin writeback on each dirty page */
> > + for (i = 0; i < obj->base.size >> PAGE_SHIFT; i++) {
> > + struct page *page;
> > +
> > + page = find_lock_entry(mapping, i);
> > + if (!page || radix_tree_exceptional_entry(page))
> > + continue;
> > +
> > + if (!page_mapped(page) && clear_page_dirty_for_io(page)) {
> > + int ret;
> > +
> > + SetPageReclaim(page);
> > + ret = mapping->a_ops->writepage(page, &wbc);
> > + if (!PageWriteback(page))
> > + ClearPageReclaim(page);
> > + if (!ret)
> > + goto put;
> > + }
> > + unlock_page(page);
> > +put:
> > + put_page(page);
> > + }
> 
> Apart from this part (which should probably be a helper function
> outside of i915), the code is:
> 
> Reviewed-by: Joonas Lahtinen 

Thanks for the review, I've pushed the fix plus simple patches, leaving
this one for more feedback.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH IGT] tests/chamelium: Close DRM file descriptor after tests

[Paul Kocialkowski]

On Wed, 2017-06-14 at 10:36 +0100, Chris Wilson wrote:
> Quoting Paul Kocialkowski (2017-06-12 16:21:45)
> > On Mon, 2017-06-12 at 17:39 +0300, Paul Kocialkowski wrote:
> > > This adds a call to close the DRM file descriptor. It is reauired as IGT
> > > will attempt to become DRM master after running the test, resulting in a
> > > failure.
> > 
> > This should fix (at least) 3 of the failures seen on the CI machine that
> > runs
> > chamelium tests.
> 
> This would be papering over the bug in the atexit handlers if they
> assume they can become drm master and worse cause a failure it they
> don't. I was not aware that the core made that presumption, so more
> details would be useful.

Here is the log from running the dp-hpd-storm test:

IGT-Version: 1.19-geeeb304a (x86_64) (Linux: 4.12.0-rc4-ARCH+ x86_64)
Subtest dp-hpd-storm: SUCCESS (8.917s)
Test requirement not met in function require_connector_present, file
chamelium.c:99:
Test requirement: found
No port of type HDMI-A was found
Test requirement not met in function require_connector_present, file
chamelium.c:99:
Test requirement: found
No port of type VGA was found
Test requirement not met in function drm_open_driver_master, file drmtest.c:391:
Test requirement: drmSetMaster(fd) == 0
Can't become DRM master, please check if no other DRM client is running.
Last errno: 22, Invalid argument
chamelium: igt_core.c:955: igt_skip: Assertion `in_fixture' failed.
./chamelium.sh: line 3:  8566 Aborted (core dumped)
/usr/local/libexec/intel-gpu-tools/chamelium "$@"

Which is actually called by igt_hpd_storm_exit_handler in order to call
igt_hpd_storm_reset with the drm fd.

Thinking about it, I should have made it clear in the commit message that this
is very specific to the hpd storm feature testing.

-- 
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 v8 3/6] drm/i915/gvt: Frame buffer decoder support for GVT-g

[Chen, Xiaoguang]

>-Original Message-
>From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
>Sent: Wednesday, June 14, 2017 5:39 PM
>To: Chen, Xiaoguang 
>Cc: alex.william...@redhat.com; kra...@redhat.com; ch...@chris-wilson.co.uk;
>intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org;
>zhen...@linux.intel.com; Lv, Zhiyuan ; intel-gvt-
>d...@lists.freedesktop.org; Wang, Zhi A ; Tian, Kevin
>
>Subject: Re: [PATCH v8 3/6] drm/i915/gvt: Frame buffer decoder support for GVT-
>g
>
>On 2017.06.09 14:50:39 +0800, Xiaoguang Chen wrote:
>> decode frambuffer attributes of primary, cursor and sprite plane
>>
>> Signed-off-by: Xiaoguang Chen 
>
>...
>
>> +/**
>> + * intel_vgpu_decode_primary_plane - Decode primary plane
>> + * @vgpu: input vgpu
>> + * @plane: primary plane to save decoded info
>> + * This function is called for decoding plane
>> + *
>> + * Returns:
>> + * 0 on success, non-zero if failed.
>> + */
>> +int intel_vgpu_decode_primary_plane(struct intel_vgpu *vgpu,
>> +struct intel_vgpu_primary_plane_format *plane) {
>> +u32 val, fmt;
>> +struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
>> +int pipe;
>> +
>> +pipe = get_active_pipe(vgpu);
>> +if (pipe >= I915_MAX_PIPES)
>> +return -ENODEV;
>> +
>> +val = vgpu_vreg(vgpu, DSPCNTR(pipe));
>> +plane->enabled = !!(val & DISPLAY_PLANE_ENABLE);
>> +if (!plane->enabled)
>> +return -ENODEV;
>> +
>> +if (IS_SKYLAKE(dev_priv)) {
>> +plane->tiled = (val & PLANE_CTL_TILED_MASK) >>
>> +_PLANE_CTL_TILED_SHIFT;
>> +fmt = skl_format_to_drm(
>> +val & PLANE_CTL_FORMAT_MASK,
>> +val & PLANE_CTL_ORDER_RGBX,
>> +val & PLANE_CTL_ALPHA_MASK,
>> +val & PLANE_CTL_YUV422_ORDER_MASK);
>> +plane->bpp = skl_pixel_formats[fmt].bpp;
>> +plane->drm_format = skl_pixel_formats[fmt].drm_format;
>> +} else {
>> +plane->tiled = !!(val & DISPPLANE_TILED);
>> +fmt = (val & DISPPLANE_PIXFORMAT_MASK) >>
>_PRI_PLANE_FMT_SHIFT;
>> +plane->bpp = bdw_pixel_formats[fmt].bpp;
>> +plane->drm_format = bdw_pixel_formats[fmt].drm_format;
>> +}
>> +
>> +if (!skl_pixel_formats[fmt].bpp && !bdw_pixel_formats[fmt].bpp) {
>> +gvt_vgpu_err("Non-supported pixel format (0x%x)\n", fmt);
>> +return -EINVAL;
>> +}
>
>Is this correct? shouldn't be plane->bpp as last time comment?
Yes. But use plane->bpp is more concisely. Will change.
  
>
>> diff --git a/include/uapi/drm/drm_fourcc.h
>> b/include/uapi/drm/drm_fourcc.h index 55e3010..400759f 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -161,6 +161,12 @@ extern "C" {
>>  #define DRM_FORMAT_YUV444   fourcc_code('Y', 'U', '2', '4') /* non-
>subsampled Cb (1) and Cr (2) planes */
>>  #define DRM_FORMAT_YVU444   fourcc_code('Y', 'V', '2', '4') /* non-
>subsampled Cr (1) and Cb (2) planes */
>>
>> +/*
>> + * Intel GVT-g plane format definition  */ #define
>> +DRM_FORMAT_XRGB161616_GVT  fourcc_code('X', 'R', '4', '8') /* [63:0]
>> +x:R:G:B 16:16:16:16 little endian */ #define
>> +DRM_FORMAT_XBGR161616_GVT  fourcc_code('X', 'B', '4', '8') /* [63:0]
>> +x:B:G:R 16:16:16:16 little endian */
>> +
>>
>
>This should be a seperate patch and not need GVT postfix for format definition.
OK.

>
>--
>Open Source Technology Center, Intel ltd.
>
>$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 3/6] drm/i915/gvt: Frame buffer decoder support for GVT-g

[Zhenyu Wang]

On 2017.06.09 14:50:39 +0800, Xiaoguang Chen wrote:
> decode frambuffer attributes of primary, cursor and sprite plane
> 
> Signed-off-by: Xiaoguang Chen 

...

> +/**
> + * intel_vgpu_decode_primary_plane - Decode primary plane
> + * @vgpu: input vgpu
> + * @plane: primary plane to save decoded info
> + * This function is called for decoding plane
> + *
> + * Returns:
> + * 0 on success, non-zero if failed.
> + */
> +int intel_vgpu_decode_primary_plane(struct intel_vgpu *vgpu,
> + struct intel_vgpu_primary_plane_format *plane)
> +{
> + u32 val, fmt;
> + struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
> + int pipe;
> +
> + pipe = get_active_pipe(vgpu);
> + if (pipe >= I915_MAX_PIPES)
> + return -ENODEV;
> +
> + val = vgpu_vreg(vgpu, DSPCNTR(pipe));
> + plane->enabled = !!(val & DISPLAY_PLANE_ENABLE);
> + if (!plane->enabled)
> + return -ENODEV;
> +
> + if (IS_SKYLAKE(dev_priv)) {
> + plane->tiled = (val & PLANE_CTL_TILED_MASK) >>
> + _PLANE_CTL_TILED_SHIFT;
> + fmt = skl_format_to_drm(
> + val & PLANE_CTL_FORMAT_MASK,
> + val & PLANE_CTL_ORDER_RGBX,
> + val & PLANE_CTL_ALPHA_MASK,
> + val & PLANE_CTL_YUV422_ORDER_MASK);
> + plane->bpp = skl_pixel_formats[fmt].bpp;
> + plane->drm_format = skl_pixel_formats[fmt].drm_format;
> + } else {
> + plane->tiled = !!(val & DISPPLANE_TILED);
> + fmt = (val & DISPPLANE_PIXFORMAT_MASK) >> _PRI_PLANE_FMT_SHIFT;
> + plane->bpp = bdw_pixel_formats[fmt].bpp;
> + plane->drm_format = bdw_pixel_formats[fmt].drm_format;
> + }
> +
> + if (!skl_pixel_formats[fmt].bpp && !bdw_pixel_formats[fmt].bpp) {
> + gvt_vgpu_err("Non-supported pixel format (0x%x)\n", fmt);
> + return -EINVAL;
> + }

Is this correct? shouldn't be plane->bpp as last time comment?

> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 55e3010..400759f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -161,6 +161,12 @@ extern "C" {
>  #define DRM_FORMAT_YUV444fourcc_code('Y', 'U', '2', '4') /* 
> non-subsampled Cb (1) and Cr (2) planes */
>  #define DRM_FORMAT_YVU444fourcc_code('Y', 'V', '2', '4') /* 
> non-subsampled Cr (1) and Cb (2) planes */
>  
> +/*
> + * Intel GVT-g plane format definition
> + */
> +#define DRM_FORMAT_XRGB161616_GVT  fourcc_code('X', 'R', '4', '8') /* [63:0] 
> x:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_XBGR161616_GVT  fourcc_code('X', 'B', '4', '8') /* [63:0] 
> x:B:G:R 16:16:16:16 little endian */
> +
>  

This should be a seperate patch and not need GVT postfix for format definition.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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] drm/i915/selftests: silence a bogus spammy warning

[Dan Carpenter]

On Wed, Jun 14, 2017 at 10:29:57AM +0100, Chris Wilson wrote:
> Quoting Dan Carpenter (2017-06-14 10:14:52)
> > These tests are reversed so it complains on every successful call and
> > stays quiet for every failure.  Also we may as well preserve the error
> > code.
> 
> The test is correct. The expectation here is that i915_gem_object_ggtt_pin()
> fails and reports ENOSPC as we have already allocated the entire GGTT. If it
> doesn't then we report the test failure.
> -Chris

Ah.  Ok.  Thanks.

This was triggering a static checker warning because we're passing a
valid pointer to PTR_ERR().  Probably the easiest thing is just to
ignore the warning...

regards,
dan carpenter


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

Re: [Intel-gfx] [PATCH IGT] tests/chamelium: Close DRM file descriptor after tests

[Chris Wilson]

Quoting Paul Kocialkowski (2017-06-12 16:21:45)
> On Mon, 2017-06-12 at 17:39 +0300, Paul Kocialkowski wrote:
> > This adds a call to close the DRM file descriptor. It is reauired as IGT
> > will attempt to become DRM master after running the test, resulting in a
> > failure.
> 
> This should fix (at least) 3 of the failures seen on the CI machine that runs
> chamelium tests.

This would be papering over the bug in the atexit handlers if they
assume they can become drm master and worse cause a failure it they
don't. I was not aware that the core made that presumption, so more
details would be useful.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/selftests: silence a bogus spammy warning

[Chris Wilson]

Quoting Dan Carpenter (2017-06-14 10:14:52)
> These tests are reversed so it complains on every successful call and
> stays quiet for every failure.  Also we may as well preserve the error
> code.

The test is correct. The expectation here is that i915_gem_object_ggtt_pin()
fails and reports ENOSPC as we have already allocated the entire GGTT. If it
doesn't then we report the test failure.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/atomic: move waiting for hw_done to a helper

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/atomic: move waiting for hw_done to a 
helper
URL   : https://patchwork.freedesktop.org/series/25761/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:447s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:580s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:506s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:586s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:434s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:454s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:401s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:462s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:475s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:401s

d4bedb8b0f9ba91df2e8cb136a489145a83e96a7 drm-tip: 2017y-06m-13d-14h-22m-46s UTC 
integration manifest
b79675f drm/i915: Wait for pending modesets to complete before trying link 
training, v2.
48dd8f5 drm/atomic: move waiting for hw_done to a helper

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/selftests: silence a bogus spammy warning

[Dan Carpenter]

These tests are reversed so it complains on every successful call and
stays quiet for every failure.  Also we may as well preserve the error
code.

Fixes: f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction")
Signed-off-by: Dan Carpenter 
---
Static analysis.  Not tested.

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 14e9c2fbc4e6..0448ef9ee807 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -152,9 +152,9 @@ static int igt_overcommit(void *arg)
list_move(&obj->global_link, &i915->mm.unbound_list);
 
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
-   if (!IS_ERR(vma) || PTR_ERR(vma) != -ENOSPC) {
+   if (IS_ERR(vma) && PTR_ERR(vma) != -ENOSPC) {
pr_err("Failed to evict+insert, i915_gem_object_ggtt_pin 
returned err=%d\n", (int)PTR_ERR(vma));
-   err = -EINVAL;
+   err = PTR_ERR(vma);
goto cleanup;
}
 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/2] drm/atomic: move waiting for hw_done to a helper

[Maarten Lankhorst]

Moving the wait to a helper allows callers outside of the core to
wait for pending updates to complete.

This can be used to prevent races against nonblocking modesets.
Only the hw_done call in swap_state is moved to a helper, doing
it for the other callers requires too many changes and I think this
is the only useful one to export.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 51 +++--
 include/drm/drm_atomic_helper.h |  1 +
 2 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 86d3093c6c9b..1b068ce1aea9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2067,6 +2067,41 @@ void drm_atomic_helper_cleanup_planes(struct drm_device 
*dev,
 EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
 
 /**
+ * drm_atomic_helper_wait_for_hw_done - wait for all previous hw updates to 
complete.
+ * @crtc: crtc to wait on.
+ *
+ * This function waits for all previous hardware updates queued on @crtc
+ * to complete.
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+int drm_atomic_helper_wait_for_hw_done(struct drm_crtc *crtc)
+{
+   struct drm_crtc_commit *commit;
+   long ret;
+
+   spin_lock(&crtc->commit_lock);
+   commit = list_first_entry_or_null(&crtc->commit_list,
+   struct drm_crtc_commit, commit_entry);
+   if (commit)
+   drm_crtc_commit_get(commit);
+   spin_unlock(&crtc->commit_lock);
+
+   if (!commit)
+   return 0;
+
+   ret = wait_for_completion_timeout(&commit->hw_done, 10 * HZ);
+   drm_crtc_commit_put(commit);
+
+   if (ret == 0)
+   return -EBUSY;
+
+   return ret > 0 ? 0 : ret;
+}
+EXPORT_SYMBOL(drm_atomic_helper_wait_for_hw_done);
+
+/**
  * drm_atomic_helper_swap_state - store atomic state into current sw state
  * @state: atomic state
  * @stall: stall for proceeding commits
@@ -2107,28 +2142,16 @@ void drm_atomic_helper_swap_state(struct 
drm_atomic_state *state,
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_plane *plane;
struct drm_plane_state *old_plane_state, *new_plane_state;
-   struct drm_crtc_commit *commit;
void *obj, *obj_state;
const struct drm_private_state_funcs *funcs;
 
if (stall) {
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
-   spin_lock(&crtc->commit_lock);
-   commit = list_first_entry_or_null(&crtc->commit_list,
-   struct drm_crtc_commit, commit_entry);
-   if (commit)
-   drm_crtc_commit_get(commit);
-   spin_unlock(&crtc->commit_lock);
+   ret = drm_atomic_helper_wait_for_hw_done(crtc);
 
-   if (!commit)
-   continue;
-
-   ret = wait_for_completion_timeout(&commit->hw_done,
- 10*HZ);
-   if (ret == 0)
+   if (ret < 0)
DRM_ERROR("[CRTC:%d:%s] hw_done timed out\n",
  crtc->base.id, crtc->name);
-   drm_crtc_commit_put(commit);
}
}
 
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index f0a8678ae98e..175a1a3fed36 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -77,6 +77,7 @@ void
 drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state *old_crtc_state,
 bool atomic);
 
+int drm_atomic_helper_wait_for_hw_done(struct drm_crtc *crtc);
 void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall);
 
-- 
2.11.0

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

[Intel-gfx] [PATCH v2 2/2] drm/i915: Wait for pending modesets to complete before trying link training, v2.

[Maarten Lankhorst]

The nonblocking modeset tests were failing on systems with a DP output,
because lijnk training could occur during the modeset.

With normal modesets we're protected by the connection_mutex lock,
but nonblocking modesets drop locks before completing. To get around
that, check if the most recent crtc_state has a modeset, and if this
is the case, wait for all outstanding atomic updates on that crtc
to complete.

This fixes the following spew when running nonblocking tests:
[ 1061.653778] [ cut here ]
[ 1061.653781] WARNING: CPU: 1 PID: 8165 at
drivers/gpu/drm/drm_irq.c:1217 drm_wait_one_vblank+0x165/0x1a0
[ 1061.653782] vblank not available on crtc 0, ret=-22
[ 1061.653783] Modules linked in: vgem snd_hda_intel i915
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core
snd_pcm mei_me mei e1000e ptp pps_core i2c_hid [last unloaded: vgem]
[ 1061.653796] CPU: 1 PID: 8165 Comm: kworker/1:3 Tainted: G U  W
4.10.0-rc1-CI-Custom_114+ #1
[ 1061.653797] Hardware name: GIGABYTE GB-BKi5A-7200/MFLP5AP-00, BIOS F1
07/27/2016
[ 1061.653812] Workqueue: events i915_hpd_poll_init_work [i915]
[ 1061.653813] Call Trace:
[ 1061.653816]  dump_stack+0x67/0x92
[ 1061.653818]  __warn+0xc6/0xe0
[ 1061.653819]  warn_slowpath_fmt+0x4a/0x50
[ 1061.653820]  ? drm_vblank_get+0x74/0xc0
[ 1061.653821]  drm_wait_one_vblank+0x165/0x1a0
[ 1061.653823]  ? drm_dp_dpcd_write+0x16/0x20
[ 1061.653837]  ? intel_dp_set_link_train+0x44/0xe0 [i915]
[ 1061.653851]  intel_dp_check_link_status+0x113/0x1a0 [i915]
[ 1061.653864]  intel_dp_detect+0x5a1/0xa40 [i915]
[ 1061.653866]  drm_helper_hpd_irq_event+0x8d/0x110
[ 1061.653880]  i915_hpd_poll_init_work+0xab/0xd0 [i915]
[ 1061.653882]  process_one_work+0x1f4/0x6d0
[ 1061.653883]  ? process_one_work+0x16e/0x6d0
[ 1061.653885]  worker_thread+0x49/0x4a0
[ 1061.653886]  kthread+0x107/0x140
[ 1061.653888]  ? process_one_work+0x6d0/0x6d0
[ 1061.653889]  ? kthread_create_on_node+0x40/0x40
[ 1061.653891]  ret_from_fork+0x27/0x40
[ 1061.653892] ---[ end trace f6037618668d4cbc ]---
[ 1061.656353] [drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out 
waiting for DP idle patterns

Changes since v1:
- intel_dp_detect() now holds connection_mutex and has an acquire_ctx,
  rewrite patch to take advantage of it.

Signed-off-by: Maarten Lankhorst 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
Testcase: kms_atomic_transitions.1x-modeset-transitions-nonblocking
---
 drivers/gpu/drm/i915/intel_dp.c | 72 ++---
 1 file changed, 60 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 64fa774c855b..c7a66883e453 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4243,21 +4243,32 @@ static void
 intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
-   struct drm_device *dev = intel_dp_to_dev(intel_dp);
u8 link_status[DP_LINK_STATUS_SIZE];
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_crtc *crtc;
 
-   WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
-
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
-   DRM_ERROR("Failed to get link status\n");
+   crtc = intel_connector->base.state->crtc;
+   if (!crtc)
return;
-   }
 
-   if (!intel_encoder->base.crtc)
+   WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
+
+   if (!crtc->state->active)
return;
 
-   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   if (drm_atomic_crtc_needs_modeset(crtc->state)) {
+   int ret;
+
+   /* wait for atomic modeset to complete */
+   ret = drm_atomic_helper_wait_for_hw_done(crtc);
+   if (ret < 0)
+   DRM_ERROR("Waiting for hw_done timed out\n");
+   }
+
+   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   DRM_ERROR("Failed to get link status\n");
return;
+   }
 
/*
 * Validate the cached values of intel_dp->link_rate and
@@ -4291,7 +4302,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
-   struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
u8 sink_irq_vector = 0;
u8 old_sink_count = intel_dp->sink_count;
@@ -4331,9 +4341,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
 
-   drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
intel_dp_check_link_st

[Intel-gfx] [PATCH i-g-t] tests/kms_cursor_crc: Fix the cursor tests to work on CHV

[Maarten Lankhorst]

On CHV pipe C when the cursor is visible with a negative X coordinate
a FIFO Underrun will occur. The kernel worked around this by disallowing
cursor updates on pipe C at negative X coordinates when the cursor is
visible.

This was done in the following kernel commit:
commit ef8dd37af85a8f37ca3a29074647511e52c56181
Author: Ville Syrjälä 
Date:   Fri Dec 18 19:24:39 2015 +0200

drm/i915: Workaround CHV pipe C cursor fail

kms_chv_cursor_fail was created to test this issue, but it also happens
in kms_cursor_crc, so workaround it there too.

Signed-off-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
---
 tests/kms_cursor_crc.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index 0940752b8c40..4c5e00c074a5 100644
--- a/tests/kms_cursor_crc.c
+++ b/tests/kms_cursor_crc.c
@@ -106,6 +106,34 @@ static void cursor_disable(data_t *data)
igt_plane_set_fb(cursor, NULL);
 }
 
+static bool chv_cursor_broken(data_t *data, int x)
+{
+   /*
+* CHV gets a FIFO underrun on pipe C when cursor x coordinate
+* is negative and the cursor visible.
+*
+* i915 is fixed to return -EINVAL on cursor updates with those
+* negative coordinates, so require cursor update to fail with
+* -EINVAL in that case.
+*
+* See also kms_chv_cursor_fail.c
+*/
+   if (x >= 0)
+   return false;
+
+   return IS_CHERRYVIEW(data->devid) && data->pipe == PIPE_C;
+}
+
+static bool cursor_visible(data_t *data, int x, int y)
+{
+   if (x + data->curw <= 0 || y + data->curh <= 0)
+   return false;
+
+   if (x >= data->screenw || y >= data->screenh)
+   return false;
+
+   return true;
+}
 
 static void do_single_test(data_t *data, int x, int y)
 {
@@ -114,6 +142,7 @@ static void do_single_test(data_t *data, int x, int y)
igt_crc_t crc, ref_crc;
igt_plane_t *cursor;
cairo_t *cr = igt_get_cairo_ctx(data->drm_fd, &data->primary_fb);
+   int ret = 0;
 
igt_print_activity();
 
@@ -122,7 +151,17 @@ static void do_single_test(data_t *data, int x, int y)
cursor_enable(data);
cursor = igt_output_get_plane_type(data->output, DRM_PLANE_TYPE_CURSOR);
igt_plane_set_position(cursor, x, y);
+
+   if (chv_cursor_broken(data, x) && cursor_visible(data, x, y)) {
+   ret = igt_display_try_commit2(display, COMMIT_LEGACY);
+   igt_assert_eq(ret, -EINVAL);
+   igt_plane_set_position(cursor, 0, y);
+
+   return;
+   }
+
igt_display_commit(display);
+
igt_wait_for_vblank(data->drm_fd, data->pipe);
igt_pipe_crc_collect_crc(pipe_crc, &crc);
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Require HPD storm control for basic hotplug test

[Paul Kocialkowski]

On Wed, 2017-06-14 at 10:47 +0300, Paul Kocialkowski wrote:
> Hi,
> 
> On Tue, 2017-06-13 at 14:20 -0400, Lyude Paul wrote:
> > NAK, igt_hpd_storm_set_threshold is expected to be called in both
> > situations with and without hpd storm control support. The function
> > should be able to notice when the host doesn't have the debugfs nodes
> > for hpd storm control, and just return without doing anything in that
> > case:
> > 
> > void igt_hpd_storm_set_threshold(int drm_fd, unsigned int threshold)
> > {
> > int fd = igt_debugfs_open(drm_fd, "i915_hpd_storm_ctl", O_WRONLY);
> > char buf[16];
> > 
> > /* Right here is where we should be exiting if we don't have the debugfs
> > file present */
> > if (fd < 0)
> > return;
> > 
> > igt_debug("Setting HPD storm threshold to %d\n", threshold);
> > snprintf(buf, sizeof(buf), "%d", threshold);
> > igt_assert_eq(write(fd, buf, strlen(buf)), strlen(buf));
> > 
> > close(fd);
> > igt_install_exit_handler(igt_hpd_storm_exit_handler);
> > }
> > 
> > The igt asserts that come after that are there because if we do have
> > the i915_hpd_storm_ctl file but it doesn't do what we expect it to,
> > then that's probably an error. This being said, adding a call to
> > igt_require_hpd_storm_ctl(data->drm_fd); will result in the hotplugging
> > tests being skipped on every non-intel platform.
> 
> That is the expected behavior, the test should definitely be skipped when the
> debugfs node is not available. Without requiring hpd storm ctl,
> test_basic_hotplug will fail at reprobe_connector according to the following
> log:

Ah wait, I just thought twice about this. This is a basic HPD test, so it should
 work regardless of the storm detect feature, I suppose.

I guess this means there is another issue there then. I will look into it.

> IGT-Version: 1.19-g5d494bda (x86_64) (Linux: 4.11.3-1-ARCH x86_64)
> (chamelium:523) CRITICAL: Test assertion failure function test_basic_hotplug,
> file chamelium.c:166:
> (chamelium:523) CRITICAL: Failed assertion: reprobe_connector(data, port) ==
> DRM_MODE_CONNECTED
> (chamelium:523) CRITICAL: error: 2 != 1
> Stack trace:
>   #0 [__igt_fail_assert+0xef]
>   #1 [test_basic_hotplug.constprop.20+0x157]
>   #2 [__real_main588+0xe88]
>   #3 [main+0x33]
>   #4 [__libc_start_main+0xea]
>   #5 [_start+0x2a]
> Subtest dp-hpd failed.
>  DEBUG 
> (chamelium:523) igt-chamelium-DEBUG: Resetting the chamelium
> (chamelium:523) DEBUG: Waiting for DP-1 to disconnect...
> (chamelium:523) DEBUG: Reprobing DP-1...
> (chamelium:523) igt-debugfs-DEBUG: Opening debugfs directory
> '/sys/kernel/debug/dri/0'
> (chamelium:523) igt-chamelium-DEBUG: Plugging DP-1
> (chamelium:523) DEBUG: Reprobing DP-1...
> (chamelium:523) CRITICAL: Test assertion failure function test_basic_hotplug,
> file chamelium.c:166:
> (chamelium:523) CRITICAL: Failed assertion: reprobe_connector(data, port) ==
> DRM_MODE_CONNECTED
> (chamelium:523) CRITICAL: error: 2 != 1
>   END  
> Subtest dp-hpd: FAIL (1.383s)
> Test requirement not met in function require_connector_present, file
> chamelium.c:99:
> Test requirement: found
> No port of type HDMI-A was found
> Test requirement not met in function require_connector_present, file
> chamelium.c:99:
> Test requirement: found
> No port of type VGA was found
> 
> > Are these tests no longer working on systems without hpd storm control?
> > The last time I tested it I didn't see any issues, but that was a while
> > ago.
> > 
> > On Tue, 2017-06-13 at 15:46 +0300, Paul Kocialkowski wrote:
> > > On Tue, 2017-06-13 at 15:44 +0300, Paul Kocialkowski wrote:
> > > > The basic hotplug test (test_basic_hotplug) makes calls to
> > > > igt_hpd_storm_set_threshold, which requires HPD storm control.
> > > > 
> > > > This adds a check for that control, since it was missing.
> > > 
> > > This is a resend of yesterday's patch with the right subject prefix
> > > so that
> > > patchwork can pick it up.
> > > 
> > > > Signed-off-by: Paul Kocialkowski  > > > > 
> > > > 
> > > > ---
> > > >  tests/chamelium.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/tests/chamelium.c b/tests/chamelium.c
> > > > index 2e14ccb9..bd7772f8 100644
> > > > --- a/tests/chamelium.c
> > > > +++ b/tests/chamelium.c
> > > > @@ -153,6 +153,8 @@ test_basic_hotplug(data_t *data, struct
> > > > chamelium_port
> > > > *port)
> > > > struct udev_monitor *mon = igt_watch_hotplug();
> > > > int i;
> > > >  
> > > > +   igt_require_hpd_storm_ctl(data->drm_fd);
> > > > +
> > > > reset_state(data, port);
> > > > igt_hpd_storm_set_threshold(data->drm_fd, 0);
> > > >  
-- 
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 i-g-t] tests/chamelium: Require HPD storm control for basic hotplug test

[Paul Kocialkowski]

Hi,

On Tue, 2017-06-13 at 14:20 -0400, Lyude Paul wrote:
> NAK, igt_hpd_storm_set_threshold is expected to be called in both
> situations with and without hpd storm control support. The function
> should be able to notice when the host doesn't have the debugfs nodes
> for hpd storm control, and just return without doing anything in that
> case:
> 
> void igt_hpd_storm_set_threshold(int drm_fd, unsigned int threshold)
> {
>   int fd = igt_debugfs_open(drm_fd, "i915_hpd_storm_ctl", O_WRONLY);
>   char buf[16];
> 
>   /* Right here is where we should be exiting if we don't have the debugfs
> file present */
>   if (fd < 0)
>   return;
> 
>   igt_debug("Setting HPD storm threshold to %d\n", threshold);
>   snprintf(buf, sizeof(buf), "%d", threshold);
>   igt_assert_eq(write(fd, buf, strlen(buf)), strlen(buf));
> 
>   close(fd);
>   igt_install_exit_handler(igt_hpd_storm_exit_handler);
> }
> 
> The igt asserts that come after that are there because if we do have
> the i915_hpd_storm_ctl file but it doesn't do what we expect it to,
> then that's probably an error. This being said, adding a call to
> igt_require_hpd_storm_ctl(data->drm_fd); will result in the hotplugging
> tests being skipped on every non-intel platform.

That is the expected behavior, the test should definitely be skipped when the
debugfs node is not available. Without requiring hpd storm ctl,
test_basic_hotplug will fail at reprobe_connector according to the following
log:

IGT-Version: 1.19-g5d494bda (x86_64) (Linux: 4.11.3-1-ARCH x86_64)
(chamelium:523) CRITICAL: Test assertion failure function test_basic_hotplug,
file chamelium.c:166:
(chamelium:523) CRITICAL: Failed assertion: reprobe_connector(data, port) ==
DRM_MODE_CONNECTED
(chamelium:523) CRITICAL: error: 2 != 1
Stack trace:
  #0 [__igt_fail_assert+0xef]
  #1 [test_basic_hotplug.constprop.20+0x157]
  #2 [__real_main588+0xe88]
  #3 [main+0x33]
  #4 [__libc_start_main+0xea]
  #5 [_start+0x2a]
Subtest dp-hpd failed.
 DEBUG 
(chamelium:523) igt-chamelium-DEBUG: Resetting the chamelium
(chamelium:523) DEBUG: Waiting for DP-1 to disconnect...
(chamelium:523) DEBUG: Reprobing DP-1...
(chamelium:523) igt-debugfs-DEBUG: Opening debugfs directory
'/sys/kernel/debug/dri/0'
(chamelium:523) igt-chamelium-DEBUG: Plugging DP-1
(chamelium:523) DEBUG: Reprobing DP-1...
(chamelium:523) CRITICAL: Test assertion failure function test_basic_hotplug,
file chamelium.c:166:
(chamelium:523) CRITICAL: Failed assertion: reprobe_connector(data, port) ==
DRM_MODE_CONNECTED
(chamelium:523) CRITICAL: error: 2 != 1
  END  
Subtest dp-hpd: FAIL (1.383s)
Test requirement not met in function require_connector_present, file
chamelium.c:99:
Test requirement: found
No port of type HDMI-A was found
Test requirement not met in function require_connector_present, file
chamelium.c:99:
Test requirement: found
No port of type VGA was found

> Are these tests no longer working on systems without hpd storm control?
> The last time I tested it I didn't see any issues, but that was a while
> ago.
>
> On Tue, 2017-06-13 at 15:46 +0300, Paul Kocialkowski wrote:
> > On Tue, 2017-06-13 at 15:44 +0300, Paul Kocialkowski wrote:
> > > The basic hotplug test (test_basic_hotplug) makes calls to
> > > igt_hpd_storm_set_threshold, which requires HPD storm control.
> > > 
> > > This adds a check for that control, since it was missing.
> > 
> > This is a resend of yesterday's patch with the right subject prefix
> > so that
> > patchwork can pick it up.
> > 
> > > Signed-off-by: Paul Kocialkowski  > > > 
> > > 
> > > ---
> > >  tests/chamelium.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/tests/chamelium.c b/tests/chamelium.c
> > > index 2e14ccb9..bd7772f8 100644
> > > --- a/tests/chamelium.c
> > > +++ b/tests/chamelium.c
> > > @@ -153,6 +153,8 @@ test_basic_hotplug(data_t *data, struct
> > > chamelium_port
> > > *port)
> > >   struct udev_monitor *mon = igt_watch_hotplug();
> > >   int i;
> > >  
> > > + igt_require_hpd_storm_ctl(data->drm_fd);
> > > +
> > >   reset_state(data, port);
> > >   igt_hpd_storm_set_threshold(data->drm_fd, 0);
> > >  
-- 
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] ✓ Fi.CI.BAT: success for drm/i915: Check if WM is greater than previous level

[Mustaffa, Mustamin B]

Please ignore this patch. The owner will upstream this patch himself. 

-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org] 
Sent: Wednesday, June 14, 2017 1:56 PM
To: Mustaffa, Mustamin B 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✓ Fi.CI.BAT: success for drm/i915: Check if WM is greater than 
previous level

== Series Details ==

Series: drm/i915: Check if WM is greater than previous level
URL   : https://patchwork.freedesktop.org/series/25752/
State : success

== Summary ==

Series 25752v1 drm/i915: Check if WM is greater than previous level 
https://patchwork.freedesktop.org/api/1.0/series/25752/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

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
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:446s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:440s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:585s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:514s
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:495s
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:427s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:501s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:568s
fi-kbl-r total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:579s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:463s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:404s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:478s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

d4bedb8b0f9ba91df2e8cb136a489145a83e96a7 drm-tip: 2017y-06m-13d-14h-22m-46s UTC 
integration manifest
c99d729 drm/i915: Check if WM is greater than previous level

== Logs ==

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