Re: [Intel-gfx] [PATCH 10/10] drm/i915/cnl: Fix DP max rate for Cannonlake with port F.

2018-01-29 Thread Jani Nikula
On Mon, 29 Jan 2018, Rodrigo Vivi  wrote:
> On CNL SKUs that uses port F,  max DP rate is 8.1G for all
> ports when we have the elevated voltage (higher than 0.85V).
>
> v2: Make commit message more generic.
> v3: Move conditions to a helper to get easier to read. (Ville).
> v4: Add a mention to the numerical voltage on commit
> message per Manasi request.
> v5: Thanks CI! "error: control reaches end of non-void function"
>
> Cc: Ville Syrjälä 
> Cc: Lucas De Marchi 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 31 ---
>  1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 86a5e8bfe2a6..1f10bdb855e7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -220,15 +220,36 @@ intel_dp_downstream_max_dotclock(struct intel_dp 
> *intel_dp)
>   return max_dotclk;
>  }
>  
> +static int cnl_adjusted_max_rate(struct intel_dp *intel_dp, int size)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> + enum port port = dig_port->base.port;
> +
> + u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
> +
> + /* Low voltage SKUs are limited to max of 5.4G */
> + if (voltage == VOLTAGE_INFO_0_85V)
> + return size - 2;
> +
> + /* For this SKU 8.1G is supported in all ports */
> + if(IS_CNL_WITH_PORT_F(dev_priv))
> + return size;
> +
> + /* For other SKUs, max rate on ports A and B is 5.4G */
> + if (port == PORT_A || port == PORT_D)
> + return size - 2;
> +
> + return size;

IMO this splits the ARRAY_SIZE() and the (size - 2) adjustments too
much. They were tolerable within one function, but looking at this
function alone, the (size - 2) is a big WTF.

I'd just put this all in the same function.

BR,
Jani.


> +}
> +
>  static void
>  intel_dp_set_source_rates(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - enum port port = dig_port->base.port;
>   const int *source_rates;
>   int size;
> - u32 voltage;
>  
>   /* This should only be done once */
>   WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates);
> @@ -238,11 +259,7 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
>   size = ARRAY_SIZE(bxt_rates);
>   } else if (IS_CANNONLAKE(dev_priv)) {
>   source_rates = cnl_rates;
> - size = ARRAY_SIZE(cnl_rates);
> - voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
> - if (port == PORT_A || port == PORT_D ||
> - voltage == VOLTAGE_INFO_0_85V)
> - size -= 2;
> + size = cnl_adjusted_max_rate(intel_dp, ARRAY_SIZE(cnl_rates));
>   } else if (IS_GEN9_BC(dev_priv)) {
>   source_rates = skl_rates;
>   size = ARRAY_SIZE(skl_rates);

-- 
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 v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

2018-01-29 Thread Jani Nikula
On Tue, 23 Jan 2018, Imre Deak  wrote:
> On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
>> On Mon, 22 Jan 2018, Imre Deak  wrote:
>> > On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
>> >> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
>> >> > In case of eDP because the panel has a fixed mode, the link rate
>> >> > and lane count at which it is trained corresponds to the link BW
>> >> > required to support the native resolution of the panel. In case of
>> >> > panles with lower resolutions where fewer lanes are hooked up 
>> >> > internally,
>> >> > that number is reflected in the MAX_LANE_COUNT DPCD register of the 
>> >> > panel.
>> >> > So it is pointless to fallback to lower link rate/lane count in case
>> >> > of link training failure on eDP connector since the lower link BW
>> >> > will not support the native resolution of the panel and we cannot
>> >> > prune the preferred mode on the eDP connector.
>> >> > 
>> >> > In case of Link training failure on the eDP panel, something is wrong
>> >> > in the HW internally and hence driver errors out with a loud
>> >> > and clear DRM_ERROR message.
>> >> > 
>> >> > v2:
>> >> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
>> >> > 
>> >> > Cc: Clinton Taylor 
>> >> > Cc: Jim Bride 
>> >> > Cc: Jani Nikula 
>> >> > Cc: Ville Syrjala 
>> >> > Cc: Dave Airlie 
>> >> > Cc: Daniel Vetter 
>> >> > Signed-off-by: Manasi Navare 
>> >> > Reviewed-by: Ville Syrjala 
>> >> 
>> >> This fell through the cracks, looks like it partially fixes
>> >> https://bugs.freedesktop.org/show_bug.cgi?id=103369
>> >> 
>> >> Why link training fails there is not clear.
>> >
>> > Ok, the link training fail turned out to be a race between a modeset
>> > link training and a link retraining called from
>> > runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
>> > one was fixed meanwhile by
>> >
>> > commit 42e5e65765265485ecf2a480c244d76c2c624449
>> > Author: Daniel Vetter 
>> > AuthorDate: Mon Nov 13 17:01:40 2017 +0100
>> > Commit: Daniel Vetter 
>> > CommitDate: Thu Nov 23 14:59:07 2017 +0100
>> >
>> > drm/i915: sync dp link status checks against atomic commmits
>> >
>> > I merged now this fix to address the other issue, adding the above bug
>> > as reference. Thanks for the patch and the review.
>> 
>> Thanks for the follow-up... but should we have added a Fixes: or cc:
>> stable tag here?
>
> Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
> training failure")
>
> I wasn't sure about stable, since for me the link training failure
> happened only due to the bug fixed by 42e5e65765265. In any case I can't
> see how it could cause problems, so yes let's Cc: stable too.

Rodrigo, here's another one to cherry-pick to drm-intel-next-fixes.

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 v2] drm/i915: Check for fused or unused pipes

2018-01-29 Thread Jani Nikula
On Mon, 29 Jan 2018, Chris Wilson  wrote:
> Quoting Jani Nikula (2018-01-19 14:22:49)
>> On Mon, 18 Dec 2017, Mika Kahola  wrote:
>> > We may have fused or unused pipes in our system. Let's check that the pipe
>> > in question is within limits of accessible pipes. In case, that we are not
>> > able to access the pipe, we return early with a warning.
>> >
>> > v2: Rephrasing of the commit message (Jani)
>> >
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103206
>> > Reported-by: Thomas Gleixner 
>> > Tested-by: Jaswinder Singh Rajput 
>> > Suggested-by: Jani Nikula 
>> > Reviewed-by: Jani Nikula 
>> > Signed-off-by: Mika Kahola 
>> 
>> Pushed, thanks for the patch, sorry for the delay.
>
> This WARN is in the wild, should we queue this for drm-intel-fixes.
>
> Reported-by: frit...@xbmc.org

Rodrigo, please cherry-pick this to drm-intel-next-fixes, with Cc:
stable, with any other cherry-picks you might have, and send a pull
request to Dave to merge either during the merge window or at -rc1.

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 15/15] drm/i915: Add NV12 support to intel_framebuffer_init

2018-01-29 Thread Kumar, Mahesh

Hi,

On 1/30/2018 9:35 AM, Srinivas, Vidya wrote:



-Original Message-
From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
Sent: Monday, January 29, 2018 10:47 PM
To: Srinivas, Vidya ; intel-
g...@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to
intel_framebuffer_init

Op 20-01-18 om 22:45 schreef Vidya Srinivas:

From: Chandra Konduru 

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

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

v3: rebased (me)

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

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

v6: Rebased (me)

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

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

v9: Rebased (me)

Hey,

Has NV12 been tested at all on skylake with rotation?

y_min_scanlines = 16 for 90°/270° rotation with cpp=1
skl_needs_memory_bw_wa() doubles the scanlines required, which will
trigger the following error quite easily when patching kms_rotation_crc to
use NV12:

[   67.049190] [drm:skl_compute_wm_levels [i915]] Requested display
configuration exceeds system watermark limitations [   67.049212]
[drm:skl_compute_wm_levels [i915]] [PLANE:28:plane 1A] blocks required =
161/572, lines required = 32/31

If we violate the spec for the workaround, by using 31 lines instead of 32 for
90/270 rotation, the tests work but this needs to be solved first before we
can move forward.
We are hitting this issue due to memory_bw_wa (this is applicable for 
GEN-9 only) & we are applying WA irrespective of it's required or not.
I had plan to apply this WA based on our discussion, but it never 
materialized :(

https://www.spinics.net/lists/intel-gfx/msg124872.html


We came across many such scenarios during NV12 testing on BXT. During 
downscaling,
the "Max supported pixel clock with scaling exceeded" is seen if the user layer 
tries to downscale
much. And rotation, as you mentioned we have seen such messages. We discussed 
the same during the meeting
long back and mentioned that if we remove the limitations, it works. But as per 
discussion, if limitations are removed, it may work,
but there may be certain conditions where it may not work. Hence we concluded 
that some such cases are expected not to work.
Either we can conclude that as a limitation (as expected behavior) OR we 
can enable WA only when it's required (as discussed, assuming all the 
planes are enabled with max supported scaling to avoid taking mutex in 
each flip). what you say?


-Mahesh

However, I will discuss once again with Mahesh Kumar (CC) who works on WM 
implementation to re-confirm on the same.


~Maarten


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


Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to intel_framebuffer_init

2018-01-29 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, January 29, 2018 5:12 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to
> intel_framebuffer_init
> 
> Op 20-01-18 om 22:45 schreef Vidya Srinivas:
> > From: Chandra Konduru 
> >
> > This patch adds NV12 as supported format to intel_framebuffer_init and
> > performs various checks.
> >
> > v2:
> > -Fix an issue in checks added (Chandra Konduru)
> >
> > v3: rebased (me)
> >
> > v4: Review comments by Ville addressed Added platform check for NV12
> > in intel_framebuffer_init Removed offset checks for NV12 case
> >
> > v5: Addressed review comments by Clinton A Taylor This NV12 support
> > only correctly works on SKL.
> > Plane color space conversion is different on GLK and later platforms
> > causing the colors to display incorrectly.
> > Ville's plane color space property patch series in review will fix
> > this issue.
> > - Restricted the NV12 case in intel_framebuffer_init to SKL and BXT
> > only.
> >
> > v6: Rebased (me)
> >
> > v7: Addressed review comments by Ville Restricting the NV12 to BXT for
> > now.
> >
> > v8: Rebased (me)
> > Restricting the NV12 changes to BXT and KBL for now.
> >
> > v9: Rebased (me)
> >
> > Tested-by: Clinton Taylor 
> > Reviewed-by: Clinton Taylor 
> > Signed-off-by: Chandra Konduru 
> > Signed-off-by: Nabendu Maiti 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 88bc750..db42448 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14005,6 +14005,14 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> > goto err;
> > }
> > break;
> > +   case DRM_FORMAT_NV12:
> > +   if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv)) {
> > +   DRM_DEBUG_KMS("unsupported pixel format:
> %s\n",
> > + drm_get_format_name(mode_cmd->pixel_format,
> > +   &format_name));
> > +   goto err;
> > +   }
> > +   break;
> > default:
> > DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> >   drm_get_format_name(mode_cmd-
> >pixel_format, &format_name));
> 
> Hey,
> 
> When implementing this for IGT I've noticed a small gap in documentation,
> which will definitely need clarification somewhere. intel_framebuffer_init is
> probably good enough since it's specific to how intel works internally..
> The Yf tiling mode depends on BPP, is it correct to say that plane 0 has 8 bpp
> and plane 1 16 bpp for tiling calculations?
> 
> What bpp is used?
> 
> Are macroblock sizes always the same for Y and UV?

I think, under display buffer programming it is mentioned that: For NV12 Bpp is 
1 for Y and 2 for UV.
This is for all SKL+, it says.
> 
> ~Maarten

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


Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to intel_framebuffer_init

2018-01-29 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, January 29, 2018 10:47 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to
> intel_framebuffer_init
> 
> Op 20-01-18 om 22:45 schreef Vidya Srinivas:
> > From: Chandra Konduru 
> >
> > This patch adds NV12 as supported format to intel_framebuffer_init and
> > performs various checks.
> >
> > v2:
> > -Fix an issue in checks added (Chandra Konduru)
> >
> > v3: rebased (me)
> >
> > v4: Review comments by Ville addressed Added platform check for NV12
> > in intel_framebuffer_init Removed offset checks for NV12 case
> >
> > v5: Addressed review comments by Clinton A Taylor This NV12 support
> > only correctly works on SKL.
> > Plane color space conversion is different on GLK and later platforms
> > causing the colors to display incorrectly.
> > Ville's plane color space property patch series in review will fix
> > this issue.
> > - Restricted the NV12 case in intel_framebuffer_init to SKL and BXT
> > only.
> >
> > v6: Rebased (me)
> >
> > v7: Addressed review comments by Ville Restricting the NV12 to BXT for
> > now.
> >
> > v8: Rebased (me)
> > Restricting the NV12 changes to BXT and KBL for now.
> >
> > v9: Rebased (me)
> Hey,
> 
> Has NV12 been tested at all on skylake with rotation?
> 
> y_min_scanlines = 16 for 90°/270° rotation with cpp=1
> skl_needs_memory_bw_wa() doubles the scanlines required, which will
> trigger the following error quite easily when patching kms_rotation_crc to
> use NV12:
> 
> [   67.049190] [drm:skl_compute_wm_levels [i915]] Requested display
> configuration exceeds system watermark limitations [   67.049212]
> [drm:skl_compute_wm_levels [i915]] [PLANE:28:plane 1A] blocks required =
> 161/572, lines required = 32/31
> 
> If we violate the spec for the workaround, by using 31 lines instead of 32 for
> 90/270 rotation, the tests work but this needs to be solved first before we
> can move forward.
> 
We came across many such scenarios during NV12 testing on BXT. During 
downscaling,
the "Max supported pixel clock with scaling exceeded" is seen if the user layer 
tries to downscale
much. And rotation, as you mentioned we have seen such messages. We discussed 
the same during the meeting
long back and mentioned that if we remove the limitations, it works. But as per 
discussion, if limitations are removed, it may work,
but there may be certain conditions where it may not work. Hence we concluded 
that some such cases are expected not to work.
However, I will discuss once again with Mahesh Kumar (CC) who works on WM 
implementation to re-confirm on the same.

> ~Maarten

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


[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

2018-01-29 Thread Patchwork
== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU.
URL   : https://patchwork.freedesktop.org/series/37309/
State : warning

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-render:
pass   -> SKIP   (shard-snb) fdo#103167
Subgroup fbc-rgb101010-draw-mmap-gtt:
pass   -> SKIP   (shard-snb)
Test kms_busy:
Subgroup extended-pageflip-hang-newfb-render-a:
pass   -> SKIP   (shard-snb)
Test kms_rotation_crc:
Subgroup sprite-rotation-90-flip:
fail   -> PASS   (shard-apl) fdo#103356
Test drv_selftest:
Subgroup live_gtt:
pass   -> INCOMPLETE (shard-apl) fdo#103927
Test kms_cursor_legacy:
Subgroup short-flip-before-cursor-atomic-transitions:
pass   -> FAIL   (shard-apl) fdo#103792
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip   -> PASS   (shard-snb) fdo#103880
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Test perf_pmu:
Subgroup frequency:
fail   -> PASS   (shard-apl) fdo#104829
Test perf:
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Test kms_vblank:
Subgroup pipe-b-ts-continuation-suspend:
fail   -> PASS   (shard-snb)

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103356 https://bugs.freedesktop.org/show_bug.cgi?id=103356
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#103792 https://bugs.freedesktop.org/show_bug.cgi?id=103792
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#104829 https://bugs.freedesktop.org/show_bug.cgi?id=104829
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715

shard-apltotal:2816 pass:1726 dwarn:1   dfail:0   fail:24  skip:1064 
time:12295s
shard-hswtotal:2838 pass:1733 dwarn:1   dfail:0   fail:13  skip:1090 
time:12024s
shard-snbtotal:2838 pass:1325 dwarn:1   dfail:0   fail:12  skip:1500 
time:6624s
Blacklisted hosts:
shard-kbltotal:2838 pass:1818 dwarn:53  dfail:0   fail:25  skip:942 
time:9488s

== Logs ==

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


Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/prime_mmap_coherency: Close dmabuf after use

2018-01-29 Thread Antonio Argenziano



On 29/01/18 06:28, Chris Wilson wrote:

As we loop over the coherency tests many times, we need to close the
dmabufs opened on every pass to prevent a fd leak and the test
exploding when it hits the process limit.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103649
Signed-off-by: Chris Wilson 


LGTM.
Reviewed-by: Antonio Argenziano 


---
  tests/prime_mmap_coherency.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
index 192b43489..04b15dddb 100644
--- a/tests/prime_mmap_coherency.c
+++ b/tests/prime_mmap_coherency.c
@@ -101,6 +101,8 @@ static int test_read_flush(void)
drm_intel_bo_unreference(bo_1);
munmap(ptr_cpu, width * height);
  
+	close(dma_buf_fd);

+
return stale;
  }
  
@@ -169,6 +171,9 @@ static int test_write_flush(void)

drm_intel_bo_unreference(bo_2);
munmap(ptr_cpu, width * height);
  
+	close(dma_buf2_fd);

+   close(dma_buf_fd);
+
return stale;
  }
  


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


Re: [Intel-gfx] [PATCH] drm/i915: Only allocate preempt context when required

2018-01-29 Thread Daniele Ceraolo Spurio




@@ -979,17 +979,19 @@ static int guc_clients_create(struct intel_guc *guc)
}
guc->execbuf_client = client;
  
-	client = guc_client_alloc(dev_priv,

- INTEL_INFO(dev_priv)->ring_mask,
- GUC_CLIENT_PRIORITY_KMD_HIGH,
- dev_priv->preempt_context);
-   if (IS_ERR(client)) {
-   DRM_ERROR("Failed to create GuC client for preemption!\n");
-   guc_client_free(guc->execbuf_client);
-   guc->execbuf_client = NULL;
-   return PTR_ERR(client);
+   if (dev_priv->preempt_context) {
+   client = guc_client_alloc(dev_priv,
+ INTEL_INFO(dev_priv)->ring_mask,
+ GUC_CLIENT_PRIORITY_KMD_HIGH,
+ dev_priv->preempt_context);
+   if (IS_ERR(client)) {
+   DRM_ERROR("Failed to create GuC client for 
preemption!\n");
+   guc_client_free(guc->execbuf_client);
+   guc->execbuf_client = NULL;
+   return PTR_ERR(client);
+   }
+   guc->preempt_client = client;
}


I was having another look at this patch while rebasing my patches on top 
of it and I noticed that although guc->preempt_client is now not always 
created other code still assumes that it is always there. All platforms 
with GuC also have preemption, so i think the only case in which we can 
have issues is when we fail to create the preempt context and keep going 
with the driver loading assuming preemption disabled.


Daniele
___
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 [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

2018-01-29 Thread Patchwork
== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU.
URL   : https://patchwork.freedesktop.org/series/37309/
State : success

== Summary ==

Series 37309v1 series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI 
IDs for another SKU.
https://patchwork.freedesktop.org/api/1.0/series/37309/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> PASS   (fi-pnv-d510) fdo#101600

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:493s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:393s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:465s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:495s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:223  dwarn:0   dfail:0   fail:0   skip:65  
time:560s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:422s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:418s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:528s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s
Blacklisted hosts:
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:536s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s

9afefca72cf89d53e114f3974c5afea1d663d3e1 drm-tip: 2018y-01m-29d-22h-12m-08s UTC 
integration manifest
14d26d862f59 drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
3e78baeb28d4 drm/i915/cnl: Enable DDI-F on Cannonlake.
93e8c1123894 drm/i915/cnl: Add HPD support for Port F.
c9ec4be24ee6 drm/i915: For HPD connected port use hpd_pin instead of port.
c7082bdab406 drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.
547dfae7a658 drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.
8565802eb87a drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.
e3fc834de5e7 drm/i915/cnl: Extend Wa 1178 to Aux F.
f867fb784b0f drm/i915/cnl: Add AUX-F support
41224a5eec38 drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Always run hangcheck while the GPU is busy

2018-01-29 Thread Antonio Argenziano



On 29/01/18 06:41, Chris Wilson wrote:

Previously, we relied on only running the hangcheck while somebody was
waiting on the GPU, in order to minimise the amount of time hangcheck
had to run. (If nobody was watching the GPU, nobody would notice if the
GPU wasn't responding -- eventually somebody would care and so kick
hangcheck into action.) However, this falls apart from around commit
4680816be336 ("drm/i915: Wait first for submission, before waiting for
request completion"), as not all waiters declare themselves to hangcheck
and so we could switch off hangcheck and miss GPU hangs even when
waiting under the struct_mutex.

If we enable hangcheck from the first request submission, and let it run
until the GPU is idle again, we forgo all the complexity involved with
only enabling around waiters. Instead we have to be careful that we do
not declare a GPU hang when idly waiting for the next request to be come
ready.

Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for 
request completion"


It also fixes https://bugs.freedesktop.org/show_bug.cgi?id=104840.

Thanks,
Antonio


Signed-off-by: Chris Wilson 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/i915_gem.c  |  7 +++
  drivers/gpu/drm/i915/i915_gem_request.c  |  2 ++
  drivers/gpu/drm/i915/intel_breadcrumbs.c | 11 ---
  drivers/gpu/drm/i915/intel_hangcheck.c   |  7 +--
  4 files changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 062b21408698..63308ec016a3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3322,16 +3322,15 @@ i915_gem_retire_work_handler(struct work_struct *work)
mutex_unlock(&dev->struct_mutex);
}
  
-	/* Keep the retire handler running until we are finally idle.

+   /*
+* Keep the retire handler running until we are finally idle.
 * We do not need to do this test under locking as in the worst-case
 * we queue the retire worker once too often.
 */
-   if (READ_ONCE(dev_priv->gt.awake)) {
-   i915_queue_hangcheck(dev_priv);
+   if (READ_ONCE(dev_priv->gt.awake))
queue_delayed_work(dev_priv->wq,
   &dev_priv->gt.retire_work,
   round_jiffies_up_relative(HZ));
-   }
  }
  
  static void shrink_caches(struct drm_i915_private *i915)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 9b02310307fc..6cacd78cc849 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -393,6 +393,8 @@ static void mark_busy(struct drm_i915_private *i915)
  
  	intel_engines_unpark(i915);
  
+	i915_queue_hangcheck(i915);

+
queue_delayed_work(i915->wq,
   &i915->gt.retire_work,
   round_jiffies_up_relative(HZ));
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 86acac010bb8..62b2a20bc24e 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -149,17 +149,6 @@ static void intel_breadcrumbs_fake_irq(struct timer_list 
*t)
return;
  
  	mod_timer(&b->fake_irq, jiffies + 1);

-
-   /* Ensure that even if the GPU hangs, we get woken up.
-*
-* However, note that if no one is waiting, we never notice
-* a gpu hang. Eventually, we will have to wait for a resource
-* held by the GPU and so trigger a hangcheck. In the most
-* pathological case, this will be upon memory starvation! To
-* prevent this, we also queue the hangcheck from the retire
-* worker.
-*/
-   i915_queue_hangcheck(engine->i915);
  }
  
  static void irq_enable(struct intel_engine_cs *engine)

diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 31f01d64c021..348a4f7ffb67 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -411,7 +411,6 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
struct intel_engine_cs *engine;
enum intel_engine_id id;
unsigned int hung = 0, stuck = 0;
-   int busy_count = 0;
  
  	if (!i915_modparams.enable_hangcheck)

return;
@@ -429,7 +428,6 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
  
  	for_each_engine(engine, dev_priv, id) {

-   const bool busy = intel_engine_has_waiter(engine);
struct intel_engine_hangcheck hc;
  
  		semaphore_clear_deadlocks(dev_priv);

@@ -443,16 +441,13 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
if (hc.action != ENGINE_DEAD)
stuck |= intel_en

Re: [Intel-gfx] [PATCH 06/17] drm/i915/icl: Do not fix dbuf block size to 512

2018-01-29 Thread James Ausmus
On Mon, Jan 29, 2018 at 09:07:30PM -0200, Paulo Zanoni wrote:
> From: Mahesh Kumar 
> 
> GEN9/10 had fixed DBuf block size of 512. Dbuf block size is not a
> fixed number anymore in GEN11, it varies according to bits per pixel
> and tiling. If 8bpp & Yf-tile surface, block size = 256 else block
> size = 512
> 
> This patch addresses the same.
> 
> v2 (from Paulo):
>   - Make it compile.
>   - Fix a few coding style issues.
> v3:
>   - Rebase on top of upstream patches
> v4 (from Paulo):
>   - Bikeshed if statements (James).
> 
> Reviewed-by: Paulo Zanoni 
> Signed-off-by: Mahesh Kumar 
> Signed-off-by: Paulo Zanoni 

Reviewed-by: James Ausmus 

> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_pm.c | 24 +---
>  2 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 454d8f937fae..d93e784c3f14 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1460,6 +1460,7 @@ struct skl_wm_params {
>   uint_fixed_16_16_t plane_blocks_per_line;
>   uint_fixed_16_16_t y_tile_minimum;
>   uint32_t linetime_us;
> + uint32_t dbuf_block_size;
>  };
>  
>  /*
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 11aac65d1543..985642cf1c9a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4312,7 +4312,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>  */
>  static uint_fixed_16_16_t
>  skl_wm_method1(const struct drm_i915_private *dev_priv, uint32_t pixel_rate,
> -uint8_t cpp, uint32_t latency)
> +uint8_t cpp, uint32_t latency, uint32_t dbuf_block_size)
>  {
>   uint32_t wm_intermediate_val;
>   uint_fixed_16_16_t ret;
> @@ -4321,7 +4321,7 @@ skl_wm_method1(const struct drm_i915_private *dev_priv, 
> uint32_t pixel_rate,
>   return FP_16_16_MAX;
>  
>   wm_intermediate_val = latency * pixel_rate * cpp;
> - ret = div_fixed16(wm_intermediate_val, 1000 * 512);
> + ret = div_fixed16(wm_intermediate_val, 1000 * dbuf_block_size);
>  
>   if (INTEL_GEN(dev_priv) >= 10)
>   ret = add_fixed16_u32(ret, 1);
> @@ -4431,6 +4431,12 @@ skl_compute_plane_wm_params(const struct 
> drm_i915_private *dev_priv,
>   wp->plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate,
>intel_pstate);
>  
> + if (INTEL_GEN(dev_priv) >= 11 &&
> + fb->modifier == I915_FORMAT_MOD_Yf_TILED && wp->cpp == 8)
> + wp->dbuf_block_size = 256;
> + else
> + wp->dbuf_block_size = 512;
> +
>   if (drm_rotation_90_or_270(pstate->rotation)) {
>  
>   switch (wp->cpp) {
> @@ -4457,7 +4463,8 @@ skl_compute_plane_wm_params(const struct 
> drm_i915_private *dev_priv,
>   wp->plane_bytes_per_line = wp->width * wp->cpp;
>   if (wp->y_tiled) {
>   interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line *
> -wp->y_min_scanlines, 512);
> +wp->y_min_scanlines,
> +wp->dbuf_block_size);
>  
>   if (INTEL_GEN(dev_priv) >= 10)
>   interm_pbpl++;
> @@ -4465,10 +4472,12 @@ skl_compute_plane_wm_params(const struct 
> drm_i915_private *dev_priv,
>   wp->plane_blocks_per_line = div_fixed16(interm_pbpl,
>   wp->y_min_scanlines);
>   } else if (wp->x_tiled && IS_GEN9(dev_priv)) {
> - interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line, 512);
> + interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
> +wp->dbuf_block_size);
>   wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
>   } else {
> - interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line, 512) + 1;
> + interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
> +wp->dbuf_block_size) + 1;
>   wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
>   }
>  
> @@ -4515,7 +4524,7 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   latency += 15;
>  
>   method1 = skl_wm_method1(dev_priv, wp->plane_pixel_rate,
> -  wp->cpp, latency);
> +  wp->cpp, latency, wp->dbuf_block_size);
>   method2 = skl_wm_method2(wp->plane_pixel_rate,
>cstate->base.adjusted_mode.crtc_htotal,
>latency,
> @@ -4525,7 +4534,8 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   selected_result = max_fixed16(method2, wp->y_tile_minimum);
>   } else {
>   if ((wp->cpp * cstate->base.adjusted_mo

[Intel-gfx] ✗ Fi.CI.BAT: failure for ICL display initialization and some plane bits (rev2)

2018-01-29 Thread Patchwork
== Series Details ==

Series: ICL display initialization and some plane bits (rev2)
URL   : https://patchwork.freedesktop.org/series/36993/
State : failure

== Summary ==

Series 36993v2 ICL display initialization and some plane bits
https://patchwork.freedesktop.org/api/1.0/series/36993/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6700hq) fdo#101144 +2
pass   -> FAIL   (fi-skl-6700k2) fdo#103191 +1
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-guc)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
pass   -> FAIL   (fi-cfl-s2)
Subgroup suspend-read-crc-pipe-b:
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-guc)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
pass   -> FAIL   (fi-cfl-s2) k.org#197971 +1
Subgroup suspend-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-6260u) fdo#104108 +4
pass   -> FAIL   (fi-skl-guc)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
k.org#197971 https://bugzilla.kernel.org/show_bug.cgi?id=197971
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:255  dwarn:0   dfail:0   fail:3   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:457s
fi-cfl-s2total:288  pass:259  dwarn:0   dfail:0   fail:3   skip:26  
time:579s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:277s
fi-glk-1 total:288  pass:257  dwarn:0   dfail:0   fail:3   skip:28  
time:525s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:260  dwarn:1   dfail:0   fail:3   skip:24  
time:457s
fi-kbl-7560u total:288  pass:266  dwarn:0   dfail:0   fail:3   skip:19  
time:512s
fi-kbl-7567u total:288  pass:265  dwarn:0   dfail:0   fail:3   skip:20  
time:456s
fi-k

[Intel-gfx] [PATCH 04/10] drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.

2018-01-29 Thread Rodrigo Vivi
This was wrong since its introduction on commit '04416108ccea
("drm/i915/cnl: Add registers related to voltage swing sequences.")'

But since no Port F was needed so far we don't need to
propagate fixes back there.

Cc: Lucas De Marchi 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Dhinakaran Pandiyan 
---
 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 dda77443cb89..31e2fa602620 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1964,7 +1964,7 @@ enum i915_power_well_id {
 #define _CNL_PORT_TX_DW2_LN0_B 0x162648
 #define _CNL_PORT_TX_DW2_LN0_C 0x162C48
 #define _CNL_PORT_TX_DW2_LN0_D 0x162E48
-#define _CNL_PORT_TX_DW2_LN0_F 0x162A48
+#define _CNL_PORT_TX_DW2_LN0_F 0x162848
 #define CNL_PORT_TX_DW2_GRP(port)  _MMIO_PORT6(port, \
_CNL_PORT_TX_DW2_GRP_AE, \
_CNL_PORT_TX_DW2_GRP_B, \
-- 
2.13.6

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


[Intel-gfx] [PATCH 08/10] drm/i915/cnl: Add HPD support for Port F.

2018-01-29 Thread Rodrigo Vivi
On CNP boards that are using DDI F,
bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing
the Digital Port F hotplug line when the Digital
Port F hotplug detect input is enabled.

v2: Reuse all existent structure instead of adding a
new HPD_PORT_F pointing to pin of port E.
v3: Use IS_CNL_WITH_PORT_F so we can start upstreaming
this right now. If that SKU ever get a proper name
we come back and update it.
v4: Rebase on top of digital connected port using encoder
instead of port.
v5: Moved IS_CNL_WITH_PORT_F definition to the PCI IDs patch.

Cc: Lucas De Marchi 
Cc: Manasi Navare 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  6 --
 drivers/gpu/drm/i915/i915_irq.c  | 35 +++
 drivers/gpu/drm/i915/intel_dp.c  |  4 +++-
 drivers/gpu/drm/i915/intel_hdmi.c|  2 +-
 drivers/gpu/drm/i915/intel_hotplug.c | 19 +++
 5 files changed, 42 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f89a1a0a25c8..388b72cccde4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2958,8 +2958,10 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
 void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
 void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
-enum port intel_hpd_pin_to_port(enum hpd_pin pin);
-enum hpd_pin intel_hpd_pin(enum port port);
+enum port intel_hpd_pin_to_port(struct drm_i915_private *dev_priv,
+   enum hpd_pin pin);
+enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
+  enum port port);
 bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
 void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4d84b1c41a94..0213860963ab 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1574,10 +1574,11 @@ static bool i9xx_port_hotplug_long_detect(enum port 
port, u32 val)
  *
  * Note that the caller is expected to zero out the masks initially.
  */
-static void intel_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
-u32 hotplug_trigger, u32 dig_hotplug_reg,
-const u32 hpd[HPD_NUM_PINS],
-bool long_pulse_detect(enum port port, u32 val))
+static void intel_get_hpd_pins(struct drm_i915_private *dev_priv,
+  u32 *pin_mask, u32 *long_mask,
+  u32 hotplug_trigger, u32 dig_hotplug_reg,
+  const u32 hpd[HPD_NUM_PINS],
+  bool long_pulse_detect(enum port port, u32 val))
 {
enum port port;
int i;
@@ -1588,7 +1589,7 @@ static void intel_get_hpd_pins(u32 *pin_mask, u32 
*long_mask,
 
*pin_mask |= BIT(i);
 
-   port = intel_hpd_pin_to_port(i);
+   port = intel_hpd_pin_to_port(dev_priv, i);
if (port == PORT_NONE)
continue;
 
@@ -1976,8 +1977,9 @@ static void i9xx_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
 
if (hotplug_trigger) {
-   intel_get_hpd_pins(&pin_mask, &long_mask, 
hotplug_trigger,
-  hotplug_trigger, hpd_status_g4x,
+   intel_get_hpd_pins(dev_priv, &pin_mask, &long_mask,
+  hotplug_trigger, hotplug_trigger,
+  hpd_status_g4x,
   i9xx_port_hotplug_long_detect);
 
intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
@@ -1989,8 +1991,9 @@ static void i9xx_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
 
if (hotplug_trigger) {
-   intel_get_hpd_pins(&pin_mask, &long_mask, 
hotplug_trigger,
-  hotplug_trigger, hpd_status_i915,
+   intel_get_hpd_pins(dev_priv, &pin_mask, &long_mask,
+  hotplug_trigger, hotplug_trigger,
+  hpd_status_i915,
   i9xx_port_hotplug_long_detect);
intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
}
@@ -2191,7 +2194,7 @@ static void ibx_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
if (!hotplug_trigger)
return;
 
-   intel_get_hpd_pins(&pin_m

[Intel-gfx] [PATCH 09/10] drm/i915/cnl: Enable DDI-F on Cannonlake.

2018-01-29 Thread Rodrigo Vivi
Now let's finish the Port-F support by adding the
proper port F detection, irq and power well support.

v2: Rebase
v3: Use BIT_ULL
v4: Cover missed case on ddi init.
v5: Update commit message.
v6: Rebase on top of display headers rework.
v7: Squash power-well handling related to DDI F to this
patch to avoid warns as pointed out by DK.
v8: Introduce DDI_F_LANES to PG2. (DK)
v9: Squash in the PORT_F case for enabling DP MST encoder. (DK)

Cc: Dhinakaran Pandiyan 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: David Weinehall 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/intel_ddi.c|  4 
 drivers/gpu/drm/i915/intel_display.c|  6 +-
 drivers/gpu/drm/i915/intel_display.h|  2 ++
 drivers/gpu/drm/i915/intel_dp.c |  3 ++-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +---
 6 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 076a49107e02..8261fe4c4316 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1304,6 +1304,7 @@ enum i915_power_well_id {
SKL_DISP_PW_DDI_B,
SKL_DISP_PW_DDI_C,
SKL_DISP_PW_DDI_D,
+   CNL_DISP_PW_DDI_F = 6,
 
GLK_DISP_PW_AUX_A = 8,
GLK_DISP_PW_AUX_B,
@@ -8945,6 +8946,7 @@ enum skl_power_gate {
 #define  SFUSE_STRAP_RAW_FREQUENCY (1<<8)
 #define  SFUSE_STRAP_DISPLAY_DISABLED  (1<<7)
 #define  SFUSE_STRAP_CRT_DISABLED  (1<<6)
+#define  SFUSE_STRAP_DDIF_DETECTED (1<<3)
 #define  SFUSE_STRAP_DDIB_DETECTED (1<<2)
 #define  SFUSE_STRAP_DDIC_DETECTED (1<<1)
 #define  SFUSE_STRAP_DDID_DETECTED (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e51559be2e3b..cfcd9cb37d5d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2946,6 +2946,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
intel_dig_port->ddi_io_power_domain =
POWER_DOMAIN_PORT_DDI_E_IO;
break;
+   case PORT_F:
+   intel_dig_port->ddi_io_power_domain =
+   POWER_DOMAIN_PORT_DDI_F_IO;
+   break;
default:
MISSING_CASE(port);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 67e0ec4fb5e3..cf42917725d0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5647,6 +5647,8 @@ enum intel_display_power_domain 
intel_port_to_power_domain(enum port port)
return POWER_DOMAIN_PORT_DDI_D_LANES;
case PORT_E:
return POWER_DOMAIN_PORT_DDI_E_LANES;
+   case PORT_F:
+   return POWER_DOMAIN_PORT_DDI_F_LANES;
default:
MISSING_CASE(port);
return POWER_DOMAIN_PORT_OTHER;
@@ -13619,7 +13621,7 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
if (found || IS_GEN9_BC(dev_priv))
intel_ddi_init(dev_priv, PORT_A);
 
-   /* DDI B, C and D detection is indicated by the SFUSE_STRAP
+   /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
 * register */
found = I915_READ(SFUSE_STRAP);
 
@@ -13629,6 +13631,8 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
intel_ddi_init(dev_priv, PORT_C);
if (found & SFUSE_STRAP_DDID_DETECTED)
intel_ddi_init(dev_priv, PORT_D);
+   if (found & SFUSE_STRAP_DDIF_DETECTED)
+   intel_ddi_init(dev_priv, PORT_F);
/*
 * On SKL we don't have a way to detect DDI-E so we rely on VBT.
 */
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index 30fa2041a45f..c4042e342f50 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -157,11 +157,13 @@ enum intel_display_power_domain {
POWER_DOMAIN_PORT_DDI_C_LANES,
POWER_DOMAIN_PORT_DDI_D_LANES,
POWER_DOMAIN_PORT_DDI_E_LANES,
+   POWER_DOMAIN_PORT_DDI_F_LANES,
POWER_DOMAIN_PORT_DDI_A_IO,
POWER_DOMAIN_PORT_DDI_B_IO,
POWER_DOMAIN_PORT_DDI_C_IO,
POWER_DOMAIN_PORT_DDI_D_IO,
POWER_DOMAIN_PORT_DDI_E_IO,
+   POWER_DOMAIN_PORT_DDI_F_IO,
POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_PORT_CRT,
POWER_DOMAIN_PORT_OTHER,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ad055c527b1e..86a5e8bfe2a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6358,7 +6358,8 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 
/* init MS

[Intel-gfx] [PATCH 10/10] drm/i915/cnl: Fix DP max rate for Cannonlake with port F.

2018-01-29 Thread Rodrigo Vivi
On CNL SKUs that uses port F,  max DP rate is 8.1G for all
ports when we have the elevated voltage (higher than 0.85V).

v2: Make commit message more generic.
v3: Move conditions to a helper to get easier to read. (Ville).
v4: Add a mention to the numerical voltage on commit
message per Manasi request.
v5: Thanks CI! "error: control reaches end of non-void function"

Cc: Ville Syrjälä 
Cc: Lucas De Marchi 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 31 ---
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 86a5e8bfe2a6..1f10bdb855e7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -220,15 +220,36 @@ intel_dp_downstream_max_dotclock(struct intel_dp 
*intel_dp)
return max_dotclk;
 }
 
+static int cnl_adjusted_max_rate(struct intel_dp *intel_dp, int size)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+   enum port port = dig_port->base.port;
+
+   u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+
+   /* Low voltage SKUs are limited to max of 5.4G */
+   if (voltage == VOLTAGE_INFO_0_85V)
+   return size - 2;
+
+   /* For this SKU 8.1G is supported in all ports */
+   if(IS_CNL_WITH_PORT_F(dev_priv))
+   return size;
+
+   /* For other SKUs, max rate on ports A and B is 5.4G */
+   if (port == PORT_A || port == PORT_D)
+   return size - 2;
+
+   return size;
+}
+
 static void
 intel_dp_set_source_rates(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
-   enum port port = dig_port->base.port;
const int *source_rates;
int size;
-   u32 voltage;
 
/* This should only be done once */
WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates);
@@ -238,11 +259,7 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
size = ARRAY_SIZE(bxt_rates);
} else if (IS_CANNONLAKE(dev_priv)) {
source_rates = cnl_rates;
-   size = ARRAY_SIZE(cnl_rates);
-   voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
-   if (port == PORT_A || port == PORT_D ||
-   voltage == VOLTAGE_INFO_0_85V)
-   size -= 2;
+   size = cnl_adjusted_max_rate(intel_dp, ARRAY_SIZE(cnl_rates));
} else if (IS_GEN9_BC(dev_priv)) {
source_rates = skl_rates;
size = ARRAY_SIZE(skl_rates);
-- 
2.13.6

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


[Intel-gfx] [PATCH 06/10] drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.

2018-01-29 Thread Rodrigo Vivi
On CNP Pin 3 is for misc of Port F usage depending on the
configuration. For CNL that uses Port F, pin 3 is the one.

v2: Make it more generic and update commit message.

Cc: Anusha Srivatsa 
Cc: Lucas De Marchi 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Paulo Zanoni 
---
 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 57066d6cf52f..80476bb14b58 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2175,6 +2175,9 @@ static u8 cnp_port_to_ddc_pin(struct drm_i915_private 
*dev_priv,
case PORT_D:
ddc_pin = GMBUS_PIN_4_CNP;
break;
+   case PORT_F:
+   ddc_pin = GMBUS_PIN_3_BXT;
+   break;
default:
MISSING_CASE(port);
ddc_pin = GMBUS_PIN_1_BXT;
-- 
2.13.6

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


[Intel-gfx] [PATCH 02/10] drm/i915/cnl: Add AUX-F support

2018-01-29 Thread Rodrigo Vivi
On some Cannonlake SKUs we have a dedicated Aux for port F,
that is only the full split between port A and port E.

There is still no Aux E for Port E, as in previous platforms,
because port_E still means shared lanes with port A.

v2: Rebase.
v3: Add couple missed PORT_F cases on intel_dp.
v4: Rebase and fix commit message.
v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
v6: Rebase on top of display headers rework.
v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
v8: Fix Aux bits for Port F (DK)
v9: Fix VBT definition of Port F (DK).
v10: Squash power well addition to this patch to avoid
 warns as pointed by DK.
v11: Clean up squashed commit message. (David)
v12: Remove unnecessary handling for older platforms (DK)
 Adding AUX_F to PG2 following other existent ones. (DK)

Cc: David Weinehall 
Cc: Dhinakaran Pandiyan 
Cc: Lucas De Marchi 
Cc: Imre Deak 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: David Weinehall 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c |  6 ++
 drivers/gpu/drm/i915/i915_reg.h |  9 +
 drivers/gpu/drm/i915/intel_display.h|  1 +
 drivers/gpu/drm/i915/intel_dp.c |  6 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c | 22 ++
 6 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5702ebf17974..f89a1a0a25c8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1255,6 +1255,7 @@ enum modeset_restore {
 #define DP_AUX_B 0x10
 #define DP_AUX_C 0x20
 #define DP_AUX_D 0x30
+#define DP_AUX_F 0x60
 
 #define DDC_PIN_B  0x05
 #define DDC_PIN_C  0x04
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f643d5ad7ff7..4d84b1c41a94 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2585,6 +2585,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   tmp_mask |= CNL_AUX_CHANNEL_F;
+
if (iir & tmp_mask) {
dp_aux_irq_handler(dev_priv);
found = true;
@@ -3623,6 +3626,9 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
}
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   de_port_masked |= CNL_AUX_CHANNEL_F;
+
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
   GEN8_PIPE_FIFO_UNDERRUN;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 64933fd74cb6..44f46593172f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1312,6 +1312,7 @@ enum i915_power_well_id {
CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
CNL_DISP_PW_AUX_D,
+   CNL_DISP_PW_AUX_F,
 
SKL_DISP_PW_1 = 14,
SKL_DISP_PW_2,
@@ -5284,6 +5285,13 @@ enum {
 #define _DPD_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64320)
 #define _DPD_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64324)
 
+#define _DPF_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64510)
+#define _DPF_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64514)
+#define _DPF_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64518)
+#define _DPF_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6451c)
+#define _DPF_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64520)
+#define _DPF_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64524)
+
 #define DP_AUX_CH_CTL(port)_MMIO_PORT(port, _DPA_AUX_CH_CTL, 
_DPB_AUX_CH_CTL)
 #define DP_AUX_CH_DATA(port, i)_MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
_DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
 
@@ -6939,6 +6947,7 @@ enum {
 #define GEN8_DE_PORT_IMR _MMIO(0x4)
 #define GEN8_DE_PORT_IIR _MMIO(0x8)
 #define GEN8_DE_PORT_IER _MMIO(0xc)
+#define  CNL_AUX_CHANNEL_F (1 << 28)
 #define  GEN9_AUX_CHANNEL_D(1 << 27)
 #define  GEN9_AUX_CHANNEL_C(1 << 26)
 #define  GEN9_AUX_CHANNEL_B(1 << 25)
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index e47638931b51..30fa2041a45f 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -172,6 +172,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_B,
POWER_DOMAIN_AUX_C,
POWER_DOMAIN_AUX_D,
+   POWER_DOMAIN_AUX_F,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
PO

[Intel-gfx] [PATCH 07/10] drm/i915: For HPD connected port use hpd_pin instead of port.

2018-01-29 Thread Rodrigo Vivi
Let's try to simplify this mapping to hpd_pin -> bit
instead using port.
So for CNL with port F where we have this port using
hdp_pin and bits of other ports we don't need to duplicated
the mapping.

But for now this is only a re-org with no functional change
expected.

v2: Add missing lines and nuke @port reference from code
documentation. (Ville)

Cc: Lucas De Marchi 
Suggested-by: Ville Syrjälä 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 150 ++--
 drivers/gpu/drm/i915/intel_drv.h|   3 +-
 drivers/gpu/drm/i915/intel_lspcon.c |   3 +-
 3 files changed, 77 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 934feccfecfe..f9c90b79cbc4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4485,173 +4485,174 @@ edp_detect(struct intel_dp *intel_dp)
return status;
 }
 
-static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool ibx_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_B:
bit = SDE_PORTB_HOTPLUG;
break;
-   case PORT_C:
+   case HPD_PORT_C:
bit = SDE_PORTC_HOTPLUG;
break;
-   case PORT_D:
+   case HPD_PORT_D:
bit = SDE_PORTD_HOTPLUG;
break;
default:
-   MISSING_CASE(port->base.port);
+   MISSING_CASE(encoder->hpd_pin);
return false;
}
 
return I915_READ(SDEISR) & bit;
 }
 
-static bool cpt_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool cpt_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_B:
bit = SDE_PORTB_HOTPLUG_CPT;
break;
-   case PORT_C:
+   case HPD_PORT_C:
bit = SDE_PORTC_HOTPLUG_CPT;
break;
-   case PORT_D:
+   case HPD_PORT_D:
bit = SDE_PORTD_HOTPLUG_CPT;
break;
default:
-   MISSING_CASE(port->base.port);
+   MISSING_CASE(encoder->hpd_pin);
return false;
}
 
return I915_READ(SDEISR) & bit;
 }
 
-static bool spt_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool spt_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_A:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_A:
bit = SDE_PORTA_HOTPLUG_SPT;
break;
-   case PORT_E:
+   case HPD_PORT_E:
bit = SDE_PORTE_HOTPLUG_SPT;
break;
default:
-   return cpt_digital_port_connected(dev_priv, port);
+   return cpt_digital_port_connected(encoder);
}
 
return I915_READ(SDEISR) & bit;
 }
 
-static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool g4x_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_G4X;
break;
-   case PORT_C:
+   case HPD_PORT_C:
bit = PORTC_HOTPLUG_LIVE_STATUS_G4X;
break;
-   case PORT_D:
+   case HPD_PORT_D:
bit = PORTD_HOTPLUG_LIVE_STATUS_G4X;
break;
default:
-   MISSING_CASE(port->base.port);
+   MISSING_CASE(encoder->hpd_pin);
return false;
}
 
return I915_READ(PORT_HOTPLUG_STAT) & bit;
 }
 
-static bool gm45_digital_port_connected(struct drm_i915_private *dev_priv,
-   struct intel_digital_port *port)
+static bool gm45_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder

[Intel-gfx] [PATCH 05/10] drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.

2018-01-29 Thread Rodrigo Vivi
Since when it got introduced with commit '555e38d27317
("drm/i915/cnl: DDI - PLL mapping")' the support for Port F
was wrong, because Port F bits are far from bits used
for A to E.

Since Port F is not used so far we don't need to propagate
Fixes back there.

v2: Reuse _SHIFT definition to avoid complicated duplication (DK).

Cc: Dhinakaran Pandiyan 
Cc: Lucas De Marchi 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_reg.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 31e2fa602620..076a49107e02 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8844,10 +8844,12 @@ enum skl_power_gate {
  * CNL Clocks
  */
 #define DPCLKA_CFGCR0  _MMIO(0x6C200)
-#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port)   (1 << ((port)+10))
-#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)  (3 << ((port)*2))
-#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port) ((port)*2)
-#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)  ((pll) << ((port)*2))
+#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port)   (1 << ((port) ==  PORT_F ? 23 : 
\
+ (port)+10))
+#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port) ((port) == PORT_F ? 21 : \
+   (port)*2)
+#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)  (3 << 
DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port))
+#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)  ((pll) << 
DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port))
 
 /* CNL PLL */
 #define DPLL0_ENABLE   0x46010
-- 
2.13.6

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


[Intel-gfx] [PATCH 01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

2018-01-29 Thread Rodrigo Vivi
The only difference is that this SKUs has the full
Port A/E split named as Port F.

But since SKUs differences don't matter on the platform
definition group and ids, let's merge all off them together.

v2: Really include the PCI IDs to the picidlist[];
v3: Add the PCI Id for another SKU (Anusha).
v4: Update IDs, really include to pciidlists again.
v5: Unify all GT2 IDs.
v6: Unify in a way that we don't break early-quirks.c
v7: Remove GT reference since it doesn't matter here (Paulo)
Also move IS_CNL_WITH_PORT_F macro to this patch to
make it easier for review this part and also to get
used sooner.
v8: Rebased on top of commit 5db47e37b387 ("Revert "drm/i915:
mark all device info struct with __initconst"")

Cc: Dhinakaran Pandiyan 
Cc: Paulo Zanoni 
Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_pci.c |  5 ++---
 include/drm/i915_pciids.h   | 18 +++---
 3 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 454d8f937fae..5702ebf17974 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2648,6 +2648,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 (dev_priv)->info.gt == 2)
 #define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
 (dev_priv)->info.gt == 3)
+#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
+   (INTEL_DEVID(dev_priv) & 0x0004) == 
0x0004)
 
 #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 138228dd7782..4e7a10c89782 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -571,7 +571,7 @@ static const struct intel_device_info 
intel_coffeelake_gt3_info = {
.ddb_size = 1024, \
GLK_COLORS
 
-static const struct intel_device_info intel_cannonlake_gt2_info = {
+static const struct intel_device_info intel_cannonlake_info = {
GEN10_FEATURES,
.is_alpha_support = 1,
.platform = INTEL_CANNONLAKE,
@@ -649,8 +649,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_CFL_U_GT1_IDS(&intel_coffeelake_gt1_info),
INTEL_CFL_U_GT2_IDS(&intel_coffeelake_gt2_info),
INTEL_CFL_U_GT3_IDS(&intel_coffeelake_gt3_info),
-   INTEL_CNL_U_GT2_IDS(&intel_cannonlake_gt2_info),
-   INTEL_CNL_Y_GT2_IDS(&intel_cannonlake_gt2_info),
+   INTEL_CNL_IDS(&intel_cannonlake_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 5db0458dd832..9e1fe6634424 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -414,24 +414,20 @@
INTEL_CFL_U_GT2_IDS(info), \
INTEL_CFL_U_GT3_IDS(info)
 
-/* CNL U 2+2 */
-#define INTEL_CNL_U_GT2_IDS(info) \
+/* CNL */
+#define INTEL_CNL_IDS(info) \
INTEL_VGA_DEVICE(0x5A52, info), \
INTEL_VGA_DEVICE(0x5A5A, info), \
INTEL_VGA_DEVICE(0x5A42, info), \
-   INTEL_VGA_DEVICE(0x5A4A, info)
-
-/* CNL Y 2+2 */
-#define INTEL_CNL_Y_GT2_IDS(info) \
+   INTEL_VGA_DEVICE(0x5A4A, info), \
INTEL_VGA_DEVICE(0x5A51, info), \
INTEL_VGA_DEVICE(0x5A59, info), \
INTEL_VGA_DEVICE(0x5A41, info), \
INTEL_VGA_DEVICE(0x5A49, info), \
INTEL_VGA_DEVICE(0x5A71, info), \
-   INTEL_VGA_DEVICE(0x5A79, info)
-
-#define INTEL_CNL_IDS(info) \
-   INTEL_CNL_U_GT2_IDS(info), \
-   INTEL_CNL_Y_GT2_IDS(info)
+   INTEL_VGA_DEVICE(0x5A79, info), \
+   INTEL_VGA_DEVICE(0x5A54, info), \
+   INTEL_VGA_DEVICE(0x5A5C, info), \
+   INTEL_VGA_DEVICE(0x5A44, info)
 
 #endif /* _I915_PCIIDS_H */
-- 
2.13.6

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


[Intel-gfx] [PATCH 03/10] drm/i915/cnl: Extend Wa 1178 to Aux F.

2018-01-29 Thread Rodrigo Vivi
We also need to extend this WA to Aux F.

Cc: Dhinakaran Pandiyan 
Cc: Lucas De Marchi 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_reg.h | 4 +++-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 44f46593172f..dda77443cb89 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8439,10 +8439,12 @@ enum skl_power_gate {
 #define _CNL_AUX_ANAOVRD1_B0x162250
 #define _CNL_AUX_ANAOVRD1_C0x162210
 #define _CNL_AUX_ANAOVRD1_D0x1622D0
+#define _CNL_AUX_ANAOVRD1_F0x162A90
 #define CNL_AUX_ANAOVRD1(pw)   _MMIO(_PICK(_CNL_AUX_REG_IDX(pw), \
_CNL_AUX_ANAOVRD1_B, \
_CNL_AUX_ANAOVRD1_C, \
-   _CNL_AUX_ANAOVRD1_D))
+   _CNL_AUX_ANAOVRD1_D, \
+   _CNL_AUX_ANAOVRD1_F))
 #define   CNL_AUX_ANAOVRD1_ENABLE  (1<<16)
 #define   CNL_AUX_ANAOVRD1_LDO_BYPASS  (1<<23)
 
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index a274e930f045..294b85adc413 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -395,7 +395,7 @@ static void hsw_power_well_enable(struct drm_i915_private 
*dev_priv,
/* Display WA #1178: cnl */
if (IS_CANNONLAKE(dev_priv) &&
(id == CNL_DISP_PW_AUX_B || id == CNL_DISP_PW_AUX_C ||
-id == CNL_DISP_PW_AUX_D)) {
+id == CNL_DISP_PW_AUX_D || id == CNL_DISP_PW_AUX_F)) {
val = I915_READ(CNL_AUX_ANAOVRD1(id));
val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS;
I915_WRITE(CNL_AUX_ANAOVRD1(id), val);
-- 
2.13.6

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


[Intel-gfx] [PATCH 07/13] drm/i915/icl: Fail flip if ddb allocated are less than min display buffer needed

2018-01-29 Thread Paulo Zanoni
From: Mahesh Kumar 

ICL require DDB allocation of plane to be more than "minimum display
buffer needed" for each level in order to enable WM level.

This patch implements and consider the same while allocating DDB
and enabling WM.

Changes Since V1:
 - rebase
Changes Since V2:
 - Remove extra parentheses
 - Use FP16.16 only when absolutely necessary (Paulo)
Changes Since V3:
 - Rebase
Changes since v4 (from Paulo):
 - Coding style issue.
Changes since v5 (from Paulo):
 - Do the final checks according to BSpec.

Reviewed-by: Paulo Zanoni 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 985642cf1c9a..24421603e605 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4507,6 +4507,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
struct intel_atomic_state *state =
to_intel_atomic_state(cstate->base.state);
bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
+   uint32_t min_disp_buf_needed;
 
if (latency == 0 ||
!intel_wm_plane_visible(cstate, intel_pstate)) {
@@ -4565,7 +4566,31 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
}
 
-   if (res_blocks >= ddb_allocation || res_lines > 31) {
+   if (INTEL_GEN(dev_priv) >= 11) {
+   if (wp->y_tiled) {
+   uint32_t extra_lines;
+   uint_fixed_16_16_t fp_min_disp_buf_needed;
+
+   if (res_lines % wp->y_min_scanlines == 0)
+   extra_lines = wp->y_min_scanlines;
+   else
+   extra_lines = wp->y_min_scanlines * 2 -
+ res_lines % wp->y_min_scanlines;
+
+   fp_min_disp_buf_needed = mul_u32_fixed16(res_lines +
+   extra_lines,
+   wp->plane_blocks_per_line);
+   min_disp_buf_needed = fixed16_to_u32_round_up(
+   fp_min_disp_buf_needed);
+   } else {
+   min_disp_buf_needed = DIV_ROUND_UP(res_blocks * 11, 10);
+   }
+   } else {
+   min_disp_buf_needed = res_blocks;
+   }
+
+   if (res_blocks >= ddb_allocation || res_lines > 31 ||
+   min_disp_buf_needed >= ddb_allocation) {
*enabled = false;
 
/*
-- 
2.14.3

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


[Intel-gfx] [PATCH 06/17] drm/i915/icl: Do not fix dbuf block size to 512

2018-01-29 Thread Paulo Zanoni
From: Mahesh Kumar 

GEN9/10 had fixed DBuf block size of 512. Dbuf block size is not a
fixed number anymore in GEN11, it varies according to bits per pixel
and tiling. If 8bpp & Yf-tile surface, block size = 256 else block
size = 512

This patch addresses the same.

v2 (from Paulo):
  - Make it compile.
  - Fix a few coding style issues.
v3:
  - Rebase on top of upstream patches
v4 (from Paulo):
  - Bikeshed if statements (James).

Reviewed-by: Paulo Zanoni 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 24 +---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 454d8f937fae..d93e784c3f14 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1460,6 +1460,7 @@ struct skl_wm_params {
uint_fixed_16_16_t plane_blocks_per_line;
uint_fixed_16_16_t y_tile_minimum;
uint32_t linetime_us;
+   uint32_t dbuf_block_size;
 };
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 11aac65d1543..985642cf1c9a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4312,7 +4312,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
 */
 static uint_fixed_16_16_t
 skl_wm_method1(const struct drm_i915_private *dev_priv, uint32_t pixel_rate,
-  uint8_t cpp, uint32_t latency)
+  uint8_t cpp, uint32_t latency, uint32_t dbuf_block_size)
 {
uint32_t wm_intermediate_val;
uint_fixed_16_16_t ret;
@@ -4321,7 +4321,7 @@ skl_wm_method1(const struct drm_i915_private *dev_priv, 
uint32_t pixel_rate,
return FP_16_16_MAX;
 
wm_intermediate_val = latency * pixel_rate * cpp;
-   ret = div_fixed16(wm_intermediate_val, 1000 * 512);
+   ret = div_fixed16(wm_intermediate_val, 1000 * dbuf_block_size);
 
if (INTEL_GEN(dev_priv) >= 10)
ret = add_fixed16_u32(ret, 1);
@@ -4431,6 +4431,12 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
wp->plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate,
 intel_pstate);
 
+   if (INTEL_GEN(dev_priv) >= 11 &&
+   fb->modifier == I915_FORMAT_MOD_Yf_TILED && wp->cpp == 8)
+   wp->dbuf_block_size = 256;
+   else
+   wp->dbuf_block_size = 512;
+
if (drm_rotation_90_or_270(pstate->rotation)) {
 
switch (wp->cpp) {
@@ -4457,7 +4463,8 @@ skl_compute_plane_wm_params(const struct drm_i915_private 
*dev_priv,
wp->plane_bytes_per_line = wp->width * wp->cpp;
if (wp->y_tiled) {
interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line *
-  wp->y_min_scanlines, 512);
+  wp->y_min_scanlines,
+  wp->dbuf_block_size);
 
if (INTEL_GEN(dev_priv) >= 10)
interm_pbpl++;
@@ -4465,10 +4472,12 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
wp->plane_blocks_per_line = div_fixed16(interm_pbpl,
wp->y_min_scanlines);
} else if (wp->x_tiled && IS_GEN9(dev_priv)) {
-   interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line, 512);
+   interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
+  wp->dbuf_block_size);
wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
} else {
-   interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line, 512) + 1;
+   interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
+  wp->dbuf_block_size) + 1;
wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
}
 
@@ -4515,7 +4524,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
latency += 15;
 
method1 = skl_wm_method1(dev_priv, wp->plane_pixel_rate,
-wp->cpp, latency);
+wp->cpp, latency, wp->dbuf_block_size);
method2 = skl_wm_method2(wp->plane_pixel_rate,
 cstate->base.adjusted_mode.crtc_htotal,
 latency,
@@ -4525,7 +4534,8 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
selected_result = max_fixed16(method2, wp->y_tile_minimum);
} else {
if ((wp->cpp * cstate->base.adjusted_mode.crtc_htotal /
-512 < 1) && (wp->plane_bytes_per_line / 512 < 1))
+wp->dbuf_block_size < 1) &&
+(wp->plane_bytes_per_line / wp->dbuf_block_size < 1))
   

Re: [Intel-gfx] [PATCH 16/17] drm/i915/icl: enable SAGV for ICL platform

2018-01-29 Thread Paulo Zanoni
Em Ter, 2018-01-23 às 17:05 -0200, Paulo Zanoni escreveu:
> From: Mahesh Kumar 
> 
> Enable SAGV for ICL platform.

The requirements for enabling SAGV on ICL are different. We need to
implement them. While we don't have them, perhaps the best option is to
add ICL to intel_has_sagv() but then always return false on
can_enable_sagv().

> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 1edd1445ab5b..dedc76781524 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3605,7 +3605,7 @@ static bool
>  intel_has_sagv(struct drm_i915_private *dev_priv)
>  {
>   if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> - IS_CANNONLAKE(dev_priv))
> + IS_CANNONLAKE(dev_priv) || IS_ICELAKE(dev_priv))
>   return true;
>  
>   if (IS_SKYLAKE(dev_priv) &&
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

2018-01-29 Thread Rodrigo Vivi
On Mon, Jan 29, 2018 at 05:42:53AM +, Kai Heng Feng wrote:
> 
> > On 26 Jan 2018, at 6:25 AM, Rodrigo Vivi  wrote:
> > 
> > If the table result is out of bounds on the array map
> > there is something really wrong with VBT pin so we don't
> > return that vbt_pin, but only return 0 instead.
> > 
> > This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
> > Ignore VBT request for know invalid DDC pin.")'
> > 
> > Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
> > Map VBT DDC Pin to BSpec DDC Pin.")
> > 
> > v2: Do in a way that we don't break other platforms. (Jani)
> > 
> > v3: Keep debug message (Jani)
> > 
> > v4: Don't mess with 0 mapping was noticed by Jani and
> >addressed with a simple solution suggested by Lucas
> >that makes this even simpler.
> > 
> > Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC 
> > pin.")
> > Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
> > Cc: Radhakrishna Sripada 
> > Cc: Jani Nikula 
> > Cc: Kai Heng Feng 
> > Cc: Lucas De Marchi 
> > Suggested-by: Lucas De Marchi 
> > Signed-off-by: Rodrigo Vivi 
> 
> Tested-by: Kai-Heng Feng 

merged. thanks for suggestions, reviews, tests and patience ;)

> 
> > ---
> > drivers/gpu/drm/i915/intel_bios.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 95f0b310d656..cf3f8f1ba6f7 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1107,6 +1107,7 @@ static void sanitize_aux_ch(struct drm_i915_private 
> > *dev_priv,
> > }
> > 
> > static const u8 cnp_ddc_pin_map[] = {
> > +   [0] = 0, /* N/A */
> > [DDC_BUS_DDI_B] = GMBUS_PIN_1_BXT,
> > [DDC_BUS_DDI_C] = GMBUS_PIN_2_BXT,
> > [DDC_BUS_DDI_D] = GMBUS_PIN_4_CNP, /* sic */
> > @@ -1116,9 +1117,9 @@ static const u8 cnp_ddc_pin_map[] = {
> > static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> > {
> > if (HAS_PCH_CNP(dev_priv)) {
> > -   if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> > +   if (vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) {
> > return cnp_ddc_pin_map[vbt_pin];
> > -   if (vbt_pin > GMBUS_PIN_4_CNP) {
> > +   } else {
> > DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC 
> > pin %d, which is not valid for this platform\n", vbt_pin);
> > return 0;
> > }
> > -- 
> > 2.13.6
> > 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/cnl: Enable DDI-F on Cannonlake.

2018-01-29 Thread Pandiyan, Dhinakaran



On Fri, 2018-01-26 at 17:33 -0800, Rodrigo Vivi wrote:
> Now let's finish the Port-F support by adding the
> proper port F detection, irq and power well support.
> 
> v2: Rebase
> v3: Use BIT_ULL
> v4: Cover missed case on ddi init.
> v5: Update commit message.
> v6: Rebase on top of display headers rework.
> v7: Squash power-well handling related to DDI F to this
> patch to avoid warns as pointed out by DK.
> v8: Introduce DDI_F_LANES to PG2. (DK)
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: David Weinehall 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/intel_ddi.c|  4 
>  drivers/gpu/drm/i915/intel_display.c|  6 +-
>  drivers/gpu/drm/i915/intel_display.h|  2 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +---
>  5 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 076a49107e02..8261fe4c4316 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1304,6 +1304,7 @@ enum i915_power_well_id {
>   SKL_DISP_PW_DDI_B,
>   SKL_DISP_PW_DDI_C,
>   SKL_DISP_PW_DDI_D,
> + CNL_DISP_PW_DDI_F = 6,
>  
>   GLK_DISP_PW_AUX_A = 8,
>   GLK_DISP_PW_AUX_B,
> @@ -8945,6 +8946,7 @@ enum skl_power_gate {
>  #define  SFUSE_STRAP_RAW_FREQUENCY   (1<<8)
>  #define  SFUSE_STRAP_DISPLAY_DISABLED(1<<7)
>  #define  SFUSE_STRAP_CRT_DISABLED(1<<6)
> +#define  SFUSE_STRAP_DDIF_DETECTED   (1<<3)
>  #define  SFUSE_STRAP_DDIB_DETECTED   (1<<2)
>  #define  SFUSE_STRAP_DDIC_DETECTED   (1<<1)
>  #define  SFUSE_STRAP_DDID_DETECTED   (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index e51559be2e3b..cfcd9cb37d5d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2946,6 +2946,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   intel_dig_port->ddi_io_power_domain =
>   POWER_DOMAIN_PORT_DDI_E_IO;
>   break;
> + case PORT_F:
> + intel_dig_port->ddi_io_power_domain =
> + POWER_DOMAIN_PORT_DDI_F_IO;
> + break;
>   default:
>   MISSING_CASE(port);
>   }


It also looked liked intel_dp_set_source_rates was wrong, but I see that
you fix it in the last patch. The conditions for
intel_dp_mst_encoder_init() need to be updated too. I think that is all
I have for this patch.

With the MST change squashed in.
Reviewed-by: Dhinakaran Pandiyan 



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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: expose RCS topology to userspace

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: expose RCS topology to userspace
URL   : https://patchwork.freedesktop.org/series/37290/
State : failure

== Summary ==

Test gem_gpgpu_fill:
pass   -> FAIL   (shard-hsw)
pass   -> FAIL   (shard-apl)
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Test pm_sseu:
Subgroup full-enable:
pass   -> FAIL   (shard-apl) fdo#104651
Test perf_pmu:
Subgroup frequency:
fail   -> PASS   (shard-apl) fdo#104829
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
skip   -> PASS   (shard-snb) fdo#101623 +1
Subgroup fbc-1p-shrfb-fliptrack:
fail   -> PASS   (shard-apl) fdo#103167
Test gem_media_fill:
pass   -> FAIL   (shard-hsw)
pass   -> FAIL   (shard-apl)

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#104651 https://bugs.freedesktop.org/show_bug.cgi?id=104651
fdo#104829 https://bugs.freedesktop.org/show_bug.cgi?id=104829
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

shard-apltotal:2838 pass:1749 dwarn:1   dfail:0   fail:24  skip:1064 
time:12653s
shard-hswtotal:2838 pass:1734 dwarn:1   dfail:0   fail:12  skip:1090 
time:11983s
shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:10  skip:1497 
time:6663s
Blacklisted hosts:
shard-kbltotal:2838 pass:1866 dwarn:5   dfail:0   fail:26  skip:941 
time:9623s

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Remove Firmware URL.

2018-01-29 Thread Rodrigo Vivi
On Mon, Jan 29, 2018 at 08:45:24PM +, Chris Wilson wrote:
> Quoting Srivatsa, Anusha (2018-01-29 20:17:25)
> > 
> > 
> > >-Original Message-
> > >From: Vivi, Rodrigo
> > >Sent: Friday, January 26, 2018 10:22 AM
> > >To: intel-gfx@lists.freedesktop.org
> > >Cc: Vivi, Rodrigo ; Srivatsa, Anusha
> > >
> > >Subject: [PATCH] drm/i915: Remove Firmware URL.
> > >
> > >The right place for the firmware is linux-firmware.git.
> > >We shouldn't advertise anywhere to users to start downloading firmware 
> > >blobs
> > >manually.
> > >
> > >Also it seems that 01.org page is outdated and it doesn't contain DMC 1.27 
> > >for
> > >SKL, for instance. Probably other firmware releases are missing there, 
> > >while they
> > >are part of the official linux-firmware.git.
> 
> Then get them onto 01.org. If Intel cannot be relied on to provide their
> own firmwares, the alternative is to stop shipping blobs entirely.

I understand your point. But the goal is to have only one place and this place
is linux-firmware.git.

The web-page will still have the information about the firmware and
a text explaining the linux-firmware repository.

But what I want is to avoid any users with the impression they
have to manually go there and install anything.

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Free memdup-ed bios data structures on driver_unload

2018-01-29 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Free memdup-ed bios data 
structures on driver_unload
URL   : https://patchwork.freedesktop.org/series/37282/
State : failure

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-mmap-cpu:
pass   -> FAIL   (shard-apl)
Subgroup fbc-1p-primscrn-shrfb-pgflip-blt:
pass   -> DMESG-FAIL (shard-apl) fdo#101623 +2
Subgroup fbc-1p-shrfb-fliptrack:
fail   -> PASS   (shard-apl) fdo#103167
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw)
Subgroup modeset-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> SKIP   (shard-snb) fdo#103880
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test perf_pmu:
Subgroup frequency:
fail   -> PASS   (shard-apl) fdo#104829

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#104829 https://bugs.freedesktop.org/show_bug.cgi?id=104829

shard-apltotal:2758 pass:1706 dwarn:1   dfail:1   fail:21  skip:1029 
time:12189s
shard-hswtotal:2838 pass:1734 dwarn:1   dfail:0   fail:12  skip:1090 
time:12060s
shard-snbtotal:2838 pass:1329 dwarn:1   dfail:0   fail:10  skip:1498 
time:6694s
Blacklisted hosts:
shard-kbltotal:2838 pass:1872 dwarn:5   dfail:0   fail:23  skip:938 
time:9628s

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Simplify guard logic for setup_scratch_page()

2018-01-29 Thread Chris Wilson
Quoting Matthew Auld (2018-01-29 10:54:35)
> On 29 January 2018 at 10:28, Chris Wilson  wrote:
> > Older gcc is complaining it can't follow the guards and thinks that
> > addr may be used uninitialised
> >
> > In the process, we can simplify down to one loop,
> > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-131 (-131)
> > Function old new   delta
> > setup_scratch_page   545 414-131
> >
> > Reported-by: Geert Uytterhoeven 
> > Signed-off-by: Chris Wilson 
> > Cc: Matthew Auld 
> 
> With or without __GFP_RETRY_MAYFAIL:

Snuck it in.
 
> Reviewed-by: Matthew Auld 

Ta, pushed. Remind me in 6 months (4.17) to see if we're finally clean.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Assert the engine has finished the seqno on unsubmission

2018-01-29 Thread Chris Wilson
Quoting Michał Winiarski (2018-01-29 11:10:42)
> On Mon, Jan 29, 2018 at 09:49:12AM +, Chris Wilson wrote:
> > Assert that we do not try to unsubmit a completed request, as should we
> > try to resubmit it later, the ring is already past the request's
> > breadcrumb and the breadcrumb will not be updated.
> 
> "Assert that we do not try to unsubmit a completed request" in the subject?
> (what does it mean to "finish the seqno"?)
> 
> Reviewed-by: Michał Winiarski 

Fixed up the subject as suggested, and pushed. Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Remove Firmware URL.

2018-01-29 Thread Chris Wilson
Quoting Srivatsa, Anusha (2018-01-29 20:17:25)
> 
> 
> >-Original Message-
> >From: Vivi, Rodrigo
> >Sent: Friday, January 26, 2018 10:22 AM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: Vivi, Rodrigo ; Srivatsa, Anusha
> >
> >Subject: [PATCH] drm/i915: Remove Firmware URL.
> >
> >The right place for the firmware is linux-firmware.git.
> >We shouldn't advertise anywhere to users to start downloading firmware blobs
> >manually.
> >
> >Also it seems that 01.org page is outdated and it doesn't contain DMC 1.27 
> >for
> >SKL, for instance. Probably other firmware releases are missing there, while 
> >they
> >are part of the official linux-firmware.git.

Then get them onto 01.org. If Intel cannot be relied on to provide their
own firmwares, the alternative is to stop shipping blobs entirely.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915: Check for fused or unused pipes

2018-01-29 Thread Chris Wilson
Quoting Jani Nikula (2018-01-19 14:22:49)
> On Mon, 18 Dec 2017, Mika Kahola  wrote:
> > We may have fused or unused pipes in our system. Let's check that the pipe
> > in question is within limits of accessible pipes. In case, that we are not
> > able to access the pipe, we return early with a warning.
> >
> > v2: Rephrasing of the commit message (Jani)
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103206
> > Reported-by: Thomas Gleixner 
> > Tested-by: Jaswinder Singh Rajput 
> > Suggested-by: Jani Nikula 
> > Reviewed-by: Jani Nikula 
> > Signed-off-by: Mika Kahola 
> 
> Pushed, thanks for the patch, sorry for the delay.

This WARN is in the wild, should we queue this for drm-intel-fixes.

Reported-by: frit...@xbmc.org
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add AUX-F support

2018-01-29 Thread Pandiyan, Dhinakaran


On Fri, 2018-01-26 at 17:27 -0800, Rodrigo Vivi wrote:
> On some Cannonlake SKUs we have a dedicated Aux for port F,
> that is only the full split between port A and port E.
> 
> There is still no Aux E for Port E, as in previous platforms,
> because port_E still means shared lanes with port A.
> 
> v2: Rebase.
> v3: Add couple missed PORT_F cases on intel_dp.
> v4: Rebase and fix commit message.
> v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
> v6: Rebase on top of display headers rework.
> v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
> v8: Fix Aux bits for Port F (DK)
> v9: Fix VBT definition of Port F (DK).
> v10: Squash power well addition to this patch to avoid
>  warns as pointed by DK.
> v11: Clean up squashed commit message. (David)
> v12: Remove unnecessary handling for older platforms (DK)
>  Adding AUX_F to PG2 following other existent ones. (DK)


Looks good to me now,
Reviewed-by: Dhinakaran Pandiyan 

> Cc: David Weinehall 
> Cc: Dhinakaran Pandiyan 
> Cc: Lucas De Marchi 
> Cc: Imre Deak 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: David Weinehall 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_irq.c |  6 ++
>  drivers/gpu/drm/i915/i915_reg.h |  9 +
>  drivers/gpu/drm/i915/intel_display.h|  1 +
>  drivers/gpu/drm/i915/intel_dp.c |  6 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 22 ++
>  6 files changed, 45 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5702ebf17974..f89a1a0a25c8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1255,6 +1255,7 @@ enum modeset_restore {
>  #define DP_AUX_B 0x10
>  #define DP_AUX_C 0x20
>  #define DP_AUX_D 0x30
> +#define DP_AUX_F 0x60
>  
>  #define DDC_PIN_B  0x05
>  #define DDC_PIN_C  0x04
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f643d5ad7ff7..4d84b1c41a94 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2585,6 +2585,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   GEN9_AUX_CHANNEL_C |
>   GEN9_AUX_CHANNEL_D;
>  
> + if (IS_CNL_WITH_PORT_F(dev_priv))
> + tmp_mask |= CNL_AUX_CHANNEL_F;
> +
>   if (iir & tmp_mask) {
>   dp_aux_irq_handler(dev_priv);
>   found = true;
> @@ -3623,6 +3626,9 @@ static void gen8_de_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>   de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
>   }
>  
> + if (IS_CNL_WITH_PORT_F(dev_priv))
> + de_port_masked |= CNL_AUX_CHANNEL_F;
> +
>   de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
>  GEN8_PIPE_FIFO_UNDERRUN;
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 64933fd74cb6..44f46593172f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1312,6 +1312,7 @@ enum i915_power_well_id {
>   CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
>   CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
>   CNL_DISP_PW_AUX_D,
> + CNL_DISP_PW_AUX_F,
>  
>   SKL_DISP_PW_1 = 14,
>   SKL_DISP_PW_2,
> @@ -5284,6 +5285,13 @@ enum {
>  #define _DPD_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64320)
>  #define _DPD_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64324)
>  
> +#define _DPF_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64510)
> +#define _DPF_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64514)
> +#define _DPF_AUX_CH_DATA2(dev_priv->info.display_mmio_offset + 0x64518)
> +#define _DPF_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6451c)
> +#define _DPF_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64520)
> +#define _DPF_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64524)
> +
>  #define DP_AUX_CH_CTL(port)  _MMIO_PORT(port, _DPA_AUX_CH_CTL, 
> _DPB_AUX_CH_CTL)
>  #define DP_AUX_CH_DATA(port, i)  _MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
> _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
>  
> @@ -6939,6 +6947,7 @@ enum {
>  #define GEN8_DE_PORT_IMR _MMIO(0x4)
>  #define GEN8_DE_PORT_IIR _MMIO(0x8)
>  #define GEN8_DE_PORT_IER _MMIO(0xc)
> +#define  CNL_AUX_CHANNEL_F   (1 << 28)
>  #define  GEN9_AUX_CHANNEL_D  (1 << 27)
>  #define  GEN9_AUX_CHANNEL_C  (1 << 26)
>  #define  GEN9_AUX_CHANNEL_B  (1 << 25)
> diff --git a/drivers/gpu/drm/i915/intel_display.h 
> b/drivers/gpu/drm/i915/intel_display.h
> index e47638931b51..30fa2041a45f 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/int

Re: [Intel-gfx] [PATCH 01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

2018-01-29 Thread Jani Nikula
On Mon, 29 Jan 2018, "Pandiyan, Dhinakaran"  
wrote:
> On Sat, 2018-01-27 at 11:05 +0200, Jani Nikula wrote:
>> On Fri, 26 Jan 2018, Rodrigo Vivi  wrote:
>> > On Fri, Jan 26, 2018 at 10:12:00AM +, Jani Nikula wrote:
>> >> On Thu, 25 Jan 2018, Rodrigo Vivi  wrote:
>> >> > The only difference is that this SKUs has the full
>> >> > Port A/E split named as Port F.
>> >> >
>> >> > But since SKUs differences don't matter on the platform
>> >> > definition group and ids, let's merge all off them together.
>> >> >
>> >> > v2: Really include the PCI IDs to the picidlist[];
>> >> > v3: Add the PCI Id for another SKU (Anusha).
>> >> > v4: Update IDs, really include to pciidlists again.
>> >> > v5: Unify all GT2 IDs.
>> >> > v6: Unify in a way that we don't break early-quirks.c
>> >> > v7: Remove GT reference since it doesn't matter here (Paulo)
>> >> > Also move IS_CNL_WITH_PORT_F macro to this patch to
>> >> > make it easier for review this part and also to get
>> >> > used sooner.
>> >> >
>> >> > Cc: Dhinakaran Pandiyan 
>> >> > Cc: Paulo Zanoni 
>> >> > Cc: Lucas De Marchi 
>> >> > Signed-off-by: Anusha Srivatsa 
>> >> > Signed-off-by: Rodrigo Vivi 
>> >> > Reviewed-by: Paulo Zanoni 
>> >> > ---
>> >> >  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>> >> >  drivers/gpu/drm/i915/i915_pci.c |  5 ++---
>> >> >  include/drm/i915_pciids.h   | 18 +++---
>> >> >  3 files changed, 11 insertions(+), 14 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> >> > b/drivers/gpu/drm/i915/i915_drv.h
>> >> > index 454d8f937fae..5702ebf17974 100644
>> >> > --- a/drivers/gpu/drm/i915/i915_drv.h
>> >> > +++ b/drivers/gpu/drm/i915/i915_drv.h
>> >> > @@ -2648,6 +2648,8 @@ intel_info(const struct drm_i915_private 
>> >> > *dev_priv)
>> >> >  (dev_priv)->info.gt == 2)
>> >> >  #define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
>> >> >  (dev_priv)->info.gt == 3)
>> >> > +#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
>> >> > +   (INTEL_DEVID(dev_priv) & 
>> >> > 0x0004) == 0x0004)
>> >> 
>> >> I'd be happy if bit 2 in device id actually meant "port F", but I'm not
>> >> so happy with coming up with rules like this for coincidental things.
>> >
>> > the port F thing is just that we have no name for that SKU :(
>> > but from the spec organization this bit seems to represent that
>> > group. Although I fully agree with you that this is horrible.
>> >
>> >> 
>> >> More generally, I'm not all that happy about *any* of the INTEL_DEVID
>> >> uses in i915_drv.h because it spreads out the device id information, so
>> >> I'd rather not add more. I'd rather move towards single point of truth
>> >> for device ids.
>> >
>> > Yeah. I guess I agree with you.
>> > There should be something inside the device info right?
>> > even if we have to separate that in two groups.
>> 
>> That's the thing. It also worries me to add everything in device info,
>> because it grows the device info structs for all devices, and you also
>> need to add more device infos to cover all combinations. Unless you
>> initialize them runtime, which is also a bit meh.
>> 
>
> I am wondering if we can augment the device info struct at run-time with
> a union of platform-specific key-value pairs.

That occurred to me too, but I'm not thrilled about the prospect of
maintaining the union and ensuring we only ever access the fields within
correct platform specific code or conditions.

BR,
Jani.


>
>
>> > If you agree with this approach I can follow up with a patch/series
>> > that kill INTEL_DEVID in favor of device info structs.
>> >
>> > Or do you have any other idea for solving this?
>> 
>> Not really. Cc: Chris and Tvrtko who seem to come up with ideas for
>> things like this on a regular basis. ;)
>> 
>> BR,
>> Jani.
>> 
>> >
>> > on this particular case here I considered that, but
>> > since I had no good name and INTEL_DEVID was there I've
>> > chosen the lazy path.
>> >
>> >> 
>> >> Okay, so this is late in the review cycles, and part of a more general
>> >> problem, so we should probably just go with this for now and come back
>> >> to this later.
>> >
>> > It is never too late ;)
>> >
>> > But in this case I'd prefer moving with this series as is
>> > to avoid blocking Paulo with ICL enabling and minimize
>> > the conflicts and rebase pain to only one area of the code.
>> >
>> > Thanks for bringing it up,
>> > Rodrigo.
>> >
>> >> 
>> >> 
>> >> BR,
>> >> Jani.
>> >> 
>> >> 
>> >> 
>> >> 
>> >> >  
>> >> >  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
>> >> >  
>> >> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
>> >> > b/drivers/gpu/drm/i915/i915_pci.c
>> >> > index f28c165fc49d..7eb3d5e4350e 100644
>> >> > --- a/drivers/gpu/drm/i915/i915_pci.c
>> >> > +++ b/drivers/gpu/drm/i915/i915_pci.c
>> >> > @@ -571,7 +571,7 @@ static const struct intel_device_info 
>> >> > intel

Re: [Intel-gfx] [PATCH] drm/i915: Remove Firmware URL.

2018-01-29 Thread Srivatsa, Anusha


>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, January 26, 2018 10:22 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo ; Srivatsa, Anusha
>
>Subject: [PATCH] drm/i915: Remove Firmware URL.
>
>The right place for the firmware is linux-firmware.git.
>We shouldn't advertise anywhere to users to start downloading firmware blobs
>manually.
>
>Also it seems that 01.org page is outdated and it doesn't contain DMC 1.27 for
>SKL, for instance. Probably other firmware releases are missing there, while 
>they
>are part of the official linux-firmware.git.
>
>So, let's stop advertising that place here.
>But also let's work in parallel to kill that page for good and maybe with a 
>message
>explaining to users that they don't need to install manually, but rely on their
>distros for getting linux-firmware package updates.
>
>Cc: Anusha Srivatsa 
>Signed-off-by: Rodrigo Vivi 
Thanks for this much needed patch.

Reviewed-by: Anusha Srivatsa
>---
> drivers/gpu/drm/i915/intel_csr.c   | 2 --
> drivers/gpu/drm/i915/intel_uc_fw.c | 2 --  drivers/gpu/drm/i915/intel_uc_fw.h 
> |
>3 ---
> 3 files changed, 7 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_csr.c 
>b/drivers/gpu/drm/i915/intel_csr.c
>index 41e6c75a7f3c..05761ffbf2ec 100644
>--- a/drivers/gpu/drm/i915/intel_csr.c
>+++ b/drivers/gpu/drm/i915/intel_csr.c
>@@ -429,8 +429,6 @@ static void csr_load_work_fn(struct work_struct *work)
>  "Failed to load DMC firmware %s."
>  " Disabling runtime power management.\n",
>  csr->fw_path);
>-  dev_notice(dev_priv->drm.dev, "DMC firmware homepage: %s",
>- INTEL_UC_FIRMWARE_URL);
>   }
>
>   release_firmware(fw);
>diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c
>b/drivers/gpu/drm/i915/intel_uc_fw.c
>index 784eff9cdfc8..f2c4ddb4b91d 100644
>--- a/drivers/gpu/drm/i915/intel_uc_fw.c
>+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
>@@ -189,8 +189,6 @@ void intel_uc_fw_fetch(struct drm_i915_private
>*dev_priv,
>
>   DRM_WARN("%s: Failed to fetch firmware %s (error %d)\n",
>intel_uc_fw_type_repr(uc_fw->type), uc_fw->path, err);
>-  DRM_INFO("%s: Firmware can be downloaded from %s\n",
>-   intel_uc_fw_type_repr(uc_fw->type),
>INTEL_UC_FIRMWARE_URL);
>
>   release_firmware(fw);   /* OK even if fw is NULL */
> }
>diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h
>b/drivers/gpu/drm/i915/intel_uc_fw.h
>index d5fd4609c785..ee40852f2250 100644
>--- a/drivers/gpu/drm/i915/intel_uc_fw.h
>+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
>@@ -29,9 +29,6 @@ struct drm_printer;
> struct drm_i915_private;
> struct i915_vma;
>
>-/* Home of GuC, HuC and DMC firmwares */ -#define
>INTEL_UC_FIRMWARE_URL "https://01.org/linuxgraphics/downloads/firmware";
>-
> enum intel_uc_fw_status {
>   INTEL_UC_FIRMWARE_FAIL = -1,
>   INTEL_UC_FIRMWARE_NONE = 0,
>--
>2.13.6

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


Re: [Intel-gfx] [PATCH 00/10] drm/uapi: Validate mode flags/type, and deprecate some of them

2018-01-29 Thread Ville Syrjälä
On Tue, Nov 14, 2017 at 08:32:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> I recently realized that we're not validating the mode flags/type
> passed in from userspace. Let's try to fix that.
> 
> I'd also like to entirely eliminate some of the more crazy mode flags.
> PIXMUX and BCAST look pretty easy, so I've targetted them first.
> 
> Ideally I'd like to kill DBLCLK, CLKDIV2, HSKEW, DBLSCAN, and vscan
> as well. IMO there's no good reason to expose any of that to userspace,
> and instead it should all be handled internally by the drivers.
> Unfortunately all of those seem to be used to some degree by a handful
> of drivers.
> 
> I also tried to nuke some of the crazy mode types.
> 
> Cc: Jose Abreu 
> Cc: Adam Jackson 
> Cc: Keith Packard 
> 
> Ville Syrjälä (10):
>   drm/modes: Move 3D stereo flag check into drm_mode_validate_basic()
>   drm/uapi: Validate the mode flags/type
>   drm/uapi: Deprecate DRM_MODE_FLAG_PIXMUX
>   drm/uapi: Deprecate DRM_MODE_FLAG_BCAST
>   drm/modes: Fix description of DRM_MODE_TYPE_USERDEF
>   drm/modes: Kill off the oddball DRM_MODE_TYPE_CRTC_C vs.
> DRM_MODE_TYPE_BUILTIN handling
>   drm/modes: Kill DRM_MODE_TYPE_CLOCK_CRTC_C define
>   drm/uapi: Deprecate nonsense kms mode types
>   drm/modes: Provide global mode_valid hook
>   drm/i915: Provide a device level .mode_valid() hook

Entire series pushed to drm-misc-next. Thanks for the reviews.

> 
>  drivers/gpu/drm/drm_atomic.c |  2 +-
>  drivers/gpu/drm/drm_crtc.c   |  2 +-
>  drivers/gpu/drm/drm_modes.c  | 60 
> +---
>  drivers/gpu/drm/drm_probe_helper.c   |  2 +-
>  drivers/gpu/drm/i915/intel_crt.c |  3 --
>  drivers/gpu/drm/i915/intel_display.c | 27 
>  drivers/gpu/drm/i915/intel_dsi.c |  5 ---
>  drivers/gpu/drm/i915/intel_dvo.c |  3 --
>  drivers/gpu/drm/i915/intel_fbc.c |  3 +-
>  drivers/gpu/drm/i915/intel_hdmi.c|  3 --
>  drivers/gpu/drm/i915/intel_sdvo.c|  3 --
>  include/drm/drm_mode_config.h| 12 
>  include/drm/drm_modes.h  | 24 +++
>  include/uapi/drm/drm_mode.h  | 30 ++
>  14 files changed, 120 insertions(+), 59 deletions(-)
> 
> -- 
> 2.13.6

-- 
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/i915: Add display WA #1175 for planes ending close to right screen edge

2018-01-29 Thread Ville Syrjälä
On Tue, Jan 16, 2018 at 01:24:14PM +0200, Imre Deak wrote:
> As described in the WA on GLK and CNL planes on the right edge of the
> screen that have less than 4 pixels visible from the beginning of the
> plane to the edge of the screen can cause FIFO underflow and display
> corruption.
> 
> On GLK/CNL I could trigger the problem only if the plane was at the same
> time also aligned to the top edge of the screen (after clipping) and
> there were exactly 2 pixels visible from the start of the plane to the
> right edge of the screen (so couldn't trigger it with 1 or 3 pixels
> visible). Nevertheless, to be sure, I also applied the WA for these cases.
> 
> I also couldn't see any problem with the cursor plane and later Art
> confirmed that it's not affected, so the WA is applied only for the
> other plane types.
> 
> v2:
> - Use -ERANGE instead of -EINVAL. (Chris)
> 
> Signed-off-by: Imre Deak 

For both patches
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 28 
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
>  drivers/gpu/drm/i915/intel_sprite.c  |  2 +-
>  3 files changed, 27 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 221e3a183d36..7fe1592bf0df 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2917,14 +2917,19 @@ static bool skl_check_main_ccs_coordinates(struct 
> intel_plane_state *plane_state
>   return true;
>  }
>  
> -static int skl_check_main_surface(struct intel_plane_state *plane_state)
> +static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
> +   struct intel_plane_state *plane_state)
>  {
> + struct drm_i915_private *dev_priv =
> + to_i915(plane_state->base.plane->dev);
>   const struct drm_framebuffer *fb = plane_state->base.fb;
>   unsigned int rotation = plane_state->base.rotation;
>   int x = plane_state->base.src.x1 >> 16;
>   int y = plane_state->base.src.y1 >> 16;
>   int w = drm_rect_width(&plane_state->base.src) >> 16;
>   int h = drm_rect_height(&plane_state->base.src) >> 16;
> + int dst_x = plane_state->base.dst.x1;
> + int pipe_src_w = crtc_state->pipe_src_w;
>   int max_width = skl_max_plane_width(fb, 0, rotation);
>   int max_height = 4096;
>   u32 alignment, offset, aux_offset = plane_state->aux.offset;
> @@ -2935,6 +2940,20 @@ static int skl_check_main_surface(struct 
> intel_plane_state *plane_state)
>   return -EINVAL;
>   }
>  
> + /*
> +  * Display WA #1175: cnl,glk
> +  * Planes other than the cursor may cause FIFO underflow and display
> +  * corruption if starting less than 4 pixels from the right edge of
> +  * the screen.
> +  */
> + if ((IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
> + dst_x > pipe_src_w - 4) {
> + DRM_DEBUG_KMS("requested plane X start position %d invalid 
> (valid range %d-%d)\n",
> +   dst_x,
> +   0, pipe_src_w - 4);
> + return -ERANGE;
> + }
> +
>   intel_add_fb_offsets(&x, &y, plane_state, 0);
>   offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
>   alignment = intel_surf_alignment(fb, 0);
> @@ -3067,7 +3086,8 @@ static int skl_check_ccs_aux_surface(struct 
> intel_plane_state *plane_state)
>   return 0;
>  }
>  
> -int skl_check_plane_surface(struct intel_plane_state *plane_state)
> +int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
> + struct intel_plane_state *plane_state)
>  {
>   const struct drm_framebuffer *fb = plane_state->base.fb;
>   unsigned int rotation = plane_state->base.rotation;
> @@ -3107,7 +3127,7 @@ int skl_check_plane_surface(struct intel_plane_state 
> *plane_state)
>   plane_state->aux.y = 0;
>   }
>  
> - ret = skl_check_main_surface(plane_state);
> + ret = skl_check_main_surface(crtc_state, plane_state);
>   if (ret)
>   return ret;
>  
> @@ -12766,7 +12786,7 @@ intel_check_primary_plane(struct intel_plane *plane,
>   return 0;
>  
>   if (INTEL_GEN(dev_priv) >= 9) {
> - ret = skl_check_plane_surface(state);
> + ret = skl_check_plane_surface(crtc_state, state);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 5c8e260ca2bc..0f2356d84d0d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1588,7 +1588,8 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
> *crtc_state,
> const struct intel_plane_state *plane_state);
>  u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
>unsigned int rotation);
> -int skl_check_plane_su

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Tracking waiters for execution wrt hangcheck

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: Tracking waiters for execution wrt hangcheck
URL   : https://patchwork.freedesktop.org/series/37276/
State : warning

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-shrfb-fliptrack:
fail   -> PASS   (shard-apl) fdo#103167
Subgroup fbc-1p-primscrn-spr-indfb-fullscreen:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-legacy:
pass   -> SKIP   (shard-snb)
Subgroup flip-vs-cursor-toggle:
pass   -> FAIL   (shard-hsw) fdo#102670
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-bottom-edge:
pass   -> SKIP   (shard-snb)
Subgroup pipe-a-128x128-bottom-edge:
pass   -> SKIP   (shard-snb)
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
pass   -> SKIP   (shard-snb) fdo#102365

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365

shard-apltotal:2838 pass:1751 dwarn:1   dfail:0   fail:22  skip:1064 
time:12676s
shard-hswtotal:2838 pass:1735 dwarn:1   dfail:0   fail:11  skip:1090 
time:12041s
shard-snbtotal:2838 pass:1324 dwarn:1   dfail:0   fail:10  skip:1503 
time:6573s
Blacklisted hosts:
shard-kbltotal:2838 pass:1869 dwarn:5   dfail:0   fail:22  skip:942 
time:9676s

== Logs ==

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


[Intel-gfx] [PULL] Backlight helpers from tinydrm

2018-01-29 Thread Sean Paul

Hi Lee,
Here's the pull request for Meghana's patch set. It's based on 4.15, and just
contains the backlight portion of the set. I couldn't include the rest as it
depends on patches that only exist in drm-misc-next atm.

Thanks for coordinating with me on this!


topic/backlight_for_lag-2018-01-29:
This contains the backlight portion of Meghana Madhyastha's patch set to
migrate the backlight helpers from tinydrm to the backlight subsystem.

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

Cc: Meghana Madhyastha 

Cheers, Sean


The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:

  Linux 4.15 (2018-01-28 13:20:33 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc 
tags/topic/backlight_for_lag-2018-01-29

for you to fetch changes up to 2e4ef3347b4a4eb65c4fd950d94bbd75fed4d798:

  video: backlight: Add devres versions of of_find_backlight (2018-01-29 
10:34:53 -0500)


This contains the backlight portion of Meghana Madhyastha's patch set to
migrate the backlight helpers from tinydrm to the backlight subsystem.

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

Cc: Meghana Madhyastha 


Meghana Madhyastha (3):
  video: backlight: Add helpers to enable and disable backlight
  video: backlight: Add of_find_backlight helper in backlight.c
  video: backlight: Add devres versions of of_find_backlight

 drivers/video/backlight/backlight.c | 73 +
 include/linux/backlight.h   | 58 +
 2 files changed, 131 insertions(+)

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


Re: [Intel-gfx] [PATCH 01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

2018-01-29 Thread Pandiyan, Dhinakaran



On Sat, 2018-01-27 at 11:05 +0200, Jani Nikula wrote:
> On Fri, 26 Jan 2018, Rodrigo Vivi  wrote:
> > On Fri, Jan 26, 2018 at 10:12:00AM +, Jani Nikula wrote:
> >> On Thu, 25 Jan 2018, Rodrigo Vivi  wrote:
> >> > The only difference is that this SKUs has the full
> >> > Port A/E split named as Port F.
> >> >
> >> > But since SKUs differences don't matter on the platform
> >> > definition group and ids, let's merge all off them together.
> >> >
> >> > v2: Really include the PCI IDs to the picidlist[];
> >> > v3: Add the PCI Id for another SKU (Anusha).
> >> > v4: Update IDs, really include to pciidlists again.
> >> > v5: Unify all GT2 IDs.
> >> > v6: Unify in a way that we don't break early-quirks.c
> >> > v7: Remove GT reference since it doesn't matter here (Paulo)
> >> > Also move IS_CNL_WITH_PORT_F macro to this patch to
> >> > make it easier for review this part and also to get
> >> > used sooner.
> >> >
> >> > Cc: Dhinakaran Pandiyan 
> >> > Cc: Paulo Zanoni 
> >> > Cc: Lucas De Marchi 
> >> > Signed-off-by: Anusha Srivatsa 
> >> > Signed-off-by: Rodrigo Vivi 
> >> > Reviewed-by: Paulo Zanoni 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_drv.h |  2 ++
> >> >  drivers/gpu/drm/i915/i915_pci.c |  5 ++---
> >> >  include/drm/i915_pciids.h   | 18 +++---
> >> >  3 files changed, 11 insertions(+), 14 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> > b/drivers/gpu/drm/i915/i915_drv.h
> >> > index 454d8f937fae..5702ebf17974 100644
> >> > --- a/drivers/gpu/drm/i915/i915_drv.h
> >> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> > @@ -2648,6 +2648,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> >> >   (dev_priv)->info.gt == 2)
> >> >  #define IS_CFL_GT3(dev_priv)(IS_COFFEELAKE(dev_priv) && \
> >> >   (dev_priv)->info.gt == 3)
> >> > +#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
> >> > +(INTEL_DEVID(dev_priv) & 
> >> > 0x0004) == 0x0004)
> >> 
> >> I'd be happy if bit 2 in device id actually meant "port F", but I'm not
> >> so happy with coming up with rules like this for coincidental things.
> >
> > the port F thing is just that we have no name for that SKU :(
> > but from the spec organization this bit seems to represent that
> > group. Although I fully agree with you that this is horrible.
> >
> >> 
> >> More generally, I'm not all that happy about *any* of the INTEL_DEVID
> >> uses in i915_drv.h because it spreads out the device id information, so
> >> I'd rather not add more. I'd rather move towards single point of truth
> >> for device ids.
> >
> > Yeah. I guess I agree with you.
> > There should be something inside the device info right?
> > even if we have to separate that in two groups.
> 
> That's the thing. It also worries me to add everything in device info,
> because it grows the device info structs for all devices, and you also
> need to add more device infos to cover all combinations. Unless you
> initialize them runtime, which is also a bit meh.
> 

I am wondering if we can augment the device info struct at run-time with
a union of platform-specific key-value pairs.


> > If you agree with this approach I can follow up with a patch/series
> > that kill INTEL_DEVID in favor of device info structs.
> >
> > Or do you have any other idea for solving this?
> 
> Not really. Cc: Chris and Tvrtko who seem to come up with ideas for
> things like this on a regular basis. ;)
> 
> BR,
> Jani.
> 
> >
> > on this particular case here I considered that, but
> > since I had no good name and INTEL_DEVID was there I've
> > chosen the lazy path.
> >
> >> 
> >> Okay, so this is late in the review cycles, and part of a more general
> >> problem, so we should probably just go with this for now and come back
> >> to this later.
> >
> > It is never too late ;)
> >
> > But in this case I'd prefer moving with this series as is
> > to avoid blocking Paulo with ICL enabling and minimize
> > the conflicts and rebase pain to only one area of the code.
> >
> > Thanks for bringing it up,
> > Rodrigo.
> >
> >> 
> >> 
> >> BR,
> >> Jani.
> >> 
> >> 
> >> 
> >> 
> >> >  
> >> >  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
> >> >  
> >> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> >> > b/drivers/gpu/drm/i915/i915_pci.c
> >> > index f28c165fc49d..7eb3d5e4350e 100644
> >> > --- a/drivers/gpu/drm/i915/i915_pci.c
> >> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> >> > @@ -571,7 +571,7 @@ static const struct intel_device_info 
> >> > intel_coffeelake_gt3_info __initconst = {
> >> >  .ddb_size = 1024, \
> >> >  GLK_COLORS
> >> >  
> >> > -static const struct intel_device_info intel_cannonlake_gt2_info 
> >> > __initconst = {
> >> > +static const struct intel_device_info intel_cannonlake_info __initconst 
> >> > = {
> >> >  GEN10_FEATURES,
> >> >  .is_alpha_support = 1,
> >> > 

Re: [Intel-gfx] [PATCH] drm/i915: Fix Limited Range Color Handling

2018-01-29 Thread Ville Syrjälä
On Fri, Dec 29, 2017 at 08:29:11PM +0530, Uma Shankar wrote:
> From: Johnson Lin 
> 
> Some panels support limited range output (16-235) compared
> to full range RGB values (0-255). Also userspace can control
> the RGB range using "Broadcast RGB" property. Currently the
> code to handle full range to limited range is broken. This
> patch fixes the same by properly scaling down all the full
> range co-efficients with limited range scaling factor.
> 
> v2: Fixed Ville's review comments.
> 
> Signed-off-by: Johnson Lin 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/intel_color.c |   29 +++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_color.c 
> b/drivers/gpu/drm/i915/intel_color.c
> index aa66e95..55408e2 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -84,26 +84,27 @@ static bool crtc_state_is_legacy_gamma(struct 
> drm_crtc_state *state)
>  
>  /*
>   * When using limited range, multiply the matrix given by userspace by
> - * the matrix that we would use for the limited range. We do the
> - * multiplication in U2.30 format.
> + * the matrix that we would use for the limited range.
>   */
>  static void ctm_mult_by_limited(uint64_t *result, int64_t *input)

Since your touching pretty much every line anyway, maybe
s/uint64/u64/ etc. all over. 

'input' should really be const u64 *.

>  {
>   int i;
>  
> - for (i = 0; i < 9; i++)
> - result[i] = 0;
> + for (i = 0; i < 9; i++) {
> + uint64_t user_coeff = input[i];
> + uint32_t limited_coeff = CTM_COEFF_LIMITED_RANGE;
> + uint32_t abs_coeff = (uint32_t)(clamp_val(

The cast is not needed.

Apart from those nits this lgtm.
Reviewed-by: Ville Syrjälä 

> + CTM_COEFF_ABS(user_coeff),
> + 0,
> + CTM_COEFF_4_0 - 1) >> 2);
>  
> - for (i = 0; i < 3; i++) {
> - int64_t user_coeff = input[i * 3 + i];
> - uint64_t limited_coeff = CTM_COEFF_LIMITED_RANGE >> 2;
> - uint64_t abs_coeff = clamp_val(CTM_COEFF_ABS(user_coeff),
> -0,
> -CTM_COEFF_4_0 - 1) >> 2;
> -
> - result[i * 3 + i] = (limited_coeff * abs_coeff) >> 27;
> - if (CTM_COEFF_NEGATIVE(user_coeff))
> - result[i * 3 + i] |= CTM_COEFF_SIGN;
> + /*
> +  * By scaling every co-efficient with limited range (16-235)
> +  * vs full range (0-255) the final o/p will be scaled down to
> +  * fit in the limited range supported by the panel.
> +  */
> + result[i] = mul_u32_u32(limited_coeff, abs_coeff) >> 30;
> + result[i] |= user_coeff & CTM_COEFF_SIGN;
>   }
>  }
>  
> -- 
> 1.7.9.5
> 
> ___
> 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 07/17] drm/i915/icl: Fail flip if ddb allocated are less than min display buffer needed

2018-01-29 Thread Paulo Zanoni
Em Sex, 2018-01-26 às 15:50 -0800, James Ausmus escreveu:
> On Tue, Jan 23, 2018 at 05:05:26PM -0200, Paulo Zanoni wrote:
> > From: Mahesh Kumar 
> > 
> > ICL require DDB allocation of plane to be more than "minimum
> > display
> > buffer needed" for each level in order to enable WM level.
> > 
> > This patch implements and consider the same while allocating DDB
> > and enabling WM.
> > 
> > Changes Since V1:
> >  - rebase
> > Changes Since V2:
> >  - Remove extra parentheses
> >  - Use FP16.16 only when absolutely necessary (Paulo)
> > Changes Since V3:
> >  - Rebase
> > Changes since v4 (from Paulo)
> >  - Coding style issue.
> > 
> > Reviewed-by: Paulo Zanoni 
> > Signed-off-by: Mahesh Kumar 
> > Signed-off-by: Paulo Zanoni 
> 
> Reviewed-by: James Ausmus 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 30
> > +-
> >  1 file changed, 29 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 44d952a3d9a6..c6d31a5075ad 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4510,6 +4510,7 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > struct intel_atomic_state *state =
> > to_intel_atomic_state(cstate->base.state);
> > bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
> > +   uint32_t min_disp_buf_needed;
> >  
> > if (latency == 0 ||
> > !intel_wm_plane_visible(cstate, intel_pstate)) {
> > @@ -4568,7 +4569,34 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > }
> > }
> >  
> > -   if (res_blocks >= ddb_allocation || res_lines > 31) {
> > +   if (INTEL_GEN(dev_priv) >= 11) {
> > +   if (wp->y_tiled) {
> > +   uint32_t extra_lines;
> > +   uint_fixed_16_16_t fp_min_disp_buf_needed;
> > +
> > +   if (res_lines % wp->y_min_scanlines == 0)
> > +   extra_lines = wp->y_min_scanlines;
> > +   else
> > +   extra_lines = wp->y_min_scanlines
> > * 2 -
> > + res_lines % wp-
> > >y_min_scanlines;
> > +
> > +   fp_min_disp_buf_needed =
> > mul_u32_fixed16(res_lines +
> > +   extra_lines,
> > +   wp-
> > >plane_blocks_per_line);
> > +   min_disp_buf_needed =
> > fixed16_to_u32_round_up(
> > +   fp_min_disp_buf_ne
> > eded);
> > +   } else {
> > +   min_disp_buf_needed =
> > DIV_ROUND_UP(res_blocks * 11, 10);
> > +   }
> > +   } else {
> > +   /*
> > +* To enable a WM level ddb_allocation should be
> > +* greater than result blocks for GEN-9/10.
> > +*/
> > +   min_disp_buf_needed = res_blocks + 1;
> > +   }
> > +
> > +   if (min_disp_buf_needed > ddb_allocation || res_lines > 

BSpec says that if min_disp_buf_needed == ddb_allocation we should also
fail, as weird as it sounds.


> > 31) {
> > *enabled = false;
> >  
> > /*
> > -- 
> > 2.14.3
> > 
> > ___
> > 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 04/17] drm/i915/icl: Enable both DBuf slices during init

2018-01-29 Thread Paulo Zanoni
Em Sex, 2018-01-26 às 18:50 -0200, Paulo Zanoni escreveu:
> Em Ter, 2018-01-23 às 16:49 -0800, James Ausmus escreveu:
> > On Tue, Jan 23, 2018 at 05:05:23PM -0200, Paulo Zanoni wrote:
> > > From: Mahesh Kumar 
> > > 
> > > ICL has 2 slices of DBuf, enable both the slices during display
> > > init.
> > > 
> > > Ideally we should only enable the second slice when needed in
> > > order
> > > to
> > > save power, but while we're not there yet, adopt the simpler
> > > solution
> > > to keep us bug-free.
> > > 
> > > v2 (from Paulo):
> > >   - Add the TODO comment.
> > >   - Reorganize where things are defined.
> > >   - Fix indentation.
> > >   - Remove unnecessary POSTING_READ() calls.
> > >   - Improve the commit message.
> > > 
> > > Signed-off-by: Mahesh Kumar 
> > > Signed-off-by: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h |  2 ++
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 34
> > > +++--
> > >  2 files changed, 34 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 979bc06a59f4..1746df9a263d 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7122,6 +7122,8 @@ enum {
> > >  #define  DISP_DATA_PARTITION_5_6 (1<<6)
> > >  #define  DISP_IPC_ENABLE (1<<3)
> > >  #define DBUF_CTL _MMIO(0x45008)
> > > +#define DBUF_CTL_S1  _MMIO(0x45008)
> > 
> > Since it's the exact same register, is it really worth duplicating,
> > or
> > should we just use the existing DBUF_CTL instead of adding
> > DBUF_CTL_S1?
> 
> I like it: it's just a single extra line on i915_reg.h and adds
> clarity
> to the code that uses it. But I have nothing against removing it too.
> 
> 
> > 
> > 
> > > +#define DBUF_CTL_S2  _MMIO(0x44FE8)
> > >  #define  DBUF_POWER_REQUEST  (1<<31)
> > >  #define  DBUF_POWER_STATE(1<<30)
> > >  #define GEN7_MSG_CTL _MMIO(0x45010)
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index 2556db16c76a..7801a425398f 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -2610,6 +2610,36 @@ static void gen9_dbuf_disable(struct
> > > drm_i915_private *dev_priv)
> > >   DRM_ERROR("DBuf power disable timeout!\n");
> > >  }
> > >  
> > > +/*
> > > + * TODO: we shouldn't always enable DBUF_CTL_S2, we should only
> > > enable it when
> > > + * needed and keep it disabled as much as possible.
> > > + */
> > > +static void icl_dbuf_enable(struct drm_i915_private *dev_priv)
> > > +{
> > > + I915_WRITE(DBUF_CTL_S1, I915_READ(DBUF_CTL_S1) |
> > > DBUF_POWER_REQUEST);
> > > + I915_WRITE(DBUF_CTL_S2, I915_READ(DBUF_CTL_S2) |
> > > DBUF_POWER_REQUEST);
> > > + POSTING_READ(DBUF_CTL_S2);
> > > +
> > > + udelay(10);
> > 
> > BSpec says to poll, and timeout/fail after 10 uS, rather than
> > unconditionally busy wait - worth making more complex to
> > potentially
> > save a few uS of busy wait?
> 
> Yeah, good points. We have intel_wait_for_register() to help avoid
> the
> complexity here.

Oops, I realized this is just 10us. Our wait macros aren't helpful
here, the sleep is too small.

Also, these functions are modeled after skl_dbuf_{dis,en}enable, which
uses udelay too. We probably want to keep the same coding style for the
gen9 and the icl one.

So I think the best course is to keep the udelay, and if we come up
with a better solution we apply to the skl functions too.

With all that said, I guess my r-b patch on the patch stands.

> 
> 
> > 
> > > +
> > > + if (!(I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
> > > + !(I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
> > > + DRM_ERROR("DBuf power enable timeout\n");
> > > +}
> > > +
> > > +static void icl_dbuf_disable(struct drm_i915_private *dev_priv)
> > > +{
> > > + I915_WRITE(DBUF_CTL_S1, I915_READ(DBUF_CTL_S1) &
> > > ~DBUF_POWER_REQUEST);
> > > + I915_WRITE(DBUF_CTL_S2, I915_READ(DBUF_CTL_S2) &
> > > ~DBUF_POWER_REQUEST);
> > > + POSTING_READ(DBUF_CTL_S2);
> > > +
> > > + udelay(10);
> > > +
> > > + if ((I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
> > > + (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
> > > + DRM_ERROR("DBuf power disable timeout!\n");
> > > +}
> > > +
> > >  static void skl_display_core_init(struct drm_i915_private
> > > *dev_priv,
> > >  bool resume)
> > >  {
> > > @@ -2920,7 +2950,7 @@ static void icl_display_core_init(struct
> > > drm_i915_private *dev_priv,
> > >   icl_init_cdclk(dev_priv);
> > >  
> > >   /* 6. Enable DBUF. */
> > > - gen9_dbuf_enable(dev_priv);
> > > + icl_dbuf_enable(dev_priv);
> > >  
> > >   /* 7. Setup MBUS. */
> > >   /* FIXME: MBUS code not here yet. */
> > > @@ -2940,7 +2970,7 @@ static void icl_display_core_uninit(struct
> > > drm_i915_private *dev_priv)
> > >   /* 1. Disable all display engine function

Re: [Intel-gfx] [PATCH] drm/i915: Only allocate preempt context when required

2018-01-29 Thread Daniele Ceraolo Spurio



On 27/01/18 12:28, Chris Wilson wrote:

If we remove some hardcoded assumptions about the preempt context having
a fixed id, reserved from use by normal user contexts, we may only
allocate the i915_gem_context when required. Then the subsequent
decisions on using preemption reduce to having the preempt context
available.

Signed-off-by: Chris Wilson 
Cc: Michal Winiarski 
Cc: Tvrtko Ursulin 
Cc: Arkadiusz Hiler 
Cc: Mika Kuoppala 
Cc: Daniele Ceraolo Spurio 
---


Acked-by: Daniele Ceraolo Spurio 

I didn't spot anything wrong with the patch, but I'll leave the full 
review to the preemption experts ;)


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


Re: [Intel-gfx] [PATCH v3] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

2018-01-29 Thread Ville Syrjälä
On Thu, Jan 25, 2018 at 10:12:52AM -0500, Harry Wentland wrote:
> On 2018-01-25 08:30 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> > Naturally we can only do that if the index of those objects stays
> > below 32. Issue a warning whenever we exceed that limit, hopefully
> > prompting someone to fix the problem.
> > 
> > For connectors the issue is a bit more complicated as they can
> > be created/destroyed at runtime due to MST. So the problem is no
> > longer a purely theoretical programmer error. As the connector
> > indexes are allocated via ida, we can simply limit the maximum
> > value the ida is allowed to hand out. The error handling is already
> > in place.
> > 
> > v2: Return an error to the caller (Harry)
> > v3: Print a debug message so that we know what happened (Maarten)
> > 
> > Cc: Harry Wentland 
> > Cc: Maarten Lankhorst 
> > Cc: Daniel Vetter 
> > Reviewed-by: Maarten Lankhorst 
> 
> Reviewed-by: Harry Wentland 

Thanks for the review. Pushed to drm-misc-next.

> 
> Harry
> 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_connector.c | 9 +++--
> >  drivers/gpu/drm/drm_crtc.c  | 4 
> >  drivers/gpu/drm/drm_encoder.c   | 4 
> >  drivers/gpu/drm/drm_plane.c | 4 
> >  4 files changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index b85a7749709d..16b9c3810af2 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -205,9 +205,14 @@ int drm_connector_init(struct drm_device *dev,
> > connector->dev = dev;
> > connector->funcs = funcs;
> >  
> > -   ret = ida_simple_get(&config->connector_ida, 0, 0, GFP_KERNEL);
> > -   if (ret < 0)
> > +   /* connector index is used with 32bit bitmasks */
> > +   ret = ida_simple_get(&config->connector_ida, 0, 32, GFP_KERNEL);
> > +   if (ret < 0) {
> > +   DRM_DEBUG_KMS("Failed to allocate %s connector index: %d\n",
> > + drm_connector_enum_list[connector_type].name,
> > + ret);
> > goto out_put;
> > +   }
> > connector->index = ret;
> > ret = 0;
> >  
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index f0556e654116..5b4be382a1d7 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -282,6 +282,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> > struct drm_crtc *crtc,
> > WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
> > WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
> >  
> > +   /* crtc index is used with 32bit bitmasks */
> > +   if (WARN_ON(config->num_crtc >= 32))
> > +   return -EINVAL;
> > +
> > crtc->dev = dev;
> > crtc->funcs = funcs;
> >  
> > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > index 59e0ebe733f8..273e1c59c54a 100644
> > --- a/drivers/gpu/drm/drm_encoder.c
> > +++ b/drivers/gpu/drm/drm_encoder.c
> > @@ -110,6 +110,10 @@ int drm_encoder_init(struct drm_device *dev,
> >  {
> > int ret;
> >  
> > +   /* encoder index is used with 32bit bitmasks */
> > +   if (WARN_ON(dev->mode_config.num_encoder >= 32))
> > +   return -EINVAL;
> > +
> > ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
> > if (ret)
> > return ret;
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 2c90519576a3..22b54663b6e7 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -173,6 +173,10 @@ int drm_universal_plane_init(struct drm_device *dev, 
> > struct drm_plane *plane,
> > unsigned int format_modifier_count = 0;
> > int ret;
> >  
> > +   /* plane index is used with 32bit bitmasks */
> > +   if (WARN_ON(config->num_total_plane >= 32))
> > +   return -EINVAL;
> > +
> > ret = drm_mode_object_add(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
> > if (ret)
> > return ret;
> > 

-- 
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 15/15] drm/i915: Add NV12 support to intel_framebuffer_init

2018-01-29 Thread Maarten Lankhorst
Op 20-01-18 om 22:45 schreef Vidya Srinivas:
> From: Chandra Konduru 
>
> This patch adds NV12 as supported format
> to intel_framebuffer_init and performs various checks.
>
> v2:
> -Fix an issue in checks added (Chandra Konduru)
>
> v3: rebased (me)
>
> v4: Review comments by Ville addressed
> Added platform check for NV12 in intel_framebuffer_init
> Removed offset checks for NV12 case
>
> v5: Addressed review comments by Clinton A Taylor
> This NV12 support only correctly works on SKL.
> Plane color space conversion is different on GLK and later platforms
> causing the colors to display incorrectly.
> Ville's plane color space property patch series
> in review will fix this issue.
> - Restricted the NV12 case in intel_framebuffer_init to
> SKL and BXT only.
>
> v6: Rebased (me)
>
> v7: Addressed review comments by Ville
> Restricting the NV12 to BXT for now.
>
> v8: Rebased (me)
> Restricting the NV12 changes to BXT and KBL for now.
>
> v9: Rebased (me)
Hey,

Has NV12 been tested at all on skylake with rotation?

y_min_scanlines = 16 for 90°/270° rotation with cpp=1
skl_needs_memory_bw_wa() doubles the scanlines required,
which will trigger the following error quite easily when patching 
kms_rotation_crc to use NV12:

[   67.049190] [drm:skl_compute_wm_levels [i915]] Requested display 
configuration exceeds system watermark limitations
[   67.049212] [drm:skl_compute_wm_levels [i915]] [PLANE:28:plane 1A] blocks 
required = 161/572, lines required = 32/31

If we violate the spec for the workaround, by using 31 lines instead of 32 for 
90/270
rotation, the tests work but this needs to be solved first before we can move 
forward.

~Maarten

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


Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of HDMI LPE audio

2018-01-29 Thread Ville Syrjälä
On Wed, Dec 13, 2017 at 03:06:55PM +0100, Thomas Gleixner wrote:
> On Wed, 13 Dec 2017, Takashi Iwai wrote:
> > On Wed, 13 Dec 2017 12:35:54 +0100,
> > Thomas Gleixner wrote:
> > > 
> > > > > On Mon, 11 Dec 2017, Anand, Jerome wrote:
> > > > > > > On Fri, 8 Dec 2017, Ville Syrjälä wrote:
> > > > > > >
> > > > > > > > On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrote:
> > > > > > > > > The chip data of HDMI LPE audio is set to drm_i915_private 
> > > > > > > > > which
> > > > > > > > > is not consistent with the expectation by x86 APIC driver.
> > > > > > > >
> > > > > > > > Hmm. Why is the apic code looking at data for an irq chip it
> > > > > > > > hasn't created?
> > > > > > > >
> > > > > >
> > > > > > apic code expects an irq domain to be place as generic approach.
> > > > > 
> > > > > APIC code does not even see that interrupt at all. It's completely 
> > > > > disconnected.
> > > > > 
> > > > 
> > > > That's the problem - APIC just converts the chip data to its internal
> > > > format and fails.
> > > 
> > > How does APIC code end up to touch that interrupt at all? Call stack 
> > > please.
> > 
> > It's found in the bugzilla referred in the patch:
> >   https://bugs.freedesktop.org/show_bug.cgi?id=103731
> > 
> > [   87.353072] irq 298 idata->chip->name hdmi_lpe_audio_irqchip
> > [   87.353072] irq 298 apic_chip_data
> > [   87.353073] irq 298 data->domain is NULL
> > [   87.353120] BUG: unable to handle kernel NULL pointer dereference at 
> > (null)
> > [   87.353132] IP: setup_vector_irq+0x1ba/0x230
> > [   87.353133] PGD 0
> > 
> > If my understanding is correct, it happens only with 4.14 and earlier
> > kernels where __setup_vector_irq() loops over the all irqs:
> > 
> > static void __setup_vector_irq(int cpu)
> > {
> > struct apic_chip_data *data;
> > struct irq_desc *desc;
> > int irq, vector;
> > 
> > /* Mark the inuse vectors */
> > for_each_irq_desc(irq, desc) {
> > struct irq_data *idata = irq_desc_get_irq_data(desc);
> > 
> > data = apic_chip_data(idata);
> > if (!data || !cpumask_test_cpu(cpu, data->domain))
> > continue;
> > 
> > 
> > And since we have assigned a non-APIC chip data in the driver, the
> > code above refers to a wrong object, leading to Oops.
> 
> Bah crap. This information should have been provided earlier instead of
> handwavy 'doesnt work with CONFIG_FOO and hotplug'.
> 
> > As a further note, the setup_vector_irq() code has been changed in
> > 4.15, and such a reference won't happen any longer.  So the patch
> > isn't necessary for now, although it's not bad to take as a cleanup.
> > And we can eventually put Cc to stable there since it actually works
> > around the issue above for the older kernels -- of course, with more
> > detailed descriptions about the background.
> 
> No, that's just tinkering. The proper fix is to make that code robust.
> 
> Something like the completely untested patch below should do the trick.
> 
> Thanks,
> 
>   tglx
> ---
> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
> index f3557a1eb562..02e6a3cc0d74 100644
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -58,6 +58,9 @@ static struct apic_chip_data *apic_chip_data(struct 
> irq_data *irq_data)
>   while (irq_data->parent_data)
>   irq_data = irq_data->parent_data;
>  
> + if (irq_data->domain != x86_vector_domain)
> + return NULL;
> +
>   return irq_data->chip_data;
>  }
>  
> 

Did this patch resolve the issue?

-- 
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: expose RCS topology to userspace

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: expose RCS topology to userspace
URL   : https://patchwork.freedesktop.org/series/37290/
State : success

== Summary ==

Series 37290v1 drm/i915: expose RCS topology to userspace
https://patchwork.freedesktop.org/api/1.0/series/37290/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:491s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:415s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:455s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:500s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:515s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s
fi-skl-6700hq failed to collect. IGT log at Patchwork_7810/fi-skl-6700hq/igt.log

5f9f3637ad4677971149ec7cde9ed2081a90839b drm-tip: 2018y-01m-29d-13h-02m-54s UTC 
integration manifest
d02134e51838 RFC: drm/i915: reuse new chipset/driver query in getparam
c47cff0245e4 RFC: drm/i915: expose chipset/driver properties through query uAPI
a1892c017b5d drm/i915: expose rcs topology through query uAPI
9c5a93f46d27 drm/i915: add query uAPI
f42c533d3656 drm/i915: add rcs topology to error state
e050f06ebba9 drm/i915/debugfs: add rcs topology entry
c32afc436cbe drm/i915/debugfs: reuse max slice/subslices already stored in sseu
e0415f64bdd2 drm/i915: store all subslice masks

== Logs ==

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


Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks (rev3)

2018-01-29 Thread Ville Syrjälä
On Thu, Jan 25, 2018 at 03:17:21PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit 
> bitmasks (rev3)
> URL   : https://patchwork.freedesktop.org/series/37058/
> State : failure
> 
> == Summary ==
> 
> Test drv_suspend:
> Subgroup fence-restore-untiled-hibernate:
> fail   -> SKIP   (shard-snb) fdo#103375
> Test perf:
> Subgroup oa-exponents:
> pass   -> FAIL   (shard-apl) fdo#102254
> Test kms_flip:
> Subgroup plain-flip-ts-check-interruptible:
> pass   -> FAIL   (shard-hsw) fdo#100368 +1
> Subgroup 2x-flip-vs-modeset-interruptible:
> dmesg-warn -> PASS   (shard-hsw) fdo#102614
> Subgroup 2x-flip-vs-expired-vblank:
> pass   -> FAIL   (shard-hsw) fdo#102887
> Test kms_plane_lowres:
> Subgroup pipe-a-tiling-x:
> pass   -> FAIL   (shard-apl)

CRC mismatch of some sort:

(kms_plane_lowres:1487) igt-debugfs-CRITICAL: Test assertion failure function 
igt_assert_crc_equal, file igt_debugfs.c:356:
(kms_plane_lowres:1487) igt-debugfs-CRITICAL: Failed assertion:  !mismatch
(kms_plane_lowres:1487) igt-debugfs-CRITICAL: Last errno: 9, Bad file  
descriptor

> Test kms_cursor_legacy:
> Subgroup 2x-long-flip-vs-cursor-legacy:
> pass   -> FAIL   (shard-hsw)

Missed vbl seq:

(kms_cursor_legacy:10485) CRITICAL: Test assertion failure function 
two_screens_flip_vs_cursor, file kms_cursor_legacy.c:976:
(kms_cursor_legacy:10485) CRITICAL: Failed assertion: vbl.sequence == 
vblank_start + 1
(kms_cursor_legacy:10485) CRITICAL: Last errno: 25, Inappropriate ioctl
for device
(kms_cursor_legacy:10485) CRITICAL: error: 38169 != 38168

Both seem unrelated to the patch.

> Subgroup flip-vs-cursor-crc-atomic:
> fail   -> PASS   (shard-apl) fdo#102670
> 
> fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
> fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
> fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
> fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
> 
> shard-apltotal:2838 pass:1751 dwarn:1   dfail:0   fail:24  skip:1062 
> time:12644s
> shard-hswtotal:2838 pass:1732 dwarn:1   dfail:0   fail:14  skip:1090 
> time:11915s
> shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:9   skip:1498 
> time:6646s
> Blacklisted hosts:
> shard-kbltotal:2838 pass:1861 dwarn:13  dfail:1   fail:23  skip:940 
> time:9553s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7776/shards.html

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


[Intel-gfx] [PATCH v12 7/8] RFC: drm/i915: expose chipset/driver properties through query uAPI

2018-01-29 Thread Lionel Landwerlin
The purpose of this is to give the ability to userspace to query a
bunch of properties in 1 ioctl rather than a series of successive
GETPARAM ioctl().

This loosely divides the properties in 2 groups, one being hardware
focused and the other being rather driver features.

The structures defined in the uAPI can be extended only by adding new
fields. If userspace uses an old version of the structures, the kernel
will only copy data up to the size requested by userspace. In the case
userspace has an newer version of the struct than what the kernel can
provide, any field tag with a more recent version than what returned
by the kernel should be ignored.

This change leaves out some of the GETPARAMs :

  - EU/slice/subslice: those are already covered by topology structs
  - engines queries: those might be addressed in another patch/series
  - some deprecated fields which always return ENODEV

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_query.c | 135 ++
 drivers/gpu/drm/i915/i915_query.h |   5 ++
 include/uapi/drm/i915_drm.h   |  76 +
 3 files changed, 216 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index ff87ec8a321a..3770a0e49dad 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -132,11 +132,146 @@ static int query_eu_info(struct drm_i915_private 
*dev_priv,
   sseu->eu_mask, data_length);
 }
 
+void i915_query_fill_chipset_info(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_chipset_info 
*chipset_info)
+{
+   struct pci_dev *pdev = dev_priv->drm.pdev;
+
+   memset(chipset_info, 0, sizeof(*chipset_info));
+   chipset_info->version = 1;
+
+   chipset_info->chipset_id = pdev->device;
+   chipset_info->chipset_revision = pdev->revision;
+   chipset_info->num_fences_available = dev_priv->num_fence_regs;
+   chipset_info->cs_timestamp_frequency =
+   1000ULL * INTEL_INFO(dev_priv)->cs_timestamp_frequency_khz;
+   chipset_info->has_llc = HAS_LLC(dev_priv);
+   chipset_info->has_overlay = dev_priv->overlay ? 1 : 0;
+   chipset_info->has_semaphores = HAS_LEGACY_SEMAPHORES(dev_priv);
+   chipset_info->has_writethrough = HAS_WT(dev_priv);
+}
+
+static int query_chipset_info(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+   struct drm_i915_query_chipset_info chipset_info;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (query_item->length == 0) {
+   query_item->length = sizeof(chipset_info);
+   return 0;
+   }
+
+   i915_query_fill_chipset_info(dev_priv, &chipset_info);
+
+   /*
+* Only copy request user size as it depends upon the version of the
+* struct used by userspace.
+*/
+   if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+&chipset_info, query_item->length))
+   return -EFAULT;
+
+   return 0;
+}
+
+void i915_query_fill_driver_info(struct drm_i915_private *dev_priv,
+struct drm_i915_query_driver_info *driver_info)
+{
+   memset(driver_info, 0, sizeof(*driver_info));
+   driver_info->version = 1;
+
+   /* Remember to bump this if the version changes! */
+   driver_info->mmap_version = 1;
+
+   /* For the time being all of these are always true;
+* if some supported hardware does not have one of these
+* features this value needs to be provided from
+* INTEL_INFO(), a feature macro, or similar.
+*/
+   driver_info->has_coherent_phys_gtt = 1;
+   driver_info->has_coherent_rings = 1;
+   driver_info->has_exec_async = 1;
+   driver_info->has_exec_batch_first = 1;
+   driver_info->has_exec_capture = 1;
+   driver_info->has_exec_fence = 1;
+   driver_info->has_exec_fence_array = 1;
+   driver_info->has_exec_handle_lut = 1;
+   driver_info->has_exec_no_reloc = 1;
+   driver_info->has_exec_softpin = 1;
+   driver_info->has_execbuf2 = 1;
+   driver_info->has_gem = 1;
+   driver_info->has_gen7_sol_reset = 1;
+   driver_info->has_pageflipping = 1;
+   driver_info->has_pinned_batches = 1;
+   driver_info->has_prime_vmap_flush = 1;
+   driver_info->has_relaxed_delta = 1;
+   driver_info->has_relaxed_fencing = 1;
+   driver_info->has_wait_timeout = 1;
+
+   driver_info->has_aliasing_ppgtt = USES_PPGTT(dev_priv);
+
+   driver_info->has_context_isolation =
+   intel_engines_has_context_isolation(dev_priv);
+
+   driver_info->has_gpu_reset = i915_modparams.enable_hangcheck &&
+   intel_has_gpu_reset(dev_priv);
+   if (driver_info->has_gpu_reset && intel_has_reset_engine(dev_priv))
+   driver_info->has_gpu_reset = 2

[Intel-gfx] [PATCH v12 6/8] drm/i915: expose rcs topology through query uAPI

2018-01-29 Thread Lionel Landwerlin
With the introduction of asymmetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because counters need to be normalized to the number of
EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
not gives us sufficient information.

As a bonus we can draw representations of the GPU :

https://imgur.com/a/vuqpa

v2: Rename uapi struct s/_mask/_info/ (Tvrtko)
Report max_slice/subslice/eus_per_subslice rather than strides (Tvrtko)
Add uapi macros to read data from *_info structs (Tvrtko)

v3: Use !!(v & DRM_I915_BIT()) for uapi macros instead of custom shifts (Tvrtko)

v4: factorize query item writting (Tvrtko)
tweak uapi struct/define names (Tvrtko)

v5: Replace ALIGN() macro (Chris)

v6: Updated uapi comments (Tvrtko)
Moved flags != 0 checks into vfuncs (Tvrtko)

v7: Use access_ok() before copying anything, to avoid overflows (Chris)
Switch BUG_ON() to GEM_WARN_ON() (Tvrtko)

v8: Tweak uapi comments style to match the coding style (Lionel)

v9: Fix error in comment about computation of enabled subslice (Tvrtko)

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_query.c | 110 ++
 include/uapi/drm/i915_drm.h   |  71 
 2 files changed, 181 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 5aa886313cf9..ff87ec8a321a 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -25,8 +25,118 @@
 #include "i915_drv.h"
 #include 
 
+static int copy_query_data(struct drm_i915_query_item *query_item,
+  const void *item_ptr, u32 item_length,
+  const void *data_ptr, u32 data_length)
+{
+   u32 total_length = item_length + data_length;
+
+   if (GEM_WARN_ON(add_overflows(item_length, data_length)))
+   return -EINVAL;
+
+   if (query_item->length == 0)
+   return total_length;
+
+   if (query_item->length < total_length)
+   return -EINVAL;
+
+   if (!access_ok(VERIFY_WRITE, u64_to_user_ptr(query_item->data_ptr),
+  total_length))
+   return -EFAULT;
+
+   if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+  item_ptr, item_length))
+   return -EFAULT;
+
+   if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr + item_length),
+  data_ptr, data_length))
+   return -EFAULT;
+
+   return total_length;
+}
+
+static int query_slice_info(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu;
+   struct drm_i915_query_slice_info slice_info;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   /*
+* If we ever change the internal slice mask data type, we'll need to
+* update this function.
+*/
+   BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
+
+   memset(&slice_info, 0, sizeof(slice_info));
+   slice_info.max_slices = sseu->max_slices;
+
+   return copy_query_data(query_item, &slice_info, sizeof(slice_info),
+  &sseu->slice_mask, sizeof(sseu->slice_mask));
+}
+
+static int query_subslice_info(struct drm_i915_private *dev_priv,
+  struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu;
+   struct drm_i915_query_subslice_info subslice_info;
+   u32 data_length;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   memset(&subslice_info, 0, sizeof(subslice_info));
+   subslice_info.max_slices = sseu->max_slices;
+   subslice_info.max_subslices = sseu->max_subslices;
+
+   data_length = subslice_info.max_slices *
+   DIV_ROUND_UP(subslice_info.max_subslices,
+sizeof(sseu->subslice_mask[0]) * BITS_PER_BYTE);
+
+   return copy_query_data(query_item,
+  &subslice_info, sizeof(subslice_info),
+  sseu->subslice_mask, data_length);
+}
+
+static int query_eu_info(struct drm_i915_private *dev_priv,
+struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu;
+   struct drm_i915_query_eu_info eu_info;
+   u32 data_length;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   

[Intel-gfx] [PATCH v12 3/8] drm/i915/debugfs: add rcs topology entry

2018-01-29 Thread Lionel Landwerlin
While the end goal is to make this information available to userspace
through a new ioctl, there is no reason we can't display it in a human
readable fashion through debugfs.

slice0: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)
slice1: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)
slice2: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)

v2: Reformat debugfs printing (Tvrtko)
Use the new EU mask helper (Tvrtko)

v3: Move printing code to intel_device_info.c to be shared with error
state (Michal)

Suggested-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 11 +++
 drivers/gpu/drm/i915/intel_device_info.c | 25 +
 drivers/gpu/drm/i915/intel_device_info.h |  2 ++
 3 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ca8c90f20bb7..dd6be4b3c5b8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3154,6 +3154,16 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static int i915_rcs_topology(struct seq_file *m, void *unused)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct drm_printer p = drm_seq_file_printer(m);
+
+   intel_device_info_dump_topology(&INTEL_INFO(dev_priv)->sseu, &p);
+
+   return 0;
+}
+
 static int i915_shrinker_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *i915 = node_to_i915(m->private);
@@ -4684,6 +4694,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_dmc_info", i915_dmc_info, 0},
{"i915_display_info", i915_display_info, 0},
{"i915_engine_info", i915_engine_info, 0},
+   {"i915_rcs_topology", i915_rcs_topology, 0},
{"i915_shrinker_info", i915_shrinker_info, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
{"i915_dp_mst_info", i915_dp_mst_info, 0},
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 80cf72069bae..04d00b73523b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -124,6 +124,31 @@ void intel_device_info_dump(const struct intel_device_info 
*info,
intel_device_info_dump_flags(info, p);
 }
 
+void intel_device_info_dump_topology(const struct sseu_dev_info *sseu,
+struct drm_printer *p)
+{
+   int s, ss;
+
+   if (sseu->max_slices == 0) {
+   drm_printf(p, "Unavailable\n");
+   return;
+   }
+
+   for (s = 0; s < sseu->max_slices; s++) {
+   drm_printf(p, "slice%d: %u subslice(s) (0x%hhx):\n",
+  s, hweight8(sseu->subslice_mask[s]),
+  sseu->subslice_mask[s]);
+
+   for (ss = 0; ss < sseu->max_subslices; ss++) {
+   u8 enabled_eus = sseu_get_eus(sseu, s, ss);
+
+   drm_printf(p, "\tsubslice%d: %u EUs (0x%hhx)\n",
+  ss, hweight8(enabled_eus), enabled_eus);
+   }
+   }
+}
+
+
 static u16 compute_eu_total(const struct sseu_dev_info *sseu)
 {
u16 i, total = 0;
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 213db0ca6252..5086adf85824 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -222,5 +222,7 @@ void intel_device_info_dump_flags(const struct 
intel_device_info *info,
  struct drm_printer *p);
 void intel_device_info_dump_runtime(const struct intel_device_info *info,
struct drm_printer *p);
+void intel_device_info_dump_topology(const struct sseu_dev_info *sseu,
+struct drm_printer *p);
 
 #endif
-- 
2.15.1

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


[Intel-gfx] [PATCH v12 4/8] drm/i915: add rcs topology to error state

2018-01-29 Thread Lionel Landwerlin
This might be useful information for developers looking at an error
state.

v2: Place topology towards the end of the error state (Chris)

v3: Reuse common printing code (Michal)

v4: Make this a one-liner (Chris)

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

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a81351d9e3a6..499a346923ec 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -578,6 +578,7 @@ static void err_print_capabilities(struct 
drm_i915_error_state_buf *m,
struct drm_printer p = i915_error_printer(m);
 
intel_device_info_dump_flags(info, &p);
+   intel_device_info_dump_topology(&info->sseu, &p);
 }
 
 static void err_print_params(struct drm_i915_error_state_buf *m,
-- 
2.15.1

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


[Intel-gfx] [PATCH v12 1/8] drm/i915: store all subslice masks

2018-01-29 Thread Lionel Landwerlin
Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymmetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

v2: Rework how we store total numbers in sseu_dev_info (Tvrtko)
Fix CHV eu masks, was reading disabled as enabled (Tvrtko)
Readability changes (Tvrtko)
Add EU index helper (Tvrtko)

v3: Turn ALIGN(v, 8) / 8 into DIV_ROUND_UP(v, BITS_PER_BYTE) (Tvrtko)
Reuse sseu_eu_idx() for setting eu_mask on CHV (Tvrtko)
Reformat debug prints for subslices (Tvrtko)

v4: Change eu_mask helper into sseu_set_eus() (Tvrtko)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  25 ++--
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.c | 201 +++
 drivers/gpu/drm/i915/intel_device_info.h |  47 +++-
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 6 files changed, 216 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3849ded354e3..8776e028449d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4277,7 +4277,7 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask = BIT(0);
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[0] |= BIT(ss);
eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4324,7 +4324,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask |= BIT(s);
-   sseu->subslice_mask = info->sseu.subslice_mask;
+   sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4379,8 +4379,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
 
if (IS_GEN9_BC(dev_priv))
-   sseu->subslice_mask =
-   INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4390,7 +4390,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
/* skip disabled subslice */
continue;
 
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[s] |= BIT(ss);
}
 
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4412,9 +4412,12 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
 
if (sseu->slice_mask) {
-   sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
sseu->eu_per_subslice =
INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
+   }
sseu->eu_total = sseu->eu_per_subslice *
 sseu_subslice_total(sseu);
 
@@ -4433,6 +4436,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const char *type = is_available_info ? "Available" : "Enabled";
+   int s;
 
seq_printf(m, "  %s Slice Mask: %04x\n", type,
   sseu->slice_mask);
@@ -4440,10 +,11 @@ static void i915_print_sseu_info(struct seq_file *m, 
bool is_available_info,
   hweight8(sseu->slice_mask));
seq_printf(m, "  %s Subslice Total: %u\n", type,
   sseu_subslice_total(sseu));
-   seq_printf(m, "  %s Subslice Mask: %04x\n", type,
-  sseu->subslice_mask);
-   seq_printf(m, "  %s Subslice Per Slice: %u\n", type,
-  hweight8(sseu->subslice_mask));
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   seq_printf(m, "  %s Slice%i %u subslices, mask=%04x\n", type,
+  s, hweight8(sseu->subslice_mask[s]

[Intel-gfx] [PATCH v12 5/8] drm/i915: add query uAPI

2018-01-29 Thread Lionel Landwerlin
There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices and also which ones
have been fused off for die recovery).

At the moment the GET_PARAM ioctl covers some basic needs, but
generally is only able to return a single value for each defined
parameter. This is a bit problematic with topology descriptions which
are array/maps of available units.

This change introduces a new ioctl that can deal with requests to fill
structures of potentially variable lengths. The user is expected fill
a query with length fields set at 0 on the first call, the kernel then
sets the length fields to the their expected values. A second call to
the kernel with length fields at their expected values will trigger a
copy of the data to the pointed memory locations.

The scope of this uAPI is only to provide information to userspace,
not to allow configuration of the device.

v2: Simplify dispatcher code iteration (Tvrtko)
Tweak uapi drm_i915_query_item structure (Tvrtko)

v3: Rename pad fields into flags (Chris)
Return error on flags field != 0 (Chris)
Only copy length back to userspace in drm_i915_query_item (Chris)

v4: Use array of functions instead of switch (Chris)

v5: More comments in uapi (Tvrtko)
Return query item errors in length field (All)

v6: Tweak uapi comments style to match the coding style (Lionel)

v7: Add i915_query.h (Joonas)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Makefile |  1 +
 drivers/gpu/drm/i915/i915_drv.c   |  2 ++
 drivers/gpu/drm/i915/i915_query.c | 67 +++
 drivers/gpu/drm/i915/i915_query.h | 33 +++
 include/uapi/drm/i915_drm.h   | 41 
 5 files changed, 144 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_query.c
 create mode 100644 drivers/gpu/drm/i915/i915_query.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a06806..b0415a3e2d59 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
+ i915_query.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 902c5304ef12..ebb2e4241cf7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -49,6 +49,7 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "i915_pmu.h"
+#include "i915_query.h"
 #include "i915_vgpu.h"
 #include "intel_drv.h"
 #include "intel_uc.h"
@@ -2835,6 +2836,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
new file mode 100644
index ..5aa886313cf9
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -0,0 +1,67 @@
+/*
+ * 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.
+ *
+ */
+
+#include "i915_drv.h"
+#include 
+
+static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item) 
= {
+};
+
+int i915_query

[Intel-gfx] [PATCH v12 2/8] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

2018-01-29 Thread Lionel Landwerlin
Now that we have that information in topology fields, let's just reused it.

v2: Style tweaks (Tvrtko)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8776e028449d..ca8c90f20bb7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4292,11 +4292,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 struct sseu_dev_info *sseu)
 {
const struct intel_device_info *info = INTEL_INFO(dev_priv);
-   int s_max = 6, ss_max = 4;
int s, ss;
-   u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
/*
 * FIXME: Valid SS Mask respects the spec and read
 * only valid bits for those registers, excluding reserverd
@@ -4318,7 +4318,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4326,7 +4326,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4346,17 +4346,12 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
-   int s_max = 3, ss_max = 4;
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
int s, ss;
-   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-   /* BXT has a single slice and at most 3 subslices. */
-   if (IS_GEN9_LP(dev_priv)) {
-   s_max = 1;
-   ss_max = 3;
-   }
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4371,7 +4366,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4382,7 +4377,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->subslice_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (IS_GEN9_LP(dev_priv)) {
-- 
2.15.1

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


[Intel-gfx] [PATCH v12 8/8] RFC: drm/i915: reuse new chipset/driver query in getparam

2018-01-29 Thread Lionel Landwerlin
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.c | 212 ++--
 1 file changed, 119 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ebb2e4241cf7..cc0342e8a400 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -278,11 +278,123 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
pci_dev_put(pch);
 }
 
+static int read_unsigned_struct_field(void *data, uint32_t offset, uint32_t 
size)
+{
+   switch (size) {
+   case 1:
+   return *(uint8_t *)(data + offset);
+   case 2:
+   return *(uint16_t *)(data + offset);
+   case 4:
+   return *(uint32_t *)(data + offset);
+   case 8:
+   return *(uint64_t *)(data + offset);
+   }
+
+   GEM_BUG_ON(true);
+   return 0;
+}
+
+static const struct {
+   uint32_t param;
+   uint32_t offset;
+   uint8_t size;
+} i915_param_chipset_mapping[] = {
+#define MEMBER_OFFSET_SIZE(param, member) \
+   { param, \
+ offsetof(struct drm_i915_query_chipset_info, member), \
+ sizeof(((struct drm_i915_query_chipset_info *)0)->member), }
+   MEMBER_OFFSET_SIZE(I915_PARAM_CHIPSET_ID,   chipset_id),
+   MEMBER_OFFSET_SIZE(I915_PARAM_REVISION, 
chipset_revision),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_LLC,  has_llc),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_WT,   
has_writethrough),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_SEMAPHORES,   has_semaphores),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_OVERLAY,  has_overlay),
+   MEMBER_OFFSET_SIZE(I915_PARAM_NUM_FENCES_AVAIL, 
num_fences_available),
+   MEMBER_OFFSET_SIZE(I915_PARAM_CS_TIMESTAMP_FREQUENCY,   
cs_timestamp_frequency),
+#undef MEMBER_OFFSET_SIZE
+};
+static bool i915_getparam_chipset(struct drm_i915_private *dev_priv,
+ s32 param, int *value)
+{
+   struct drm_i915_query_chipset_info chipset_info;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(i915_param_chipset_mapping); i++) {
+   if (i915_param_chipset_mapping[i].param == param) {
+   i915_query_fill_chipset_info(dev_priv, &chipset_info);
+   *value = read_unsigned_struct_field(&chipset_info,
+   
i915_param_chipset_mapping[i].offset,
+   
i915_param_chipset_mapping[i].size);
+   return true;
+   }
+   }
+
+   return false;
+}
+
+static const struct {
+   uint32_t param;
+   uint32_t offset;
+   uint8_t size;
+} i915_param_driver_mapping[] = {
+#define MEMBER_OFFSET_SIZE(param, member) \
+   { param, \
+ offsetof(struct drm_i915_query_driver_info, member), \
+ sizeof(((struct drm_i915_query_driver_info *)0)->member), }
+   MEMBER_OFFSET_SIZE(I915_PARAM_CMD_PARSER_VERSION,   
cmd_parser_version),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_ALIASING_PPGTT,   
has_aliasing_ppgtt),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_CONTEXT_ISOLATION,
has_context_isolation),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_COHERENT_PHYS_GTT,
has_coherent_phys_gtt),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_COHERENT_RINGS,   
has_coherent_rings),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_GEM,  has_gem),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_GEN7_SOL_RESET,   
has_gen7_sol_reset),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_GPU_RESET,has_gpu_reset),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_PAGEFLIPPING, 
has_pageflipping),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_EXEC_ASYNC,   has_exec_async),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_EXEC_BATCH_FIRST, 
has_exec_batch_first),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_EXEC_CAPTURE, 
has_exec_capture),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_EXEC_NO_RELOC,
has_exec_no_reloc),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_EXEC_FENCE,   has_exec_fence),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_EXEC_FENCE_ARRAY, 
has_exec_fence_array),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_EXEC_HANDLE_LUT,  
has_exec_handle_lut),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_EXEC_SOFTPIN, 
has_exec_softpin),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_PINNED_BATCHES,   
has_pinned_batches),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_PRIME_VMAP_FLUSH, 
has_prime_vmap_flush),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_RELAXED_DELTA,
has_relaxed_delta),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_RELAXED_FENCING,  
has_relaxed_fencing),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_RESOURCE_STREAMER,
has_resource_streamer),
+   MEMBER_OFFSET_SIZE(I915_PARAM_HAS_SCHEDULER,

[Intel-gfx] [PATCH v12 0/8] drm/i915: expose RCS topology to userspace

2018-01-29 Thread Lionel Landwerlin
Hi,

There is almost no changes from the previous series. I just put the
i915_query_ioctl() declaration in its own header file (like Joonas
suggested, if I remember correctly).

Adding a couple of patches for discussion on how to have a userspace
query all of the information it needs from the device in one ioctl
(Chris' suggestion).

Would be great to land !RFC if people are okay with it.

Cheers,

Lionel Landwerlin (8):
  drm/i915: store all subslice masks
  drm/i915/debugfs: reuse max slice/subslices already stored in sseu
  drm/i915/debugfs: add rcs topology entry
  drm/i915: add rcs topology to error state
  drm/i915: add query uAPI
  drm/i915: expose rcs topology through query uAPI
  RFC: drm/i915: expose chipset/driver properties through query uAPI
  RFC: drm/i915: reuse new chipset/driver query in getparam

 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_debugfs.c  |  63 ---
 drivers/gpu/drm/i915/i915_drv.c  | 216 +++--
 drivers/gpu/drm/i915/i915_gpu_error.c|   1 +
 drivers/gpu/drm/i915/i915_query.c| 312 +++
 drivers/gpu/drm/i915/i915_query.h|  38 
 drivers/gpu/drm/i915/intel_device_info.c | 226 +-
 drivers/gpu/drm/i915/intel_device_info.h |  49 -
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 include/uapi/drm/i915_drm.h  | 188 +++
 11 files changed, 926 insertions(+), 172 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_query.c
 create mode 100644 drivers/gpu/drm/i915/i915_query.h

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


[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Simplify guard logic for setup_scratch_page()

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: Simplify guard logic for setup_scratch_page()
URL   : https://patchwork.freedesktop.org/series/37265/
State : warning

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
skip   -> PASS   (shard-snb) fdo#101623 +2
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-render-untiled:
pass   -> SKIP   (shard-snb)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> SKIP   (shard-snb) fdo#103880
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
skip   -> PASS   (shard-snb) fdo#102365
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Test gem_eio:
Subgroup in-flight:
dmesg-warn -> PASS   (shard-snb) fdo#104058
Test syncobj_wait:
Subgroup wait-any-snapshot:
fail   -> PASS   (shard-apl)

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058

shard-apltotal:2838 pass:1751 dwarn:1   dfail:0   fail:22  skip:1064 
time:12639s
shard-hswtotal:2838 pass:1736 dwarn:1   dfail:0   fail:10  skip:1090 
time:12058s
shard-snbtotal:2838 pass:1328 dwarn:1   dfail:0   fail:10  skip:1499 
time:6693s
Blacklisted hosts:
shard-kbltotal:2838 pass:1870 dwarn:4   dfail:0   fail:22  skip:942 
time:9622s

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Assert the engine has finished the seqno on unsubmission

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: Assert the engine has finished the seqno on unsubmission
URL   : https://patchwork.freedesktop.org/series/37263/
State : failure

== Summary ==

Test syncobj_wait:
Subgroup wait-any-snapshot:
fail   -> PASS   (shard-apl)
Test perf_pmu:
Subgroup frequency:
fail   -> PASS   (shard-apl) fdo#104829
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (shard-hsw) fdo#103375
Test kms_plane_lowres:
Subgroup pipe-a-tiling-yf:
pass   -> FAIL   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
dmesg-fail -> PASS   (shard-apl) fdo#101623 +2
Test gem_eio:
Subgroup in-flight:
dmesg-warn -> PASS   (shard-snb) fdo#104058
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
skip   -> PASS   (shard-snb) fdo#102365
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup 2x-dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw)

fdo#104829 https://bugs.freedesktop.org/show_bug.cgi?id=104829
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-apltotal:2838 pass:1749 dwarn:1   dfail:0   fail:23  skip:1064 
time:12699s
shard-hswtotal:2838 pass:1733 dwarn:1   dfail:0   fail:12  skip:1091 
time:11982s
shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:10  skip:1497 
time:6668s
Blacklisted hosts:
shard-kbltotal:2820 pass:1858 dwarn:1   dfail:0   fail:21  skip:939 
time:9395s

== Logs ==

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


Re: [Intel-gfx] [PATCH v11 5/6] drm/i915: add query uAPI

2018-01-29 Thread Lionel Landwerlin

On 24/01/18 15:14, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-24 12:03:46)

On 23/01/2018 14:17, Lionel Landwerlin wrote:

Hi all,

I've been trying to expose some information to userspace about the fused
parts of the GPU.
This is the 4th attempt at getting this upstream, here are the previous
ones :
  https://patchwork.freedesktop.org/patch/185959/
  https://patchwork.freedesktop.org/series/33436/
  https://patchwork.freedesktop.org/series/33950/

This last iteration was based upon some direction by Daniel :
https://lists.freedesktop.org/archives/dri-devel/2017-December/160162.html
There was, I think, a fair point about having this working in
environments where sysfs (mechanism used in the 3rd iteration) is not
available (containers).

Following some discussion on IRC, it seems Joonas would like this
rewritten in a such way that we essentially drop the generic mechanism
introduced in this patch, and instead go for an additional ioctl() on
the drm fd just for querying the state of a fused part of
slice/subslice/eus.
The proposal is to have a single struct like :

struct drm_i915_topology {
     /* All field are in/out */
     int slice;
     int subslice;
     int eu;

     int enabled;
};

You would let the slice field to -1 and then the kernel would fill it
with the max slice value. Same for subslice (with a valid slice value)
and eu.
When querying with slice = 0, and all other fields to -1, the kernel
would fill the enabled value with 0 or 1.
Essentially that would mean that an application wanting to query the
state of all of the EUs would have to go through them one by one (which
would be about ~100 ioctl() on SKL GT4 for example).

Apart from the fact that we'll probably end up adding another ioctl()
for engine discovery, I don't have any problem with what Joonas is
proposing.
It's just a bit annoying this comes up on the 4th rewrite.
I really wouldn't like to rewrite this one more time and get turned down
because this isn't to the taste of one of the reviewer.
So my question is : Is everybody happy with what Joonas is proposing?
Anybody in favor of having a generic mechanism?

I am not very keen on this counter-proposal for two reasons.

First is that I think is a bit inelegant to have to query so many times
just to get the full topology out. If this ends in some library, we may
end up running this on every trivial client startup.

Secondly, it is kind of dispatcher in it's own right. Since the
operation mode will depend on the combination of field values. As such a
generic, or at least a more explicit, dispatcher, like the proposed
i915_query_ioctl sounds cleaner to me.

I take the point we can't guess how many other users we will have for it
in the future. So there is a little bit of a risk of adding something
generic which won't be used a lot in the future.

Because apart from the three queries Lionel needs, I would be adding an
engine info query and potentially, depending on userspace interest,
engine queue depths. So that would be a maximum of five queries I am
aware of would use the generic framework. Maybe too little, or maybe
good enough for a start?

Another use case would be a single shot method to gather all GETPARAMs.

There's a lot of too'ing and fro'ing at the start of mesa trying to
determine all of the kernel's capabilities, which more or less come down
to a long series of parsing GETPARAM results. Bundling all of those up
into a single ioctl seems attractive to me (bonus for it being properly
defined and not a compat nightmare).
-Chris


Thanks all,

I don't really read much opposition to the current patch series. If 
anything we could actually want to do more it seems.

It would be good to have the green light and land that.
I've played quickly with a Chris' idea and will add a couple of RFC 
patches for discussion.


Cheers,

-
Lionel

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


Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

2018-01-29 Thread Leo Li

Updated IGT results seem sane:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html

Would someone be able to apply this patch?

Thanks,
Leo

On 2018-01-17 03:18 PM, Sean Paul wrote:

On Wed, Jan 17, 2018 at 10:39 AM, Maarten Lankhorst
 wrote:

Op 17-01-18 om 19:29 schreef Sean Paul:

On Wed, Jan 17, 2018 at 12:51:08PM +0100, Maarten Lankhorst wrote:

From: "Leo (Sunpeng) Li" 

During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).

Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.

Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.

Changes since v1:
- Also check for state->event->base.completion being set, to
   handle the case where stall_checks() fails in setup_crtc_commit().
Changes since v2:
- Add a flag to drm_crtc_commit, to prevent dereferencing a freed event.
   i915 may unreference the state in a worker.

Fixes: 24835e442f28 ("drm: reference count event->completion")
Cc:  # v4.11+
Signed-off-by: Leo (Sunpeng) Li 
Acked-by: Harry Wentland  #v1
Signed-off-by: Maarten Lankhorst 
---
  drivers/gpu/drm/drm_atomic_helper.c | 15 +++
  include/drm/drm_atomic.h|  9 +
  2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ab4032167094..ae3cbfe9e01c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1878,6 +1878,8 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,
  new_crtc_state->event->base.completion = &commit->flip_done;
  new_crtc_state->event->base.completion_release = 
release_crtc_commit;
  drm_crtc_commit_get(commit);
+
+commit->abort_completion = true;
  }

  for_each_oldnew_connector_in_state(state, conn, old_conn_state, 
new_conn_state, i) {
@@ -3421,8 +3423,21 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
  void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
  {
  if (state->commit) {
+/*
+ * In the event that a non-blocking commit returns
+ * -ERESTARTSYS before the commit_tail work is queued, we will
+ * have an extra reference to the commit object. Release it, if
+ * the event has not been consumed by the worker.
+ *
+ * state->event may be freed, so we can't directly look at
+ * state->event->base.completion.
+ */
+if (state->event && state->commit->abort_completion)
+drm_crtc_commit_put(state->commit);
+
  kfree(state->commit->event);
  state->commit->event = NULL;
+
  drm_crtc_commit_put(state->commit);
  }

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 1c27526c499e..cf13842a6dbd 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -134,6 +134,15 @@ struct drm_crtc_commit {
   * &drm_pending_vblank_event pointer to clean up private events.
   */
  struct drm_pending_vblank_event *event;
+
+/**
+ * @abort_completion:
+ *
+ * A flag that's set after drm_atomic_helper_setup_commit takes a second
+ * reference for the completion of $drm_crtc_state.event. It's used by
+ * the free code to remove the second reference if commit fails.
+ */

Perhaps it's just me, or I'm oversimplifying the problem. I think this would
be easier to understand if we just dropped the additional reference at the point
of failure (ie: in swap_state). That way we don't have to add Yet Another Piece
Of State.


That's assuming nothing can fail between setup_commit() and swap_state() and
also that the driver implementing atomci puts no calls in between. And also
assumes that even setup_commit has proper rollback. I think it's overkill,
and we have no choice but to do it like this. :(



yeah, fair enough.

Reviewed-by: Sean Paul 


~Maarten


___
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 [1/2] drm/i915: Free memdup-ed bios data structures on driver_unload

2018-01-29 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Free memdup-ed bios data 
structures on driver_unload
URL   : https://patchwork.freedesktop.org/series/37282/
State : success

== Summary ==

Series 37282v1 series starting with [1/2] drm/i915: Free memdup-ed bios data 
structures on driver_unload
https://patchwork.freedesktop.org/api/1.0/series/37282/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:462s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:281s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:389s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:462s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:494s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:575s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:490s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:527s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:474s

5f9f3637ad4677971149ec7cde9ed2081a90839b drm-tip: 2018y-01m-29d-13h-02m-54s UTC 
integration manifest
283ef4a64178 drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT 
sequence v3
efb87dbaa7e4 drm/i915: Free memdup-ed bios data structures on driver_unload

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Always run hangcheck while the GPU is busy

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: Always run hangcheck while the GPU is busy
URL   : https://patchwork.freedesktop.org/series/37281/
State : success

== Summary ==

Series 37281v1 drm/i915: Always run hangcheck while the GPU is busy
https://patchwork.freedesktop.org/api/1.0/series/37281/revisions/1/mbox/

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:475s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:394s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:502s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:436s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:520s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
Blacklisted hosts:
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:527s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s
fi-gdg-551 failed to collect. IGT log at Patchwork_7808/fi-gdg-551/igt.log

5f9f3637ad4677971149ec7cde9ed2081a90839b drm-tip: 2018y-01m-29d-13h-02m-54s UTC 
integration manifest
589aaf248006 drm/i915: Always run hangcheck while the GPU is busy

== Logs ==

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


[Intel-gfx] [PATCH 2/2] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v3

2018-01-29 Thread Hans de Goede
So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
index = 3, one of which has been kindly provided to me by Jan Brummer,
where not working with the i915 driver, giving a black screen on the
first modeset.

The problem with at least these Dells is that their VBT defines a MIPI
ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
reset in their INIT_OTP sequence, but the deassert must be done before
calling intel_dsi_device_ready(), so that is too late.

Simply doing the INIT_OTP sequence earlier is not enough to fix this,
because the INIT_OTP sequence also sends various MIPI packets to the
panel, which can only happen after calling intel_dsi_device_ready().

This commit fixes this by splitting the INIT_OTP sequence into everything
before the first DSI packet and everything else, including the first DSI
packet. The first part (everything before the first DSI packet) is then
used as deassert sequence.

Changed in v2:
-Split the init OTP sequence into a deassert reset and the actual init
 OTP sequence, instead of calling it earlier and then having the first
 mipi_exec_send_packet() call call intel_dsi_device_ready().

Changes in v3:
-Move the whole shebang to intel_bios.c

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=82880
Related: https://bugs.freedesktop.org/show_bug.cgi?id=101205
Cc: Jan-Michael Brummer 
Reported-by: Jan-Michael Brummer 
Tested-by: Hans de Goede 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c | 83 +++
 2 files changed, 84 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 081190da0818..1f346266956b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1349,6 +1349,7 @@ struct intel_vbt_data {
u32 size;
u8 *data;
const u8 *sequence[MIPI_SEQ_MAX];
+   u8 *deassert_seq; /* Used by fixup_mipi_sequences() */
} dsi;
 
int crt_ddc_pin;
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 64a0d55df28e..cca620f8deb6 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -947,6 +947,86 @@ static int goto_next_sequence_v3(const u8 *data, int 
index, int total)
return 0;
 }
 
+/*
+ * Get len of pre-fixed deassert fragment from a v1 init OTP sequence,
+ * skip all delay + gpio operands and stop at the first DSI packet op.
+ */
+static int get_init_otp_deassert_fragment_len(struct drm_i915_private 
*dev_priv)
+{
+   const u8 *data = dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP];
+   int index, len;
+
+   if (WARN_ON(!data || dev_priv->vbt.dsi.seq_version != 1))
+   return 0;
+
+   /* index = 1 to skip sequence byte */
+   for (index = 1; data[index] != MIPI_SEQ_ELEM_END; index += len) {
+   switch (data[index]) {
+   case MIPI_SEQ_ELEM_SEND_PKT:
+   return index == 1 ? 0 : index;
+   case MIPI_SEQ_ELEM_DELAY:
+   len = 5; /* 1 byte for operand + uint32 */
+   break;
+   case MIPI_SEQ_ELEM_GPIO:
+   len = 3; /* 1 byte for op, 1 for gpio_nr, 1 for value */
+   break;
+   default:
+   return 0;
+   }
+   }
+
+   return 0;
+}
+
+/*
+ * Some v1 VBT MIPI sequences do the deassert in the init OTP sequence.
+ * The deassert must be done before calling intel_dsi_device_ready, so for
+ * these devices we split the init OTP sequence into a deassert sequence and
+ * the actual init OTP part.
+ */
+static void fixup_mipi_sequences(struct drm_i915_private *dev_priv)
+{
+   u8 *init_otp;
+   int len;
+
+   /* Limit this to VLV for now. */
+   if (!IS_VALLEYVIEW(dev_priv))
+   return;
+
+   /* Limit this to v1 vid-mode sequences */
+   if (dev_priv->vbt.dsi.config->is_cmd_mode ||
+   dev_priv->vbt.dsi.seq_version != 1)
+   return;
+
+   /* Only do this if there are otp and assert seqs and no deassert seq */
+   if (!dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP] ||
+   !dev_priv->vbt.dsi.sequence[MIPI_SEQ_ASSERT_RESET] ||
+   dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET])
+   return;
+
+   /* The deassert-sequence ends at the first DSI packet */
+   len = get_init_otp_deassert_fragment_len(dev_priv);
+   if (!len)
+   return;
+
+   DRM_DEBUG_KMS("Using init OTP fragment to deassert reset\n");
+
+   /* Copy the fragment, update seq byte and terminate it */
+   init_otp = (u8 *)dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP];
+   dev_priv->vbt.dsi.deassert_seq = kmemdup(init_otp, len + 1, GFP_KERNEL);
+   if (!dev_priv->vbt.dsi.deassert_seq)
+   return;
+   dev_priv

[Intel-gfx] [PATCH 1/2] drm/i915: Free memdup-ed bios data structures on driver_unload

2018-01-29 Thread Hans de Goede
Add a new intel_bios_cleanup function to free memdup-ed bios data
structures and call it from i915_driver_unload().

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/i915_drv.c   |  2 ++
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c | 11 +++
 3 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ec12add34b2..4ecf41724183 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1437,6 +1437,8 @@ void i915_driver_unload(struct drm_device *dev)
 
intel_modeset_cleanup(dev);
 
+   intel_bios_cleanup(dev_priv);
+
/*
 * free the memory space allocated for the child device
 * config parsed from VBT
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 454d8f937fae..081190da0818 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3663,6 +3663,7 @@ extern void intel_i2c_reset(struct drm_i915_private 
*dev_priv);
 
 /* intel_bios.c */
 void intel_bios_init(struct drm_i915_private *dev_priv);
+void intel_bios_cleanup(struct drm_i915_private *dev_priv);
 bool intel_bios_is_valid_vbt(const void *buf, size_t size);
 bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
 bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
*i2c_pin);
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 95f0b310d656..64a0d55df28e 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1588,6 +1588,17 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
pci_unmap_rom(pdev, bios);
 }
 
+/**
+ * intel_bios_cleanup - Free any resources allocated by intel_bios_init()
+ * @dev_priv: i915 device instance
+ */
+void intel_bios_cleanup(struct drm_i915_private *dev_priv)
+{
+   kfree(dev_priv->vbt.dsi.data);
+   kfree(dev_priv->vbt.dsi.pps);
+   kfree(dev_priv->vbt.dsi.config);
+}
+
 /**
  * intel_bios_is_tv_present - is integrated TV present in VBT
  * @dev_priv:  i915 device instance
-- 
2.14.3

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


[Intel-gfx] [PATCH] drm/i915: Always run hangcheck while the GPU is busy

2018-01-29 Thread Chris Wilson
Previously, we relied on only running the hangcheck while somebody was
waiting on the GPU, in order to minimise the amount of time hangcheck
had to run. (If nobody was watching the GPU, nobody would notice if the
GPU wasn't responding -- eventually somebody would care and so kick
hangcheck into action.) However, this falls apart from around commit
4680816be336 ("drm/i915: Wait first for submission, before waiting for
request completion"), as not all waiters declare themselves to hangcheck
and so we could switch off hangcheck and miss GPU hangs even when
waiting under the struct_mutex.

If we enable hangcheck from the first request submission, and let it run
until the GPU is idle again, we forgo all the complexity involved with
only enabling around waiters. Instead we have to be careful that we do
not declare a GPU hang when idly waiting for the next request to be come
ready.

Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for 
request completion"
Signed-off-by: Chris Wilson 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c  |  7 +++
 drivers/gpu/drm/i915/i915_gem_request.c  |  2 ++
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 11 ---
 drivers/gpu/drm/i915/intel_hangcheck.c   |  7 +--
 4 files changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 062b21408698..63308ec016a3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3322,16 +3322,15 @@ i915_gem_retire_work_handler(struct work_struct *work)
mutex_unlock(&dev->struct_mutex);
}
 
-   /* Keep the retire handler running until we are finally idle.
+   /*
+* Keep the retire handler running until we are finally idle.
 * We do not need to do this test under locking as in the worst-case
 * we queue the retire worker once too often.
 */
-   if (READ_ONCE(dev_priv->gt.awake)) {
-   i915_queue_hangcheck(dev_priv);
+   if (READ_ONCE(dev_priv->gt.awake))
queue_delayed_work(dev_priv->wq,
   &dev_priv->gt.retire_work,
   round_jiffies_up_relative(HZ));
-   }
 }
 
 static void shrink_caches(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 9b02310307fc..6cacd78cc849 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -393,6 +393,8 @@ static void mark_busy(struct drm_i915_private *i915)
 
intel_engines_unpark(i915);
 
+   i915_queue_hangcheck(i915);
+
queue_delayed_work(i915->wq,
   &i915->gt.retire_work,
   round_jiffies_up_relative(HZ));
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 86acac010bb8..62b2a20bc24e 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -149,17 +149,6 @@ static void intel_breadcrumbs_fake_irq(struct timer_list 
*t)
return;
 
mod_timer(&b->fake_irq, jiffies + 1);
-
-   /* Ensure that even if the GPU hangs, we get woken up.
-*
-* However, note that if no one is waiting, we never notice
-* a gpu hang. Eventually, we will have to wait for a resource
-* held by the GPU and so trigger a hangcheck. In the most
-* pathological case, this will be upon memory starvation! To
-* prevent this, we also queue the hangcheck from the retire
-* worker.
-*/
-   i915_queue_hangcheck(engine->i915);
 }
 
 static void irq_enable(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 31f01d64c021..348a4f7ffb67 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -411,7 +411,6 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
struct intel_engine_cs *engine;
enum intel_engine_id id;
unsigned int hung = 0, stuck = 0;
-   int busy_count = 0;
 
if (!i915_modparams.enable_hangcheck)
return;
@@ -429,7 +428,6 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
 
for_each_engine(engine, dev_priv, id) {
-   const bool busy = intel_engine_has_waiter(engine);
struct intel_engine_hangcheck hc;
 
semaphore_clear_deadlocks(dev_priv);
@@ -443,16 +441,13 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
if (hc.action != ENGINE_DEAD)
stuck |= intel_engine_flag(engine);
}
-
-   busy_count += busy;
}
 
if (hung)

[Intel-gfx] [PATCH igt] igt/prime_mmap_coherency: Close dmabuf after use

2018-01-29 Thread Chris Wilson
As we loop over the coherency tests many times, we need to close the
dmabufs opened on every pass to prevent a fd leak and the test
exploding when it hits the process limit.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103649
Signed-off-by: Chris Wilson 
---
 tests/prime_mmap_coherency.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
index 192b43489..04b15dddb 100644
--- a/tests/prime_mmap_coherency.c
+++ b/tests/prime_mmap_coherency.c
@@ -101,6 +101,8 @@ static int test_read_flush(void)
drm_intel_bo_unreference(bo_1);
munmap(ptr_cpu, width * height);
 
+   close(dma_buf_fd);
+
return stale;
 }
 
@@ -169,6 +171,9 @@ static int test_write_flush(void)
drm_intel_bo_unreference(bo_2);
munmap(ptr_cpu, width * height);
 
+   close(dma_buf2_fd);
+   close(dma_buf_fd);
+
return stale;
 }
 
-- 
2.15.1

___
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: Tracking waiters for execution wrt hangcheck

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: Tracking waiters for execution wrt hangcheck
URL   : https://patchwork.freedesktop.org/series/37276/
State : success

== Summary ==

Series 37276v1 drm/i915: Tracking waiters for execution wrt hangcheck
https://patchwork.freedesktop.org/api/1.0/series/37276/revisions/1/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:467s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:461s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:275s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:463s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:502s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:577s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-glk-dsi failed to collect. IGT log at Patchwork_7807/fi-glk-dsi/igt.log

5f9f3637ad4677971149ec7cde9ed2081a90839b drm-tip: 2018y-01m-29d-13h-02m-54s UTC 
integration manifest
c14445012a81 drm/i915: Tracking waiters for execution wrt hangcheck

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Tracking waiters for execution wrt hangcheck

2018-01-29 Thread Chris Wilson
Quoting Chris Wilson (2018-01-29 13:50:13)
> Hangcheck wants to turn itself off when no one is listening (to save
> needless wakeups). However, we now may have waiters that are not waiting
> for requests already on the GPU, but waiting for requests deep in the
> queue for execution, and do not have an irq alloted. Therefore, inside
> hangcheck we can not simply just check if any waiter has an irq
> assigned, but can look at whether anyone is listening for hangcheck
> signals.

This is not sufficient for unlocked waits. (Although I might argue
that all waits eventually hit somebody who will wait.) I am thinking
that we move hangcheck over to mark_busy.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Tracking waiters for execution wrt hangcheck

2018-01-29 Thread Chris Wilson
Hangcheck wants to turn itself off when no one is listening (to save
needless wakeups). However, we now may have waiters that are not waiting
for requests already on the GPU, but waiting for requests deep in the
queue for execution, and do not have an irq alloted. Therefore, inside
hangcheck we can not simply just check if any waiter has an irq
assigned, but can look at whether anyone is listening for hangcheck
signals.

Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for 
request completion")
Signed-off-by: Chris Wilson 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_hangcheck.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 31f01d64c021..34db72e635fc 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -411,7 +411,6 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
struct intel_engine_cs *engine;
enum intel_engine_id id;
unsigned int hung = 0, stuck = 0;
-   int busy_count = 0;
 
if (!i915_modparams.enable_hangcheck)
return;
@@ -429,7 +428,6 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
 
for_each_engine(engine, dev_priv, id) {
-   const bool busy = intel_engine_has_waiter(engine);
struct intel_engine_hangcheck hc;
 
semaphore_clear_deadlocks(dev_priv);
@@ -443,15 +441,13 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
if (hc.action != ENGINE_DEAD)
stuck |= intel_engine_flag(engine);
}
-
-   busy_count += busy;
}
 
if (hung)
hangcheck_declare_hang(dev_priv, hung, stuck);
 
/* Reset timer in case GPU hangs without another request being added */
-   if (busy_count)
+   if (waitqueue_active(&dev_priv->gpu_error.wait_queue))
i915_queue_hangcheck(dev_priv);
 }
 
-- 
2.15.1

___
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: Simplify guard logic for setup_scratch_page()

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: Simplify guard logic for setup_scratch_page()
URL   : https://patchwork.freedesktop.org/series/37265/
State : success

== Summary ==

Series 37265v1 drm/i915: Simplify guard logic for setup_scratch_page()
https://patchwork.freedesktop.org/api/1.0/series/37265/revisions/1/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:576s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:497s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:533s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
Blacklisted hosts:
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s

2bbded26cfa2309e876e69069c85acae21b09920 drm-tip: 2018y-01m-29d-10h-43m-15s UTC 
integration manifest
51145ced7dd5 drm/i915: Simplify guard logic for setup_scratch_page()

== Logs ==

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


Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to intel_framebuffer_init

2018-01-29 Thread Maarten Lankhorst
Op 20-01-18 om 22:45 schreef Vidya Srinivas:
> From: Chandra Konduru 
>
> This patch adds NV12 as supported format
> to intel_framebuffer_init and performs various checks.
>
> v2:
> -Fix an issue in checks added (Chandra Konduru)
>
> v3: rebased (me)
>
> v4: Review comments by Ville addressed
> Added platform check for NV12 in intel_framebuffer_init
> Removed offset checks for NV12 case
>
> v5: Addressed review comments by Clinton A Taylor
> This NV12 support only correctly works on SKL.
> Plane color space conversion is different on GLK and later platforms
> causing the colors to display incorrectly.
> Ville's plane color space property patch series
> in review will fix this issue.
> - Restricted the NV12 case in intel_framebuffer_init to
> SKL and BXT only.
>
> v6: Rebased (me)
>
> v7: Addressed review comments by Ville
> Restricting the NV12 to BXT for now.
>
> v8: Rebased (me)
> Restricting the NV12 changes to BXT and KBL for now.
>
> v9: Rebased (me)
>
> Tested-by: Clinton Taylor 
> Reviewed-by: Clinton Taylor 
> Signed-off-by: Chandra Konduru 
> Signed-off-by: Nabendu Maiti 
> Signed-off-by: Vidya Srinivas 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 88bc750..db42448 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14005,6 +14005,14 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   goto err;
>   }
>   break;
> + case DRM_FORMAT_NV12:
> + if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv)) {
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +   drm_get_format_name(mode_cmd->pixel_format,
> + &format_name));
> + goto err;
> + }
> + break;
>   default:
>   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> drm_get_format_name(mode_cmd->pixel_format, 
> &format_name));

Hey,

When implementing this for IGT I've noticed a small gap in documentation, which 
will definitely need clarification somewhere. intel_framebuffer_init is 
probably good enough since it's specific to how intel works internally..
The Yf tiling mode depends on BPP, is it correct to say that plane 0 has 8 bpp 
and plane 1 16 bpp for tiling calculations?

What bpp is used?

Are macroblock sizes always the same for Y and UV?

~Maarten

___
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: Assert the engine has finished the seqno on unsubmission

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: Assert the engine has finished the seqno on unsubmission
URL   : https://patchwork.freedesktop.org/series/37263/
State : success

== Summary ==

Series 37263v1 drm/i915: Assert the engine has finished the seqno on 
unsubmission
https://patchwork.freedesktop.org/api/1.0/series/37263/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:475s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:466s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:530s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

2bbded26cfa2309e876e69069c85acae21b09920 drm-tip: 2018y-01m-29d-10h-43m-15s UTC 
integration manifest
f691c54c84a5 drm/i915: Assert the engine has finished the seqno on unsubmission

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Assert the engine has finished the seqno on unsubmission

2018-01-29 Thread Michał Winiarski
On Mon, Jan 29, 2018 at 09:49:12AM +, Chris Wilson wrote:
> Assert that we do not try to unsubmit a completed request, as should we
> try to resubmit it later, the ring is already past the request's
> breadcrumb and the breadcrumb will not be updated.

"Assert that we do not try to unsubmit a completed request" in the subject?
(what does it mean to "finish the seqno"?)

Reviewed-by: Michał Winiarski 

-Michał

> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem_request.c | 2 ++
>  1 file changed, 2 insertions(+)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Simplify guard logic for setup_scratch_page()

2018-01-29 Thread Matthew Auld
On 29 January 2018 at 10:28, Chris Wilson  wrote:
> Older gcc is complaining it can't follow the guards and thinks that
> addr may be used uninitialised
>
> In the process, we can simplify down to one loop,
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-131 (-131)
> Function old new   delta
> setup_scratch_page   545 414-131
>
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 

With or without __GFP_RETRY_MAYFAIL:

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


Re: [Intel-gfx] [PATCH 01/17] drm/i915/icl: add the main CDCLK functions

2018-01-29 Thread Imre Deak
On Tue, Jan 23, 2018 at 05:05:20PM -0200, Paulo Zanoni wrote:
> This commit adds the basic CDCLK functions, but it's still missing
> pieces of the display initialization sequence.
> 
> v2:
>  - Implement the voltage levels.
>  - Rebase.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|  10 +-
>  drivers/gpu/drm/i915/intel_cdclk.c | 253 
> -
>  drivers/gpu/drm/i915/intel_drv.h   |   2 +
>  3 files changed, 261 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index abd9ee876186..d72e206b2b9f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7113,8 +7113,12 @@ enum {
>  #define SKL_DFSM_PIPE_B_DISABLE  (1 << 21)
>  #define SKL_DFSM_PIPE_C_DISABLE  (1 << 28)
>  
> -#define SKL_DSSM _MMIO(0x51004)
> -#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz  (1 << 31)
> +#define SKL_DSSM _MMIO(0x51004)
> +#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz  (1 << 31)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_MASK   (7 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_24MHz  (0 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz(1 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz(2 << 29)
>  
>  #define GEN7_FF_SLICE_CS_CHICKEN1_MMIO(0x20e0)
>  #define   GEN9_FFSC_PERCTX_PREEMPT_CTRL  (1<<14)
> @@ -8760,6 +8764,8 @@ enum skl_power_gate {
>  #define  BXT_CDCLK_CD2X_PIPE_NONEBXT_CDCLK_CD2X_PIPE(3)
>  #define  BXT_CDCLK_SSA_PRECHARGE_ENABLE  (1<<16)
>  #define  CDCLK_FREQ_DECIMAL_MASK (0x7ff)
> +#define  ICL_CDCLK_CD2X_PIPE(pipe)   ((pipe) << 19)
> +#define  ICL_CDCLK_CD2X_PIPE_NONEICL_CDCLK_CD2X_PIPE(7)
>  
>  /* LCPLL_CTL */
>  #define LCPLL1_CTL   _MMIO(0x46010)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index c4392ea34a3d..d867956d5a9f 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1766,6 +1766,215 @@ static void cnl_sanitize_cdclk(struct 
> drm_i915_private *dev_priv)
>   dev_priv->cdclk.hw.vco = -1;
>  }
>  
> +static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
> +{
> + int ranges_24[] = { 312000, 552000, 648000 };
> + int ranges_19_38[] = { 307200, 556800, 652800 };
> + int *ranges;
> +
> + switch (ref) {
> + default:
> + MISSING_CASE(ref);
> + case 24000:
> + ranges = ranges_24;
> + break;
> + case 19200:
> + case 38400:
> + ranges = ranges_19_38;
> + break;
> + }
> +
> + if (min_cdclk > ranges[1])
> + return ranges[2];
> + else if (min_cdclk > ranges[0])
> + return ranges[1];
> + else
> + return ranges[0];
> +}
> +
> +static int icl_calc_cdclk_pll_vco(struct drm_i915_private *dev_priv, int 
> cdclk)
> +{
> + int ratio;
> +
> + /* 50MHz == CDCLK PLL disabled. */
> + if (cdclk == 5)

Here and everywhere else cdclk.hw.bypass should be used instead of hard
coding it.

> + return 0;
> +
> + switch (cdclk) {
> + default:
> + MISSING_CASE(cdclk);
> + case 307200:
> + case 556800:
> + case 652800:
> + WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
> + dev_priv->cdclk.hw.ref != 38400);
> + break;
> + case 312000:
> + case 552000:
> + case 648000:
> + WARN_ON(dev_priv->cdclk.hw.ref != 24000);
> + }
> +
> + ratio = cdclk / (dev_priv->cdclk.hw.ref / 2);
> +
> + return dev_priv->cdclk.hw.ref * ratio;
> +}
> +
> +static void icl_set_cdclk(struct drm_i915_private *dev_priv,
> +   const struct intel_cdclk_state *cdclk_state)
> +{
> + unsigned int cdclk = cdclk_state->cdclk;
> + unsigned int vco = cdclk_state->vco;
> + int ret;
> + u32 voltage_level;
> +
> + mutex_lock(&dev_priv->pcu_lock);
> + ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
> + SKL_CDCLK_PREPARE_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE, 3);
> + mutex_unlock(&dev_priv->pcu_lock);
> + if (ret) {
> + DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
> +   ret);
> + return;
> + }
> +
> + /* FIXME: We should also consider the DDI clock here. */
> + switch (cdclk) {
> + case 307200:
> + case 312000:
> + voltage_level = 0;
> + break;
> + case 556800:
> + case 552000:
> + voltage_level = 1;
> + break;
> + default:
> + MISSING_CASE(cdclk);
> + case 652800:
> + case 648000:
> + voltage_level = 2;
> + break;
> + }
> +
> + if (dev_priv->c

Re: [Intel-gfx] [PATCH] Revert "drm/i915: mark all device info struct with __initconst"

2018-01-29 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-01-29 10:34:05)
> 
> On 29/01/2018 09:00, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-01-29 08:33:46)
> >> This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.
> >>
> >>   Conflicts:
> >>  drivers/gpu/drm/i915/i915_pci.c
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805
> >> Signed-off-by: Lionel Landwerlin 
> > 
> > Mea culpa, completely didn't realise post-module init loading was a
> > thing.
> > Reviewed-by: Chris Wilson 
> > 
> > It's still on the low hanging fruit list for reducing our bloat. Ideas?
> > i915_pcidata.ko? How far could we go with that, make all gen specific
> > code a separate section and unload them after init?
> 
> There is one maybe easy win with DMI_MATCH business. It modpost was 
> taught to handle string relocs, one could remove the hardcoded string 
> storage of 4x79 bytes for every DMI_MATCH entry. We have one large-ish 
> table which is not __initconst in intel_no_lvds, but I haven't looked at 
> the rest of the kernel - if all other users are mostly __initconst then 
> the saving wouldn't be that universally interesting.
> 
> One larger code re-org could be to move all genX prefixed functions into 
> separate .kos and load them dynamically. But it is very difficult to 
> estimate the saving given how much re-use we have. And the extraction 
> would probably be quite messy.

I was dreaming of some advanced LTO which could mark used sections at
runtime linking (would need to be more involved so that it's run after
init/probe) and unload the rest. Doing some manual splitting seems like
the easy-ish thing to do in the near term, but I'd like to keep a fat
i915.ko and retrieve data sections from it on probe (just for the
convenience of having only one module). Dream on :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] Revert "drm/i915: mark all device info struct with __initconst"

2018-01-29 Thread Tvrtko Ursulin


On 29/01/2018 09:00, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-01-29 08:33:46)

This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.

  Conflicts:
 drivers/gpu/drm/i915/i915_pci.c

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805
Signed-off-by: Lionel Landwerlin 


Mea culpa, completely didn't realise post-module init loading was a
thing.
Reviewed-by: Chris Wilson 

It's still on the low hanging fruit list for reducing our bloat. Ideas?
i915_pcidata.ko? How far could we go with that, make all gen specific
code a separate section and unload them after init?


There is one maybe easy win with DMI_MATCH business. It modpost was 
taught to handle string relocs, one could remove the hardcoded string 
storage of 4x79 bytes for every DMI_MATCH entry. We have one large-ish 
table which is not __initconst in intel_no_lvds, but I haven't looked at 
the rest of the kernel - if all other users are mostly __initconst then 
the saving wouldn't be that universally interesting.


One larger code re-org could be to move all genX prefixed functions into 
separate .kos and load them dynamically. But it is very difficult to 
estimate the saving given how much re-use we have. And the extraction 
would probably be quite messy.


Regards,

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm/i915: mark all device info struct with __initconst"

2018-01-29 Thread Patchwork
== Series Details ==

Series: Revert "drm/i915: mark all device info struct with __initconst"
URL   : https://patchwork.freedesktop.org/series/37260/
State : failure

== Summary ==

Warning: bzip CI_DRM_3686/shard-glkb6/results14.json.bz2 wasn't in correct JSON 
format
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw)
Subgroup flip-vs-panning-vs-hang:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Subgroup 2x-dpms-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw)
Test pm_rpm:
Subgroup system-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103375
Test kms_mmap_write_crc:
skip   -> PASS   (shard-apl)
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Test gem_exec_schedule:
Subgroup preempt-other-render:
pass   -> FAIL   (shard-apl) fdo#102848
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass   -> SKIP   (shard-snb) fdo#103880

fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102848 https://bugs.freedesktop.org/show_bug.cgi?id=102848
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880

shard-apltotal:2838 pass:1752 dwarn:1   dfail:0   fail:21  skip:1064 
time:12630s
shard-hswtotal:2808 pass:1717 dwarn:1   dfail:0   fail:12  skip:1076 
time:11824s
shard-snbtotal:2838 pass:1327 dwarn:2   dfail:0   fail:11  skip:1498 
time:6632s
Blacklisted hosts:
shard-kbltotal:2825 pass:1816 dwarn:39  dfail:3   fail:23  skip:943 
time:9481s

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Simplify guard logic for setup_scratch_page()

2018-01-29 Thread Chris Wilson
Quoting Chris Wilson (2018-01-29 10:28:40)
> Older gcc is complaining it can't follow the guards and thinks that
> addr may be used uninitialised
> 
> In the process, we can simplify down to one loop,
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-131 (-131)
> Function old new   delta
> setup_scratch_page   545 414-131
> 
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 
> ---
> +   size = I915_GTT_PAGE_SIZE_4K;
> if (i915_vm_is_48bit(vm) &&
> HAS_PAGE_SIZES(vm->i915, I915_GTT_PAGE_SIZE_64K)) {
> +   size = I915_GTT_PAGE_SIZE_64K;
> +   gfp |= __GFP_NOWARN;

We may want to sneak in a __GFP_RETRY_MAYFAIL here.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Simplify guard logic for setup_scratch_page()

2018-01-29 Thread Chris Wilson
Older gcc is complaining it can't follow the guards and thinks that
addr may be used uninitialised

In the process, we can simplify down to one loop,
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-131 (-131)
Function old new   delta
setup_scratch_page   545 414-131

Reported-by: Geert Uytterhoeven 
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 68 +
 1 file changed, 32 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index be227512430a..0a0030e4cb10 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -543,9 +543,7 @@ static void fill_page_dma_32(struct i915_address_space *vm,
 static int
 setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
 {
-   struct page *page = NULL;
-   dma_addr_t addr;
-   int order;
+   unsigned long size;
 
/*
 * In order to utilize 64K pages for an object with a size < 2M, we will
@@ -559,48 +557,46 @@ setup_scratch_page(struct i915_address_space *vm, gfp_t 
gfp)
 * TODO: we should really consider write-protecting the scratch-page and
 * sharing between ppgtt
 */
+   size = I915_GTT_PAGE_SIZE_4K;
if (i915_vm_is_48bit(vm) &&
HAS_PAGE_SIZES(vm->i915, I915_GTT_PAGE_SIZE_64K)) {
-   order = get_order(I915_GTT_PAGE_SIZE_64K);
-   page = alloc_pages(gfp | __GFP_ZERO | __GFP_NOWARN, order);
-   if (page) {
-   addr = dma_map_page(vm->dma, page, 0,
-   I915_GTT_PAGE_SIZE_64K,
-   PCI_DMA_BIDIRECTIONAL);
-   if (unlikely(dma_mapping_error(vm->dma, addr))) {
-   __free_pages(page, order);
-   page = NULL;
-   }
-
-   if (!IS_ALIGNED(addr, I915_GTT_PAGE_SIZE_64K)) {
-   dma_unmap_page(vm->dma, addr,
-  I915_GTT_PAGE_SIZE_64K,
-  PCI_DMA_BIDIRECTIONAL);
-   __free_pages(page, order);
-   page = NULL;
-   }
-   }
+   size = I915_GTT_PAGE_SIZE_64K;
+   gfp |= __GFP_NOWARN;
}
 
-   if (!page) {
-   order = 0;
-   page = alloc_page(gfp | __GFP_ZERO);
+   do {
+   int order = get_order(size);
+   struct page *page;
+   dma_addr_t addr;
+
+   page = alloc_pages(gfp | __GFP_ZERO, order);
if (unlikely(!page))
-   return -ENOMEM;
+   goto skip;
 
-   addr = dma_map_page(vm->dma, page, 0, PAGE_SIZE,
+   addr = dma_map_page(vm->dma, page, 0, size,
PCI_DMA_BIDIRECTIONAL);
-   if (unlikely(dma_mapping_error(vm->dma, addr))) {
-   __free_page(page);
-   return -ENOMEM;
-   }
-   }
+   if (unlikely(dma_mapping_error(vm->dma, addr)))
+   goto free_page;
 
-   vm->scratch_page.page = page;
-   vm->scratch_page.daddr = addr;
-   vm->scratch_page.order = order;
+   if (unlikely(!IS_ALIGNED(addr, size)))
+   goto unmap_page;
 
-   return 0;
+   vm->scratch_page.page = page;
+   vm->scratch_page.daddr = addr;
+   vm->scratch_page.order = order;
+   return 0;
+
+unmap_page:
+   dma_unmap_page(vm->dma, addr, size, PCI_DMA_BIDIRECTIONAL);
+free_page:
+   __free_pages(page, order);
+skip:
+   if (size == I915_GTT_PAGE_SIZE_4K)
+   return -ENOMEM;
+
+   size = I915_GTT_PAGE_SIZE_4K;
+   gfp &= ~__GFP_NOWARN;
+   } while (1);
 }
 
 static void cleanup_scratch_page(struct i915_address_space *vm)
-- 
2.15.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: mark all device info struct with __initconst"

2018-01-29 Thread Lukas Wunner
On Mon, Jan 29, 2018 at 09:27:39AM +, Lionel Landwerlin wrote:
> On 29/01/18 09:02, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-01-29 08:33:46)
> > > This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.
> > > 
> > >   Conflicts:
> > >  drivers/gpu/drm/i915/i915_pci.c
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805
> > Fixes: 5b54eddd3920 ("drm/i915: mark all device info struct with 
> > __initconst")
> > 
> > So it ends up in the right place.
> > -Chris
> > 
> Thanks, pushed.

This is missing
Reported-by: Chris Murphy 

Also, someone please put on the todo list to write an igt test which
unbinds and rebinds the driver to prevent this regression from
reappearing:

echo PCI-ID > /sys/bus/pci/drivers/i915/unbind
echo PCI-ID > /sys/bus/pci/drivers/i915/bind

Thanks,

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


Re: [Intel-gfx] [PATCH] Revert "drm/i915: mark all device info struct with __initconst"

2018-01-29 Thread Jani Nikula
On Mon, 29 Jan 2018, Lionel Landwerlin  wrote:
> On 29/01/18 09:02, Chris Wilson wrote:
>> Quoting Lionel Landwerlin (2018-01-29 08:33:46)
>>> This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.
>>>
>>>   Conflicts:
>>>  drivers/gpu/drm/i915/i915_pci.c
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805
>> Fixes: 5b54eddd3920 ("drm/i915: mark all device info struct with 
>> __initconst")
>>
>> So it ends up in the right place.
>> -Chris
>>
> Thanks, pushed.

Please *always* wait for the full IGT results before pushing.

Please *always* include a self-contained reason *why* in the commit
message instead of relying on Bugzilla: link only.

Please run 'dim fixes ' to get the proper tags; now Cc: stable
is missing. Fixes: alone doesn't cut it now that v4.15 has been
released.

No patch needs to be merged within an hour. There's never such a
rush. Please let's give more people a chance to look at the patches
before they get merged.


Thanks,
Jani.


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

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


Re: [Intel-gfx] [PATCH] drm/i915: Assert the engine has finished the seqno on unsubmission

2018-01-29 Thread Chris Wilson
s/has/has not/

Quoting Chris Wilson (2018-01-29 09:49:12)
> Assert that we do not try to unsubmit a completed request, as should we
> try to resubmit it later, the ring is already past the request's
> breadcrumb and the breadcrumb will not be updated.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem_request.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index 9b02310307fc..7192521e3d10 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -652,6 +652,8 @@ void __i915_gem_request_unsubmit(struct 
> drm_i915_gem_request *request)
>  */
> GEM_BUG_ON(!request->global_seqno);
> GEM_BUG_ON(request->global_seqno != engine->timeline->seqno);
> +   GEM_BUG_ON(i915_seqno_passed(intel_engine_get_seqno(engine),
> +request->global_seqno));
> engine->timeline->seqno--;
>  
> /* We may be recursing from the signal callback of another i915 fence 
> */
> -- 
> 2.15.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Assert the engine has finished the seqno on unsubmission

2018-01-29 Thread Chris Wilson
Assert that we do not try to unsubmit a completed request, as should we
try to resubmit it later, the ring is already past the request's
breadcrumb and the breadcrumb will not be updated.

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

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 9b02310307fc..7192521e3d10 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -652,6 +652,8 @@ void __i915_gem_request_unsubmit(struct 
drm_i915_gem_request *request)
 */
GEM_BUG_ON(!request->global_seqno);
GEM_BUG_ON(request->global_seqno != engine->timeline->seqno);
+   GEM_BUG_ON(i915_seqno_passed(intel_engine_get_seqno(engine),
+request->global_seqno));
engine->timeline->seqno--;
 
/* We may be recursing from the signal callback of another i915 fence */
-- 
2.15.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: mark all device info struct with __initconst"

2018-01-29 Thread Lionel Landwerlin

On 29/01/18 09:02, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-01-29 08:33:46)

This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.

  Conflicts:
 drivers/gpu/drm/i915/i915_pci.c

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805

Fixes: 5b54eddd3920 ("drm/i915: mark all device info struct with __initconst")

So it ends up in the right place.
-Chris


Thanks, pushed.

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


Re: [Intel-gfx] [Bug 104805] regression in 4.15 unable to reboot/poweroff, vgaswitcheroo doesn't work, RIP: 0010:i915_pci_probe+0x11/0x70 [i915]

2018-01-29 Thread Chris Murphy
On Sun, Jan 28, 2018 at 2:37 PM, Lukas Wunner  wrote:
> On Sat, Jan 27, 2018 at 10:42:45AM +, bugzilla-dae...@freedesktop.org 
> wrote:
>> https://bugs.freedesktop.org/show_bug.cgi?id=104805
>>
>> --- Comment #6 from Chris Wilson  ---
>> Sigh. Revert then solve the bloat another way. I think we can move it to a
>> seperate module and only load it during pci_probe. (That module can then play
>> some tricks to construct driver_info using private commands to allow feature
>> enabling.)
>
> The following might work:  Set i915_pci_driver->id_table = NULL.
> Then in i915_init(), after calling pci_register_driver(), iterate
> over pciidlist[] and call pci_add_dynid() for each entry.  Finally,
> call pci_free_dynids().
>
> The problem is that after manually unbinding the driver via sysfs,
> you can't bind it again.
>
> Also, as soon as Intel introduces a discrete GPU (e.g. in a dock,
> hotplugged via Thunderbolt), the whole idea falls apart.
>
> How many bytes are we talking about here anyway?  I imagine it's less
> than a page.  Honestly I think it's not worth the effort.
>
> I'm wondering why noone else is seeing this crash, myself included.
> Is the driver somehow unbound and rebound on Chris Murphy's machine?

I can't answer this question, my understanding this model defaults to
discrete GPU (AMD) graphics by the firmware. Fedora has enabled
/usr/lib/systemd/system/switcheroo-control.service by default to try
to disable discrete GPUs on dual GPU computers, favoring the more
power efficient integrated GPU. I see evidence the service is enabled
but no evidence whether it was run and in dmesg it's definitely not
enabled like what happens on 4.14. So maybe the switcheroo attempt is
what triggers the crash?

>
> @Chris Murphy: You may have noticed an 8 second delay on reboot with
> 4.15.  Before you waste time bisecting it:  A fix is already queued
> for 4.16 and marked for stable:
> https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?id=493fb50e958c

I haven't noticed such a delay.

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


Re: [Intel-gfx] [PATCH] Revert "drm/i915: mark all device info struct with __initconst"

2018-01-29 Thread Chris Wilson
Quoting Lionel Landwerlin (2018-01-29 08:33:46)
> This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.
> 
>  Conflicts:
> drivers/gpu/drm/i915/i915_pci.c
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805
Fixes: 5b54eddd3920 ("drm/i915: mark all device info struct with __initconst")

So it ends up in the right place.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] Revert "drm/i915: mark all device info struct with __initconst"

2018-01-29 Thread Chris Wilson
Quoting Lionel Landwerlin (2018-01-29 08:33:46)
> This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.
> 
>  Conflicts:
> drivers/gpu/drm/i915/i915_pci.c
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805
> Signed-off-by: Lionel Landwerlin 

Mea culpa, completely didn't realise post-module init loading was a
thing.
Reviewed-by: Chris Wilson 

It's still on the low hanging fruit list for reducing our bloat. Ideas?
i915_pcidata.ko? How far could we go with that, make all gen specific
code a separate section and unload them after init?
-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 Revert "drm/i915: mark all device info struct with __initconst"

2018-01-29 Thread Patchwork
== Series Details ==

Series: Revert "drm/i915: mark all device info struct with __initconst"
URL   : https://patchwork.freedesktop.org/series/37260/
State : success

== Summary ==

Series 37260v1 Revert "drm/i915: mark all device info struct with __initconst"
https://patchwork.freedesktop.org/api/1.0/series/37260/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:473s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:500s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
ede31d66330c Revert "drm/i915: mark all device info struct with __initconst"

== Logs ==

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


[Intel-gfx] [PATCH] Revert "drm/i915: mark all device info struct with __initconst"

2018-01-29 Thread Lionel Landwerlin
This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.

 Conflicts:
drivers/gpu/drm/i915/i915_pci.c

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_pci.c | 96 -
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f28c165fc49d..138228dd7782 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -74,19 +74,19 @@
GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
-static const struct intel_device_info intel_i830_info __initconst = {
+static const struct intel_device_info intel_i830_info = {
GEN2_FEATURES,
.platform = INTEL_I830,
.is_mobile = 1, .cursor_needs_physical = 1,
.num_pipes = 2, /* legal, last one wins */
 };
 
-static const struct intel_device_info intel_i845g_info __initconst = {
+static const struct intel_device_info intel_i845g_info = {
GEN2_FEATURES,
.platform = INTEL_I845G,
 };
 
-static const struct intel_device_info intel_i85x_info __initconst = {
+static const struct intel_device_info intel_i85x_info = {
GEN2_FEATURES,
.platform = INTEL_I85X, .is_mobile = 1,
.num_pipes = 2, /* legal, last one wins */
@@ -94,7 +94,7 @@ static const struct intel_device_info intel_i85x_info 
__initconst = {
.has_fbc = 1,
 };
 
-static const struct intel_device_info intel_i865g_info __initconst = {
+static const struct intel_device_info intel_i865g_info = {
GEN2_FEATURES,
.platform = INTEL_I865G,
 };
@@ -108,7 +108,7 @@ static const struct intel_device_info intel_i865g_info 
__initconst = {
GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
-static const struct intel_device_info intel_i915g_info __initconst = {
+static const struct intel_device_info intel_i915g_info = {
GEN3_FEATURES,
.platform = INTEL_I915G, .cursor_needs_physical = 1,
.has_overlay = 1, .overlay_needs_physical = 1,
@@ -116,7 +116,7 @@ static const struct intel_device_info intel_i915g_info 
__initconst = {
.unfenced_needs_alignment = 1,
 };
 
-static const struct intel_device_info intel_i915gm_info __initconst = {
+static const struct intel_device_info intel_i915gm_info = {
GEN3_FEATURES,
.platform = INTEL_I915GM,
.is_mobile = 1,
@@ -128,7 +128,7 @@ static const struct intel_device_info intel_i915gm_info 
__initconst = {
.unfenced_needs_alignment = 1,
 };
 
-static const struct intel_device_info intel_i945g_info __initconst = {
+static const struct intel_device_info intel_i945g_info = {
GEN3_FEATURES,
.platform = INTEL_I945G,
.has_hotplug = 1, .cursor_needs_physical = 1,
@@ -137,7 +137,7 @@ static const struct intel_device_info intel_i945g_info 
__initconst = {
.unfenced_needs_alignment = 1,
 };
 
-static const struct intel_device_info intel_i945gm_info __initconst = {
+static const struct intel_device_info intel_i945gm_info = {
GEN3_FEATURES,
.platform = INTEL_I945GM, .is_mobile = 1,
.has_hotplug = 1, .cursor_needs_physical = 1,
@@ -148,14 +148,14 @@ static const struct intel_device_info intel_i945gm_info 
__initconst = {
.unfenced_needs_alignment = 1,
 };
 
-static const struct intel_device_info intel_g33_info __initconst = {
+static const struct intel_device_info intel_g33_info = {
GEN3_FEATURES,
.platform = INTEL_G33,
.has_hotplug = 1,
.has_overlay = 1,
 };
 
-static const struct intel_device_info intel_pineview_info __initconst = {
+static const struct intel_device_info intel_pineview_info = {
GEN3_FEATURES,
.platform = INTEL_PINEVIEW, .is_mobile = 1,
.has_hotplug = 1,
@@ -172,7 +172,7 @@ static const struct intel_device_info intel_pineview_info 
__initconst = {
GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
-static const struct intel_device_info intel_i965g_info __initconst = {
+static const struct intel_device_info intel_i965g_info = {
GEN4_FEATURES,
.platform = INTEL_I965G,
.has_overlay = 1,
@@ -180,7 +180,7 @@ static const struct intel_device_info intel_i965g_info 
__initconst = {
.has_snoop = false,
 };
 
-static const struct intel_device_info intel_i965gm_info __initconst = {
+static const struct intel_device_info intel_i965gm_info = {
GEN4_FEATURES,
.platform = INTEL_I965GM,
.is_mobile = 1, .has_fbc = 1,
@@ -190,13 +190,13 @@ static const struct intel_device_info intel_i965gm_info 
__initconst = {
.has_snoop = false,
 };
 
-static const struct intel_device_info intel_g45_info __initconst = {
+static const struct intel_device_info intel_g45_info = {
GEN4_FEATURES,
.platform = INTEL_G45,
.ring_mask = RENDER_RING | BSD_RING,
 };
 
-static const struct intel_device_info intel_gm45_info __initconst = {
+

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Enable debugobjects for request validation (rev2)

2018-01-29 Thread Patchwork
== Series Details ==

Series: drm/i915: Enable debugobjects for request validation (rev2)
URL   : https://patchwork.freedesktop.org/series/37240/
State : failure

== Summary ==

Warning: bzip CI_DRM_3686/shard-glkb6/results14.json.bz2 wasn't in correct JSON 
format
Test gem_exec_schedule:
Subgroup wide-blt:
pass   -> FAIL   (shard-apl) fdo#102848 +2
Subgroup wide-render:
pass   -> FAIL   (shard-apl)
Test kms_mmap_write_crc:
skip   -> PASS   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#102848 https://bugs.freedesktop.org/show_bug.cgi?id=102848
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:2838 pass:1749 dwarn:1   dfail:0   fail:24  skip:1064 
time:12830s
shard-hswtotal:2838 pass:1736 dwarn:1   dfail:0   fail:10  skip:1090 
time:12157s
shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:10  skip:1497 
time:6756s
Blacklisted hosts:
shard-kbltotal:2825 pass:1849 dwarn:11  dfail:1   fail:21  skip:942 
time:9559s

== Logs ==

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