[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Do not enable movntdqa optimization in hypervisor guest

[Patchwork]

== Series Details ==

Series: drm/i915: Do not enable movntdqa optimization in hypervisor guest
URL   : https://patchwork.freedesktop.org/series/35711/
State : warning

== Summary ==

Test pm_rpm:
Subgroup system-suspend:
skip   -> PASS   (shard-hsw) fdo#103375
Subgroup system-suspend-modeset:
pass   -> SKIP   (shard-hsw)
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-snb) fdo#104218 +1
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-snb)
Subgroup sysfs-reader:
skip   -> PASS   (shard-hsw)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> SKIP   (shard-hsw) fdo#103540

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

shard-hswtotal:2712 pass:1534 dwarn:1   dfail:0   fail:10  skip:1167 
time:9395s
shard-snbtotal:2640 pass:1283 dwarn:1   dfail:0   fail:10  skip:1345 
time:7824s
Blacklisted hosts:
shard-apltotal:2712 pass:1685 dwarn:1   dfail:0   fail:24  skip:1001 
time:13756s
shard-kbltotal:2653 pass:1753 dwarn:10  dfail:1   fail:24  skip:864 
time:10677s

== Logs ==

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

Re: [Intel-gfx] [PULL] more gvt-next for 4.16

[Jani Nikula]

On Fri, 22 Dec 2017, Zhenyu Wang  wrote:
> On 2017.12.21 19:07:07 -0800, Rodrigo Vivi wrote:
>> On Fri, Dec 22, 2017 at 02:43:06AM +, Zhenyu Wang wrote:
>> dim apply-pull drm-intel-next-queued
>> 
>> https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
>> From https://github.com/intel/gvt-linux
>>  * tag gvt-next-2017-12-22 -> FETCH_HEAD
>> dim: ERROR: 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7 is lacking mandatory 
>> review, aborting
>>
>
> Looks dim doesn't allow committer == author without ack or r-b? Is
> this really mandatory required?

Yes. We want a minimum of two people looking at each patch. It's pretty
much irrelevant if the committer/maintainer is the author or not. 2*sob
or sob+rb or sob+ack, or more for more complicated things.

It's unfortunately common that the "obviously correct and trivial" patch
quickly committed by the author without anyone else looking at it is
actually buggy...

> If yes, I will apply this rule for gvt tree as well and encourage gvt
> developer to send a-b/r-b mail as looks people more like to use IM to
> exchange review comment..

We don't have a strict rule to always send acks or rb by mail. IRC or IM
is fine too for simple things. But we want to record the acks and rb in
the commit regardless. When I push patches that got IRC review, I add
the tags, and typically reply with something along the lines of, "Pushed
with J. Random Hacker's IRC review".

That said, I do encourage explicit ack/rb messages on the lists for
non-trivial things in the interest of open development and transparency.

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] ✓ Fi.CI.BAT: success for drm/i915/dmc: DMC 1.07 for Cannonlake

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Patchwork
> Sent: torstai 21. joulukuuta 2017 23.08
> To: Srivatsa, Anusha 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmc: DMC 1.07 for
> Cannonlake
> 
> == Series Details ==
> 
> Series: drm/i915/dmc: DMC 1.07 for Cannonlake
> URL   : https://patchwork.freedesktop.org/series/35651/
> State : success
> 
> == Summary ==
> 
> Series 35651v1 drm/i915/dmc: DMC 1.07 for Cannonlake
> https://patchwork.freedesktop.org/api/1.0/series/35651/revisions/1/mbox/
> 
> Test debugfs_test:
> Subgroup read_all_entries:
> incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> pass   -> INCOMPLETE (fi-hsw-4770) fdo#103375
> pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
> Test kms_psr_sink_crc:
> Subgroup psr_basic:
> pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144
> 
> fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
> fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
> fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172
> fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
> 
> fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
> time:443s
> fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
> time:444s
> fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
> time:381s
> fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
> time:499s
> fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
> time:276s
> fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
> time:494s
> fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
> time:496s
> 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:463s
> fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45
> fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
> time:266s
> fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
> time:530s
> fi-hsw-4770  total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:23
> fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
> time:412s
> fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
> time:470s
> fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
> time:426s
> fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
> time:479s
> fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
> time:521s
> fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
> time:466s
> fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
> time:524s
> fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
> time:581s
> fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
> time:442s
> fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
> time:532s
> fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
> time:551s
> fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
> time:508s
> fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
> time:502s
> fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
> time:446s
> 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:409s
> Blacklisted hosts:
> fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
> time:592s
> fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
> time:630s
Now was there:
<7>[  559.133380] [drm:intel_csr_ucode_init [i915]] Loading 
i915/cnl_dmc_ver1_07.bin
<6>[  559.140760] [drm] Finished loading DMC firmware i915/cnl_dmc_ver1_07.bin 
(v1.7)


> fi-glk-dsi   total:288  pass:257  dwarn:0   dfail:0   fail:1   skip:30  
> time:494s
> 
> c0a64101df89fe312cb41d27e184555400d0e3b9 drm-tip: 2017y-12m-21d-
> 18h-02m-56s UTC integration manifest
> 191490226900 drm/i915/dmc: DMC 1.07 for Cannonlake
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_7560/issues.html


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not enable movntdqa optimization in hypervisor guest

[Patchwork]

== Series Details ==

Series: drm/i915: Do not enable movntdqa optimization in hypervisor guest
URL   : https://patchwork.freedesktop.org/series/35711/
State : success

== Summary ==

Series 35711v1 drm/i915: Do not enable movntdqa optimization in hypervisor guest
https://patchwork.freedesktop.org/api/1.0/series/35711/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:436s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:496s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:491s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:502s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:477s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:463s
fi-elk-e7500 total:224  pass:164  dwarn:14  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:261s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:424s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:483s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:520s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:519s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:439s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:529s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:552s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:546s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:411s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:593s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:624s
fi-glk-dsi   total:288  pass:189  dwarn:1   dfail:4   fail:0   skip:94  
time:404s

c0a64101df89fe312cb41d27e184555400d0e3b9 drm-tip: 2017y-12m-21d-18h-02m-56s UTC 
integration manifest
af8be38582f2 drm/i915: Do not enable movntdqa optimization in hypervisor guest

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Do not enable movntdqa optimization in hypervisor guest

[changbin . du]

From: Changbin Du 

Our QA reported a problem caused by movntdqa instructions. Currently,
the KVM hypervisor doesn't support VEX-prefix instructions emulation.
If users passthrough a GPU to guest with vfio option 'x-no-mmap=on',
then all access to the BARs will be trapped and emulated. The KVM
hypervisor would raise an inertal error to qemu which cause the guest
killed. (Since 'movntdqa' ins is not supported.)

This patch try not to enable movntdqa optimization if the driver is
running in hypervisor guest.

Signed-off-by: Changbin Du 
---
 drivers/gpu/drm/i915/i915_memcpy.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_memcpy.c 
b/drivers/gpu/drm/i915/i915_memcpy.c
index 49a0794..8921f40 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/i915/i915_memcpy.c
@@ -96,6 +96,11 @@ bool i915_memcpy_from_wc(void *dst, const void *src, 
unsigned long len)
 
 void i915_memcpy_init_early(struct drm_i915_private *dev_priv)
 {
-   if (static_cpu_has(X86_FEATURE_XMM4_1))
+   /**
+* Some hypervisors (e.g. KVM) don't support VEX-prefix instructions
+* emulation. So don't enable movntdqa in hypervisor guest.
+*/
+   if (static_cpu_has(X86_FEATURE_XMM4_1) &&
+   !boot_cpu_has(X86_FEATURE_HYPERVISOR))
static_branch_enable(_movntdqa);
 }
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Pandiyan, Dhinakaran]

On Fri, 2017-12-22 at 00:48 +, Pandiyan, Dhinakaran wrote:
> On Thu, 2017-12-21 at 08:53 +0200, Jani Nikula wrote:
> > On Wed, 20 Dec 2017, Dhinakaran Pandiyan  
> > wrote:
> > > Occasionally there are LINK_ADDRESS sideband messages timing out with the
> > > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> > > failures lead to the display not coming up on boot. Power cycling the port
> > > corresponding to the MST monitor's branch device and resending the message
> > > fixes the issue. I am not entirely sure if this is specific to my setup.
> > > However, as the power state is toggled conditionally on LINK_ADDRESS
> > > timeouts, this should not affect the working cases.
> > 
> > With stuff like this, I always wonder if catering for a failing setup
> > blocks us from improving working setups, because once we add this, we
> > can't regress it. For example, is there a valid scenario where we'd want
> > to fail fast here, instead of retrying?
> 
> Link address failure would result in not probing a branch device that
> already has been detected. I guess the fail fast case will be applicable
> if the said device was not really present but the parent branch told us
> otherwise.
>  

The other option is we could check the device ID of the dock and
implement this as a quirk.

Btw I found some relevant information in the spec.

"The Message Transaction originator must perform the reply timeout
check. If an error to a request causes the system to be in an invalid
state (e.g., all nodes failed to delete a virtual channel, it is the
responsibility of the Message Transaction originator to return the
system to a valid state). The Message Transaction originator is
responsible for any retries."

and

"SET_POWER_STATE
Must be programmed to 001 (binary) upon power-on reset or an upstream
device disconnect.
001 = Set local Sink device and all downstream Sink devices to D0
(normal operation mode)."

I wonder if the dock is missing this step because the monitor seems to
work well with a discrete MST hub.


> > 
> > Some nits below.
> > 
> > > Cc: Lyude 
> > > Cc: Dave Airlie 
> > > Cc: Jani Nikula 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 70dcfa58d3c2..e06defcdcf18 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > > drm_dp_mst_topology_mgr *mgr,
> > >   int len;
> > >   struct drm_dp_sideband_msg_tx *txmsg;
> > >   int ret;
> > > + int attempts = 5;
> > >  
> > > - txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > > +retry:   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > >   if (!txmsg)
> > >   return;
> > >  
> > > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > > drm_dp_mst_topology_mgr *mgr,
> > >   }
> > >   (*mgr->cbs->hotplug)(mgr);
> > >   }
> > > + } else if (attempts--) {
> > 
> > You'll end up doing (attempts + 1) attempts, including the first one.
> Yeah, that is what I intended to do :) I renamed it from 'retry' to
> 'attempt' at the last moment, which made it a bit confusing I suppose.
> 
> 
> I am stressing testing my setup more to see how well this recovery works
> and update this patch.
> 

Here's what I got with 266 rounds of reboots. 
Correct link address at
 1st try180
 Retry 145
 Retry 232
 Retry 30
 Retry 40
 Retry 52
Giving up   3
Incorrect link address  4

The retries help about 30% of the cases. 

>  
> 
> > 
> > > + kfree(txmsg);
> > 
> > How about memset(txmsg, 0, sizoef(*txmsg)); here and move the goto label
> > down to avoid repeated allocations?
> Absolutely.
> 
> > 
> > > + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > > +  false);
> > > + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > > +  true);
> > > + DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> > 
> > Maybe do the debug message before you power down/up?
> Ok.
> > 
> > BR,
> > Jani.
> > 
> > > + goto retry;
> > >   } else {
> > >   mstb->link_address_sent = false;
> > > - DRM_DEBUG_KMS("link address failed %d\n", ret);
> > > + DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
> > >   }
> > >  
> > >   kfree(txmsg);
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> 

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Use an atomic_t array to track power domain use count.

[Pandiyan, Dhinakaran]

On Thu, 2017-12-21 at 13:37 +0100, Maarten Lankhorst wrote:
> Hey,
> 
> Op 19-12-17 om 06:26 schreef Dhinakaran Pandiyan:
> > Convert the power_domains->domain_use_count array that tracks per-domain
> > use count to atomic_t type. This is needed to be able to read/write the use
> > counts outside of the power domain mutex.
> >
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
> >  drivers/gpu/drm/i915/i915_drv.h |  2 +-
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
> >  3 files changed, 7 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 1a7b28f62570..1f1d9162f2c2 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2764,7 +2764,7 @@ static int i915_power_domain_info(struct seq_file *m, 
> > void *unused)
> > for_each_power_domain(power_domain, power_well->domains)
> > seq_printf(m, "  %-23s %d\n",
> >  intel_display_power_domain_str(power_domain),
> > -power_domains->domain_use_count[power_domain]);
> > +
> > atomic_read(_domains->domain_use_count[power_domain]));
> > }
> >  
> > mutex_unlock(_domains->lock);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 1e4e613e7b41..ddadeb9eaf49 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1489,7 +1489,7 @@ struct i915_power_domains {
> > int power_well_count;
> >  
> > struct mutex lock;
> > -   int domain_use_count[POWER_DOMAIN_NUM];
> > +   atomic_t domain_use_count[POWER_DOMAIN_NUM];
> > struct i915_power_well *power_wells;
> >  };
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 96ab74f3d101..992caec1fbc4 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -1453,7 +1453,7 @@ __intel_display_power_get_domain(struct 
> > drm_i915_private *dev_priv,
> > for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
> > intel_power_well_get(dev_priv, power_well);
> >  
> > -   power_domains->domain_use_count[domain]++;
> > +   atomic_inc(_domains->domain_use_count[domain]);
> >  }
> >  
> >  /**
> > @@ -1539,10 +1539,9 @@ void intel_display_power_put(struct drm_i915_private 
> > *dev_priv,
> >  
> > mutex_lock(_domains->lock);
> >  
> > -   WARN(!power_domains->domain_use_count[domain],
> > -"Use count on domain %s is already zero\n",
> > +   WARN(atomic_dec_return(_domains->domain_use_count[domain]) < 0,
> > +"Use count on domain %s was already zero\n",
> >  intel_display_power_domain_str(domain));
> > -   power_domains->domain_use_count[domain]--;
> >  
> > for_each_power_domain_well_rev(dev_priv, power_well, BIT_ULL(domain))
> > intel_power_well_put(dev_priv, power_well);
> > @@ -3049,7 +3048,7 @@ static void intel_power_domains_dump_info(struct 
> > drm_i915_private *dev_priv)
> > for_each_power_domain(domain, power_well->domains)
> > DRM_DEBUG_DRIVER("  %-23s %d\n",
> >  intel_display_power_domain_str(domain),
> > -
> > power_domains->domain_use_count[domain]);
> > +
> > atomic_read(_domains->domain_use_count[domain]));
> > }
> >  }
> >  
> > @@ -3092,7 +3091,7 @@ void intel_power_domains_verify_state(struct 
> > drm_i915_private *dev_priv)
> >  
> > domains_count = 0;
> > for_each_power_domain(domain, power_well->domains)
> > -   domains_count += 
> > power_domains->domain_use_count[domain];
> > +   domains_count += 
> > atomic_read(_domains->domain_use_count[domain]);
> >  
> > if (power_well->count != domains_count) {
> > DRM_ERROR("power well %s refcount/domain refcount 
> > mismatch "
> 
> I can imagine this will start failing really badly. The previous code assumed 
> that
> everything is protected by power_domains->lock, and now this changes makes it 
> no
> longer the case..
> 

This won't fail until the next patch where it is read outside of the
mutex. And that patch reads these values within the new spin_lock. I was
trying to split the changes so that the next patch does not become too
heavy.

> I see the rest of the code changes things even more, but it would be better 
> if the
> locking rework was done in a single patch, and not bolted on..
> 
I see your point, I can squash them together.

> And instead 

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

[Sagar Arun Kamble]

On 12/7/2017 6:18 AM, Robert Bragg wrote:



On Wed, Nov 15, 2017 at 12:13 PM, Sagar Arun Kamble 
> wrote:


We can compute system time corresponding to GPU timestamp by taking a
reference point (CPU monotonic time, GPU timestamp) and then adding
delta time computed using timecounter/cyclecounter support in kernel.
We have to configure cyclecounter with the GPU timestamp frequency.
Earlier approach that was based on cross-timestamp is not needed. It
was being used to approximate the frequency based on invalid
assumptions
(possibly drift was being seen in the time due to precision issue).
The precision of time from GPU clocks is already in ns and timecounter
takes care of it as verified over variable durations.


Hi Sagar,

I have some doubts about this analysis...

The intent behind Sourab's original approach was to be able to 
determine the frequency at runtime empirically because the constants 
we have aren't particularly accurate. Without a perfectly stable 
frequency that's known very precisely then an interpolated correlation 
will inevitably drift. I think the nature of HW implies we can't 
expect to have either of those. Then the general idea had been to try 
and use existing kernel infrastructure for a problem which isn't 
unique to GPU clocks.

Hi Robert,

Testing on SKL shows timestamps drift only about 10us for sampling done 
in kernel for about 30min time.
Verified with changes from 
https://github.com/sakamble/i915-timestamp-support/commits/drm-tip
Note that since we are sampling counter in debugfs, there is likely 
overhead of read that is adding to drift so adjustment might be needed.
But with OA reports we just have to worry about initial timecounter 
setup where we need accurate pair of system time and GPU timestamp clock 
counts.
I think timestamp clock is highly stable and we don't need logic to 
determine frequency at runtime. Will try to get confirmation from HW 
team as well.


If we need to determine the frequency, Sourab's approach needs to refined as
1. It can be implemented entirely in i915 because what we need is pair 
of system time and gpu clocks over different durations.
2. crosstimestamp framework usage in that approach is incorrect as 
ideally we should be sending ART counter and GPU counter. Instead we were

hacking to send the TSC clock.
Quoting Thomas from  https://patchwork.freedesktop.org/patch/144298/
get_device_system_crosststamp() is for timestamps taken via a clock 
which is directly correlated with the timekeeper clocksource.


ART and TSC are correlated via: TSC = (ART * scale) + offset
get_device_system_crosststamp() invokes the device function which reads 
ART, which is converted to CLOCK_MONOTONIC_RAW by the conversion above,
and then uses interpolation to map the CLOCK_MONOTONIC_RAW value to 
CLOCK_MONOTONIC.
The device function does not know anything about TSC. All it knows about 
is ART.


I am not aware if GPU timestamp clock is correlated with TSC like ART 
for ethernet drivers and if i915 can read ART like ethernet drivers.
3. I have seen precision issues in the calculations in 
i915_perf_clock_sync_work and usage of MONO_RAW which might jump time.


That's not to say that a more limited, simpler solution based on 
frequent re-correlation wouldn't be more than welcome if tracking an 
accurate frequency is too awkward for now
Adjusting timecounter time can be another option if we confirm that GPU 
timestamp frequency is stable.

, but I think some things need to be considered in that case:

- It would be good to quantify the kind of drift seen in practice to 
know how frequently it's necessary to re-synchronize. It sounds like 
you've done this ("as verified over variable durations") so I'm 
curious what kind of drift you saw. I'd imagine you would see a 
significant drift over, say, one second and it might not take much 
longer for the drift to even become clearly visible to the user when 
plotted in a UI. For reference I once updated the arb_timer_query test 
in piglit to give some insight into this drift 
(https://lists.freedesktop.org/archives/piglit/2016-September/020673.html) 
and at least from what I wrote back then it looks like I was seeing a 
drift of a few milliseconds per second on SKL. I vaguely recall it 
being much worse given the frequency constants we had for Haswell.


On SKL I have seen very small drift of less than 10us over a period of 
30 minutes.
Verified with changes from 
https://github.com/sakamble/i915-timestamp-support/commits/drm-tip


36bit counter will overflow in about 95min at 12mhz and timecounter 
framework considers
counter value with delta from timecounter init of more than half of 
total time covered by counter as time in the past so current approach 
works for less than 45min.
Will need to add overflow watchdog support like other drivers which just 
reinitializes timecounter prior to 45min.


- What guarantees will 

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

[Sagar Arun Kamble]

On 12/22/2017 10:45 AM, Sagar Arun Kamble wrote:




On 12/7/2017 1:32 AM, Lionel Landwerlin wrote:
I've put together some trival IGT tests : 
https://github.com/djdeath/intel-gpu-tools/commits/wip/djdeath/cpu-timestamps
With a few changes which I pointed in the review : 
https://github.com/djdeath/linux/commit/d0e4cf4d3f464491b4ffe97d112284d1ce73656d


Put together it seems to work relatively well.
There is still a small drift happening between the 2 timestamps. I've 
noticed over a 160ms of OA reports, there is a accumulated difference 
of ~35us between the GPU timestamp and cpu timestamps.
I may be doing something wrong with the scaling in the tests, or 
maybe there is an issue in the kernel, or both.
Went through the testcase. scaled_gpu_delta calculation is same as 
what timecounter does in kernel for calculating system_time corresponding
to gpu timestamp hence we don't see much of delta between these two 
times/time deltas.
Ideally we should be testing the system time delta by sampling system 
time and gpu timestamp atomically (which isn't feasible unless we do 
some precise adjustments)
I have attempted to check these two times/delta by sampling them in 
debugfs and reading over variable periods manually and checking the delta.

https://github.com/sakamble/i915-timestamp-support/commit/03be3056752d7b05a02cd01f5c20b3fcfcf18395

It is showing that delta is less than 10us in most cases for 30min and 
occasionally around 20-30us. Again this delta might be because of 
initial time setting as well.
timecounter initializing system time and gpu clocks as pair should be 
highly accurate for which I have currently taken 350us start offset.


I think gpu timestamp clock is highly stable as seen in my testing on 
SKL. I think this clock is used for calculations in GuC too so will
be good to get confirmation about the stability of this clock from 
them and HW team.


   systemd-udevd-169   [001]  3.035812: i915_driver_load: sys 
start time: 1512308011156099790


   systemd-udevd-169   [001] d... 3.036012: 
i915_cyclecounter_read: 52025098974


 cat-1654  [001]     52.407957: 
i915_cyclecounter_read: 52617562292


 cat-1654  [001]     52.407958: i915_timestamp_info: 
sys time: 1512308060527894638


 cat-1654  [001]     52.407958: i915_timestamp_info: 
ts: 52617562292 device time: 1512308060528043050


 cat-1684  [001]    177.239733: 
i915_cyclecounter_read: 54115543581


 cat-1684  [001]    177.239736: i915_timestamp_info: 
sys time: 151230818535902


 cat-1684  [001]    177.239737: i915_timestamp_info: 
ts: 54115543581 device time: 1512308185359817372


 cat-1693  [001]    329.820374: 
i915_cyclecounter_read: 55946511277


 cat-1693  [001]    329.820377: i915_timestamp_info: 
sys time: 1512308337940301732


 cat-1693  [001]    329.820378: i915_timestamp_info: 
ts: 55946511277 device time: 1512308337940458996



samples (177, 329) = 6494ns>



 cat-1702  [001]    506.980313: 
i915_cyclecounter_read: 58072430542


 cat-1702  [001]    506.980315: i915_timestamp_info: 
sys time: 1512308515100233102


 cat-1702  [001]    506.980317: i915_timestamp_info: 
ts: 58072430542 device time: 1512308515100398084


samples (329, 506) = 6494ns>



Fixing typo here:
samples (329, 506) = 7718ns>


I'll build the GPUTop parts and see if the results make sense.

Thanks!,

-
Lionel

On 15/11/17 12:13, Sagar Arun Kamble wrote:

We can compute system time corresponding to GPU timestamp by taking a
reference point (CPU monotonic time, GPU timestamp) and then adding
delta time computed using timecounter/cyclecounter support in kernel.
We have to configure cyclecounter with the GPU timestamp frequency.
Earlier approach that was based on cross-timestamp is not needed. It
was being used to approximate the frequency based on invalid 
assumptions

(possibly drift was being seen in the time due to precision issue).
The precision of time from GPU clocks is already in ns and timecounter
takes care of it as verified over variable durations.

This series adds base timecounter/cyclecounter changes and changes to
get GPU and CPU timestamps in OA samples.

Sagar Arun Kamble (1):
   drm/i915/perf: Add support to correlate GPU timestamp with system 
time


Sourab Gupta (3):
   drm/i915/perf: Add support for collecting 64 bit timestamps with OA
 reports
   drm/i915/perf: Extract raw GPU timestamps from OA reports
   drm/i915/perf: Send system clock monotonic time in perf samples

  drivers/gpu/drm/i915/i915_drv.h  |  11 
  drivers/gpu/drm/i915/i915_perf.c | 124 
++-

  drivers/gpu/drm/i915/i915_reg.h  |   6 ++
  include/uapi/drm/i915_drm.h  |  14 +
  4 files changed, 154 insertions(+), 1 deletion(-)







___
Intel-gfx mailing list

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

[Sagar Arun Kamble]

On 12/7/2017 1:32 AM, Lionel Landwerlin wrote:
I've put together some trival IGT tests : 
https://github.com/djdeath/intel-gpu-tools/commits/wip/djdeath/cpu-timestamps
With a few changes which I pointed in the review : 
https://github.com/djdeath/linux/commit/d0e4cf4d3f464491b4ffe97d112284d1ce73656d


Put together it seems to work relatively well.
There is still a small drift happening between the 2 timestamps. I've 
noticed over a 160ms of OA reports, there is a accumulated difference 
of ~35us between the GPU timestamp and cpu timestamps.
I may be doing something wrong with the scaling in the tests, or maybe 
there is an issue in the kernel, or both.
Went through the testcase. scaled_gpu_delta calculation is same as what 
timecounter does in kernel for calculating system_time corresponding
to gpu timestamp hence we don't see much of delta between these two 
times/time deltas.
Ideally we should be testing the system time delta by sampling system 
time and gpu timestamp atomically (which isn't feasible unless we do 
some precise adjustments)
I have attempted to check these two times/delta by sampling them in 
debugfs and reading over variable periods manually and checking the delta.

https://github.com/sakamble/i915-timestamp-support/commit/03be3056752d7b05a02cd01f5c20b3fcfcf18395

It is showing that delta is less than 10us in most cases for 30min and 
occasionally around 20-30us. Again this delta might be because of 
initial time setting as well.
timecounter initializing system time and gpu clocks as pair should be 
highly accurate for which I have currently taken 350us start offset.


I think gpu timestamp clock is highly stable as seen in my testing on 
SKL. I think this clock is used for calculations in GuC too so will
be good to get confirmation about the stability of this clock from them 
and HW team.


   systemd-udevd-169   [001]  3.035812: i915_driver_load: sys 
start time: 1512308011156099790


   systemd-udevd-169   [001] d... 3.036012: i915_cyclecounter_read: 
52025098974


 cat-1654  [001]     52.407957: i915_cyclecounter_read: 
52617562292


 cat-1654  [001]     52.407958: i915_timestamp_info: 
sys time: 1512308060527894638


 cat-1654  [001]     52.407958: i915_timestamp_info: 
ts: 52617562292 device time: 1512308060528043050


 cat-1684  [001]    177.239733: i915_cyclecounter_read: 
54115543581


 cat-1684  [001]    177.239736: i915_timestamp_info: 
sys time: 151230818535902


 cat-1684  [001]    177.239737: i915_timestamp_info: 
ts: 54115543581 device time: 1512308185359817372


 cat-1693  [001]    329.820374: i915_cyclecounter_read: 
55946511277


 cat-1693  [001]    329.820377: i915_timestamp_info: 
sys time: 1512308337940301732


 cat-1693  [001]    329.820378: i915_timestamp_info: 
ts: 55946511277 device time: 1512308337940458996



samples (177, 329) = 6494ns>



 cat-1702  [001]    506.980313: i915_cyclecounter_read: 
58072430542


 cat-1702  [001]    506.980315: i915_timestamp_info: 
sys time: 1512308515100233102


 cat-1702  [001]    506.980317: i915_timestamp_info: 
ts: 58072430542 device time: 1512308515100398084


samples (329, 506) = 6494ns>




I'll build the GPUTop parts and see if the results make sense.

Thanks!,

-
Lionel

On 15/11/17 12:13, Sagar Arun Kamble wrote:

We can compute system time corresponding to GPU timestamp by taking a
reference point (CPU monotonic time, GPU timestamp) and then adding
delta time computed using timecounter/cyclecounter support in kernel.
We have to configure cyclecounter with the GPU timestamp frequency.
Earlier approach that was based on cross-timestamp is not needed. It
was being used to approximate the frequency based on invalid assumptions
(possibly drift was being seen in the time due to precision issue).
The precision of time from GPU clocks is already in ns and timecounter
takes care of it as verified over variable durations.

This series adds base timecounter/cyclecounter changes and changes to
get GPU and CPU timestamps in OA samples.

Sagar Arun Kamble (1):
   drm/i915/perf: Add support to correlate GPU timestamp with system 
time


Sourab Gupta (3):
   drm/i915/perf: Add support for collecting 64 bit timestamps with OA
 reports
   drm/i915/perf: Extract raw GPU timestamps from OA reports
   drm/i915/perf: Send system clock monotonic time in perf samples

  drivers/gpu/drm/i915/i915_drv.h  |  11 
  drivers/gpu/drm/i915/i915_perf.c | 124 
++-

  drivers/gpu/drm/i915/i915_reg.h  |   6 ++
  include/uapi/drm/i915_drm.h  |  14 +
  4 files changed, 154 insertions(+), 1 deletion(-)





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

Re: [Intel-gfx] [PULL] more gvt-next for 4.16

[Zhenyu Wang]

On 2017.12.21 19:07:07 -0800, Rodrigo Vivi wrote:
> On Fri, Dec 22, 2017 at 02:43:06AM +, Zhenyu Wang wrote:
> > 
> > Hi,
> > 
> > Here's last gvt-next pull for 4.16 merge window. I need to backmerge
> > once for one i915 param change to resolve patch dependence. This includes
> > mmio switch optimization, cleanups for write protect handler and our
> > i915_reg_t vs. offset usage.
> > 
> > thanks
> > --
> > The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee:
> > 
> >   drm/i915: Update DRIVER_DATE to 20171214 (2017-12-14 12:10:02 -0800)
> > 
> > are available in the Git repository at:
> > 
> >   https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
> > 
> > for you to fetch changes up to 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7:
> > 
> >   drm/i915/gvt: move write protect handler out of mmio emulation function 
> > (2017-12-21 11:03:27 +0800)
> > 
> > 
> > gvt-next-2017-12-22:
> > 
> > - more mmio switch optimization (Weinan)
> > - cleanup i915_reg_t vs. offset usage (Zhenyu)
> > - move write protect handler out of mmio handler (Zhenyu)
> > 
> > 
> > Weinan Li (4):
> >   drm/i915/gvt: refine trace_render_mmio
> >   drm/i915/gvt: optimize for vGPU mmio switch
> >   drm/i915/gvt: refine mocs save restore policy
> >   drm/i915/gvt: load host render mocs once in mocs switch
> > 
> > Xiaolin Zhang (1):
> >   drm/i915/gvt: Fix pipe A enable as default for vgpu
> > 
> > Zhenyu Wang (4):
> >   Merge tag 'drm-intel-next-2017-12-14' into gvt-next
> >   drm/i915/gvt: always use i915_reg_t for MMIO handler definition
> >   drm/i915/gvt: cleanup usage for typed mmio reg vs. offset
> >   drm/i915/gvt: move write protect handler out of mmio emulation 
> > function
> 
> dim apply-pull drm-intel-next-queued
> 
> https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
> From https://github.com/intel/gvt-linux
>  * tag gvt-next-2017-12-22 -> FETCH_HEAD
> dim: ERROR: 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7 is lacking mandatory 
> review, aborting
>

Looks dim doesn't allow committer == author without ack or r-b? Is this
really mandatory required? If yes, I will apply this rule for gvt tree as well
and encourage gvt developer to send a-b/r-b mail as looks people more like
to use IM to exchange review comment..

-- 
Open Source Technology Center, Intel ltd.

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


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

Re: [Intel-gfx] [PULL] more gvt-next for 4.16

[Rodrigo Vivi]

On Fri, Dec 22, 2017 at 02:43:06AM +, Zhenyu Wang wrote:
> 
> Hi,
> 
> Here's last gvt-next pull for 4.16 merge window. I need to backmerge
> once for one i915 param change to resolve patch dependence. This includes
> mmio switch optimization, cleanups for write protect handler and our
> i915_reg_t vs. offset usage.
> 
> thanks
> --
> The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee:
> 
>   drm/i915: Update DRIVER_DATE to 20171214 (2017-12-14 12:10:02 -0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
> 
> for you to fetch changes up to 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7:
> 
>   drm/i915/gvt: move write protect handler out of mmio emulation function 
> (2017-12-21 11:03:27 +0800)
> 
> 
> gvt-next-2017-12-22:
> 
> - more mmio switch optimization (Weinan)
> - cleanup i915_reg_t vs. offset usage (Zhenyu)
> - move write protect handler out of mmio handler (Zhenyu)
> 
> 
> Weinan Li (4):
>   drm/i915/gvt: refine trace_render_mmio
>   drm/i915/gvt: optimize for vGPU mmio switch
>   drm/i915/gvt: refine mocs save restore policy
>   drm/i915/gvt: load host render mocs once in mocs switch
> 
> Xiaolin Zhang (1):
>   drm/i915/gvt: Fix pipe A enable as default for vgpu
> 
> Zhenyu Wang (4):
>   Merge tag 'drm-intel-next-2017-12-14' into gvt-next
>   drm/i915/gvt: always use i915_reg_t for MMIO handler definition
>   drm/i915/gvt: cleanup usage for typed mmio reg vs. offset
>   drm/i915/gvt: move write protect handler out of mmio emulation function

dim apply-pull drm-intel-next-queued

https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
From https://github.com/intel/gvt-linux
 * tag gvt-next-2017-12-22 -> FETCH_HEAD
dim: ERROR: 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7 is lacking mandatory 
review, aborting

> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c   |  39 +-
>  drivers/gpu/drm/i915/gvt/display.c  |  81 ++--
>  drivers/gpu/drm/i915/gvt/edid.c |  22 +-
>  drivers/gpu/drm/i915/gvt/fb_decoder.c   |  30 +-
>  drivers/gpu/drm/i915/gvt/gtt.c  |  37 +-
>  drivers/gpu/drm/i915/gvt/gtt.h  |   3 +
>  drivers/gpu/drm/i915/gvt/gvt.c  |   1 +
>  drivers/gpu/drm/i915/gvt/gvt.h  |  33 +-
>  drivers/gpu/drm/i915/gvt/handlers.c | 750 
> 
>  drivers/gpu/drm/i915/gvt/kvmgt.c|   4 +-
>  drivers/gpu/drm/i915/gvt/mmio.c |  57 +--
>  drivers/gpu/drm/i915/gvt/mmio.h |   7 -
>  drivers/gpu/drm/i915/gvt/mmio_context.c | 238 +-
>  drivers/gpu/drm/i915/gvt/trace.h|  15 +-
>  drivers/gpu/drm/i915/gvt/vgpu.c |  24 +-
>  15 files changed, 675 insertions(+), 666 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

Re: [Intel-gfx] [PATCH v2] drm/syncobj: Stop reusing the same struct file for all syncobj -> fd

[Dave Airlie]

On 21 December 2017 at 19:28, Chris Wilson  wrote:
> The vk cts test:
> dEQP-VK.api.external.semaphore.opaque_fd.export_multiple_times_temporary
>
> triggers a lot of
> VFS: Close: file count is 0
>
> Dave pointed out that clearing the syncobj->file from
> drm_syncobj_file_release() was sufficient to silence the test, but that
> opens a can of worm since we assumed that the syncobj->file was never
> unset. So stop trying to reuse the same struct file for every fd pointing
> to the drm_syncobj, and allocate one file for each fd instead.
>
> v2: Fixup return handling of drm_syncobj_fd_to_handle
>
> Reported-by: Dave Airlie 
> Testcase: igt/syncobj_base/test-create-close-twice
> Signed-off-by: Chris Wilson 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_syncobj.c | 78 
> ---
>  include/drm/drm_syncobj.h |  4 ---
>  2 files changed, 29 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 131695915acd..c235046c9ac2 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -399,23 +399,6 @@ static const struct file_operations 
> drm_syncobj_file_fops = {
> .release = drm_syncobj_file_release,
>  };
>
> -static int drm_syncobj_alloc_file(struct drm_syncobj *syncobj)
> -{
> -   struct file *file = anon_inode_getfile("syncobj_file",
> -  _syncobj_file_fops,
> -  syncobj, 0);
> -   if (IS_ERR(file))
> -   return PTR_ERR(file);
> -
> -   drm_syncobj_get(syncobj);
> -   if (cmpxchg(>file, NULL, file)) {
> -   /* lost the race */
> -   fput(file);
> -   }
> -
> -   return 0;
> -}
> -
>  /**
>   * drm_syncobj_get_fd - get a file descriptor from a syncobj
>   * @syncobj: Sync object to export
> @@ -427,21 +410,24 @@ static int drm_syncobj_alloc_file(struct drm_syncobj 
> *syncobj)
>   */
>  int drm_syncobj_get_fd(struct drm_syncobj *syncobj, int *p_fd)
>  {
> -   int ret;
> +   struct file *file;
> int fd;
>
> fd = get_unused_fd_flags(O_CLOEXEC);
> if (fd < 0)
> return fd;
>
> -   if (!syncobj->file) {
> -   ret = drm_syncobj_alloc_file(syncobj);
> -   if (ret) {
> -   put_unused_fd(fd);
> -   return ret;
> -   }
> +   file = anon_inode_getfile("syncobj_file",
> + _syncobj_file_fops,
> + syncobj, 0);
> +   if (IS_ERR(file)) {
> +   put_unused_fd(fd);
> +   return PTR_ERR(file);
> }
> -   fd_install(fd, syncobj->file);
> +
> +   drm_syncobj_get(syncobj);
> +   fd_install(fd, file);
> +
> *p_fd = fd;
> return 0;
>  }
> @@ -461,32 +447,22 @@ static int drm_syncobj_handle_to_fd(struct drm_file 
> *file_private,
> return ret;
>  }
>
> -static struct drm_syncobj *drm_syncobj_fdget(int fd)
> -{
> -   struct file *file = fget(fd);
> -
> -   if (!file)
> -   return NULL;
> -   if (file->f_op != _syncobj_file_fops)
> -   goto err;
> -
> -   return file->private_data;
> -err:
> -   fput(file);
> -   return NULL;
> -};
> -
>  static int drm_syncobj_fd_to_handle(struct drm_file *file_private,
> int fd, u32 *handle)
>  {
> -   struct drm_syncobj *syncobj = drm_syncobj_fdget(fd);
> +   struct drm_syncobj *syncobj;
> +   struct file *file;
> int ret;
>
> -   if (!syncobj)
> +   file = fget(fd);
> +   if (!file)
> return -EINVAL;
>
> -   /* take a reference to put in the idr */
> -   drm_syncobj_get(syncobj);
> +   if (file->f_op != _syncobj_file_fops) {
> +   ret = -EINVAL;
> +   goto out_file;
> +   }
> +   syncobj = file->private_data;
>
> idr_preload(GFP_KERNEL);
> spin_lock(_private->syncobj_table_lock);
> @@ -494,12 +470,16 @@ static int drm_syncobj_fd_to_handle(struct drm_file 
> *file_private,
> spin_unlock(_private->syncobj_table_lock);
> idr_preload_end();
>
> -   if (ret < 0) {
> -   fput(syncobj->file);
> -   return ret;
> +   if (ret > 0) {
> +   /* take a reference for the idr */
> +   drm_syncobj_get(syncobj);
> +   *handle = ret;
> +   ret = 0;

I can't see getting the refcount after adding it to the idr is safe here.

Entering this function we could have just the fd reference to the syncobj,
We add it to the dir, and someone could call syncobj_destroy on the
handle randomly (i.e. without us having 

Re: [Intel-gfx] Accelerated read from WC mem (i915_memcpy_from_wc()) may not work in virtualization world

[Du, Changbin]

On Thu, Dec 21, 2017 at 10:56:38AM +, Chris Wilson wrote:
> Quoting Du, Changbin (2017-12-21 09:52:16)
> > Hi Chris,
> > Our QA reported a problem caused by movntdqa instructions. Currently, the 
> > KVM
> > hypervisor doesn't support VEX-prefix instructions emulation. If users 
> > passthrough
> > a GPU to guest with vfio option 'x-no-mmap=on', then all access to the BARs 
> > will
> > be trapped and emulated. The KVM hypervisor would raise an inertal error to 
> > qemu
> > which cause the guest killed. (Since 'movntdqa' ins is not supported.)
> > 
> > One possible solution is that disable this optimization at 
> > i915_memcpy_init_early.
> > This require us to identify the CPUID to check if it is running in guest 
> > mode.
> 
> Is this mode not detected by intel_vgpu_active() ?
>
Here intel_vgpu_active() is not ready to use. i915_memcpy_init_early is executed
before MMIO mapped.

> If we need to disable movntdqa, we need to disable it. But not by
> directly checking CPUID, it should be already decoded into a cpu feature
> flag -- assuming we need more than intel_vgpu_active and possibly
> rearranging the init order.
> -Chris

Yes, for Intel CPU, Bit 31 of ECX of CPUID leaf 0x1 is Hypervisor Present Bit.
So I will write a patch to disable it in hypervisor guest if you don't have
objections. Thanks.

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

[Intel-gfx] [PULL] more gvt-next for 4.16

[Zhenyu Wang]

Hi,

Here's last gvt-next pull for 4.16 merge window. I need to backmerge
once for one i915 param change to resolve patch dependence. This includes
mmio switch optimization, cleanups for write protect handler and our
i915_reg_t vs. offset usage.

thanks
--
The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee:

  drm/i915: Update DRIVER_DATE to 20171214 (2017-12-14 12:10:02 -0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22

for you to fetch changes up to 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7:

  drm/i915/gvt: move write protect handler out of mmio emulation function 
(2017-12-21 11:03:27 +0800)


gvt-next-2017-12-22:

- more mmio switch optimization (Weinan)
- cleanup i915_reg_t vs. offset usage (Zhenyu)
- move write protect handler out of mmio handler (Zhenyu)


Weinan Li (4):
  drm/i915/gvt: refine trace_render_mmio
  drm/i915/gvt: optimize for vGPU mmio switch
  drm/i915/gvt: refine mocs save restore policy
  drm/i915/gvt: load host render mocs once in mocs switch

Xiaolin Zhang (1):
  drm/i915/gvt: Fix pipe A enable as default for vgpu

Zhenyu Wang (4):
  Merge tag 'drm-intel-next-2017-12-14' into gvt-next
  drm/i915/gvt: always use i915_reg_t for MMIO handler definition
  drm/i915/gvt: cleanup usage for typed mmio reg vs. offset
  drm/i915/gvt: move write protect handler out of mmio emulation function

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  39 +-
 drivers/gpu/drm/i915/gvt/display.c  |  81 ++--
 drivers/gpu/drm/i915/gvt/edid.c |  22 +-
 drivers/gpu/drm/i915/gvt/fb_decoder.c   |  30 +-
 drivers/gpu/drm/i915/gvt/gtt.c  |  37 +-
 drivers/gpu/drm/i915/gvt/gtt.h  |   3 +
 drivers/gpu/drm/i915/gvt/gvt.c  |   1 +
 drivers/gpu/drm/i915/gvt/gvt.h  |  33 +-
 drivers/gpu/drm/i915/gvt/handlers.c | 750 
 drivers/gpu/drm/i915/gvt/kvmgt.c|   4 +-
 drivers/gpu/drm/i915/gvt/mmio.c |  57 +--
 drivers/gpu/drm/i915/gvt/mmio.h |   7 -
 drivers/gpu/drm/i915/gvt/mmio_context.c | 238 +-
 drivers/gpu/drm/i915/gvt/trace.h|  15 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |  24 +-
 15 files changed, 675 insertions(+), 666 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


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

Re: [Intel-gfx] Accelerated read from WC mem (i915_memcpy_from_wc()) may not work in virtualization world

[Du, Changbin]

On Thu, Dec 21, 2017 at 10:58:38AM +, Chris Wilson wrote:
> Quoting Du, Changbin (2017-12-21 09:52:16)
> > Hi Chris,
> > Our QA reported a problem caused by movntdqa instructions. Currently, the 
> > KVM
> > hypervisor doesn't support VEX-prefix instructions emulation. If users 
> > passthrough
> > a GPU to guest with vfio option 'x-no-mmap=on', then all access to the BARs 
> > will
> > be trapped and emulated. The KVM hypervisor would raise an inertal error to 
> > qemu
> > which cause the guest killed. (Since 'movntdqa' ins is not supported.)
> > 
> > One possible solution is that disable this optimization at 
> > i915_memcpy_init_early.
> > This require us to identify the CPUID to check if it is running in guest 
> > mode.
> 
> But do note we are already checking the CPUID/cpuflags for support; is
> the hv not correcting them?
> -Chris

The CPU does support SSE, but just the KVM ins emulator doesn't. So it is not a
problem if the movntdqa runs on HW directly. But if it is emulated, then run
into failure.


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

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Manasi Navare]

On Thu, Dec 21, 2017 at 05:32:43PM -0800, Manasi Navare wrote:
> On Thu, Dec 21, 2017 at 05:06:22PM -0800, Pandiyan, Dhinakaran wrote:
> > On Thu, 2017-12-21 at 10:52 -0800, Manasi Navare wrote:
> > > On Wed, Dec 20, 2017 at 10:36:24PM -0800, Dhinakaran Pandiyan wrote:
> > > > Occasionally there are LINK_ADDRESS sideband messages timing out with 
> > > > the
> > > > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. 
> > > > These
> > > > failures lead to the display not coming up on boot. Power cycling the 
> > > > port
> > > > corresponding to the MST monitor's branch device and resending the 
> > > > message
> > > > fixes the issue. I am not entirely sure if this is specific to my setup.
> > > > However, as the power state is toggled conditionally on LINK_ADDRESS
> > > > timeouts, this should not affect the working cases.
> > > > 
> > > 
> > > > Cc: Lyude 
> > > > Cc: Dave Airlie 
> > > > Cc: Jani Nikula 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> > > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index 70dcfa58d3c2..e06defcdcf18 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > > > drm_dp_mst_topology_mgr *mgr,
> > > > int len;
> > > > struct drm_dp_sideband_msg_tx *txmsg;
> > > > int ret;
> > > > +   int attempts = 5;
> > > >
> > > 
> > > Does the spec say this should be retried 5 times or is this just an
> > > experimental number?
> > 
> > The spec. does not say how many times to retry, but it does say the
> > source is responsible for retrying. 
> > 
> > > We have such magical numbers for retries all over the DP code and that 
> > > makes debugging
> > > harder later, so atleast a comment of why its 5 would help.
> >
>  
> > Takes about 22 seconds from boot to complete 5 retries on my SKL, I
> > think that's enough trying from the kernel side before pulling out the
> > DP cable makes sense :)
> >
> 
> It still appears to be a magical number so better to comment it properly.
> Helps in the debug
>  
> > >   
> > > > -   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > > > +retry: txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > > > if (!txmsg)
> > > > return;
> > > >  
> > > > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > > > drm_dp_mst_topology_mgr *mgr,
> > > > }
> > > > (*mgr->cbs->hotplug)(mgr);
> > > > }
> > > > +   } else if (attempts--) {
> > > 
> > > This should be --attempts if you want the total attempts to be 5
> > I don't.
> 
> Yes the variable attempts is misleading in that case. Probably call it "tries"
>
I meant retries..

Manasi 
> Manasi
> 
> > > 
> > > Manasi
> > > 
> > > > +   kfree(txmsg);
> > > > +   drm_dp_send_power_updown_phy(mstb->mgr, 
> > > > mstb->port_parent,
> > > > +false);
> > > > +   drm_dp_send_power_updown_phy(mstb->mgr, 
> > > > mstb->port_parent,
> > > > +true);
> > > > +   DRM_DEBUG_KMS("link address failed %d, retrying\n", 
> > > > ret);
> > > > +   goto retry;
> > > > } else {
> > > > mstb->link_address_sent = false;
> > > > -   DRM_DEBUG_KMS("link address failed %d\n", ret);
> > > > +   DRM_DEBUG_KMS("link address failed %d, giving up\n", 
> > > > ret);
> > > > }
> > > >  
> > > > kfree(txmsg);
> > > > -- 
> > > > 2.11.0
> > > > 
> > > > ___
> > > > dri-devel mailing list
> > > > dri-de...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Manasi Navare]

On Thu, Dec 21, 2017 at 05:06:22PM -0800, Pandiyan, Dhinakaran wrote:
> On Thu, 2017-12-21 at 10:52 -0800, Manasi Navare wrote:
> > On Wed, Dec 20, 2017 at 10:36:24PM -0800, Dhinakaran Pandiyan wrote:
> > > Occasionally there are LINK_ADDRESS sideband messages timing out with the
> > > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> > > failures lead to the display not coming up on boot. Power cycling the port
> > > corresponding to the MST monitor's branch device and resending the message
> > > fixes the issue. I am not entirely sure if this is specific to my setup.
> > > However, as the power state is toggled conditionally on LINK_ADDRESS
> > > timeouts, this should not affect the working cases.
> > > 
> > 
> > > Cc: Lyude 
> > > Cc: Dave Airlie 
> > > Cc: Jani Nikula 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 70dcfa58d3c2..e06defcdcf18 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > > drm_dp_mst_topology_mgr *mgr,
> > >   int len;
> > >   struct drm_dp_sideband_msg_tx *txmsg;
> > >   int ret;
> > > + int attempts = 5;
> > >
> > 
> > Does the spec say this should be retried 5 times or is this just an
> > experimental number?
> 
> The spec. does not say how many times to retry, but it does say the
> source is responsible for retrying. 
> 
> > We have such magical numbers for retries all over the DP code and that 
> > makes debugging
> > harder later, so atleast a comment of why its 5 would help.
>
 
> Takes about 22 seconds from boot to complete 5 retries on my SKL, I
> think that's enough trying from the kernel side before pulling out the
> DP cable makes sense :)
>

It still appears to be a magical number so better to comment it properly.
Helps in the debug
 
> >   
> > > - txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > > +retry:   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > >   if (!txmsg)
> > >   return;
> > >  
> > > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > > drm_dp_mst_topology_mgr *mgr,
> > >   }
> > >   (*mgr->cbs->hotplug)(mgr);
> > >   }
> > > + } else if (attempts--) {
> > 
> > This should be --attempts if you want the total attempts to be 5
> I don't.

Yes the variable attempts is misleading in that case. Probably call it "tries"

Manasi

> > 
> > Manasi
> > 
> > > + kfree(txmsg);
> > > + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > > +  false);
> > > + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > > +  true);
> > > + DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> > > + goto retry;
> > >   } else {
> > >   mstb->link_address_sent = false;
> > > - DRM_DEBUG_KMS("link address failed %d\n", ret);
> > > + DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
> > >   }
> > >  
> > >   kfree(txmsg);
> > > -- 
> > > 2.11.0
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Pandiyan, Dhinakaran]

On Thu, 2017-12-21 at 10:52 -0800, Manasi Navare wrote:
> On Wed, Dec 20, 2017 at 10:36:24PM -0800, Dhinakaran Pandiyan wrote:
> > Occasionally there are LINK_ADDRESS sideband messages timing out with the
> > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> > failures lead to the display not coming up on boot. Power cycling the port
> > corresponding to the MST monitor's branch device and resending the message
> > fixes the issue. I am not entirely sure if this is specific to my setup.
> > However, as the power state is toggled conditionally on LINK_ADDRESS
> > timeouts, this should not affect the working cases.
> > 
> 
> > Cc: Lyude 
> > Cc: Dave Airlie 
> > Cc: Jani Nikula 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 70dcfa58d3c2..e06defcdcf18 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > int len;
> > struct drm_dp_sideband_msg_tx *txmsg;
> > int ret;
> > +   int attempts = 5;
> >
> 
> Does the spec say this should be retried 5 times or is this just an
> experimental number?

The spec. does not say how many times to retry, but it does say the
source is responsible for retrying. 

> We have such magical numbers for retries all over the DP code and that makes 
> debugging
> harder later, so atleast a comment of why its 5 would help.

Takes about 22 seconds from boot to complete 5 retries on my SKL, I
think that's enough trying from the kernel side before pulling out the
DP cable makes sense :)

>   
> > -   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > +retry: txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > if (!txmsg)
> > return;
> >  
> > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > }
> > (*mgr->cbs->hotplug)(mgr);
> > }
> > +   } else if (attempts--) {
> 
> This should be --attempts if you want the total attempts to be 5
I don't.
> 
> Manasi
> 
> > +   kfree(txmsg);
> > +   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > +false);
> > +   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > +true);
> > +   DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> > +   goto retry;
> > } else {
> > mstb->link_address_sent = false;
> > -   DRM_DEBUG_KMS("link address failed %d\n", ret);
> > +   DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
> > }
> >  
> > kfree(txmsg);
> > -- 
> > 2.11.0
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Pandiyan, Dhinakaran]

On Thu, 2017-12-21 at 08:53 +0200, Jani Nikula wrote:
> On Wed, 20 Dec 2017, Dhinakaran Pandiyan  
> wrote:
> > Occasionally there are LINK_ADDRESS sideband messages timing out with the
> > Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> > failures lead to the display not coming up on boot. Power cycling the port
> > corresponding to the MST monitor's branch device and resending the message
> > fixes the issue. I am not entirely sure if this is specific to my setup.
> > However, as the power state is toggled conditionally on LINK_ADDRESS
> > timeouts, this should not affect the working cases.
> 
> With stuff like this, I always wonder if catering for a failing setup
> blocks us from improving working setups, because once we add this, we
> can't regress it. For example, is there a valid scenario where we'd want
> to fail fast here, instead of retrying?

Link address failure would result in not probing a branch device that
already has been detected. I guess the fail fast case will be applicable
if the said device was not really present but the parent branch told us
otherwise.
 
> 
> Some nits below.
> 
> > Cc: Lyude 
> > Cc: Dave Airlie 
> > Cc: Jani Nikula 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 70dcfa58d3c2..e06defcdcf18 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > int len;
> > struct drm_dp_sideband_msg_tx *txmsg;
> > int ret;
> > +   int attempts = 5;
> >  
> > -   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > +retry: txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > if (!txmsg)
> > return;
> >  
> > @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > }
> > (*mgr->cbs->hotplug)(mgr);
> > }
> > +   } else if (attempts--) {
> 
> You'll end up doing (attempts + 1) attempts, including the first one.
Yeah, that is what I intended to do :) I renamed it from 'retry' to
'attempt' at the last moment, which made it a bit confusing I suppose.


I am stressing testing my setup more to see how well this recovery works
and update this patch.

 

> 
> > +   kfree(txmsg);
> 
> How about memset(txmsg, 0, sizoef(*txmsg)); here and move the goto label
> down to avoid repeated allocations?
Absolutely.

> 
> > +   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > +false);
> > +   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> > +true);
> > +   DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> 
> Maybe do the debug message before you power down/up?
Ok.
> 
> BR,
> Jani.
> 
> > +   goto retry;
> > } else {
> > mstb->link_address_sent = false;
> > -   DRM_DEBUG_KMS("link address failed %d\n", ret);
> > +   DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
> > }
> >  
> > kfree(txmsg);
> 
___
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 [CI,1/7] drm/i915: Move some utility functions to i915_util.h

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/7] drm/i915: Move some utility functions to 
i915_util.h
URL   : https://patchwork.freedesktop.org/series/35700/
State : warning

== Summary ==

Test kms_chv_cursor_fail:
Subgroup pipe-c-256x256-top-edge:
pass   -> SKIP   (shard-hsw)
Test kms_busy:
Subgroup extended-pageflip-hang-newfb-render-a:
pass   -> SKIP   (shard-hsw)
Test pm_rpm:
Subgroup system-suspend:
skip   -> PASS   (shard-hsw) fdo#103375
Test drv_suspend:
Subgroup sysfs-reader:
skip   -> PASS   (shard-hsw)
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-pwrite:
pass   -> SKIP   (shard-hsw)
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-hsw) fdo#104218

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#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218

shard-hswtotal:2712 pass:1533 dwarn:1   dfail:0   fail:10  skip:1168 
time:9356s
shard-snbtotal:2712 pass:1308 dwarn:2   dfail:0   fail:11  skip:1391 
time:8121s
Blacklisted hosts:
shard-apltotal:2712 pass:1685 dwarn:1   dfail:0   fail:25  skip:1001 
time:13787s
shard-kbltotal:2653 pass:1765 dwarn:2   dfail:0   fail:22  skip:863 
time:10677s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait

[Patchwork]

== Series Details ==

Series: igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait
URL   : https://patchwork.freedesktop.org/series/35699/
State : success

== Summary ==

Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103375 +1
Test drv_suspend:
Subgroup sysfs-reader:
skip   -> PASS   (shard-hsw)
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-snb)
skip   -> PASS   (shard-hsw)

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

shard-hswtotal:2613 pass:1476 dwarn:1   dfail:0   fail:10  skip:1124 
time:8882s
shard-snbtotal:2712 pass:1310 dwarn:1   dfail:0   fail:10  skip:1391 
time:8111s
Blacklisted hosts:
shard-apltotal:2712 pass:1685 dwarn:1   dfail:0   fail:24  skip:1001 
time:13861s
shard-kbltotal:2712 pass:1783 dwarn:25  dfail:1   fail:22  skip:881 
time:11126s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] scripts/trace.pl: Optimize event parsing and processing

[John Harrison]

On 12/21/2017 1:34 AM, Tvrtko Ursulin wrote:


On 20/12/2017 23:50, John Harrison wrote:

On 12/20/2017 1:54 AM, Tvrtko Ursulin wrote:
What was the effect of all this on your big traces? I am only 
testing with a smaller one which goes from ~3.3s to ~2.2s. On a 
larger trace it might be non-linear gains due to double sort 
avoidance, unless there will be some other effects to cancel that out.




So with a trace of a shortened gem_exec_nop/basic_sequential, the 
'perf script' output is 439MB and the original trace.pl before any of 
the changes took ~180s. After the 'auto-detect field order' patch, it 
went up to ~201s. With the optimisation patch it is down to ~129s.


However, I am also seeing differences in the HTML output since the 
optimisation patch. The differences aren't massive, just slight 
variations in the times. The structure is all the same, its just that 
the accounting and/or time stamps are out.


For example:
 {id: 1, content: 'Ring079.48% idle34.32% 
busy584.97% runnable2103.60% queued16.18% 
wait200931 batches331.28us avg batch331.38us avg 
engine batch'},

vs
 {id: 1, content: 'Ring079.48% idle34.32% 
busy584.97% runnable2103.60% queued16.18% 
wait200931 batches338.56us avg batch338.56us avg 
engine batch'},


Or:
 {id: 58, key: -210383407,  type: 'range', group: 4, subgroup: 2, 
subgroupOrder: 3, content: '428/3 0 
??? ++ 142us 
(0us)', start: '2017-01-05 21:27:45.352968', end: 
'2017-01-05 21:27:45.353110', style: 'color: white; background-color: 
red;'},

vs
 {id: 58, key: -210383407,  type: 'range', group: 4, subgroup: 2, 
subgroupOrder: 3, content: '428/3 0 
??? ++ 159us 
(0us)', start: '2017-01-05 21:27:45.352968', end: 
'2017-01-05 21:27:45.353127', style: 'color: white; background-color: 
red;'},


I can send you the full output if it is useful and the source logs 
too. The HTML output is about 840KB but as noted, the perf logs are 
hundreds of MBs.


I was able to reproduce it. I think it's down to floating point 
mishandling. Neither the original nor the optimized version were 
correct and both are accumulating error. I'll send an updated patch 
shortly.


Regards,

Tvrtko


The new version with +0.5 gives me exactly the same results as the 
previous edition without the rounding. If I get rid of the int() 
conversion too, I still get the same results.


What does make a difference is if I fix up the broken processing of 
notify traces:

diff --git a/scripts/trace.pl b/scripts/trace.pl
index 8dbd497b..20ae3c78 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -382,14 +382,16 @@ while (<>) {

    next if exists $tp{'ring'} and exists $ignore_ring{$tp{'ring'}};

-   if (exists $tp{'ring'} and exists $tp{'ctx'} and exists 
$tp{'seqno'}) {

+   if (exists $tp{'ring'} and exists $tp{'seqno'}) {
    $ring = $tp{'ring'};
-   $ctx = $tp{'ctx'};
    $seqno = $tp{'seqno'};

-   $orig_ctx = $ctx;
-   $ctx = sanitize_ctx($ctx, $ring);
-   $key = db_key($ring, $ctx, $seqno);
+   if (exists $tp{'ctx'}) {
+   $ctx = $tp{'ctx'};
+   $orig_ctx = $ctx;
+   $ctx = sanitize_ctx($ctx, $ring);
+   $key = db_key($ring, $ctx, $seqno);
+   }
    }

    if ($tp_name eq 'i915:i915_gem_request_wait_begin:') {
@@ -461,7 +463,7 @@ while (<>) {
    }
    $db{$key}->{'duration'} = $db{$key}->{'notify'} - 
$db{$key}->{'start'};
    $db{$key}->{'context-complete-delay'} = 
$db{$key}->{'end'} - $db{$key}->{'notify'};

-   } elsif ($tp_name eq 'intel_engine_notify:') {
+   } elsif ($tp_name eq 'i915:intel_engine_notify:') {
    $notify{global_key($ring, $seqno)} = $time;
    } elsif ($tp_name eq 'i915:intel_gpu_freq_change:') {
    push @freqs, [$prev_freq_ts, $time, $prev_freq] if 
$prev_freq;


With that, I get exactly the same HTML page as before the optimisation 
patch.


John.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/7] drm/i915: Move some utility functions to i915_util.h

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/7] drm/i915: Move some utility functions to 
i915_util.h
URL   : https://patchwork.freedesktop.org/series/35700/
State : success

== Summary ==

Series 35700v1 series starting with [CI,1/7] drm/i915: Move some utility 
functions to i915_util.h
https://patchwork.freedesktop.org/api/1.0/series/35700/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:437s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:385s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:508s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:491s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:482s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:273s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:429s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:480s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:523s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:522s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:560s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:450s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:559s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:411s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:586s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:612s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-pnv-d510 failed to collect. IGT log at Patchwork_7561/fi-pnv-d510/igt.log

c0a64101df89fe312cb41d27e184555400d0e3b9 drm-tip: 2017y-12m-21d-18h-02m-56s UTC 
integration manifest
3bba02510b4b drm/i915: Dump device info at once
7b419d6d548b drm/i915: Add pretty printer for runtime part of intel_device_info
cbe3e3d21526 drm/i915: Update intel_device_info_runtime_init() parameter
2a942dd8491f drm/i915: Move intel_device_info definitions to its own header
9ec679abc27f drm/i915: Move opregion definitions to dedicated intel_opregion.h
64475eb1c409 drm/i915: Move display related definitions to dedicated header
8cd695abb8e0 drm/i915: Move some utility functions to i915_util.h

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dmc: DMC 1.07 for Cannonlake

[Patchwork]

== Series Details ==

Series: drm/i915/dmc: DMC 1.07 for Cannonlake
URL   : https://patchwork.freedesktop.org/series/35651/
State : success

== Summary ==

Test pm_rpm:
Subgroup system-suspend:
skip   -> PASS   (shard-hsw) fdo#103375
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-hsw)
Subgroup sysfs-reader:
skip   -> PASS   (shard-hsw)
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-hsw) fdo#104218

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218

shard-hswtotal:2712 pass:1537 dwarn:1   dfail:0   fail:10  skip:1164 
time:9412s
shard-snbtotal:2712 pass:1307 dwarn:1   dfail:0   fail:12  skip:1392 
time:8048s
Blacklisted hosts:
shard-apltotal:2712 pass:1686 dwarn:1   dfail:0   fail:24  skip:1001 
time:13759s
shard-kbltotal:2653 pass:1753 dwarn:12  dfail:1   fail:23  skip:863 
time:10674s

== Logs ==

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

[Intel-gfx] [CI 1/7] drm/i915: Move some utility functions to i915_util.h

[Chris Wilson]

From: Michal Wajdeczko 

We have dedicated header file for utility functions and macros.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
Acked-by: Rodrigo Vivi 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-2-michal.wajdec...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h   | 15 ---
 drivers/gpu/drm/i915/i915_utils.h | 15 +++
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ca2a61966a23..381696839e2f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -243,21 +243,6 @@ static inline uint_fixed_16_16_t 
add_fixed16_u32(uint_fixed_16_16_t add1,
return clamp_u64_to_fixed16(interm_sum);
 }
 
-static inline const char *yesno(bool v)
-{
-   return v ? "yes" : "no";
-}
-
-static inline const char *onoff(bool v)
-{
-   return v ? "on" : "off";
-}
-
-static inline const char *enableddisabled(bool v)
-{
-   return v ? "enabled" : "disabled";
-}
-
 enum pipe {
INVALID_PIPE = -1,
PIPE_A = 0,
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 8d07764887ec..51dbfe5bb418 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -140,4 +140,19 @@ static inline void drain_delayed_work(struct delayed_work 
*dw)
} while (delayed_work_pending(dw));
 }
 
+static inline const char *yesno(bool v)
+{
+   return v ? "yes" : "no";
+}
+
+static inline const char *onoff(bool v)
+{
+   return v ? "on" : "off";
+}
+
+static inline const char *enableddisabled(bool v)
+{
+   return v ? "enabled" : "disabled";
+}
+
 #endif /* !__I915_UTILS_H */
-- 
2.15.1

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

[Intel-gfx] [CI 2/7] drm/i915: Move display related definitions to dedicated header

[Chris Wilson]

From: Michal Wajdeczko 

We already have separate files for display related code, there
is no reason to keep all display definitions in master header.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
Acked-by: Rodrigo Vivi 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-3-michal.wajdec...@intel.com
[ickle: quieten checkpatch]
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  | 283 +--
 drivers/gpu/drm/i915/intel_display.h | 315 +++
 2 files changed, 316 insertions(+), 282 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_display.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 381696839e2f..889a9b1337be 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -62,6 +62,7 @@
 #include "intel_uc.h"
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
+#include "intel_display.h"
 
 #include "i915_gem.h"
 #include "i915_gem_context.h"
@@ -243,159 +244,6 @@ static inline uint_fixed_16_16_t 
add_fixed16_u32(uint_fixed_16_16_t add1,
return clamp_u64_to_fixed16(interm_sum);
 }
 
-enum pipe {
-   INVALID_PIPE = -1,
-   PIPE_A = 0,
-   PIPE_B,
-   PIPE_C,
-   _PIPE_EDP,
-   I915_MAX_PIPES = _PIPE_EDP
-};
-#define pipe_name(p) ((p) + 'A')
-
-enum transcoder {
-   TRANSCODER_A = 0,
-   TRANSCODER_B,
-   TRANSCODER_C,
-   TRANSCODER_EDP,
-   TRANSCODER_DSI_A,
-   TRANSCODER_DSI_C,
-   I915_MAX_TRANSCODERS
-};
-
-static inline const char *transcoder_name(enum transcoder transcoder)
-{
-   switch (transcoder) {
-   case TRANSCODER_A:
-   return "A";
-   case TRANSCODER_B:
-   return "B";
-   case TRANSCODER_C:
-   return "C";
-   case TRANSCODER_EDP:
-   return "EDP";
-   case TRANSCODER_DSI_A:
-   return "DSI A";
-   case TRANSCODER_DSI_C:
-   return "DSI C";
-   default:
-   return "";
-   }
-}
-
-static inline bool transcoder_is_dsi(enum transcoder transcoder)
-{
-   return transcoder == TRANSCODER_DSI_A || transcoder == TRANSCODER_DSI_C;
-}
-
-/*
- * Global legacy plane identifier. Valid only for primary/sprite
- * planes on pre-g4x, and only for primary planes on g4x-bdw.
- */
-enum i9xx_plane_id {
-   PLANE_A,
-   PLANE_B,
-   PLANE_C,
-};
-#define plane_name(p) ((p) + 'A')
-
-#define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)->num_sprites[(p)] + (s) 
+ 'A')
-
-/*
- * Per-pipe plane identifier.
- * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
- * number of planes per CRTC.  Not all platforms really have this many planes,
- * which means some arrays of size I915_MAX_PLANES may have unused entries
- * between the topmost sprite plane and the cursor plane.
- *
- * This is expected to be passed to various register macros
- * (eg. PLANE_CTL(), PS_PLANE_SEL(), etc.) so adjust with care.
- */
-enum plane_id {
-   PLANE_PRIMARY,
-   PLANE_SPRITE0,
-   PLANE_SPRITE1,
-   PLANE_SPRITE2,
-   PLANE_CURSOR,
-   I915_MAX_PLANES,
-};
-
-#define for_each_plane_id_on_crtc(__crtc, __p) \
-   for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
-   for_each_if ((__crtc)->plane_ids_mask & BIT(__p))
-
-enum port {
-   PORT_NONE = -1,
-   PORT_A = 0,
-   PORT_B,
-   PORT_C,
-   PORT_D,
-   PORT_E,
-   I915_MAX_PORTS
-};
-#define port_name(p) ((p) + 'A')
-
-#define I915_NUM_PHYS_VLV 2
-
-enum dpio_channel {
-   DPIO_CH0,
-   DPIO_CH1
-};
-
-enum dpio_phy {
-   DPIO_PHY0,
-   DPIO_PHY1,
-   DPIO_PHY2,
-};
-
-enum intel_display_power_domain {
-   POWER_DOMAIN_PIPE_A,
-   POWER_DOMAIN_PIPE_B,
-   POWER_DOMAIN_PIPE_C,
-   POWER_DOMAIN_PIPE_A_PANEL_FITTER,
-   POWER_DOMAIN_PIPE_B_PANEL_FITTER,
-   POWER_DOMAIN_PIPE_C_PANEL_FITTER,
-   POWER_DOMAIN_TRANSCODER_A,
-   POWER_DOMAIN_TRANSCODER_B,
-   POWER_DOMAIN_TRANSCODER_C,
-   POWER_DOMAIN_TRANSCODER_EDP,
-   POWER_DOMAIN_TRANSCODER_DSI_A,
-   POWER_DOMAIN_TRANSCODER_DSI_C,
-   POWER_DOMAIN_PORT_DDI_A_LANES,
-   POWER_DOMAIN_PORT_DDI_B_LANES,
-   POWER_DOMAIN_PORT_DDI_C_LANES,
-   POWER_DOMAIN_PORT_DDI_D_LANES,
-   POWER_DOMAIN_PORT_DDI_E_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_DSI,
-   POWER_DOMAIN_PORT_CRT,
-   POWER_DOMAIN_PORT_OTHER,
-   POWER_DOMAIN_VGA,
-   

[Intel-gfx] [CI 7/7] drm/i915: Dump device info at once

[Chris Wilson]

From: Michal Wajdeczko 

We are dumping device info separately for sw_only and runtime part
but to simplify the code we can also do it from one place once
we complete driver load.

v2: use dedicated welcome function (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-8-michal.wajdec...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5bf4f589594a..6c8da9d20c33 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -931,12 +931,6 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
intel_display_crc_init(dev_priv);
 
-   if (drm_debug & DRM_UT_DRIVER) {
-   struct drm_printer p = drm_debug_printer("i915 device info:");
-
-   intel_device_info_dump(_priv->info, );
-   }
-
intel_detect_preproduction_hw(dev_priv);
 
return 0;
@@ -1089,11 +1083,6 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
 
intel_device_info_runtime_init(mkwrite_device_info(dev_priv));
-   if (drm_debug & DRM_UT_DRIVER) {
-   struct drm_printer p = drm_debug_printer("i915 device info:");
-
-   intel_device_info_dump_runtime(_priv->info, );
-   }
 
intel_sanitize_options(dev_priv);
 
@@ -1303,6 +1292,21 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
i915_gem_shrinker_unregister(dev_priv);
 }
 
+static void i915_welcome_messages(struct drm_i915_private *dev_priv)
+{
+   if (drm_debug & DRM_UT_DRIVER) {
+   struct drm_printer p = drm_debug_printer("i915 device info:");
+
+   intel_device_info_dump(_priv->info, );
+   intel_device_info_dump_runtime(_priv->info, );
+   }
+
+   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
+   DRM_INFO("DRM_I915_DEBUG enabled\n");
+   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+   DRM_INFO("DRM_I915_DEBUG_GEM enabled\n");
+}
+
 /**
  * i915_driver_load - setup chip and create an initial config
  * @pdev: PCI device
@@ -1388,13 +1392,10 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
intel_init_ipc(dev_priv);
 
-   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
-   DRM_INFO("DRM_I915_DEBUG enabled\n");
-   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
-   DRM_INFO("DRM_I915_DEBUG_GEM enabled\n");
-
intel_runtime_pm_put(dev_priv);
 
+   i915_welcome_messages(dev_priv);
+
return 0;
 
 out_cleanup_hw:
-- 
2.15.1

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

[Intel-gfx] [CI 3/7] drm/i915: Move opregion definitions to dedicated intel_opregion.h

[Chris Wilson]

From: Michal Wajdeczko 

We already have dedicated file for opregion related code, dedicated
header will make our life easier.

v2: reorder includes (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Reviewed-by: Chris Wilson 
Acked-by: Rodrigo Vivi 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-4-michal.wajdec...@intel.com
[ickle: quieten checkpatch]
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h   |  63 ++--
 drivers/gpu/drm/i915/intel_opregion.c |   2 +
 drivers/gpu/drm/i915/intel_opregion.h | 106 ++
 3 files changed, 112 insertions(+), 59 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_opregion.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 889a9b1337be..be756051f4c0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -56,13 +56,14 @@
 #include "i915_reg.h"
 #include "i915_utils.h"
 
-#include "intel_uncore.h"
 #include "intel_bios.h"
+#include "intel_display.h"
 #include "intel_dpll_mgr.h"
-#include "intel_uc.h"
 #include "intel_lrc.h"
+#include "intel_opregion.h"
 #include "intel_ringbuffer.h"
-#include "intel_display.h"
+#include "intel_uncore.h"
+#include "intel_uc.h"
 
 #include "i915_gem.h"
 #include "i915_gem_context.h"
@@ -355,27 +356,6 @@ struct drm_i915_file_private {
 #define DRIVER_MINOR   6
 #define DRIVER_PATCHLEVEL  0
 
-struct opregion_header;
-struct opregion_acpi;
-struct opregion_swsci;
-struct opregion_asle;
-
-struct intel_opregion {
-   struct opregion_header *header;
-   struct opregion_acpi *acpi;
-   struct opregion_swsci *swsci;
-   u32 swsci_gbda_sub_functions;
-   u32 swsci_sbcb_sub_functions;
-   struct opregion_asle *asle;
-   void *rvda;
-   void *vbt_firmware;
-   const void *vbt;
-   u32 vbt_size;
-   u32 *lid_state;
-   struct work_struct asle_work;
-};
-#define OPREGION_SIZE(8*1024)
-
 struct intel_overlay;
 struct intel_overlay_error_state;
 
@@ -3816,41 +3796,6 @@ bool intel_bios_is_port_hpd_inverted(struct 
drm_i915_private *dev_priv,
 bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
enum port port);
 
-
-/* intel_opregion.c */
-#ifdef CONFIG_ACPI
-extern int intel_opregion_setup(struct drm_i915_private *dev_priv);
-extern void intel_opregion_register(struct drm_i915_private *dev_priv);
-extern void intel_opregion_unregister(struct drm_i915_private *dev_priv);
-extern void intel_opregion_asle_intr(struct drm_i915_private *dev_priv);
-extern int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,
-bool enable);
-extern int intel_opregion_notify_adapter(struct drm_i915_private *dev_priv,
-pci_power_t state);
-extern int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv);
-#else
-static inline int intel_opregion_setup(struct drm_i915_private *dev) { return 
0; }
-static inline void intel_opregion_register(struct drm_i915_private *dev_priv) 
{ }
-static inline void intel_opregion_unregister(struct drm_i915_private 
*dev_priv) { }
-static inline void intel_opregion_asle_intr(struct drm_i915_private *dev_priv)
-{
-}
-static inline int
-intel_opregion_notify_encoder(struct intel_encoder *intel_encoder, bool enable)
-{
-   return 0;
-}
-static inline int
-intel_opregion_notify_adapter(struct drm_i915_private *dev, pci_power_t state)
-{
-   return 0;
-}
-static inline int intel_opregion_get_panel_type(struct drm_i915_private *dev)
-{
-   return -ENODEV;
-}
-#endif
-
 /* intel_acpi.c */
 #ifdef CONFIG_ACPI
 extern void intel_register_dsm_handler(void);
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index fc65f5e451dd..c58e5f53bab0 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -32,6 +32,8 @@
 
 #include 
 #include 
+
+#include "intel_opregion.h"
 #include "i915_drv.h"
 #include "intel_drv.h"
 
diff --git a/drivers/gpu/drm/i915/intel_opregion.h 
b/drivers/gpu/drm/i915/intel_opregion.h
new file mode 100644
index ..e0e437ba9e51
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_opregion.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright © 2008-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, 

[Intel-gfx] [CI 6/7] drm/i915: Add pretty printer for runtime part of intel_device_info

[Chris Wilson]

From: Michal Wajdeczko 

During initialization of the runtime part of the intel_device_info
we are dumping that part using DRM_DEBUG_DRIVER mechanism.
As we already have pretty printer for const part of the info,
make similar function for the runtime part and use it separately.

v2: add runtime dump to debugfs (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-7-michal.wajdec...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  1 +
 drivers/gpu/drm/i915/i915_drv.c  |  5 
 drivers/gpu/drm/i915/intel_device_info.c | 44 +++-
 drivers/gpu/drm/i915/intel_device_info.h |  2 ++
 4 files changed, 34 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3affcaac82db..e968aeae1d84 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -48,6 +48,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev_priv));
 
intel_device_info_dump_flags(info, );
+   intel_device_info_dump_runtime(info, );
 
kernel_param_lock(THIS_MODULE);
i915_params_dump(_modparams, );
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 06eea8dab464..5bf4f589594a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1089,6 +1089,11 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
 
intel_device_info_runtime_init(mkwrite_device_info(dev_priv));
+   if (drm_debug & DRM_UT_DRIVER) {
+   struct drm_printer p = drm_debug_printer("i915 device info:");
+
+   intel_device_info_dump_runtime(_priv->info, );
+   }
 
intel_sanitize_options(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 8e050b53834a..d28592e43512 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -78,6 +78,32 @@ void intel_device_info_dump_flags(const struct 
intel_device_info *info,
 #undef PRINT_FLAG
 }
 
+static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p)
+{
+   drm_printf(p, "slice mask: %04x\n", sseu->slice_mask);
+   drm_printf(p, "slice total: %u\n", hweight8(sseu->slice_mask));
+   drm_printf(p, "subslice total: %u\n", sseu_subslice_total(sseu));
+   drm_printf(p, "subslice mask %04x\n", sseu->subslice_mask);
+   drm_printf(p, "subslice per slice: %u\n",
+  hweight8(sseu->subslice_mask));
+   drm_printf(p, "EU total: %u\n", sseu->eu_total);
+   drm_printf(p, "EU per subslice: %u\n", sseu->eu_per_subslice);
+   drm_printf(p, "has slice power gating: %s\n",
+  yesno(sseu->has_slice_pg));
+   drm_printf(p, "has subslice power gating: %s\n",
+  yesno(sseu->has_subslice_pg));
+   drm_printf(p, "has EU power gating: %s\n", yesno(sseu->has_eu_pg));
+}
+
+void intel_device_info_dump_runtime(const struct intel_device_info *info,
+   struct drm_printer *p)
+{
+   sseu_dump(>sseu, p);
+
+   drm_printf(p, "CS timestamp frequency: %u kHz\n",
+  info->cs_timestamp_frequency_khz);
+}
+
 void intel_device_info_dump(const struct intel_device_info *info,
struct drm_printer *p)
 {
@@ -558,22 +584,4 @@ void intel_device_info_runtime_init(struct 
intel_device_info *info)
 
/* Initialize command stream timestamp frequency */
info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv);
-
-   DRM_DEBUG_DRIVER("slice mask: %04x\n", info->sseu.slice_mask);
-   DRM_DEBUG_DRIVER("slice total: %u\n", hweight8(info->sseu.slice_mask));
-   DRM_DEBUG_DRIVER("subslice total: %u\n",
-sseu_subslice_total(>sseu));
-   DRM_DEBUG_DRIVER("subslice mask %04x\n", info->sseu.subslice_mask);
-   DRM_DEBUG_DRIVER("subslice per slice: %u\n",
-hweight8(info->sseu.subslice_mask));
-   DRM_DEBUG_DRIVER("EU total: %u\n", info->sseu.eu_total);
-   DRM_DEBUG_DRIVER("EU per subslice: %u\n", info->sseu.eu_per_subslice);
-   DRM_DEBUG_DRIVER("has slice power gating: %s\n",
-info->sseu.has_slice_pg ? "y" : "n");
-   DRM_DEBUG_DRIVER("has subslice power gating: %s\n",
-info->sseu.has_subslice_pg ? "y" : "n");
-   DRM_DEBUG_DRIVER("has EU power gating: %s\n",
-

[Intel-gfx] [CI 5/7] drm/i915: Update intel_device_info_runtime_init() parameter

[Chris Wilson]

From: Michal Wajdeczko 

As we try to follow object-verb pattern in our functions, update
intel_device_info_runtime_init() parameter from dev_priv to info.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-6-michal.wajdec...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c | 10 +++---
 drivers/gpu/drm/i915/intel_device_info.h |  2 +-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6f14986dcd11..06eea8dab464 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1088,7 +1088,7 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
if (i915_inject_load_failure())
return -ENODEV;
 
-   intel_device_info_runtime_init(dev_priv);
+   intel_device_info_runtime_init(mkwrite_device_info(dev_priv));
 
intel_sanitize_options(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index f2050542b458..8e050b53834a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -431,7 +431,10 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
return 0;
 }
 
-/*
+/**
+ * intel_device_info_runtime_init - initialize runtime info
+ * @info: intel device info struct
+ *
  * Determine various intel_device_info fields at runtime.
  *
  * Use it when either:
@@ -444,9 +447,10 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
  *   - after the PCH has been detected,
  *   - before the first usage of the fields it can tweak.
  */
-void intel_device_info_runtime_init(struct drm_i915_private *dev_priv)
+void intel_device_info_runtime_init(struct intel_device_info *info)
 {
-   struct intel_device_info *info = mkwrite_device_info(dev_priv);
+   struct drm_i915_private *dev_priv =
+   container_of(info, struct drm_i915_private, info);
enum pipe pipe;
 
if (INTEL_GEN(dev_priv) >= 10) {
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 845df57c26f5..6f7a3d4fc253 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -172,7 +172,7 @@ static inline unsigned int sseu_subslice_total(const struct 
sseu_dev_info *sseu)
 
 const char *intel_platform_name(enum intel_platform platform);
 
-void intel_device_info_runtime_init(struct drm_i915_private *dev_priv);
+void intel_device_info_runtime_init(struct intel_device_info *info);
 void intel_device_info_dump(const struct intel_device_info *info,
struct drm_printer *p);
 void intel_device_info_dump_flags(const struct intel_device_info *info,
-- 
2.15.1

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

[Intel-gfx] [CI 4/7] drm/i915: Move intel_device_info definitions to its own header

[Chris Wilson]

From: Michal Wajdeczko 

We already keep intel_device_info functions in dedicated file.
Add matching header file and move related definitions there.

v2: add gen boundaries (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
Acked-by: Rodrigo Vivi 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-5-michal.wajdec...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  | 139 +---
 drivers/gpu/drm/i915/intel_device_info.c |   1 +
 drivers/gpu/drm/i915/intel_device_info.h | 181 +++
 3 files changed, 183 insertions(+), 138 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_device_info.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be756051f4c0..4b943cdbd541 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -57,6 +57,7 @@
 #include "i915_utils.h"
 
 #include "intel_bios.h"
+#include "intel_device_info.h"
 #include "intel_display.h"
 #include "intel_dpll_mgr.h"
 #include "intel_lrc.h"
@@ -448,137 +449,6 @@ struct intel_csr {
uint32_t allowed_dc_mask;
 };
 
-#define DEV_INFO_FOR_EACH_FLAG(func) \
-   func(is_mobile); \
-   func(is_lp); \
-   func(is_alpha_support); \
-   /* Keep has_* in alphabetical order */ \
-   func(has_64bit_reloc); \
-   func(has_aliasing_ppgtt); \
-   func(has_csr); \
-   func(has_ddi); \
-   func(has_dp_mst); \
-   func(has_reset_engine); \
-   func(has_fbc); \
-   func(has_fpga_dbg); \
-   func(has_full_ppgtt); \
-   func(has_full_48bit_ppgtt); \
-   func(has_gmch_display); \
-   func(has_guc); \
-   func(has_guc_ct); \
-   func(has_hotplug); \
-   func(has_l3_dpf); \
-   func(has_llc); \
-   func(has_logical_ring_contexts); \
-   func(has_logical_ring_preemption); \
-   func(has_overlay); \
-   func(has_pooled_eu); \
-   func(has_psr); \
-   func(has_rc6); \
-   func(has_rc6p); \
-   func(has_resource_streamer); \
-   func(has_runtime_pm); \
-   func(has_snoop); \
-   func(unfenced_needs_alignment); \
-   func(cursor_needs_physical); \
-   func(hws_needs_physical); \
-   func(overlay_needs_physical); \
-   func(supports_tv); \
-   func(has_ipc);
-
-struct sseu_dev_info {
-   u8 slice_mask;
-   u8 subslice_mask;
-   u8 eu_total;
-   u8 eu_per_subslice;
-   u8 min_eu_in_pool;
-   /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
-   u8 subslice_7eu[3];
-   u8 has_slice_pg:1;
-   u8 has_subslice_pg:1;
-   u8 has_eu_pg:1;
-};
-
-static inline unsigned int sseu_subslice_total(const struct sseu_dev_info 
*sseu)
-{
-   return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
-}
-
-/* Keep in gen based order, and chronological order within a gen */
-enum intel_platform {
-   INTEL_PLATFORM_UNINITIALIZED = 0,
-   INTEL_I830,
-   INTEL_I845G,
-   INTEL_I85X,
-   INTEL_I865G,
-   INTEL_I915G,
-   INTEL_I915GM,
-   INTEL_I945G,
-   INTEL_I945GM,
-   INTEL_G33,
-   INTEL_PINEVIEW,
-   INTEL_I965G,
-   INTEL_I965GM,
-   INTEL_G45,
-   INTEL_GM45,
-   INTEL_IRONLAKE,
-   INTEL_SANDYBRIDGE,
-   INTEL_IVYBRIDGE,
-   INTEL_VALLEYVIEW,
-   INTEL_HASWELL,
-   INTEL_BROADWELL,
-   INTEL_CHERRYVIEW,
-   INTEL_SKYLAKE,
-   INTEL_BROXTON,
-   INTEL_KABYLAKE,
-   INTEL_GEMINILAKE,
-   INTEL_COFFEELAKE,
-   INTEL_CANNONLAKE,
-   INTEL_MAX_PLATFORMS
-};
-
-struct intel_device_info {
-   u16 device_id;
-   u16 gen_mask;
-
-   u8 gen;
-   u8 gt; /* GT number, 0 if undefined */
-   u8 num_rings;
-   u8 ring_mask; /* Rings supported by the HW */
-
-   enum intel_platform platform;
-   u32 platform_mask;
-
-   u32 display_mmio_offset;
-
-   u8 num_pipes;
-   u8 num_sprites[I915_MAX_PIPES];
-   u8 num_scalers[I915_MAX_PIPES];
-
-   unsigned int page_sizes; /* page sizes supported by the HW */
-
-#define DEFINE_FLAG(name) u8 name:1
-   DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG);
-#undef DEFINE_FLAG
-   u16 ddb_size; /* in blocks */
-
-   /* Register offsets for the various display pipes and transcoders */
-   int pipe_offsets[I915_MAX_TRANSCODERS];
-   int trans_offsets[I915_MAX_TRANSCODERS];
-   int palette_offsets[I915_MAX_PIPES];
-   int cursor_offsets[I915_MAX_PIPES];
-
-   /* Slice/subslice/EU info */
-   struct sseu_dev_info sseu;
-
-   u32 cs_timestamp_frequency_khz;
-
-   struct color_luts {
-   u16 

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/4] drm/i915: Disable DC states around GMBUS on GLK (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915: Disable DC states around GMBUS on 
GLK (rev2)
URL   : https://patchwork.freedesktop.org/series/35117/
State : warning

== Summary ==

Test drv_suspend:
Subgroup sysfs-reader:
skip   -> PASS   (shard-hsw)
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-snb)
skip   -> PASS   (shard-hsw)
Test kms_busy:
Subgroup basic-modeset-a:
pass   -> DMESG-WARN (shard-hsw)
Subgroup basic-modeset-b:
pass   -> SKIP   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-pwrite:
pass   -> SKIP   (shard-hsw) fdo#101623 +1
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test pm_rpm:
Subgroup system-suspend:
skip   -> PASS   (shard-hsw) fdo#103375

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

shard-hswtotal:2640 pass:1499 dwarn:2   dfail:0   fail:10  skip:1128 
time:9185s
shard-snbtotal:2712 pass:1308 dwarn:2   dfail:0   fail:11  skip:1391 
time:8077s
Blacklisted hosts:
shard-apltotal:2712 pass:1685 dwarn:1   dfail:1   fail:24  skip:1001 
time:13722s
shard-kbltotal:2653 pass:1757 dwarn:8   dfail:0   fail:22  skip:865 
time:10631s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915: Add pretty printer for runtime part of intel_device_info

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-21 18:53:33)
> During initialization of the runtime part of the intel_device_info
> we are dumping that part using DRM_DEBUG_DRIVER mechanism.
> As we already have pretty printer for const part of the info,
> make similar function for the runtime part and use it separately.
> 
> v2: add runtime dump to debugfs (Chris)
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Rodrigo Vivi 
> Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 7/7] drm/i915: Dump device info at once

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-21 18:53:34)
> We are dumping device info separately for sw_only and runtime part
> but to simplify the code we can also do it from one place once
> we complete driver load.
> 
> v2: use dedicated welcome function (Chris)
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Rodrigo Vivi 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 33 +
>  1 file changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5bf4f58..6c8da9d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -931,12 +931,6 @@ static int i915_driver_init_early(struct 
> drm_i915_private *dev_priv,
>  
> intel_display_crc_init(dev_priv);
>  
> -   if (drm_debug & DRM_UT_DRIVER) {
> -   struct drm_printer p = drm_debug_printer("i915 device info:");
> -
> -   intel_device_info_dump(_priv->info, );
> -   }
> -
> intel_detect_preproduction_hw(dev_priv);
>  
> return 0;
> @@ -1089,11 +1083,6 @@ static int i915_driver_init_hw(struct drm_i915_private 
> *dev_priv)
> return -ENODEV;
>  
> intel_device_info_runtime_init(mkwrite_device_info(dev_priv));
> -   if (drm_debug & DRM_UT_DRIVER) {
> -   struct drm_printer p = drm_debug_printer("i915 device info:");
> -
> -   intel_device_info_dump_runtime(_priv->info, );
> -   }
>  
> intel_sanitize_options(dev_priv);
>  
> @@ -1303,6 +1292,21 @@ static void i915_driver_unregister(struct 
> drm_i915_private *dev_priv)
> i915_gem_shrinker_unregister(dev_priv);
>  }
>  
> +static void i915_welcome_messages(struct drm_i915_private *dev_priv)
> +{
> +   if (drm_debug & DRM_UT_DRIVER) {
> +   struct drm_printer p = drm_debug_printer("i915 device info:");
> +
> +   intel_device_info_dump(_priv->info, );
> +   intel_device_info_dump_runtime(_priv->info, );

I'd throw the flags into here as well (and to debugfs), then all parties
are doing the same and we can reduce this to a single
intel_device_info_dump() routine.

Reviewed-by: Chris Wilson 
-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 Misc i915_drv.h cleanups (rev2)

[Patchwork]

== Series Details ==

Series: Misc i915_drv.h cleanups (rev2)
URL   : https://patchwork.freedesktop.org/series/35637/
State : failure

== Summary ==

Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-hsw) fdo#104218
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-snb)
skip   -> PASS   (shard-hsw)
Subgroup sysfs-reader:
skip   -> PASS   (shard-hsw)
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
pass   -> DMESG-WARN (shard-snb)
Test pm_rpm:
Subgroup system-suspend:
skip   -> PASS   (shard-hsw) fdo#103375
Test gem_exec_parallel:
Subgroup render:
pass   -> INCOMPLETE (shard-snb)

fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-hswtotal:2712 pass:1538 dwarn:1   dfail:0   fail:9   skip:1164 
time:9377s
shard-snbtotal:2702 pass:1304 dwarn:2   dfail:0   fail:10  skip:1385 
time:7916s
Blacklisted hosts:
shard-apltotal:2660 pass:1648 dwarn:1   dfail:0   fail:24  skip:985 
time:13299s
shard-kbltotal:2653 pass:1734 dwarn:29  dfail:1   fail:22  skip:866 
time:10653s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait

[Patchwork]

== Series Details ==

Series: igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait
URL   : https://patchwork.freedesktop.org/series/35699/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
beb26d89ff5c5621c1e6b6ac2a45439507af86b7 meson: Install .testlist files and 
README from tests/intel-ci

with latest DRM-Tip kernel build CI_DRM_3566
c0a64101df89 drm-tip: 2017y-12m-21d-18h-02m-56s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989 +1
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_chamelium:
Subgroup dp-crc-fast:
pass   -> DMESG-FAIL (fi-kbl-7500u) fdo#103841
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:446s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:501s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:492s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:483s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:264s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:409s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:418s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:429s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:1   fail:0   skip:24  
time:476s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:518s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:525s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:529s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:507s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:551s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:418s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:588s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_723/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/dmc: DMC 1.07 for Cannonlake

[Patchwork]

== Series Details ==

Series: drm/i915/dmc: DMC 1.07 for Cannonlake
URL   : https://patchwork.freedesktop.org/series/35651/
State : success

== Summary ==

Series 35651v1 drm/i915/dmc: DMC 1.07 for Cannonlake
https://patchwork.freedesktop.org/api/1.0/series/35651/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-hsw-4770) fdo#103375
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:499s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:494s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:496s
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:463s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:266s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:530s
fi-hsw-4770  total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:426s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:479s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:521s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:466s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:524s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:532s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:551s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
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:409s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:592s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:630s
fi-glk-dsi   total:288  pass:257  dwarn:0   dfail:0   fail:1   skip:30  
time:494s

c0a64101df89fe312cb41d27e184555400d0e3b9 drm-tip: 2017y-12m-21d-18h-02m-56s UTC 
integration manifest
191490226900 drm/i915/dmc: DMC 1.07 for Cannonlake

== Logs ==

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

[Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Show FBC status at the start of the wait

[Chris Wilson]

Signed-off-by: Chris Wilson 
---
 tests/kms_frontbuffer_tracking.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 1601cab45..8b440dadc 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -927,6 +927,10 @@ static bool fbc_stride_not_supported(void)
 
 static bool fbc_wait_until_enabled(void)
 {
+   if (fbc_is_enabled())
+   return true;
+
+   fbc_print_status();
return igt_wait(fbc_is_enabled(), 2000, 1);
 }
 
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature

[Srivatsa, Anusha]

>-Original Message-
>From: Navare, Manasi D
>Sent: Thursday, December 21, 2017 12:36 PM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Ville 
>Syrjala
>; Jani Nikula 
>Subject: Re: [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature
>
>On Mon, Nov 27, 2017 at 04:55:44PM -0800, Anusha Srivatsa wrote:
>> Forward Error Correction is supported on DP 1.4.
>> This patch adds corresponding DPCD register definitions.
>>
>> v2: Add dri-devel to the CC list
>>
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: Ville Syrjala 
>> Cc: Jani Nikula 
>> Cc: Manasi Navare 
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  include/drm/drm_dp_helper.h | 29 +
>>  1 file changed, 29 insertions(+)
>>
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index da58a42..bc816ea 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -284,6 +284,35 @@
>>  # define DP_DSC_BITS_PER_PIXEL_1_2  0x3
>>  # define DP_DSC_BITS_PER_PIXEL_10x4
>>
>> +/* DP Forward error Correction Registers */
>> +#define DP_FEC_CAPABILITY   0x090
>> +# define DP_FEC_CAPABLE (1 << 0)
>> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
>> +# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
>> +# define DP_FEC_BIT_ERROR_COUNT_CAP (1 << 3)
>> +
>> +#define DP_FEC_CONFIGURATION0x120
>> +# define DP_FEC_READY   (1 << 0)
>> +# define DP_FEC_ERR_COUNT_DIS   (0 << 1)
>> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT  (1 << 1)
>> +# define DP_FEC_CORR_BLK_ERROR_COUNT(2 << 1)
>> +# define DP_FEC_BIT_ERROR_COUNT (3 << 1)
>
>These above values indicate the value of FEC_ERROR_COUNT_SEL.
>I think we would need a mask for FEC_ERROR_COUNT_SEL field so that we can
>read this field as drm_dpcd_read(DP_FEC_CONFIGURATION) &
>FEC_ERROR_COUNT_SEL_MASK and then compare this to each of the values for
>that field.
>So we would need an extra #define for the MASK

Sounds good 

>> +# define DP_FEC_LANE_0_SELECT   (0 << 4)
>> +# define DP_FEC_LANE_1_SELECT   (1 << 4)
>> +# define DP_FEC_LANE_2_SELECT   (2 << 4)
>> +# define DP_FEC_LANE_3_SELECT   (3 << 4)
>> +
>> +#define DP_FEC_STATUS   0x280
>> +# define DP_FEC_EN_DETECTED (1 << 0)
>
>I think better name would be DP_FEC_DECODE_EN_DETECTED since this refers to
>FEC_DECODE_EN link symbol sequence

Now that you mentioned, I noticed that's the name used in spec too. I wonder 
why I went ahead with the above name. Shall change it. Thanks.

>> +# define DP_FEC_DEC_DETECTED(1 << 1)
>
>And this should be DP_FEC_DECODE_DIS_DETECTED since this refers to
>FEC_DECODE_DIS link symbol sequence
>
>> +
>> +#define DP_FEC_ERROR_COUNT_10x0281
>> +# define DP_FEC_ERR_COUNT_7_0(err_count)(err_count << 0)
>
>So this is a RO register and so we wont be writing the err_count by passing it 
>as
>an argument as above.
>And this is the entire reister that indicates the LSB of ERR_COUNT you can just
>rename the register as DP_FEC_ERR_COUNT_LSB So while reading you just pass
>this register address and get LSB into a variable.

Yes, good point.

>
>> +
>> +#define DP_FEC_ERROR_COUNT_20x0282
>> +# define DP_FEC_ERR_COUNT_14_8(err_count)   (err_count << 0)
>
>This could be DP_FEC_ERR_COUNT_MSB_MASK and SHIFT should be 8 since you
>want to put this value at the 8th bit of a 16 bit value.

This helps thanks!

>> +# define DP_FEC_ERR_COUNT_VALID (1 << 7)
>
>Everything else looks good.

Thanks Manasi. I will incorporate these changes in the next revision.

Anusha 
>Manasi
>
>> +
>>  #define DP_PSR_SUPPORT  0x070   /* XXX 1.2? */
>>  # define DP_PSR_IS_SUPPORTED1
>>  # define DP_PSR2_IS_SUPPORTED   2   /* eDP 1.4 */
>> --
>> 2.7.4
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Disable DC states around GMBUS on GLK (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915: Disable DC states around GMBUS on 
GLK (rev2)
URL   : https://patchwork.freedesktop.org/series/35117/
State : success

== Summary ==

Series 35117v2 series starting with [1/4] drm/i915: Disable DC states around 
GMBUS on GLK
https://patchwork.freedesktop.org/api/1.0/series/35117/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:437s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:384s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:496s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:275s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:476s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:259s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:533s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:415s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:425s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:473s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:523s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:529s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:537s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:554s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:510s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:552s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-cnl-y total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:25 
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s

c0a64101df89fe312cb41d27e184555400d0e3b9 drm-tip: 2017y-12m-21d-18h-02m-56s UTC 
integration manifest
be940a4d2230 drm/i915: Disable GMBUS clock gating around GMBUS transfers on 
gen9+
50ebca98ff7b drm/i915: Clean up the PNV bit banging vs. GMBUS clock gating w/a
6f5f07314fb1 drm/i915: No need to power up PG2 for GMBUS on BXT
e88a2ff0d2d5 drm/i915: Disable DC states around GMBUS on GLK

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature

[Manasi Navare]

On Mon, Nov 27, 2017 at 04:55:44PM -0800, Anusha Srivatsa wrote:
> Forward Error Correction is supported on DP 1.4.
> This patch adds corresponding DPCD register definitions.
> 
> v2: Add dri-devel to the CC list
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  include/drm/drm_dp_helper.h | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..bc816ea 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -284,6 +284,35 @@
>  # define DP_DSC_BITS_PER_PIXEL_1_2  0x3
>  # define DP_DSC_BITS_PER_PIXEL_10x4
>  
> +/* DP Forward error Correction Registers */
> +#define DP_FEC_CAPABILITY0x090
> +# define DP_FEC_CAPABLE  (1 << 0)
> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
> +# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
> +# define DP_FEC_BIT_ERROR_COUNT_CAP  (1 << 3)
> +
> +#define DP_FEC_CONFIGURATION 0x120
> +# define DP_FEC_READY(1 << 0)
> +# define DP_FEC_ERR_COUNT_DIS(0 << 1)
> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT   (1 << 1)
> +# define DP_FEC_CORR_BLK_ERROR_COUNT (2 << 1)
> +# define DP_FEC_BIT_ERROR_COUNT  (3 << 1)

These above values indicate the value of FEC_ERROR_COUNT_SEL.
I think we would need a mask for FEC_ERROR_COUNT_SEL field so that
we can read this field as drm_dpcd_read(DP_FEC_CONFIGURATION) & 
FEC_ERROR_COUNT_SEL_MASK
and then compare this to each of the values for that field.
So we would need an extra #define for the MASK

> +# define DP_FEC_LANE_0_SELECT(0 << 4)
> +# define DP_FEC_LANE_1_SELECT(1 << 4)
> +# define DP_FEC_LANE_2_SELECT(2 << 4)
> +# define DP_FEC_LANE_3_SELECT(3 << 4)
> +
> +#define DP_FEC_STATUS0x280
> +# define DP_FEC_EN_DETECTED  (1 << 0)

I think better name would be DP_FEC_DECODE_EN_DETECTED since this refers
to FEC_DECODE_EN link symbol sequence

> +# define DP_FEC_DEC_DETECTED (1 << 1)

And this should be DP_FEC_DECODE_DIS_DETECTED since this refers to
FEC_DECODE_DIS link symbol sequence

> +
> +#define DP_FEC_ERROR_COUNT_1 0x0281
> +# define DP_FEC_ERR_COUNT_7_0(err_count)(err_count << 0)

So this is a RO register and so we wont be writing the err_count by passing it 
as
an argument as above.
And this is the entire reister that indicates the LSB of ERR_COUNT you can just 
rename the
register as DP_FEC_ERR_COUNT_LSB
So while reading you just pass this register address and get LSB into a 
variable.

> +
> +#define DP_FEC_ERROR_COUNT_2 0x0282
> +# define DP_FEC_ERR_COUNT_14_8(err_count)   (err_count << 0)

This could be DP_FEC_ERR_COUNT_MSB_MASK and SHIFT should be 8 since
you want to put this value at the 8th bit of a 16 bit value.

> +# define DP_FEC_ERR_COUNT_VALID  (1 << 7)

Everything else looks good.

Manasi

> +
>  #define DP_PSR_SUPPORT  0x070   /* XXX 1.2? */
>  # define DP_PSR_IS_SUPPORTED1
>  # define DP_PSR2_IS_SUPPORTED2   /* eDP 1.4 */
> -- 
> 2.7.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.07 for Cannonlake

[Saarinen, Jani]

HI, 
> -Original Message-
> From: Vivi, Rodrigo
> Sent: torstai 21. joulukuuta 2017 21.27
> To: Saarinen, Jani 
> Cc: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.07 for Cannonlake
> 
> On Thu, Dec 21, 2017 at 12:08:15PM +, Saarinen, Jani wrote:
> >
> >
> > > -Original Message-
> > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > > Behalf Of Anusha Srivatsa
> > > Sent: torstai 21. joulukuuta 2017 3.38
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Vivi, Rodrigo 
> > > Subject: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.07 for Cannonlake
> > >
> > > There is a new version of DMC available for KBL.
> > For CNL you mean?
> 
> With this fixed feel free to use:
> 
> Reviewed-by: Rodrigo Vivi 
> 
> Jani, these results we got from CI are already with fw applied?
I am afraid not see: 
<4>[  574.873592] i915 :00:02.0: Direct firmware load for 
i915/cnl_dmc_ver1_07.bin failed with error -2
<5>[  574.873638] i915 :00:02.0: Failed to load DMC firmware 
i915/cnl_dmc_ver1_07.bin. Disabling runtime power management.

We need to re-run because there was an issue because the CI server changes, but 
fixed now by Tomi
Re-test request sent as seen on queue now: 
https://intel-gfx-ci.01.org/queue/intel-gfx.html
With that there is already FW waiting on systems.

> Although CNL is on blacklist still right?! :(
Yes, but that do not matter for results altogether are still sent. 

> 
> > >
> > > The release notes mentions:
> > > 1. Fix for the issue where DC_STATE was getting enabled even when
> > > disabled by driver causing data corruption
> > >
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: Anusha Srivatsa 
> > > ---
> > >  drivers/gpu/drm/i915/intel_csr.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > > b/drivers/gpu/drm/i915/intel_csr.c
> > > index 7fe4aac0..ed256de 100644
> > > --- a/drivers/gpu/drm/i915/intel_csr.c
> > > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > > @@ -37,8 +37,8 @@
> > >  #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
> > >  #define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4)
> > >
> > > -#define I915_CSR_CNL "i915/cnl_dmc_ver1_06.bin"
> > > -#define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 6)
> > > +#define I915_CSR_CNL "i915/cnl_dmc_ver1_07.bin"
> > > +#define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
> > >
> > >  #define I915_CSR_KBL "i915/kbl_dmc_ver1_04.bin"
> > >  MODULE_FIRMWARE(I915_CSR_KBL);
> > > --
> > > 2.7.4
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 4/4] drm/i915: Disable GMBUS clock gating around GMBUS transfers on gen9+

[Ville Syrjala]

From: Ville Syrjälä 

Gen9+ need to disable GMBUS clock gating when doing multi part
transfers. Otherwise clock gating will kick in when GMBUS is in
the WAIT state and presumably that will corrupt the transfer.
This is documented as Display WA #0868.

Apparently older hardware doesn't allow clock gating in the WAIT
state and thus are unaffected by this problem.

v2: Limit the PCH w/a to gen9 and gen10 only (DK)
Actually change it to check the PCH type instead since
it's the PCH that actually contains the GMBUS hardware

Signed-off-by: Ville Syrjälä 
Reviewed-by: Dhinakaran Pandiyan  #v1
---
 drivers/gpu/drm/i915/i915_reg.h  |  4 
 drivers/gpu/drm/i915/intel_i2c.c | 40 
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fb05849eabab..41285bec8fc0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3859,6 +3859,9 @@ enum {
 #define   PWM2_GATING_DIS  (1 << 14)
 #define   PWM1_GATING_DIS  (1 << 13)
 
+#define GEN9_CLKGATE_DIS_4 _MMIO(0x4653C)
+#define   BXT_GMBUS_GATING_DIS (1 << 14)
+
 #define _CLKGATE_DIS_PSL_A 0x46520
 #define _CLKGATE_DIS_PSL_B 0x46524
 #define _CLKGATE_DIS_PSL_C 0x46528
@@ -7557,6 +7560,7 @@ enum {
 #define FDI_RX_CHICKEN(pipe)   _MMIO_PIPE(pipe, _FDI_RXA_CHICKEN, 
_FDI_RXB_CHICKEN)
 
 #define SOUTH_DSPCLK_GATE_D_MMIO(0xc2020)
+#define  PCH_GMBUSUNIT_CLOCK_GATE_DISABLE (1<<31)
 #define  PCH_DPLUNIT_CLOCK_GATE_DISABLE (1<<30)
 #define  PCH_DPLSUNIT_CLOCK_GATE_DISABLE (1<<29)
 #define  PCH_CPUNIT_CLOCK_GATE_DISABLE (1<<14)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index a8c08994f505..ef9f91a0b0c9 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -142,6 +142,32 @@ static void pnv_gmbus_clock_gating(struct drm_i915_private 
*dev_priv,
I915_WRITE(DSPCLK_GATE_D, val);
 }
 
+static void pch_gmbus_clock_gating(struct drm_i915_private *dev_priv,
+  bool enable)
+{
+   u32 val;
+
+   val = I915_READ(SOUTH_DSPCLK_GATE_D);
+   if (!enable)
+   val |= PCH_GMBUSUNIT_CLOCK_GATE_DISABLE;
+   else
+   val &= ~PCH_GMBUSUNIT_CLOCK_GATE_DISABLE;
+   I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
+}
+
+static void bxt_gmbus_clock_gating(struct drm_i915_private *dev_priv,
+  bool enable)
+{
+   u32 val;
+
+   val = I915_READ(GEN9_CLKGATE_DIS_4);
+   if (!enable)
+   val |= BXT_GMBUS_GATING_DIS;
+   else
+   val &= ~BXT_GMBUS_GATING_DIS;
+   I915_WRITE(GEN9_CLKGATE_DIS_4, val);
+}
+
 static u32 get_reserved(struct intel_gmbus *bus)
 {
struct drm_i915_private *dev_priv = bus->dev_priv;
@@ -484,6 +510,13 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
int i = 0, inc, try = 0;
int ret = 0;
 
+   /* Display WA #0868: skl,bxt,kbl,cfl,glk,cnl */
+   if (IS_GEN9_LP(dev_priv))
+   bxt_gmbus_clock_gating(dev_priv, false);
+   else if (HAS_PCH_SPT(dev_priv) ||
+HAS_PCH_KBP(dev_priv) || HAS_PCH_CNP(dev_priv))
+   pch_gmbus_clock_gating(dev_priv, false);
+
 retry:
I915_WRITE_FW(GMBUS0, bus->reg0);
 
@@ -585,6 +618,13 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
ret = -EAGAIN;
 
 out:
+   /* Display WA #0868: skl,bxt,kbl,cfl,glk,cnl */
+   if (IS_GEN9_LP(dev_priv))
+   bxt_gmbus_clock_gating(dev_priv, true);
+   else if (HAS_PCH_SPT(dev_priv) ||
+HAS_PCH_KBP(dev_priv) || HAS_PCH_CNP(dev_priv))
+   pch_gmbus_clock_gating(dev_priv, true);
+
return ret;
 }
 
-- 
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/dmc: DMC 1.07 for Cannonlake

[Rodrigo Vivi]

On Thu, Dec 21, 2017 at 12:08:15PM +, Saarinen, Jani wrote:
> 
> 
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
> > Of
> > Anusha Srivatsa
> > Sent: torstai 21. joulukuuta 2017 3.38
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Vivi, Rodrigo 
> > Subject: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.07 for Cannonlake
> > 
> > There is a new version of DMC available for KBL.
> For CNL you mean?

With this fixed feel free to use:

Reviewed-by: Rodrigo Vivi 

Jani, these results we got from CI are already with fw applied?
Although CNL is on blacklist still right?! :(

> > 
> > The release notes mentions:
> > 1. Fix for the issue where DC_STATE was getting enabled even when disabled 
> > by
> > driver causing data corruption
> > 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Anusha Srivatsa 
> > ---
> >  drivers/gpu/drm/i915/intel_csr.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index 7fe4aac0..ed256de 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -37,8 +37,8 @@
> >  #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
> >  #define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
> > 
> > -#define I915_CSR_CNL "i915/cnl_dmc_ver1_06.bin"
> > -#define CNL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 6)
> > +#define I915_CSR_CNL "i915/cnl_dmc_ver1_07.bin"
> > +#define CNL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 7)
> > 
> >  #define I915_CSR_KBL "i915/kbl_dmc_ver1_04.bin"
> >  MODULE_FIRMWARE(I915_CSR_KBL);
> > --
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO

[Harald Freudenberger]

On 12/19/2017 07:15 PM, Joe Perches wrote:

> Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
>   xargs perl -i -e 'local $/; while (<>) { 
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO\s*|\s*0444\s*)\)?\s*,\s*\1_show\s*,\s*NULL\s*\)/DEVICE_ATTR_RO(\1)/g;
>  print;}'
>
> Signed-off-by: Joe Perches 
> ---
>  arch/arm/mach-pxa/sharpsl_pm.c   |  4 ++--
>  arch/sh/drivers/push-switch.c|  2 +-
>  arch/tile/kernel/sysfs.c | 10 +-
>  drivers/acpi/device_sysfs.c  |  6 +++---
>  drivers/char/ipmi/ipmi_msghandler.c  | 17 -
>  drivers/gpu/drm/i915/i915_sysfs.c|  6 +++---
>  drivers/nvme/host/core.c | 10 +-
>  drivers/s390/cio/css.c   |  8 
>  drivers/s390/cio/device.c|  8 
>  drivers/s390/crypto/ap_card.c|  2 +-

For the s390 AP part,

ACK-by: Harald Freudenberger  Thanks

>  drivers/scsi/hpsa.c  | 10 +-
>  drivers/scsi/lpfc/lpfc_attr.c| 18 --
>  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c |  8 
>  drivers/thermal/thermal_sysfs.c  |  6 +++---
>  sound/soc/soc-core.c |  2 +-
>  sound/soc/soc-dapm.c |  2 +-
>  16 files changed, 58 insertions(+), 61 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
> index 398ba9ba2632..ef9fd9b759cb 100644
> --- a/arch/arm/mach-pxa/sharpsl_pm.c
> +++ b/arch/arm/mach-pxa/sharpsl_pm.c
> @@ -802,8 +802,8 @@ static ssize_t battery_voltage_show(struct device *dev, 
> struct device_attribute
>   return sprintf(buf, "%d\n", sharpsl_pm.battstat.mainbat_voltage);
>  }
>
> -static DEVICE_ATTR(battery_percentage, 0444, battery_percentage_show, NULL);
> -static DEVICE_ATTR(battery_voltage, 0444, battery_voltage_show, NULL);
> +static DEVICE_ATTR_RO(battery_percentage);
> +static DEVICE_ATTR_RO(battery_voltage);
>
>  extern void (*apm_get_power_status)(struct apm_power_info *);
>
> diff --git a/arch/sh/drivers/push-switch.c b/arch/sh/drivers/push-switch.c
> index a17181160233..762bc5619910 100644
> --- a/arch/sh/drivers/push-switch.c
> +++ b/arch/sh/drivers/push-switch.c
> @@ -24,7 +24,7 @@ static ssize_t switch_show(struct device *dev,
>   struct push_switch_platform_info *psw_info = dev->platform_data;
>   return sprintf(buf, "%s\n", psw_info->name);
>  }
> -static DEVICE_ATTR(switch, S_IRUGO, switch_show, NULL);
> +static DEVICE_ATTR_RO(switch);
>
>  static void switch_timer(struct timer_list *t)
>  {
> diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c
> index af5024f0fb5a..b09456a3d77a 100644
> --- a/arch/tile/kernel/sysfs.c
> +++ b/arch/tile/kernel/sysfs.c
> @@ -38,7 +38,7 @@ static ssize_t chip_width_show(struct device *dev,
>  {
>   return sprintf(page, "%u\n", smp_width);
>  }
> -static DEVICE_ATTR(chip_width, 0444, chip_width_show, NULL);
> +static DEVICE_ATTR_RO(chip_width);
>
>  static ssize_t chip_height_show(struct device *dev,
>   struct device_attribute *attr,
> @@ -46,7 +46,7 @@ static ssize_t chip_height_show(struct device *dev,
>  {
>   return sprintf(page, "%u\n", smp_height);
>  }
> -static DEVICE_ATTR(chip_height, 0444, chip_height_show, NULL);
> +static DEVICE_ATTR_RO(chip_height);
>
>  static ssize_t chip_serial_show(struct device *dev,
>   struct device_attribute *attr,
> @@ -54,7 +54,7 @@ static ssize_t chip_serial_show(struct device *dev,
>  {
>   return get_hv_confstr(page, HV_CONFSTR_CHIP_SERIAL_NUM);
>  }
> -static DEVICE_ATTR(chip_serial, 0444, chip_serial_show, NULL);
> +static DEVICE_ATTR_RO(chip_serial);
>
>  static ssize_t chip_revision_show(struct device *dev,
> struct device_attribute *attr,
> @@ -62,7 +62,7 @@ static ssize_t chip_revision_show(struct device *dev,
>  {
>   return get_hv_confstr(page, HV_CONFSTR_CHIP_REV);
>  }
> -static DEVICE_ATTR(chip_revision, 0444, chip_revision_show, NULL);
> +static DEVICE_ATTR_RO(chip_revision);
>
>
>  static ssize_t type_show(struct device *dev,
> @@ -71,7 +71,7 @@ static ssize_t type_show(struct device *dev,
>  {
>   return sprintf(page, "tilera\n");
>  }
> -static DEVICE_ATTR(type, 0444, type_show, NULL);
> +static DEVICE_ATTR_RO(type);
>
>  #define HV_CONF_ATTR(name, conf) \
>   static ssize_t name ## _show(struct device *dev,\
> diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
> index a041689e5701..545e91420cde 100644
> --- a/drivers/acpi/device_sysfs.c
> +++ 

Re: [Intel-gfx] [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO

[Sagi Grimberg]

for the NVMe bits,

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

Re: [Intel-gfx] [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO

[Robert Jarzmik]

"Rafael J. Wysocki"  writes:

> On Tuesday, December 19, 2017 7:15:08 PM CET Joe Perches wrote:
>> Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible.
>> 
>> Done with perl script:
>> 
>> $ git grep -w --name-only DEVICE_ATTR | \
>>   xargs perl -i -e 'local $/; while (<>) { 
>> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO\s*|\s*0444\s*)\)?\s*,\s*\1_show\s*,\s*NULL\s*\)/DEVICE_ATTR_RO(\1)/g;
>>  print;}'
>> 
>> Signed-off-by: Joe Perches 
>> ---
>>  arch/arm/mach-pxa/sharpsl_pm.c   |  4 ++--

For mach-pxa:
Acked-by: Robert Jarzmik 

Cheers.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Misc i915_drv.h cleanups (rev2)

[Patchwork]

== Series Details ==

Series: Misc i915_drv.h cleanups (rev2)
URL   : https://patchwork.freedesktop.org/series/35637/
State : success

== Summary ==

Series 35637v2 Misc i915_drv.h cleanups
https://patchwork.freedesktop.org/api/1.0/series/35637/revisions/2/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 kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:431s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:436s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:499s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:492s
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:476s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:527s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:415s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:474s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:427s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:480s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:522s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:525s
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:441s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:528s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:552s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:492s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:437s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:540s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:407s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:587s
fi-cnl-y total:245  pass:220  dwarn:0   dfail:0   fail:0   skip:24 
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s

c0a64101df89fe312cb41d27e184555400d0e3b9 drm-tip: 2017y-12m-21d-18h-02m-56s UTC 
integration manifest
25bbbaadf1df drm/i915: Dump device info at once
8152b7eebb80 drm/i915: Add pretty printer for runtime part of intel_device_info
696b81fc5097 drm/i915: Update intel_device_info_runtime_init() parameter
64ffd9738a0c drm/i915: Move intel_device_info definitions to its own header
eb9cc008be1f drm/i915: Move opregion definitions to dedicated intel_opregion.h
c4b036f45d6c drm/i915: Move display related definitions to dedicated header
3613e32913d8 drm/i915: Move some utility functions to i915_util.h

== Logs ==

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

[Intel-gfx] [PATCH v2 2/7] drm/i915: Move display related definitions to dedicated header

[Michal Wajdeczko]

We already have separate files for display related code, there
is no reason to keep all display definitions in master header.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
Acked-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h  | 283 +--
 drivers/gpu/drm/i915/intel_display.h | 312 +++
 2 files changed, 313 insertions(+), 282 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_display.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3816968..889a9b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -62,6 +62,7 @@
 #include "intel_uc.h"
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
+#include "intel_display.h"
 
 #include "i915_gem.h"
 #include "i915_gem_context.h"
@@ -243,159 +244,6 @@ static inline uint_fixed_16_16_t 
add_fixed16_u32(uint_fixed_16_16_t add1,
return clamp_u64_to_fixed16(interm_sum);
 }
 
-enum pipe {
-   INVALID_PIPE = -1,
-   PIPE_A = 0,
-   PIPE_B,
-   PIPE_C,
-   _PIPE_EDP,
-   I915_MAX_PIPES = _PIPE_EDP
-};
-#define pipe_name(p) ((p) + 'A')
-
-enum transcoder {
-   TRANSCODER_A = 0,
-   TRANSCODER_B,
-   TRANSCODER_C,
-   TRANSCODER_EDP,
-   TRANSCODER_DSI_A,
-   TRANSCODER_DSI_C,
-   I915_MAX_TRANSCODERS
-};
-
-static inline const char *transcoder_name(enum transcoder transcoder)
-{
-   switch (transcoder) {
-   case TRANSCODER_A:
-   return "A";
-   case TRANSCODER_B:
-   return "B";
-   case TRANSCODER_C:
-   return "C";
-   case TRANSCODER_EDP:
-   return "EDP";
-   case TRANSCODER_DSI_A:
-   return "DSI A";
-   case TRANSCODER_DSI_C:
-   return "DSI C";
-   default:
-   return "";
-   }
-}
-
-static inline bool transcoder_is_dsi(enum transcoder transcoder)
-{
-   return transcoder == TRANSCODER_DSI_A || transcoder == TRANSCODER_DSI_C;
-}
-
-/*
- * Global legacy plane identifier. Valid only for primary/sprite
- * planes on pre-g4x, and only for primary planes on g4x-bdw.
- */
-enum i9xx_plane_id {
-   PLANE_A,
-   PLANE_B,
-   PLANE_C,
-};
-#define plane_name(p) ((p) + 'A')
-
-#define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)->num_sprites[(p)] + (s) 
+ 'A')
-
-/*
- * Per-pipe plane identifier.
- * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
- * number of planes per CRTC.  Not all platforms really have this many planes,
- * which means some arrays of size I915_MAX_PLANES may have unused entries
- * between the topmost sprite plane and the cursor plane.
- *
- * This is expected to be passed to various register macros
- * (eg. PLANE_CTL(), PS_PLANE_SEL(), etc.) so adjust with care.
- */
-enum plane_id {
-   PLANE_PRIMARY,
-   PLANE_SPRITE0,
-   PLANE_SPRITE1,
-   PLANE_SPRITE2,
-   PLANE_CURSOR,
-   I915_MAX_PLANES,
-};
-
-#define for_each_plane_id_on_crtc(__crtc, __p) \
-   for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
-   for_each_if ((__crtc)->plane_ids_mask & BIT(__p))
-
-enum port {
-   PORT_NONE = -1,
-   PORT_A = 0,
-   PORT_B,
-   PORT_C,
-   PORT_D,
-   PORT_E,
-   I915_MAX_PORTS
-};
-#define port_name(p) ((p) + 'A')
-
-#define I915_NUM_PHYS_VLV 2
-
-enum dpio_channel {
-   DPIO_CH0,
-   DPIO_CH1
-};
-
-enum dpio_phy {
-   DPIO_PHY0,
-   DPIO_PHY1,
-   DPIO_PHY2,
-};
-
-enum intel_display_power_domain {
-   POWER_DOMAIN_PIPE_A,
-   POWER_DOMAIN_PIPE_B,
-   POWER_DOMAIN_PIPE_C,
-   POWER_DOMAIN_PIPE_A_PANEL_FITTER,
-   POWER_DOMAIN_PIPE_B_PANEL_FITTER,
-   POWER_DOMAIN_PIPE_C_PANEL_FITTER,
-   POWER_DOMAIN_TRANSCODER_A,
-   POWER_DOMAIN_TRANSCODER_B,
-   POWER_DOMAIN_TRANSCODER_C,
-   POWER_DOMAIN_TRANSCODER_EDP,
-   POWER_DOMAIN_TRANSCODER_DSI_A,
-   POWER_DOMAIN_TRANSCODER_DSI_C,
-   POWER_DOMAIN_PORT_DDI_A_LANES,
-   POWER_DOMAIN_PORT_DDI_B_LANES,
-   POWER_DOMAIN_PORT_DDI_C_LANES,
-   POWER_DOMAIN_PORT_DDI_D_LANES,
-   POWER_DOMAIN_PORT_DDI_E_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_DSI,
-   POWER_DOMAIN_PORT_CRT,
-   POWER_DOMAIN_PORT_OTHER,
-   POWER_DOMAIN_VGA,
-   POWER_DOMAIN_AUDIO,
-   POWER_DOMAIN_PLLS,
-   POWER_DOMAIN_AUX_A,
-   POWER_DOMAIN_AUX_B,
-   POWER_DOMAIN_AUX_C,
-   POWER_DOMAIN_AUX_D,
-   POWER_DOMAIN_GMBUS,
-   POWER_DOMAIN_MODESET,
-   

[Intel-gfx] [PATCH v2 7/7] drm/i915: Dump device info at once

[Michal Wajdeczko]

We are dumping device info separately for sw_only and runtime part
but to simplify the code we can also do it from one place once
we complete driver load.

v2: use dedicated welcome function (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5bf4f58..6c8da9d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -931,12 +931,6 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
intel_display_crc_init(dev_priv);
 
-   if (drm_debug & DRM_UT_DRIVER) {
-   struct drm_printer p = drm_debug_printer("i915 device info:");
-
-   intel_device_info_dump(_priv->info, );
-   }
-
intel_detect_preproduction_hw(dev_priv);
 
return 0;
@@ -1089,11 +1083,6 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
 
intel_device_info_runtime_init(mkwrite_device_info(dev_priv));
-   if (drm_debug & DRM_UT_DRIVER) {
-   struct drm_printer p = drm_debug_printer("i915 device info:");
-
-   intel_device_info_dump_runtime(_priv->info, );
-   }
 
intel_sanitize_options(dev_priv);
 
@@ -1303,6 +1292,21 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
i915_gem_shrinker_unregister(dev_priv);
 }
 
+static void i915_welcome_messages(struct drm_i915_private *dev_priv)
+{
+   if (drm_debug & DRM_UT_DRIVER) {
+   struct drm_printer p = drm_debug_printer("i915 device info:");
+
+   intel_device_info_dump(_priv->info, );
+   intel_device_info_dump_runtime(_priv->info, );
+   }
+
+   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
+   DRM_INFO("DRM_I915_DEBUG enabled\n");
+   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+   DRM_INFO("DRM_I915_DEBUG_GEM enabled\n");
+}
+
 /**
  * i915_driver_load - setup chip and create an initial config
  * @pdev: PCI device
@@ -1388,13 +1392,10 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
intel_init_ipc(dev_priv);
 
-   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
-   DRM_INFO("DRM_I915_DEBUG enabled\n");
-   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
-   DRM_INFO("DRM_I915_DEBUG_GEM enabled\n");
-
intel_runtime_pm_put(dev_priv);
 
+   i915_welcome_messages(dev_priv);
+
return 0;
 
 out_cleanup_hw:
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 5/7] drm/i915: Update intel_device_info_runtime_init() parameter

[Michal Wajdeczko]

As we try to follow object-verb pattern in our functions, update
intel_device_info_runtime_init() parameter from dev_priv to info.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c | 10 +++---
 drivers/gpu/drm/i915/intel_device_info.h |  2 +-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6f14986..06eea8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1088,7 +1088,7 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
if (i915_inject_load_failure())
return -ENODEV;
 
-   intel_device_info_runtime_init(dev_priv);
+   intel_device_info_runtime_init(mkwrite_device_info(dev_priv));
 
intel_sanitize_options(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index f205054..8e050b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -431,7 +431,10 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
return 0;
 }
 
-/*
+/**
+ * intel_device_info_runtime_init - initialize runtime info
+ * @info: intel device info struct
+ *
  * Determine various intel_device_info fields at runtime.
  *
  * Use it when either:
@@ -444,9 +447,10 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
  *   - after the PCH has been detected,
  *   - before the first usage of the fields it can tweak.
  */
-void intel_device_info_runtime_init(struct drm_i915_private *dev_priv)
+void intel_device_info_runtime_init(struct intel_device_info *info)
 {
-   struct intel_device_info *info = mkwrite_device_info(dev_priv);
+   struct drm_i915_private *dev_priv =
+   container_of(info, struct drm_i915_private, info);
enum pipe pipe;
 
if (INTEL_GEN(dev_priv) >= 10) {
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 845df57..6f7a3d4 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -172,7 +172,7 @@ static inline unsigned int sseu_subslice_total(const struct 
sseu_dev_info *sseu)
 
 const char *intel_platform_name(enum intel_platform platform);
 
-void intel_device_info_runtime_init(struct drm_i915_private *dev_priv);
+void intel_device_info_runtime_init(struct intel_device_info *info);
 void intel_device_info_dump(const struct intel_device_info *info,
struct drm_printer *p);
 void intel_device_info_dump_flags(const struct intel_device_info *info,
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 6/7] drm/i915: Add pretty printer for runtime part of intel_device_info

[Michal Wajdeczko]

During initialization of the runtime part of the intel_device_info
we are dumping that part using DRM_DEBUG_DRIVER mechanism.
As we already have pretty printer for const part of the info,
make similar function for the runtime part and use it separately.

v2: add runtime dump to debugfs (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  1 +
 drivers/gpu/drm/i915/i915_drv.c  |  5 
 drivers/gpu/drm/i915/intel_device_info.c | 44 +++-
 drivers/gpu/drm/i915/intel_device_info.h |  2 ++
 4 files changed, 34 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3affcaa..e968aea 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -48,6 +48,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev_priv));
 
intel_device_info_dump_flags(info, );
+   intel_device_info_dump_runtime(info, );
 
kernel_param_lock(THIS_MODULE);
i915_params_dump(_modparams, );
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 06eea8d..5bf4f58 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1089,6 +1089,11 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
 
intel_device_info_runtime_init(mkwrite_device_info(dev_priv));
+   if (drm_debug & DRM_UT_DRIVER) {
+   struct drm_printer p = drm_debug_printer("i915 device info:");
+
+   intel_device_info_dump_runtime(_priv->info, );
+   }
 
intel_sanitize_options(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 8e050b5..d28592e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -78,6 +78,32 @@ void intel_device_info_dump_flags(const struct 
intel_device_info *info,
 #undef PRINT_FLAG
 }
 
+static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p)
+{
+   drm_printf(p, "slice mask: %04x\n", sseu->slice_mask);
+   drm_printf(p, "slice total: %u\n", hweight8(sseu->slice_mask));
+   drm_printf(p, "subslice total: %u\n", sseu_subslice_total(sseu));
+   drm_printf(p, "subslice mask %04x\n", sseu->subslice_mask);
+   drm_printf(p, "subslice per slice: %u\n",
+  hweight8(sseu->subslice_mask));
+   drm_printf(p, "EU total: %u\n", sseu->eu_total);
+   drm_printf(p, "EU per subslice: %u\n", sseu->eu_per_subslice);
+   drm_printf(p, "has slice power gating: %s\n",
+  yesno(sseu->has_slice_pg));
+   drm_printf(p, "has subslice power gating: %s\n",
+  yesno(sseu->has_subslice_pg));
+   drm_printf(p, "has EU power gating: %s\n", yesno(sseu->has_eu_pg));
+}
+
+void intel_device_info_dump_runtime(const struct intel_device_info *info,
+   struct drm_printer *p)
+{
+   sseu_dump(>sseu, p);
+
+   drm_printf(p, "CS timestamp frequency: %u kHz\n",
+  info->cs_timestamp_frequency_khz);
+}
+
 void intel_device_info_dump(const struct intel_device_info *info,
struct drm_printer *p)
 {
@@ -558,22 +584,4 @@ void intel_device_info_runtime_init(struct 
intel_device_info *info)
 
/* Initialize command stream timestamp frequency */
info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv);
-
-   DRM_DEBUG_DRIVER("slice mask: %04x\n", info->sseu.slice_mask);
-   DRM_DEBUG_DRIVER("slice total: %u\n", hweight8(info->sseu.slice_mask));
-   DRM_DEBUG_DRIVER("subslice total: %u\n",
-sseu_subslice_total(>sseu));
-   DRM_DEBUG_DRIVER("subslice mask %04x\n", info->sseu.subslice_mask);
-   DRM_DEBUG_DRIVER("subslice per slice: %u\n",
-hweight8(info->sseu.subslice_mask));
-   DRM_DEBUG_DRIVER("EU total: %u\n", info->sseu.eu_total);
-   DRM_DEBUG_DRIVER("EU per subslice: %u\n", info->sseu.eu_per_subslice);
-   DRM_DEBUG_DRIVER("has slice power gating: %s\n",
-info->sseu.has_slice_pg ? "y" : "n");
-   DRM_DEBUG_DRIVER("has subslice power gating: %s\n",
-info->sseu.has_subslice_pg ? "y" : "n");
-   DRM_DEBUG_DRIVER("has EU power gating: %s\n",
-info->sseu.has_eu_pg ? "y" : "n");
-   DRM_DEBUG_DRIVER("CS timestamp frequency: %u kHz\n",
-info->cs_timestamp_frequency_khz);
 }
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 6f7a3d4..49cb27b 100644
--- 

[Intel-gfx] [PATCH v2 3/7] drm/i915: Move opregion definitions to dedicated intel_opregion.h

[Michal Wajdeczko]

We already have dedicated file for opregion related code, dedicated
header will make our life easier.

v2: reorder includes (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Reviewed-by: Chris Wilson 
Acked-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h   | 63 ++
 drivers/gpu/drm/i915/intel_opregion.c |  2 +
 drivers/gpu/drm/i915/intel_opregion.h | 99 +++
 3 files changed, 105 insertions(+), 59 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_opregion.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 889a9b1..be75605 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -56,13 +56,14 @@
 #include "i915_reg.h"
 #include "i915_utils.h"
 
-#include "intel_uncore.h"
 #include "intel_bios.h"
+#include "intel_display.h"
 #include "intel_dpll_mgr.h"
-#include "intel_uc.h"
 #include "intel_lrc.h"
+#include "intel_opregion.h"
 #include "intel_ringbuffer.h"
-#include "intel_display.h"
+#include "intel_uncore.h"
+#include "intel_uc.h"
 
 #include "i915_gem.h"
 #include "i915_gem_context.h"
@@ -355,27 +356,6 @@ struct drm_i915_file_private {
 #define DRIVER_MINOR   6
 #define DRIVER_PATCHLEVEL  0
 
-struct opregion_header;
-struct opregion_acpi;
-struct opregion_swsci;
-struct opregion_asle;
-
-struct intel_opregion {
-   struct opregion_header *header;
-   struct opregion_acpi *acpi;
-   struct opregion_swsci *swsci;
-   u32 swsci_gbda_sub_functions;
-   u32 swsci_sbcb_sub_functions;
-   struct opregion_asle *asle;
-   void *rvda;
-   void *vbt_firmware;
-   const void *vbt;
-   u32 vbt_size;
-   u32 *lid_state;
-   struct work_struct asle_work;
-};
-#define OPREGION_SIZE(8*1024)
-
 struct intel_overlay;
 struct intel_overlay_error_state;
 
@@ -3816,41 +3796,6 @@ bool intel_bios_is_port_hpd_inverted(struct 
drm_i915_private *dev_priv,
 bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
enum port port);
 
-
-/* intel_opregion.c */
-#ifdef CONFIG_ACPI
-extern int intel_opregion_setup(struct drm_i915_private *dev_priv);
-extern void intel_opregion_register(struct drm_i915_private *dev_priv);
-extern void intel_opregion_unregister(struct drm_i915_private *dev_priv);
-extern void intel_opregion_asle_intr(struct drm_i915_private *dev_priv);
-extern int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,
-bool enable);
-extern int intel_opregion_notify_adapter(struct drm_i915_private *dev_priv,
-pci_power_t state);
-extern int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv);
-#else
-static inline int intel_opregion_setup(struct drm_i915_private *dev) { return 
0; }
-static inline void intel_opregion_register(struct drm_i915_private *dev_priv) 
{ }
-static inline void intel_opregion_unregister(struct drm_i915_private 
*dev_priv) { }
-static inline void intel_opregion_asle_intr(struct drm_i915_private *dev_priv)
-{
-}
-static inline int
-intel_opregion_notify_encoder(struct intel_encoder *intel_encoder, bool enable)
-{
-   return 0;
-}
-static inline int
-intel_opregion_notify_adapter(struct drm_i915_private *dev, pci_power_t state)
-{
-   return 0;
-}
-static inline int intel_opregion_get_panel_type(struct drm_i915_private *dev)
-{
-   return -ENODEV;
-}
-#endif
-
 /* intel_acpi.c */
 #ifdef CONFIG_ACPI
 extern void intel_register_dsm_handler(void);
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index fc65f5e..c58e5f5 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -32,6 +32,8 @@
 
 #include 
 #include 
+
+#include "intel_opregion.h"
 #include "i915_drv.h"
 #include "intel_drv.h"
 
diff --git a/drivers/gpu/drm/i915/intel_opregion.h 
b/drivers/gpu/drm/i915/intel_opregion.h
new file mode 100644
index 000..cf0b5c3
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_opregion.h
@@ -0,0 +1,99 @@
+/*
+ * Copyright © 2008-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 

[Intel-gfx] [PATCH 0/8] Misc i915_drv.h cleanups

[Michal Wajdeczko]

Our main header is huge. Lets try to make some cleanup.

Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 

v2: fixed16 changes moved to other series

Michal Wajdeczko (7):
  drm/i915: Move some utility functions to i915_util.h
  drm/i915: Move display related definitions to dedicated header
  drm/i915: Move opregion definitions to dedicated intel_opregion.h
  drm/i915: Move intel_device_info definitions to its own header
  drm/i915: Update intel_device_info_runtime_init() parameter
  drm/i915: Add pretty printer for runtime part of intel_device_info
  drm/i915: Dump device info at once

 drivers/gpu/drm/i915/i915_debugfs.c  |   1 +
 drivers/gpu/drm/i915/i915_drv.c  |  30 +-
 drivers/gpu/drm/i915/i915_drv.h  | 498 +--
 drivers/gpu/drm/i915/i915_utils.h|  15 +
 drivers/gpu/drm/i915/intel_device_info.c |  55 ++--
 drivers/gpu/drm/i915/intel_device_info.h | 183 
 drivers/gpu/drm/i915/intel_display.h | 312 +++
 drivers/gpu/drm/i915/intel_opregion.c|   2 +
 drivers/gpu/drm/i915/intel_opregion.h|  99 ++
 9 files changed, 669 insertions(+), 526 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_device_info.h
 create mode 100644 drivers/gpu/drm/i915/intel_display.h
 create mode 100644 drivers/gpu/drm/i915/intel_opregion.h

-- 
1.9.1

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

[Intel-gfx] [PATCH v2 4/7] drm/i915: Move intel_device_info definitions to its own header

[Michal Wajdeczko]

We already keep intel_device_info functions in dedicated file.
Add matching header file and move related definitions there.

v2: add gen boundaries (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
Acked-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h  | 139 +---
 drivers/gpu/drm/i915/intel_device_info.c |   1 +
 drivers/gpu/drm/i915/intel_device_info.h | 181 +++
 3 files changed, 183 insertions(+), 138 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_device_info.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be75605..4b943cd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -57,6 +57,7 @@
 #include "i915_utils.h"
 
 #include "intel_bios.h"
+#include "intel_device_info.h"
 #include "intel_display.h"
 #include "intel_dpll_mgr.h"
 #include "intel_lrc.h"
@@ -448,137 +449,6 @@ struct intel_csr {
uint32_t allowed_dc_mask;
 };
 
-#define DEV_INFO_FOR_EACH_FLAG(func) \
-   func(is_mobile); \
-   func(is_lp); \
-   func(is_alpha_support); \
-   /* Keep has_* in alphabetical order */ \
-   func(has_64bit_reloc); \
-   func(has_aliasing_ppgtt); \
-   func(has_csr); \
-   func(has_ddi); \
-   func(has_dp_mst); \
-   func(has_reset_engine); \
-   func(has_fbc); \
-   func(has_fpga_dbg); \
-   func(has_full_ppgtt); \
-   func(has_full_48bit_ppgtt); \
-   func(has_gmch_display); \
-   func(has_guc); \
-   func(has_guc_ct); \
-   func(has_hotplug); \
-   func(has_l3_dpf); \
-   func(has_llc); \
-   func(has_logical_ring_contexts); \
-   func(has_logical_ring_preemption); \
-   func(has_overlay); \
-   func(has_pooled_eu); \
-   func(has_psr); \
-   func(has_rc6); \
-   func(has_rc6p); \
-   func(has_resource_streamer); \
-   func(has_runtime_pm); \
-   func(has_snoop); \
-   func(unfenced_needs_alignment); \
-   func(cursor_needs_physical); \
-   func(hws_needs_physical); \
-   func(overlay_needs_physical); \
-   func(supports_tv); \
-   func(has_ipc);
-
-struct sseu_dev_info {
-   u8 slice_mask;
-   u8 subslice_mask;
-   u8 eu_total;
-   u8 eu_per_subslice;
-   u8 min_eu_in_pool;
-   /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
-   u8 subslice_7eu[3];
-   u8 has_slice_pg:1;
-   u8 has_subslice_pg:1;
-   u8 has_eu_pg:1;
-};
-
-static inline unsigned int sseu_subslice_total(const struct sseu_dev_info 
*sseu)
-{
-   return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
-}
-
-/* Keep in gen based order, and chronological order within a gen */
-enum intel_platform {
-   INTEL_PLATFORM_UNINITIALIZED = 0,
-   INTEL_I830,
-   INTEL_I845G,
-   INTEL_I85X,
-   INTEL_I865G,
-   INTEL_I915G,
-   INTEL_I915GM,
-   INTEL_I945G,
-   INTEL_I945GM,
-   INTEL_G33,
-   INTEL_PINEVIEW,
-   INTEL_I965G,
-   INTEL_I965GM,
-   INTEL_G45,
-   INTEL_GM45,
-   INTEL_IRONLAKE,
-   INTEL_SANDYBRIDGE,
-   INTEL_IVYBRIDGE,
-   INTEL_VALLEYVIEW,
-   INTEL_HASWELL,
-   INTEL_BROADWELL,
-   INTEL_CHERRYVIEW,
-   INTEL_SKYLAKE,
-   INTEL_BROXTON,
-   INTEL_KABYLAKE,
-   INTEL_GEMINILAKE,
-   INTEL_COFFEELAKE,
-   INTEL_CANNONLAKE,
-   INTEL_MAX_PLATFORMS
-};
-
-struct intel_device_info {
-   u16 device_id;
-   u16 gen_mask;
-
-   u8 gen;
-   u8 gt; /* GT number, 0 if undefined */
-   u8 num_rings;
-   u8 ring_mask; /* Rings supported by the HW */
-
-   enum intel_platform platform;
-   u32 platform_mask;
-
-   u32 display_mmio_offset;
-
-   u8 num_pipes;
-   u8 num_sprites[I915_MAX_PIPES];
-   u8 num_scalers[I915_MAX_PIPES];
-
-   unsigned int page_sizes; /* page sizes supported by the HW */
-
-#define DEFINE_FLAG(name) u8 name:1
-   DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG);
-#undef DEFINE_FLAG
-   u16 ddb_size; /* in blocks */
-
-   /* Register offsets for the various display pipes and transcoders */
-   int pipe_offsets[I915_MAX_TRANSCODERS];
-   int trans_offsets[I915_MAX_TRANSCODERS];
-   int palette_offsets[I915_MAX_PIPES];
-   int cursor_offsets[I915_MAX_PIPES];
-
-   /* Slice/subslice/EU info */
-   struct sseu_dev_info sseu;
-
-   u32 cs_timestamp_frequency_khz;
-
-   struct color_luts {
-   u16 degamma_lut_size;
-   u16 gamma_lut_size;
-   } color;
-};
-
 struct intel_display_error_state;
 
 struct i915_gpu_state {
@@ -3812,13 +3682,6 @@ bool intel_bios_is_lspcon_present(struct 
drm_i915_private 

[Intel-gfx] [PATCH v2 1/7] drm/i915: Move some utility functions to i915_util.h

[Michal Wajdeczko]

We have dedicated header file for utility functions and macros.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
Acked-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h   | 15 ---
 drivers/gpu/drm/i915/i915_utils.h | 15 +++
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ca2a619..3816968 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -243,21 +243,6 @@ static inline uint_fixed_16_16_t 
add_fixed16_u32(uint_fixed_16_16_t add1,
return clamp_u64_to_fixed16(interm_sum);
 }
 
-static inline const char *yesno(bool v)
-{
-   return v ? "yes" : "no";
-}
-
-static inline const char *onoff(bool v)
-{
-   return v ? "on" : "off";
-}
-
-static inline const char *enableddisabled(bool v)
-{
-   return v ? "enabled" : "disabled";
-}
-
 enum pipe {
INVALID_PIPE = -1,
PIPE_A = 0,
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 8d07764..51dbfe5 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -140,4 +140,19 @@ static inline void drain_delayed_work(struct delayed_work 
*dw)
} while (delayed_work_pending(dw));
 }
 
+static inline const char *yesno(bool v)
+{
+   return v ? "yes" : "no";
+}
+
+static inline const char *onoff(bool v)
+{
+   return v ? "on" : "off";
+}
+
+static inline const char *enableddisabled(bool v)
+{
+   return v ? "enabled" : "disabled";
+}
+
 #endif /* !__I915_UTILS_H */
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Manasi Navare]

On Wed, Dec 20, 2017 at 10:36:24PM -0800, Dhinakaran Pandiyan wrote:
> Occasionally there are LINK_ADDRESS sideband messages timing out with the
> Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> failures lead to the display not coming up on boot. Power cycling the port
> corresponding to the MST monitor's branch device and resending the message
> fixes the issue. I am not entirely sure if this is specific to my setup.
> However, as the power state is toggled conditionally on LINK_ADDRESS
> timeouts, this should not affect the working cases.
> 

> Cc: Lyude 
> Cc: Dave Airlie 
> Cc: Jani Nikula 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 70dcfa58d3c2..e06defcdcf18 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> drm_dp_mst_topology_mgr *mgr,
>   int len;
>   struct drm_dp_sideband_msg_tx *txmsg;
>   int ret;
> + int attempts = 5;
>

Does the spec say this should be retried 5 times or is this just an
experimental number?
We have such magical numbers for retries all over the DP code and that makes 
debugging
harder later, so atleast a comment of why its 5 would help.
  
> - txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> +retry:   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
>   if (!txmsg)
>   return;
>  
> @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> drm_dp_mst_topology_mgr *mgr,
>   }
>   (*mgr->cbs->hotplug)(mgr);
>   }
> + } else if (attempts--) {

This should be --attempts if you want the total attempts to be 5

Manasi

> + kfree(txmsg);
> + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> +  false);
> + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> +  true);
> + DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> + goto retry;
>   } else {
>   mstb->link_address_sent = false;
> - DRM_DEBUG_KMS("link address failed %d\n", ret);
> + DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
>   }
>  
>   kfree(txmsg);
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: add support for specifying DMC firmware override by module param

[Srivatsa, Anusha]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Jani Nikula
>Sent: Wednesday, November 22, 2017 8:20 AM
>To: Joonas Lahtinen ; David Weinehall
>
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915: add support for specifying DMC
>firmware override by module param
>
>On Wed, 22 Nov 2017, Joonas Lahtinen 
>wrote:
>> On Tue, 2017-11-21 at 23:54 +0200, Jani Nikula wrote:
>>> On Tue, 21 Nov 2017, David Weinehall 
>wrote:
>>> > On Tue, Nov 21, 2017 at 01:51:29PM +0200, Jani Nikula wrote:
>>> > > Use i915.dmc_firmware_path to override default firmware for the
>>> > > platform and bypassing version checks.
>>> > >
>>> > > Signed-off-by: Jani Nikula 
>>> > >
>>> > > ---
>>> > >
>>> > > Untested.
>>> >
>>> > Yeah, it kind of shows.  It fails to compile :D
>>>
>>> Oops. I was anxious to get the patch on the list in the heat of IRC
>>> discussion, and just added the disclaimer instead of doing this
>>> properly... *blush*
>>>
>>> >
>>> > But if you chuck in:
>>> >
>>> > param(char *, dmc_firmware_path, NULL) \
>>
>> I think I already raised my suggestion earlier, but here it goes again.
>> Maybe we should consider consolidating these into:
>>
>> i915.firmware=guc:whatever.bin i915.firmware=dmc:whatever.bin
>
>I don't think that's possible. I didn't double check but I think you only get 
>one
>value from the module param code. Unless you roll your own modparam hooks,
>which is best avoided.
>
>> Then something like "i915.firmware=guc:disable" could be supported,
>> too.
>
>i915.dmc_firmware_path="" could mean disable.
>
>BR,
>Jani.
>
>
>>
>> Regards, Joonas
>>
>>> >
>>> > in i915_params.h
>>> >
>>> > Things work correctly and you can use:
>>> >
>>> > Tested-by: David Weinehall 
>>> > Reviewed-by: David Weinehall 
>>>
>>> Thanks. But let's wait for more input on whether this is really what
>>> people want. Perhaps this is useful *regardless* of the outcome of
>>> the other discussions.

I believe this patch is going to be useful anyway IT would make things a 
lot easier for testing purpose. I think we should get this merged.

Does anyone have any concerns?

Anusha 
>>> BR,
>>> Jani.
>>>
>>>
>>> >
>>> > > ---
>>> > >  drivers/gpu/drm/i915/i915_params.c | 3 +++
>>> > >  drivers/gpu/drm/i915/intel_csr.c   | 9 +++--
>>> > >  2 files changed, 10 insertions(+), 2 deletions(-)
>>> > >
>>> > > diff --git a/drivers/gpu/drm/i915/i915_params.c
>>> > > b/drivers/gpu/drm/i915/i915_params.c
>>> > > index 3328147b4863..c11ad6d67fa9 100644
>>> > > --- a/drivers/gpu/drm/i915/i915_params.c
>>> > > +++ b/drivers/gpu/drm/i915/i915_params.c
>>> > > @@ -171,6 +171,9 @@ i915_param_named_unsafe(guc_firmware_path,
>>> > > charp, 0400,  i915_param_named_unsafe(huc_firmware_path, charp,
>0400,
>>> > > "HuC firmware path to use instead of the default one");
>>> > >
>>> > > +i915_param_named_unsafe(dmc_firmware_path, charp, 0400,
>>> > > +   "DMC firmware path to use instead of the default one");
>>> > > +
>>> > >  i915_param_named_unsafe(enable_dp_mst, bool, 0600,
>>> > > "Enable multi-stream transport (MST) for new DisplayPort sinks.
>>> > > (default: true)");
>>> > >
>>> > > diff --git a/drivers/gpu/drm/i915/intel_csr.c
>>> > > b/drivers/gpu/drm/i915/intel_csr.c
>>> > > index 77d8b3d483ca..82db376ec7e1 100644
>>> > > --- a/drivers/gpu/drm/i915/intel_csr.c
>>> > > +++ b/drivers/gpu/drm/i915/intel_csr.c
>>> > > @@ -296,7 +296,10 @@ static uint32_t *parse_csr_fw(struct
>>> > > drm_i915_private *dev_priv,
>>> > >
>>> > > csr->version = css_header->version;
>>> > >
>>> > > -   if (IS_CANNONLAKE(dev_priv)) {
>>> > > +   if (csr->fw_path == i915_modparams.dmc_firmware_path) {
>>> > > +   /* Bypass version check for firmware override. */
>>> > > +   required_version = csr->version;
>>> > > +   } else if (IS_CANNONLAKE(dev_priv)) {
>>> > > required_version = CNL_CSR_VERSION_REQUIRED;
>>> > > } else if (IS_GEMINILAKE(dev_priv)) {
>>> > > required_version = GLK_CSR_VERSION_REQUIRED; @@ -451,7
>+454,9
>>> > > @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
>>> > > if (!HAS_CSR(dev_priv))
>>> > > return;
>>> > >
>>> > > -   if (IS_CANNONLAKE(dev_priv))
>>> > > +   if (i915_modparams.dmc_firmware_path)
>>> > > +   csr->fw_path = i915_modparams.dmc_firmware_path;
>>> > > +   else if (IS_CANNONLAKE(dev_priv))
>>> > > csr->fw_path = I915_CSR_CNL;
>>> > > else if (IS_GEMINILAKE(dev_priv))
>>> > > csr->fw_path = I915_CSR_GLK;
>>> > > --
>>> > > 2.11.0
>>> > >
>>> > > ___
>>> > > Intel-gfx 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pmu: Only enumerate available counters in sysfs

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Only enumerate available counters in sysfs
URL   : https://patchwork.freedesktop.org/series/35689/
State : success

== Summary ==

Test pm_rpm:
Subgroup system-suspend:
skip   -> PASS   (shard-hsw) fdo#103375 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test kms_vblank:
Subgroup accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-snb)
Subgroup sysfs-reader:
skip   -> PASS   (shard-hsw)
Test kms_flip:
Subgroup flip-vs-panning-vs-hang-interruptible:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-hsw) fdo#104218

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218

shard-hswtotal:2640 pass:1500 dwarn:1   dfail:0   fail:12  skip:1126 
time:8903s
shard-snbtotal:2640 pass:1281 dwarn:2   dfail:0   fail:11  skip:1345 
time:7461s
Blacklisted hosts:
shard-apltotal:2712 pass:1686 dwarn:2   dfail:0   fail:23  skip:1001 
time:12467s
shard-kbltotal:2618 pass:1742 dwarn:1   dfail:0   fail:23  skip:851 
time:10043s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7557/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: Show FBC worker status in debugfs

[Chris Wilson]

Quoting Paulo Zanoni (2017-12-21 17:20:50)
> Em Qua, 2017-12-20 às 20:58 +, Chris Wilson escreveu:
> > Include the pending update from the FBC worker in i915_fbc_status.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 13 +
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index c4780f085428..931037a458be 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1581,18 +1581,23 @@ static int i915_frontbuffer_tracking(struct
> > seq_file *m, void *unused)
> >  static int i915_fbc_status(struct seq_file *m, void *unused)
> >  {
> >   struct drm_i915_private *dev_priv = node_to_i915(m-
> > >private);
> > + struct intel_fbc *fbc = _priv->fbc;
> >  
> >   if (!HAS_FBC(dev_priv))
> >   return -ENODEV;
> >  
> >   intel_runtime_pm_get(dev_priv);
> > - mutex_lock(_priv->fbc.lock);
> > + mutex_lock(>lock);
> >  
> >   if (intel_fbc_is_active(dev_priv))
> >   seq_puts(m, "FBC enabled\n");
> >   else
> > - seq_printf(m, "FBC disabled: %s\n",
> > -    dev_priv->fbc.no_fbc_reason);
> > + seq_printf(m, "FBC disabled: %s\n", fbc-
> > >no_fbc_reason);
> > +
> > + if (fbc->work.scheduled)
> > + seq_printf(m, "FBC worker scheduled on vblank %d, 
> 
> vblank %u since this is u32?
> 
> Reviewed-by: Paulo Zanoni 

Deal. Thanks,
-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 drm/i915/pmu: Only enumerate available counters in sysfs

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Only enumerate available counters in sysfs
URL   : https://patchwork.freedesktop.org/series/35689/
State : success

== Summary ==

Series 35689v1 drm/i915/pmu: Only enumerate available counters in sysfs
https://patchwork.freedesktop.org/api/1.0/series/35689/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

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:435s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:368s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:456s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:259s
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:474s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:439s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:433s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:239s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
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:403s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:467s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:420s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:470s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:509s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:511s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:491s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:522s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:541s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:435s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:534s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:410s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:633s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s

4b29b69aee8cf163fa934b8416dfb7685a9d8bcd drm-tip: 2017y-12m-21d-11h-10m-15s UTC 
integration manifest
df50bfe75a32 drm/i915/pmu: Only enumerate available counters in sysfs

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7557/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: Show FBC worker status in debugfs

[Paulo Zanoni]

Em Qua, 2017-12-20 às 20:58 +, Chris Wilson escreveu:
> Include the pending update from the FBC worker in i915_fbc_status.
> 
> Signed-off-by: Chris Wilson 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c4780f085428..931037a458be 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1581,18 +1581,23 @@ static int i915_frontbuffer_tracking(struct
> seq_file *m, void *unused)
>  static int i915_fbc_status(struct seq_file *m, void *unused)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m-
> >private);
> + struct intel_fbc *fbc = _priv->fbc;
>  
>   if (!HAS_FBC(dev_priv))
>   return -ENODEV;
>  
>   intel_runtime_pm_get(dev_priv);
> - mutex_lock(_priv->fbc.lock);
> + mutex_lock(>lock);
>  
>   if (intel_fbc_is_active(dev_priv))
>   seq_puts(m, "FBC enabled\n");
>   else
> - seq_printf(m, "FBC disabled: %s\n",
> -    dev_priv->fbc.no_fbc_reason);
> + seq_printf(m, "FBC disabled: %s\n", fbc-
> >no_fbc_reason);
> +
> + if (fbc->work.scheduled)
> + seq_printf(m, "FBC worker scheduled on vblank %d, 

vblank %u since this is u32?

Reviewed-by: Paulo Zanoni 

> now %llu\n",
> +    fbc->work.scheduled_vblank,
> +    drm_crtc_vblank_count(>crtc->base));
>  
>   if (intel_fbc_is_active(dev_priv)) {
>   u32 mask;
> @@ -1612,7 +1617,7 @@ static int i915_fbc_status(struct seq_file *m,
> void *unused)
>   seq_printf(m, "Compressing: %s\n", yesno(mask));
>   }
>  
> - mutex_unlock(_priv->fbc.lock);
> + mutex_unlock(>lock);
>   intel_runtime_pm_put(dev_priv);
>  
>   return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/pmu: Only enumerate available counters in sysfs

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Switch over to dynamically creating device attributes, which are in turn
used by the perf core to expose available counters in sysfs.

This way we do not expose counters which are not avaiable on the current
platform, and are so more consistent between what we reply to open
attempts via the perf_event_open(2), and what is discoverable in sysfs.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 326 ++--
 drivers/gpu/drm/i915/i915_pmu.h |   8 +
 2 files changed, 256 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 55a8a1e29424..989e1ccd03e9 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -290,23 +290,44 @@ static void i915_pmu_event_destroy(struct perf_event 
*event)
WARN_ON(event->parent);
 }
 
-static int engine_event_init(struct perf_event *event)
+static int
+engine_event_status(struct intel_engine_cs *engine,
+   enum drm_i915_pmu_engine_sample sample)
 {
-   struct drm_i915_private *i915 =
-   container_of(event->pmu, typeof(*i915), pmu.base);
-
-   if (!intel_engine_lookup_user(i915, engine_event_class(event),
- engine_event_instance(event)))
-   return -ENODEV;
-
-   switch (engine_event_sample(event)) {
+   switch (sample) {
case I915_SAMPLE_BUSY:
case I915_SAMPLE_WAIT:
break;
case I915_SAMPLE_SEMA:
+   if (INTEL_GEN(engine->i915) < 6)
+   return -ENODEV;
+   break;
+   default:
+   return -ENOENT;
+   }
+
+   return 0;
+}
+
+static int
+config_status(struct drm_i915_private *i915, u64 config)
+{
+   switch (config) {
+   case I915_PMU_ACTUAL_FREQUENCY:
+   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+   /* Requires a mutex for sampling! */
+   return -ENODEV;
+   /* Fall-through. */
+   case I915_PMU_REQUESTED_FREQUENCY:
if (INTEL_GEN(i915) < 6)
return -ENODEV;
break;
+   case I915_PMU_INTERRUPTS:
+   break;
+   case I915_PMU_RC6_RESIDENCY:
+   if (!HAS_RC6(i915))
+   return -ENODEV;
+   break;
default:
return -ENOENT;
}
@@ -314,6 +335,20 @@ static int engine_event_init(struct perf_event *event)
return 0;
 }
 
+static int engine_event_init(struct perf_event *event)
+{
+   struct drm_i915_private *i915 =
+   container_of(event->pmu, typeof(*i915), pmu.base);
+   struct intel_engine_cs *engine;
+
+   engine = intel_engine_lookup_user(i915, engine_event_class(event),
+ engine_event_instance(event));
+   if (!engine)
+   return -ENODEV;
+
+   return engine_event_status(engine, engine_event_sample(event));
+}
+
 static int i915_pmu_event_init(struct perf_event *event)
 {
struct drm_i915_private *i915 =
@@ -337,30 +372,10 @@ static int i915_pmu_event_init(struct perf_event *event)
if (!cpumask_test_cpu(event->cpu, _pmu_cpumask))
return -EINVAL;
 
-   if (is_engine_event(event)) {
+   if (is_engine_event(event))
ret = engine_event_init(event);
-   } else {
-   ret = 0;
-   switch (event->attr.config) {
-   case I915_PMU_ACTUAL_FREQUENCY:
-   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
-/* Requires a mutex for sampling! */
-   ret = -ENODEV;
-   case I915_PMU_REQUESTED_FREQUENCY:
-   if (INTEL_GEN(i915) < 6)
-   ret = -ENODEV;
-   break;
-   case I915_PMU_INTERRUPTS:
-   break;
-   case I915_PMU_RC6_RESIDENCY:
-   if (!HAS_RC6(i915))
-   ret = -ENODEV;
-   break;
-   default:
-   ret = -ENOENT;
-   break;
-   }
-   }
+   else
+   ret = config_status(i915, event->attr.config);;
if (ret)
return ret;
 
@@ -657,52 +672,9 @@ static ssize_t i915_pmu_event_show(struct device *dev,
return sprintf(buf, "config=0x%lx\n", eattr->val);
 }
 
-#define I915_EVENT_ATTR(_name, _config) \
-   (&((struct i915_ext_attribute[]) { \
-   { .attr = __ATTR(_name, 0444, i915_pmu_event_show, NULL), \
- .val = _config, } \
-   })[0].attr.attr)
-
-#define I915_EVENT_STR(_name, _str) \
-   (&((struct perf_pmu_events_attr[]) { \
-   { .attr  = 

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

[Gustavo Padovan]

Hi Dave,

Flushing out drm-misc-next before the holidays. Docs and fbdev work
here. We will skip a pull request next week, back in 2018!

Regards,

Gustavo

drm-misc-next-2017-12-21:
drm-misc-next for 4.16:

Core Changes:
- mostly doc updates and some fbdev improvements
The following changes since commit ca40cfc85e548424e39dc3aebe61873535ddf7b6:

  drm/atomic-helper: Make zpos property kerneldoc less misleading (2017-12-14 
14:20:35 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2017-12-21

for you to fetch changes up to 8d44e9e69aacecd522bb2797eb2febc5c6c46558:

  drm/framebuffer: Print task that allocated the fb in debug info. (2017-12-20 
15:30:17 +0100)


drm-misc-next for 4.16:

Core Changes:
- mostly doc updates and some fbdev improvements


Daniel Vetter (5):
  drm/edid: kerneldoc for is_hdmi2_sink
  drm/print: Unconfuse kerneldoc
  drm/syncobj: some kerneldoc polish
  drm/atomic: document how to handle driver private objects
  drm/doc: Move legacy kms helpers to the very end

Fabio Estevam (2):
  drm/stm: dsi: Remove unnecessary platform_get_resource() error check
  drm/stm: ltdc: Remove unnecessary platform_get_resource() error check

Maarten Lankhorst (1):
  drm/framebuffer: Print task that allocated the fb in debug info.

Noralf Trønnes (5):
  drm/fb-helper: Set/clear dev->fb_helper in dummy init/fini
  drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()
  drm/docs: Add todo entry for drm_fb_helper_fbdev_setup()
  drm/fb-helper: Update DOC with new helpers
  drm/fb-helper: Add drm_fb_helper_defio_init()

 Documentation/gpu/drm-kms-helpers.rst |  36 +++
 Documentation/gpu/drm-kms.rst |  14 ++-
 Documentation/gpu/todo.rst|  18 
 drivers/gpu/drm/drm_atomic.c  |  45 +++-
 drivers/gpu/drm/drm_edid.c|   5 +
 drivers/gpu/drm/drm_fb_helper.c   | 191 +++---
 drivers/gpu/drm/drm_framebuffer.c |   2 +
 drivers/gpu/drm/drm_syncobj.c |  45 +++-
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c |   5 -
 drivers/gpu/drm/stm/ltdc.c|   6 --
 include/drm/drm_atomic.h  |  32 ++
 include/drm/drm_fb_helper.h   |  38 +++
 include/drm/drm_framebuffer.h |   6 ++
 include/drm/drm_mode_config.h |   9 ++
 include/drm/drm_print.h   |   2 +-
 include/drm/drm_syncobj.h |  34 +++---
 16 files changed, 419 insertions(+), 69 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for igt/gem_exec_await: Flush the WCB before attempting to queue more work

[Patchwork]

== Series Details ==

Series: igt/gem_exec_await: Flush the WCB before attempting to queue more work
URL   : https://patchwork.freedesktop.org/series/35684/
State : warning

== Summary ==

Test kms_atomic:
Subgroup plane_invalid_params:
pass   -> SKIP   (shard-snb)
Test prime_mmap_kms:
Subgroup buffer-sharing:
pass   -> SKIP   (shard-snb)
Test kms_pwrite_crc:
pass   -> SKIP   (shard-snb)
Test kms_cursor_legacy:
Subgroup cursora-vs-flipa-legacy:
pass   -> SKIP   (shard-snb)
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-snb)
Subgroup sysfs-reader:
skip   -> PASS   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test pm_rpm:
Subgroup system-suspend:
skip   -> PASS   (shard-hsw) fdo#103375 +1
Test kms_plane:
Subgroup plane-panning-bottom-right-pipe-b-planes:
pass   -> SKIP   (shard-hsw)
Test kms_atomic_transition:
Subgroup plane-all-transition-fencing:
pass   -> SKIP   (shard-hsw)
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-hsw) fdo#104218

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218

shard-hswtotal:2685 pass:1518 dwarn:1   dfail:0   fail:10  skip:1155 
time:9048s
shard-snbtotal:2685 pass:1290 dwarn:1   dfail:0   fail:10  skip:1383 
time:7749s
Blacklisted hosts:
shard-apltotal:2690 pass:1663 dwarn:1   dfail:0   fail:23  skip:1002 
time:13340s
shard-kbltotal:2712 pass:1792 dwarn:13  dfail:0   fail:24  skip:883 
time:5s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_exec_await: Flush the WCB before attempting to queue more work

[Patchwork]

== Series Details ==

Series: igt/gem_exec_await: Flush the WCB before attempting to queue more work
URL   : https://patchwork.freedesktop.org/series/35684/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
beb26d89ff5c5621c1e6b6ac2a45439507af86b7 meson: Install .testlist files and 
README from tests/intel-ci

with latest DRM-Tip kernel build CI_DRM_3564
4b29b69aee8c drm-tip: 2017y-12m-21d-11h-10m-15s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989 +1
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:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:384s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:498s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:496s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:484s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:468s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:263s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:533s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:413s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:424s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:480s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:522s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:526s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:526s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:556s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:509s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:513s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:453s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:548s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:414s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:598s
fi-cnl-y total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:24 

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/1] igt_aux: Skip hibernation attempts if hibernation is not configured

[Patchwork]

== Series Details ==

Series: series starting with [1/1] igt_aux: Skip hibernation attempts if 
hibernation is not configured
URL   : https://patchwork.freedesktop.org/series/35680/
State : success

== Summary ==

Test drv_suspend:
Subgroup sysfs-reader-hibernate:
fail   -> SKIP   (shard-snb) fdo#103375 +15
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-snb)
Subgroup sysfs-reader:
skip   -> PASS   (shard-hsw)
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-snb) fdo#104218
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2712 pass:1537 dwarn:1   dfail:0   fail:3   skip:1171 
time:9422s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:4   skip:1398 
time:8113s
Blacklisted hosts:
shard-apltotal:2712 pass:1687 dwarn:2   dfail:0   fail:11  skip:1011 
time:13539s
shard-kbltotal:2694 pass:1786 dwarn:2   dfail:0   fail:14  skip:891 
time:10825s

== Logs ==

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

[Intel-gfx] [PATCH igt] igt/gem_exec_await: Flush the WCB before attempting to queue more work

[Chris Wilson]

Ensure that the terminating write into WC-memory is flushed before we
might trigger a wait for ring space.

Signed-off-by: Chris Wilson 
---
 tests/gem_exec_await.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/gem_exec_await.c b/tests/gem_exec_await.c
index 9c4467922..28b280ff6 100644
--- a/tests/gem_exec_await.c
+++ b/tests/gem_exec_await.c
@@ -222,6 +222,7 @@ static void wide(int fd, int ring_size, int timeout, 
unsigned int flags)
 
for (unsigned e = 0; e < nengine; e++)
exec[e].cmd[0] = MI_BATCH_BUFFER_END;
+   __sync_synchronize();
}
 
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
-- 
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 series starting with [1/1] igt_aux: Skip hibernation attempts if hibernation is not configured

[Patchwork]

== Series Details ==

Series: series starting with [1/1] igt_aux: Skip hibernation attempts if 
hibernation is not configured
URL   : https://patchwork.freedesktop.org/series/35680/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
beb26d89ff5c5621c1e6b6ac2a45439507af86b7 meson: Install .testlist files and 
README from tests/intel-ci

with latest DRM-Tip kernel build CI_DRM_3564
4b29b69aee8c drm-tip: 2017y-12m-21d-11h-10m-15s UTC integration manifest

No testlist changes.

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:437s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:388s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:499s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:471s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:264s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:533s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:428s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:479s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:524s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:530s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:602s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:444s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:536s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:555s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:511s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:498s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:443s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:553s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:593s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:630s
fi-glk-dsi   total:288  pass:175  dwarn:1   dfail:4   fail:0   skip:108 
time:325s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t 1/1] igt_aux: Skip hibernation attempts if hibernation is not configured

[Petri Latvala]

On Thu, Dec 21, 2017 at 01:26:17PM +, Chris Wilson wrote:
> I've never used resume=/resume_offset= and hibernate (both from the
> desktop and echo disk > /sys/power/state) works. Why CI doesn't work is
> a mystery.

Do you have your swap on a partition? CI has it on a file.


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

[Intel-gfx] ✗ Fi.CI.IGT: warning for scripts/trace.pl: Optimize event parsing and processing (rev3)

[Patchwork]

== Series Details ==

Series: scripts/trace.pl: Optimize event parsing and processing (rev3)
URL   : https://patchwork.freedesktop.org/series/35569/
State : warning

== Summary ==

Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-snb) fdo#104218
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-atomic-transitions-varying-size:
skip   -> PASS   (shard-hsw) fdo#103172
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-top-edge:
pass   -> SKIP   (shard-hsw)
Test kms_flip:
Subgroup vblank-vs-suspend:
incomplete -> PASS   (shard-snb) fdo#103375
Test gem_eio:
Subgroup in-flight-contexts:
dmesg-warn -> PASS   (shard-snb) fdo#104058

fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103172 https://bugs.freedesktop.org/show_bug.cgi?id=103172
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058

shard-hswtotal:2712 pass:1537 dwarn:1   dfail:0   fail:9   skip:1165 
time:9402s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:11  skip:1391 
time:8130s
Blacklisted hosts:
shard-apltotal:2712 pass:1687 dwarn:1   dfail:0   fail:22  skip:1001 
time:13954s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t 1/1] igt_aux: Skip hibernation attempts if hibernation is not configured

[Chris Wilson]

Quoting Petri Latvala (2017-12-21 13:18:16)
> On Thu, Dec 21, 2017 at 12:59:41PM +, Chris Wilson wrote:
> > Quoting Petri Latvala (2017-12-21 12:53:41)
> > > rtcwake doesn't give us meaningful ways of differentiating different
> > > reasons for hibernation failing. CI doesn't configure hibernation to
> > > work at this time, and hibernation attempts will always fail. Check
> > > for the configuration in the form of resume= appearing on the kernel
> > > command line, which is what swsusp uses to find the resume device to
> > > hibernate to.
> > 
> > resume= is not required for hibernation.
> 
> Oh bugger, I was blind. swsusp_resume_device update is right there in
> swsusp_swap_check().
> 
> swsusp_resume_block is not updated there though. That's needed to
> hibernate to swapfile.
> 
> >  
> > > Hibernation failures have dug up a couple of bugs in the past, but
> > > finding actual bugs in the swamp of "rtcwake failed with 1" results is
> > > difficult enough to overweigh that benefit.
> > 
> > The ones in CI are genuine though, does it not appear? At the start of
> > the hibernate it picks swapspace to store the image, but at the end of
> > the sequence, it can not read back from the swapspace it chose.
> 
> ... and the above is what happens in CI. Correct device is checked but
> offset is missing.
> 
> Suggestions how to proceed? Does resuming from a swapfile work
> automatically without resume_offset= on cmdline? Then it would be a
> matter of updating swsusp_resume_block in swsusp_swap_check. If not,
> check that either 1) a partition exists in /proc/swaps 2)
> resume_offset is on cmdline?

I've never used resume=/resume_offset= and hibernate (both from the
desktop and echo disk > /sys/power/state) works. Why CI doesn't work is
a mystery. Is it worth seeing if it has ever worked (without extra modules
like i915.ko loaded) on one of those machines and do a regression hunt?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/1] igt_aux: Skip hibernation attempts if hibernation is not configured

[Petri Latvala]

On Thu, Dec 21, 2017 at 12:59:41PM +, Chris Wilson wrote:
> Quoting Petri Latvala (2017-12-21 12:53:41)
> > rtcwake doesn't give us meaningful ways of differentiating different
> > reasons for hibernation failing. CI doesn't configure hibernation to
> > work at this time, and hibernation attempts will always fail. Check
> > for the configuration in the form of resume= appearing on the kernel
> > command line, which is what swsusp uses to find the resume device to
> > hibernate to.
> 
> resume= is not required for hibernation.

Oh bugger, I was blind. swsusp_resume_device update is right there in
swsusp_swap_check().

swsusp_resume_block is not updated there though. That's needed to
hibernate to swapfile.

>  
> > Hibernation failures have dug up a couple of bugs in the past, but
> > finding actual bugs in the swamp of "rtcwake failed with 1" results is
> > difficult enough to overweigh that benefit.
> 
> The ones in CI are genuine though, does it not appear? At the start of
> the hibernate it picks swapspace to store the image, but at the end of
> the sequence, it can not read back from the swapspace it chose.

... and the above is what happens in CI. Correct device is checked but
offset is missing.

Suggestions how to proceed? Does resuming from a swapfile work
automatically without resume_offset= on cmdline? Then it would be a
matter of updating swsusp_resume_block in swsusp_swap_check. If not,
check that either 1) a partition exists in /proc/swaps 2)
resume_offset is on cmdline?



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

[Intel-gfx] ✗ Fi.CI.IGT: failure for igt/syncobj: Stress handle->fd/close

[Patchwork]

== Series Details ==

Series: igt/syncobj: Stress handle->fd/close
URL   : https://patchwork.freedesktop.org/series/35653/
State : failure

== Summary ==

Test gem_eio:
Subgroup in-flight-contexts:
dmesg-warn -> PASS   (shard-snb) fdo#104058
Test kms_flip:
Subgroup vblank-vs-suspend:
incomplete -> PASS   (shard-snb) fdo#103375
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-snb) fdo#104218 +1
Test prime_self_import:
Subgroup basic-with_fd_dup:
pass   -> INCOMPLETE (shard-hsw)
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-atomic-transitions-varying-size:
skip   -> PASS   (shard-hsw) fdo#103172
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#103172 https://bugs.freedesktop.org/show_bug.cgi?id=103172
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2590 pass:1465 dwarn:2   dfail:0   fail:9   skip:1112 
time:8944s
shard-snbtotal:2663 pass:1283 dwarn:1   dfail:0   fail:10  skip:1368 
time:7886s
Blacklisted hosts:
shard-apltotal:2641 pass:1630 dwarn:1   dfail:0   fail:22  skip:986 
time:13054s
shard-kbltotal:2663 pass:1771 dwarn:1   dfail:0   fail:24  skip:866 
time:10833s

== Logs ==

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

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

[Daniel Vetter]

Hi Dave,

drm-misc-fixes-2017-12-21:
drm-misc-fixes before holidays:

- fixup for the lease fixup (Keith)
- fb leak in the ww mutex fallback code (Maarten)
- sun4i fixes (Maxime, Hans)

I'll be away for two weeks, but I think Sean and Gustavo are somewhat
around-ish. But there's also not really much going on anyway.

Cheers, Daniel

The following changes since commit bd36d3bab2e3d08f80766c86487090dbceed4651:

  drm/drm_lease: Prevent deadlock in case drm_lease_create() fails (2017-12-14 
08:25:37 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2017-12-21

for you to fetch changes up to d2a48e52541cdf474ef35d51e8d73ded5be33122:

  drm: move lease init after validation in drm_lease_create (2017-12-21 
09:49:40 +0100)


drm-misc-fixes before holidays:

- fixup for the lease fixup (Keith)
- fb leak in the ww mutex fallback code (Maarten)
- sun4i fixes (Maxime, Hans)


Hans Verkuil (1):
  drm/sun4i: validate modes for HDMI

Keith Packard (1):
  drm: move lease init after validation in drm_lease_create

Maarten Lankhorst (1):
  drm/plane: Make framebuffer refcounting the responsibility of 
setplane_internal callers

Maxime Ripard (2):
  drm/sun4i: Fix error path handling
  drm/sun4i: hdmi: Move the mode_valid callback to the encoder

 drivers/gpu/drm/drm_lease.c| 22 +-
 drivers/gpu/drm/drm_plane.c| 42 --
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 20 
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  4 ++--
 4 files changed, 53 insertions(+), 35 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/1] igt_aux: Skip hibernation attempts if hibernation is not configured

[Chris Wilson]

Quoting Petri Latvala (2017-12-21 12:53:41)
> rtcwake doesn't give us meaningful ways of differentiating different
> reasons for hibernation failing. CI doesn't configure hibernation to
> work at this time, and hibernation attempts will always fail. Check
> for the configuration in the form of resume= appearing on the kernel
> command line, which is what swsusp uses to find the resume device to
> hibernate to.

resume= is not required for hibernation.
 
> Hibernation failures have dug up a couple of bugs in the past, but
> finding actual bugs in the swamp of "rtcwake failed with 1" results is
> difficult enough to overweigh that benefit.

The ones in CI are genuine though, does it not appear? At the start of
the hibernate it picks swapspace to store the image, but at the end of
the sequence, it can not read back from the swapspace it chose.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

[Lionel Landwerlin]

Some more findings I made while playing with this series & GPUTop.
Turns out the 2ms drift per second is due to timecounter. Adding the 
delta this way :


https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R607

Eliminates the drift. Timelines of perf i915 tracepoints & OA reports 
now make a lot more sense.


There is still the issue that reading the CPU clock & the RCS timestamp 
is inherently not atomic. So there is a delta there.
I think we should add a new i915 perf record type to express the delta 
that we measure this way :


https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R2475

So that userspace knows there might be a global offset between the 2 
times and is able to present it.
Measurement on my KBL system were in the order of a few microseconds 
(~30us).
I guess we might be able to setup the correlation point better (masking 
interruption?) to reduce the delta.


Thanks,

-
Lionel


On 07/12/17 00:57, Robert Bragg wrote:



On Thu, Dec 7, 2017 at 12:48 AM, Robert Bragg > wrote:



at least from what I wrote back then it looks like I was seeing a
drift of a few milliseconds per second on SKL. I vaguely recall it
being much worse given the frequency constants we had for Haswell.


Sorry I didn't actually re-read my own message properly before 
referencing it :) Apparently the 2ms per second drift was for Haswell, 
so presumably not quite so bad for SKL.


- Robert



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



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

[Intel-gfx] [PATCH i-g-t 1/1] igt_aux: Skip hibernation attempts if hibernation is not configured

[Petri Latvala]

rtcwake doesn't give us meaningful ways of differentiating different
reasons for hibernation failing. CI doesn't configure hibernation to
work at this time, and hibernation attempts will always fail. Check
for the configuration in the form of resume= appearing on the kernel
command line, which is what swsusp uses to find the resume device to
hibernate to.

Hibernation failures have dug up a couple of bugs in the past, but
finding actual bugs in the swamp of "rtcwake failed with 1" results is
difficult enough to overweigh that benefit.

Note that this only makes full hibernation to skip on unconfigured
systems. Limiting the suspend level in igt_system_suspend_autoresume
to anything other than full level still suspends.

References: https://bugs.freedesktop.org/show_bug.cgi?id=103375
Signed-off-by: Petri Latvala 
Cc: Marta Lofstedt 
Cc: Tomi Sarvela 
Cc: Arkadiusz Hiler 
---
 lib/igt_aux.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 8ca0b60d..86d9c5b9 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -775,6 +775,29 @@ static void set_suspend_test(int power_dir, enum 
igt_suspend_test test)
igt_assert(igt_sysfs_set(power_dir, "pm_test", 
suspend_test_name[test]));
 }
 
+static bool hibernate_configured(void)
+{
+   FILE *file;
+   size_t n = 0;
+   char *line = NULL;
+   bool matched = false;
+
+   file = fopen("/proc/cmdline", "r");
+   if (!file) {
+   /* Cannot check. Assume the best. */
+   return true;
+   }
+
+   if (getline(, , file) >= 0) {
+   matched = strstr(line, "resume=") != NULL;
+   }
+
+   free(line);
+   fclose(file);
+
+   return matched;
+}
+
 #define SQUELCH ">/dev/null 2>&1"
 
 static void suspend_via_rtcwake(enum igt_suspend_state state)
@@ -798,6 +821,15 @@ static void suspend_via_rtcwake(enum igt_suspend_state 
state)
 "the rtcwake tool or how your distro is set up.\n",
  ret);
 
+   /*
+* Skip if attempting to suspend to disk and hibernation is
+* not configured.
+*/
+   if (state == SUSPEND_STATE_DISK) {
+   igt_require_f(hibernate_configured(),
+ "Cannot suspend to disk; Hibernation device not 
configured.\n");
+   }
+
snprintf(cmd, sizeof(cmd), "rtcwake -s %d -m %s ",
 delay, suspend_state_name[state]);
ret = igt_system(cmd);
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Use an atomic_t array to track power domain use count.

[Maarten Lankhorst]

Hey,

Op 19-12-17 om 06:26 schreef Dhinakaran Pandiyan:
> Convert the power_domains->domain_use_count array that tracks per-domain
> use count to atomic_t type. This is needed to be able to read/write the use
> counts outside of the power domain mutex.
>
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h |  2 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
>  3 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1a7b28f62570..1f1d9162f2c2 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2764,7 +2764,7 @@ static int i915_power_domain_info(struct seq_file *m, 
> void *unused)
>   for_each_power_domain(power_domain, power_well->domains)
>   seq_printf(m, "  %-23s %d\n",
>intel_display_power_domain_str(power_domain),
> -  power_domains->domain_use_count[power_domain]);
> +  
> atomic_read(_domains->domain_use_count[power_domain]));
>   }
>  
>   mutex_unlock(_domains->lock);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1e4e613e7b41..ddadeb9eaf49 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1489,7 +1489,7 @@ struct i915_power_domains {
>   int power_well_count;
>  
>   struct mutex lock;
> - int domain_use_count[POWER_DOMAIN_NUM];
> + atomic_t domain_use_count[POWER_DOMAIN_NUM];
>   struct i915_power_well *power_wells;
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 96ab74f3d101..992caec1fbc4 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1453,7 +1453,7 @@ __intel_display_power_get_domain(struct 
> drm_i915_private *dev_priv,
>   for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
>   intel_power_well_get(dev_priv, power_well);
>  
> - power_domains->domain_use_count[domain]++;
> + atomic_inc(_domains->domain_use_count[domain]);
>  }
>  
>  /**
> @@ -1539,10 +1539,9 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>  
>   mutex_lock(_domains->lock);
>  
> - WARN(!power_domains->domain_use_count[domain],
> -  "Use count on domain %s is already zero\n",
> + WARN(atomic_dec_return(_domains->domain_use_count[domain]) < 0,
> +  "Use count on domain %s was already zero\n",
>intel_display_power_domain_str(domain));
> - power_domains->domain_use_count[domain]--;
>  
>   for_each_power_domain_well_rev(dev_priv, power_well, BIT_ULL(domain))
>   intel_power_well_put(dev_priv, power_well);
> @@ -3049,7 +3048,7 @@ static void intel_power_domains_dump_info(struct 
> drm_i915_private *dev_priv)
>   for_each_power_domain(domain, power_well->domains)
>   DRM_DEBUG_DRIVER("  %-23s %d\n",
>intel_display_power_domain_str(domain),
> -  
> power_domains->domain_use_count[domain]);
> +  
> atomic_read(_domains->domain_use_count[domain]));
>   }
>  }
>  
> @@ -3092,7 +3091,7 @@ void intel_power_domains_verify_state(struct 
> drm_i915_private *dev_priv)
>  
>   domains_count = 0;
>   for_each_power_domain(domain, power_well->domains)
> - domains_count += 
> power_domains->domain_use_count[domain];
> + domains_count += 
> atomic_read(_domains->domain_use_count[domain]);
>  
>   if (power_well->count != domains_count) {
>   DRM_ERROR("power well %s refcount/domain refcount 
> mismatch "

I can imagine this will start failing really badly. The previous code assumed 
that
everything is protected by power_domains->lock, and now this changes makes it no
longer the case..

I see the rest of the code changes things even more, but it would be better if 
the
locking rework was done in a single patch, and not bolted on..

And instead of using atomic_t, there is a refcount implementation in refcount.h,
it could be used here for locking power wells only if it would drop to zero..

Cheers,
Maarten

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

Re: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.07 for Cannonlake

[Saarinen, Jani]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Anusha Srivatsa
> Sent: torstai 21. joulukuuta 2017 3.38
> To: intel-gfx@lists.freedesktop.org
> Cc: Vivi, Rodrigo 
> Subject: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.07 for Cannonlake
> 
> There is a new version of DMC available for KBL.
For CNL you mean? 
> 
> The release notes mentions:
> 1. Fix for the issue where DC_STATE was getting enabled even when disabled by
> driver causing data corruption
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_csr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index 7fe4aac0..ed256de 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -37,8 +37,8 @@
>  #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
>  #define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4)
> 
> -#define I915_CSR_CNL "i915/cnl_dmc_ver1_06.bin"
> -#define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 6)
> +#define I915_CSR_CNL "i915/cnl_dmc_ver1_07.bin"
> +#define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
> 
>  #define I915_CSR_KBL "i915/kbl_dmc_ver1_04.bin"
>  MODULE_FIRMWARE(I915_CSR_KBL);
> --
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/syncobj: Stop reusing the same struct file for all syncobj -> fd (rev2)

[Patchwork]

== Series Details ==

Series: drm/syncobj: Stop reusing the same struct file for all syncobj -> fd 
(rev2)
URL   : https://patchwork.freedesktop.org/series/35576/
State : warning

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-render:
skip   -> PASS   (shard-snb) fdo#103167 +1
Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
skip   -> PASS   (shard-hsw) fdo#101623
Test pm_rpm:
Subgroup system-suspend-modeset:
skip   -> PASS   (shard-hsw)
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
pass   -> SKIP   (shard-snb)
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
pass   -> SKIP   (shard-hsw)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (shard-snb) fdo#103375
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-xtiled:
pass   -> SKIP   (shard-hsw)
Test kms_busy:
Subgroup extended-pageflip-modeset-hang-oldfb-render-b:
pass   -> SKIP   (shard-hsw)
Test kms_mmio_vs_cs_flip:
Subgroup setcrtc_vs_cs_flip:
pass   -> SKIP   (shard-hsw)

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-hswtotal:2712 pass:1533 dwarn:1   dfail:0   fail:10  skip:1168 
time:9296s
shard-snbtotal:2664 pass:1285 dwarn:2   dfail:0   fail:11  skip:1365 
time:7711s
Blacklisted hosts:
shard-apltotal:2690 pass:1663 dwarn:1   dfail:0   fail:24  skip:1001 
time:13385s
shard-kbltotal:2664 pass:1769 dwarn:2   dfail:0   fail:24  skip:867 
time:10494s

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Move uint_fixed_16_16_t to i915_types.h

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-21 11:37:11)
> On Wed, 20 Dec 2017 19:55:58 +0100, Chris Wilson  
>  wrote:
> 
> > Quoting Michal Wajdeczko (2017-12-20 18:36:03)
> >> Our uint_fixed_16_16_t definition and related helper functions
> >> deserve dedicated header. While here cleanup types and indent.
> >>
> >> Signed-off-by: Michal Wajdeczko 
> >> Cc: Chris Wilson 
> >> Cc: Rodrigo Vivi 
> >> Cc: Joonas Lahtinen 
> >> ---
> >>  drivers/gpu/drm/i915/i915_drv.h   | 139 +--
> >>  drivers/gpu/drm/i915/i915_types.h | 168  
> >> ++
> >>  2 files changed, 169 insertions(+), 138 deletions(-)
> >>  create mode 100644 drivers/gpu/drm/i915/i915_types.h
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h  
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index ca2a619..1e2217c 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -55,6 +55,7 @@
> >>  #include "i915_params.h"
> >>  #include "i915_reg.h"
> >>  #include "i915_utils.h"
> >> +#include "i915_types.h"
> >>
> >>  #include "intel_uncore.h"
> >>  #include "intel_bios.h"
> >> @@ -105,144 +106,6 @@
> >>  #define i915_inject_load_failure() \
> >> __i915_inject_load_failure(__func__, __LINE__)
> >>
> >> -typedef struct {
> >> -   uint32_t val;
> >> -} uint_fixed_16_16_t;
> >
> > I would throw this into its own header (not something as generic as
> > i915_types.h, preferably not something that even ties this to i915) and
> 
> 1) uint_fixed_16_16.h (like drm/amd/display/include/fixed31_32.h)

The type itself shouldn't be called uint_fixed_16_16_t.

Looking towards the future, include/linux/fixed16_16.h

> 2) i915_fixed.h (like include/drm_fixed.h)
> 
> > refuse to include it directly from i915_drv.h.
> 
> But we have to do this as uint_fixed_16_16_t is used by struct  
> skl_wm_params
> (which is still defined in this header)

Boo. But not forever as skl_wm_values isn't used by i915_drv.h!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Move intel_device_info definitions to its own header

[Michal Wajdeczko]

On Wed, 20 Dec 2017 20:07:10 +0100, Chris Wilson  
 wrote:



Quoting Michal Wajdeczko (2017-12-20 18:36:07)

We already keep intel_device_info functions in dedicated file.
Add matching header file and move related definitions there.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  | 139  
+

 drivers/gpu/drm/i915/intel_device_info.c |   1 +
 drivers/gpu/drm/i915/intel_device_info.h | 173  
+++

 3 files changed, 175 insertions(+), 138 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_device_info.h

+/* Keep in gen based order, and chronological order within a gen */
+enum intel_platform {
+   INTEL_PLATFORM_UNINITIALIZED = 0,


Next patch it's probably worth adding the gen boundaries.


Will add to v2 if this is ok.



/* gen2 */

+   INTEL_I830,
+   INTEL_I845G,
+   INTEL_I85X,
+   INTEL_I865G,

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

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Move uint_fixed_16_16_t to i915_types.h

[Michal Wajdeczko]

On Wed, 20 Dec 2017 19:55:58 +0100, Chris Wilson  
 wrote:



Quoting Michal Wajdeczko (2017-12-20 18:36:03)

Our uint_fixed_16_16_t definition and related helper functions
deserve dedicated header. While here cleanup types and indent.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h   | 139 +--
 drivers/gpu/drm/i915/i915_types.h | 168  
++

 2 files changed, 169 insertions(+), 138 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_types.h

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

index ca2a619..1e2217c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
 #include "i915_params.h"
 #include "i915_reg.h"
 #include "i915_utils.h"
+#include "i915_types.h"

 #include "intel_uncore.h"
 #include "intel_bios.h"
@@ -105,144 +106,6 @@
 #define i915_inject_load_failure() \
__i915_inject_load_failure(__func__, __LINE__)

-typedef struct {
-   uint32_t val;
-} uint_fixed_16_16_t;


I would throw this into its own header (not something as generic as
i915_types.h, preferably not something that even ties this to i915) and


1) uint_fixed_16_16.h (like drm/amd/display/include/fixed31_32.h)

2) i915_fixed.h (like include/drm_fixed.h)


refuse to include it directly from i915_drv.h.


But we have to do this as uint_fixed_16_16_t is used by struct  
skl_wm_params

(which is still defined in this header)

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

Re: [Intel-gfx] [PATCH igt] igt/gem_spin_batch: Skip overloading aliased BSD engines

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-21 11:21:23)
> 
> On 21/12/2017 10:53, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-12-21 10:02:06)
> >>
> >> On 20/12/2017 17:56, Chris Wilson wrote:
> >>> BSD == BSD1 or BSD2. Since we already emit spinners to the explicit BSD
> >>> rins, skip the aliased ring.
> >>>
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104352
> >>> Signed-off-by: Chris Wilson 
> >>> ---
> >>>tests/gem_spin_batch.c | 2 +-
> >>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/tests/gem_spin_batch.c b/tests/gem_spin_batch.c
> >>> index 896311304..cccba75a7 100644
> >>> --- a/tests/gem_spin_batch.c
> >>> +++ b/tests/gem_spin_batch.c
> >>> @@ -77,7 +77,7 @@ static void spin_on_all_engines(int fd, unsigned int 
> >>> timeout_sec)
> >>>unsigned engine;
> >>>
> >>>for_each_engine(fd, engine) {
> >>> - if (engine == 0)
> >>> + if (engine == 0 || engine == I915_EXEC_BSD)
> >>
> >> You forget the other annoyance of the VCS selection uAPI where explicit
> >> flags can only be used on dual-VCS platforms? :) So I think you need to
> >> skip on engine & I915_EXEC_BSD_RING1, unless I am missing something.
> > 
> > No way, the uapi can't be that stupid. It is.
> 
> Ugh my suggestion was even incorrect. The skipping criteria needs to be 
> branched based on HAS_BSD2.
> 
> if (HAS_BSD2())
> skip I915_EXEC_BSD
> else
> skip I915_EXEC_BSD_RING1
> 
> Can I mention again my suggestion of making for_each_engine iterate 
> engines, and not uABI flags?
> 
> That would solve multiple issues with one big swat. Maybe it would add 
> some new ones, like if we miss some ABI testing coverage, but I still 
> think exercising engines and exercising ABI is better separated.
> 
> > Can we do the s/for_each_engine/for_each_ring/ yet?
> 
> Doesn't ring a bell - what is the name change supposed to signal?

I care about uABI coverage. As I recall the^Wmy plan was when we have an
interface that allows for explicit engine selection, we use it. But that
means we first need to convert all existing loops over to
for_each_exec_ring(), and then introduce for_each_engine() converting
and adding extra tests as required depending on whether the tests are
exercising the uABI itself or only care about HW internals.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-fixes for 4.15

[Jani Nikula]

On Thu, 21 Dec 2017, Zhenyu Wang  wrote:
> Hi,
>
> Please pull one fix for 4.15 that correct default pipe
> enable for virtual display in a previous commit from Xiaolin.

Pulled, thanks.

BR,
Jani.



>
> thanks
> --
> The following changes since commit 11474e9091cf2002e948647fd9f63a7f027e488a:
>
>   drm/i915/gvt: set max priority for gvt context (2017-12-06 11:38:21 +0800)
>
> are available in the Git repository at:
>
>   https://github.com/intel/gvt-linux.git tags/gvt-fixes-2017-12-21
>
> for you to fetch changes up to f5f00e7dcc4161f07b76ff1a854e8b1ea7a1ed41:
>
>   drm/i915/gvt: Fix pipe A enable as default for vgpu (2017-12-11 17:23:11 
> +0800)
>
> 
> gvt-fixes-2017-12-21:
>
> - default pipe enable fix for virtual display (Xiaolin)
>
> 
> Xiaolin Zhang (1):
>   drm/i915/gvt: Fix pipe A enable as default for vgpu
>
>  drivers/gpu/drm/i915/gvt/display.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

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

Re: [Intel-gfx] [PATCH igt] igt/gem_spin_batch: Skip overloading aliased BSD engines

[Tvrtko Ursulin]

On 21/12/2017 10:53, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2017-12-21 10:02:06)


On 20/12/2017 17:56, Chris Wilson wrote:

BSD == BSD1 or BSD2. Since we already emit spinners to the explicit BSD
rins, skip the aliased ring.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104352
Signed-off-by: Chris Wilson 
---
   tests/gem_spin_batch.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/gem_spin_batch.c b/tests/gem_spin_batch.c
index 896311304..cccba75a7 100644
--- a/tests/gem_spin_batch.c
+++ b/tests/gem_spin_batch.c
@@ -77,7 +77,7 @@ static void spin_on_all_engines(int fd, unsigned int 
timeout_sec)
   unsigned engine;
   
   for_each_engine(fd, engine) {

- if (engine == 0)
+ if (engine == 0 || engine == I915_EXEC_BSD)


You forget the other annoyance of the VCS selection uAPI where explicit
flags can only be used on dual-VCS platforms? :) So I think you need to
skip on engine & I915_EXEC_BSD_RING1, unless I am missing something.


No way, the uapi can't be that stupid. It is.


Ugh my suggestion was even incorrect. The skipping criteria needs to be 
branched based on HAS_BSD2.


if (HAS_BSD2())
skip I915_EXEC_BSD
else
skip I915_EXEC_BSD_RING1

Can I mention again my suggestion of making for_each_engine iterate 
engines, and not uABI flags?


That would solve multiple issues with one big swat. Maybe it would add 
some new ones, like if we miss some ABI testing coverage, but I still 
think exercising engines and exercising ABI is better separated.



Can we do the s/for_each_engine/for_each_ring/ yet?


Doesn't ring a bell - what is the name change supposed to signal?

Regards,

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

[Intel-gfx] ✓ Fi.CI.BAT: success for scripts/trace.pl: Optimize event parsing and processing (rev3)

[Patchwork]

== Series Details ==

Series: scripts/trace.pl: Optimize event parsing and processing (rev3)
URL   : https://patchwork.freedesktop.org/series/35569/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
beb26d89ff5c5621c1e6b6ac2a45439507af86b7 meson: Install .testlist files and 
README from tests/intel-ci

with latest DRM-Tip kernel build CI_DRM_3563
c21bf92fbe84 drm-tip: 2017y-12m-21d-09h-56m-40s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:509s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:484s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:472s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:263s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:533s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:426s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:467s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:426s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:522s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:523s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:531s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:510s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:556s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:426s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:589s
fi-cnl-y total:247  pass:222  dwarn:0   dfail:0   fail:0   skip:24 

== Logs ==

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

Re: [Intel-gfx] Accelerated read from WC mem (i915_memcpy_from_wc()) may not work in virtualization world

[Chris Wilson]

Quoting Du, Changbin (2017-12-21 09:52:16)
> Hi Chris,
> Our QA reported a problem caused by movntdqa instructions. Currently, the KVM
> hypervisor doesn't support VEX-prefix instructions emulation. If users 
> passthrough
> a GPU to guest with vfio option 'x-no-mmap=on', then all access to the BARs 
> will
> be trapped and emulated. The KVM hypervisor would raise an inertal error to 
> qemu
> which cause the guest killed. (Since 'movntdqa' ins is not supported.)
> 
> One possible solution is that disable this optimization at 
> i915_memcpy_init_early.
> This require us to identify the CPUID to check if it is running in guest mode.

But do note we are already checking the CPUID/cpuflags for support; is
the hv not correcting them?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Accelerated read from WC mem (i915_memcpy_from_wc()) may not work in virtualization world

[Chris Wilson]

Quoting Du, Changbin (2017-12-21 09:52:16)
> Hi Chris,
> Our QA reported a problem caused by movntdqa instructions. Currently, the KVM
> hypervisor doesn't support VEX-prefix instructions emulation. If users 
> passthrough
> a GPU to guest with vfio option 'x-no-mmap=on', then all access to the BARs 
> will
> be trapped and emulated. The KVM hypervisor would raise an inertal error to 
> qemu
> which cause the guest killed. (Since 'movntdqa' ins is not supported.)
> 
> One possible solution is that disable this optimization at 
> i915_memcpy_init_early.
> This require us to identify the CPUID to check if it is running in guest mode.

Is this mode not detected by intel_vgpu_active() ?

If we need to disable movntdqa, we need to disable it. But not by
directly checking CPUID, it should be already decoded into a cpu feature
flag -- assuming we need more than intel_vgpu_active and possibly
rearranging the init order.
-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 igt/syncobj: Stress handle->fd/close

[Patchwork]

== Series Details ==

Series: igt/syncobj: Stress handle->fd/close
URL   : https://patchwork.freedesktop.org/series/35653/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
beb26d89ff5c5621c1e6b6ac2a45439507af86b7 meson: Install .testlist files and 
README from tests/intel-ci

with latest DRM-Tip kernel build CI_DRM_3563
c21bf92fbe84 drm-tip: 2017y-12m-21d-09h-56m-40s UTC integration manifest

Testlist changes:
+igt@syncobj_basic@stress-close-race

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:389s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:497s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:498s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:485s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:472s
fi-elk-e7500 total:224  pass:164  dwarn:14  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:267s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:413s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:426s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:427s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:486s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:522s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:541s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:439s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:537s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:513s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
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:413s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:595s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:619s

== Logs ==

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

Re: [Intel-gfx] [PATCH igt] igt/gem_spin_batch: Skip overloading aliased BSD engines

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-21 10:02:06)
> 
> On 20/12/2017 17:56, Chris Wilson wrote:
> > BSD == BSD1 or BSD2. Since we already emit spinners to the explicit BSD
> > rins, skip the aliased ring.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104352
> > Signed-off-by: Chris Wilson 
> > ---
> >   tests/gem_spin_batch.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tests/gem_spin_batch.c b/tests/gem_spin_batch.c
> > index 896311304..cccba75a7 100644
> > --- a/tests/gem_spin_batch.c
> > +++ b/tests/gem_spin_batch.c
> > @@ -77,7 +77,7 @@ static void spin_on_all_engines(int fd, unsigned int 
> > timeout_sec)
> >   unsigned engine;
> >   
> >   for_each_engine(fd, engine) {
> > - if (engine == 0)
> > + if (engine == 0 || engine == I915_EXEC_BSD)
> 
> You forget the other annoyance of the VCS selection uAPI where explicit 
> flags can only be used on dual-VCS platforms? :) So I think you need to 
> skip on engine & I915_EXEC_BSD_RING1, unless I am missing something.

No way, the uapi can't be that stupid. It is.

Can we do the s/for_each_engine/for_each_ring/ yet?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/syncobj: Stop reusing the same struct file for all syncobj -> fd

[Chris Wilson]

Quoting Chris Wilson (2017-12-21 09:28:42)
> The vk cts test:
> dEQP-VK.api.external.semaphore.opaque_fd.export_multiple_times_temporary
> 
> triggers a lot of
> VFS: Close: file count is 0
> 
> Dave pointed out that clearing the syncobj->file from
> drm_syncobj_file_release() was sufficient to silence the test, but that
> opens a can of worm since we assumed that the syncobj->file was never
> unset. So stop trying to reuse the same struct file for every fd pointing
> to the drm_syncobj, and allocate one file for each fd instead.
> 
> v2: Fixup return handling of drm_syncobj_fd_to_handle
> 
> Reported-by: Dave Airlie 
Fixes: e9083420bbac ("drm: introduce sync objects (v4)")

> Testcase: igt/syncobj_base/test-create-close-twice
> Signed-off-by: Chris Wilson 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Reviewed-by: Daniel Vetter 
Cc:  # v4.13+
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [drm-tip:drm-tip 2/8] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:219:6: error: redefinition of 'dm_dp_mst_dc_sink_create'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   e421f7f2b48c47438cd22d673a2c025562d1f728
commit: d4afdbb09e6b347d3ae084331e8b5d70aa168564 [2/8] Merge remote-tracking 
branch 'airlied/drm-next' into drm-tip
config: i386-randconfig-i1-201751 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout d4afdbb09e6b347d3ae084331e8b5d70aa168564
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:219:6: 
>> error: redefinition of 'dm_dp_mst_dc_sink_create'
void dm_dp_mst_dc_sink_create(struct drm_connector *connector)
 ^~~~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:183:6: 
note: previous definition of 'dm_dp_mst_dc_sink_create' was here
void dm_dp_mst_dc_sink_create(struct drm_connector *connector)
 ^~~~

vim +/dm_dp_mst_dc_sink_create +219 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c

54427651 Jerry Zuo   2017-09-20  218  
becd0875 Jerry (Fangzhi  Zuo 2017-12-01 @219) void 
dm_dp_mst_dc_sink_create(struct drm_connector *connector)
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  220) {
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  221)   struct amdgpu_dm_connector 
*aconnector = to_amdgpu_dm_connector(connector);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  222)   struct edid *edid;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  223)   struct dc_sink *dc_sink;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  224)   struct dc_sink_init_data 
init_params = {
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  225)   .link = 
aconnector->dc_link,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  226)   .sink_signal = 
SIGNAL_TYPE_DISPLAY_PORT_MST };
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  227) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  228)   edid = 
drm_dp_mst_get_edid(connector, >mst_port->mst_mgr, 
aconnector->port);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  229) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  230)   if (!edid) {
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  231)   
drm_mode_connector_update_edid_property(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  232)   
>base,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  233)   NULL);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  234)   return;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  235)   }
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  236) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  237)   aconnector->edid = edid;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  238) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  239)   dc_sink = 
dc_link_add_remote_sink(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  240)   aconnector->dc_link,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  241)   (uint8_t 
*)aconnector->edid,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  242)   
(aconnector->edid->extensions + 1) * EDID_LENGTH,
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  243)   _params);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  244) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  245)   dc_sink->priv = aconnector;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  246)   aconnector->dc_sink = dc_sink;
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  247) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  248)   
amdgpu_dm_add_sink_to_freesync_module(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  249)   connector, 
aconnector->edid);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  250) 
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  251)   
drm_mode_connector_update_edid_property(
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  252)   
>base, aconnector->edid);
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  253) }
becd0875 Jerry (Fangzhi  Zuo 2017-12-01  254) 

:: The code at line 219 was first introduced by commit
:: becd0875f4393a992afbf57aa323f7bf1a71c3ff drm/amd/display: Fix rehook MST 
display not light back on

:: TO: Jerry (Fangzhi) Zuo 
:: CC: Alex Deucher 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
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/syncobj: Stop reusing the same struct file for all syncobj -> fd (rev2)

[Patchwork]

== Series Details ==

Series: drm/syncobj: Stop reusing the same struct file for all syncobj -> fd 
(rev2)
URL   : https://patchwork.freedesktop.org/series/35576/
State : success

== Summary ==

Series 35576v2 drm/syncobj: Stop reusing the same struct file for all syncobj 
-> fd
https://patchwork.freedesktop.org/api/1.0/series/35576/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> PASS   (fi-bdw-gvtdvm) fdo#103938 +1
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:504s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:495s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:483s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:471s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:265s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:409s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:415s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:426s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:520s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:528s
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:446s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:540s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:558s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:555s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:413s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:592s

e421f7f2b48c47438cd22d673a2c025562d1f728 drm-tip: 2017y-12m-21d-08h-52m-50s UTC 
integration manifest
8307012eade3 drm/syncobj: Stop reusing the same struct file for all syncobj -> 
fd

== Logs ==

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

Re: [Intel-gfx] [PATCH igt] igt/gem_spin_batch: Skip overloading aliased BSD engines

[Tvrtko Ursulin]

On 20/12/2017 17:56, Chris Wilson wrote:

BSD == BSD1 or BSD2. Since we already emit spinners to the explicit BSD
rins, skip the aliased ring.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104352
Signed-off-by: Chris Wilson 
---
  tests/gem_spin_batch.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/gem_spin_batch.c b/tests/gem_spin_batch.c
index 896311304..cccba75a7 100644
--- a/tests/gem_spin_batch.c
+++ b/tests/gem_spin_batch.c
@@ -77,7 +77,7 @@ static void spin_on_all_engines(int fd, unsigned int 
timeout_sec)
unsigned engine;
  
  	for_each_engine(fd, engine) {

-   if (engine == 0)
+   if (engine == 0 || engine == I915_EXEC_BSD)


You forget the other annoyance of the VCS selection uAPI where explicit 
flags can only be used on dual-VCS platforms? :) So I think you need to 
skip on engine & I915_EXEC_BSD_RING1, unless I am missing something.


Regards,

Tvrtko


continue;
  
  		igt_fork(child, 1) {



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

[Intel-gfx] Accelerated read from WC mem (i915_memcpy_from_wc()) may not work in virtualization world

[Du, Changbin]

Hi Chris,
Our QA reported a problem caused by movntdqa instructions. Currently, the KVM
hypervisor doesn't support VEX-prefix instructions emulation. If users 
passthrough
a GPU to guest with vfio option 'x-no-mmap=on', then all access to the BARs will
be trapped and emulated. The KVM hypervisor would raise an inertal error to qemu
which cause the guest killed. (Since 'movntdqa' ins is not supported.)

One possible solution is that disable this optimization at 
i915_memcpy_init_early.
This require us to identify the CPUID to check if it is running in guest mode.

What do you think? Thanks.

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Disable all planes for load detection, v2.

[Maarten Lankhorst]

Op 20-12-17 om 11:28 schreef Daniel Vetter:
> On Wed, Dec 20, 2017 at 10:35:45AM +0100, Maarten Lankhorst wrote:
>> From: Ville Syrjälä 
>>
>> We don't need any active planes during load detection, so just disable
>> them all. This saves us from having to come up with a suitable
>> framebuffer. And we also avoid leaving sprite/cursor planes on and
>> potentially presenting them at a peculiar location during the load
>> detection.
>>
>> Changes since v1 (Maarten):
>> - Add missing call to add_all_affected_planes.
>>
>> Signed-off-by: Ville Syrjälä 
>> Signed-off-by: Maarten Lankhorst 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102707
> Less code, I like. And I think we have enough load-detect machines (+ plus
> the nasty igt to do it anywhere we still have native vga) to have
> reasonable ensurance it actually works.
>
> But maybe let's soak this in -next first for a while, then cherry-pick
> over after a few weeks once it's solid.
>
> With the missing Fixes: line added.
>
> Reviewed-by: Daniel Vetter 
Pushed, didn't add fixes since it's an ancient bug, for a piece of code that 
changed a lot.
Since in most cases the fbcon fb will be leaked, the impact is just a warning 
and not even
a real leak. :)

Thanks for review,

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

[Intel-gfx] [PATCH i-g-t v3] scripts/trace.pl: Optimize event parsing and processing

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

A couple of small optimizations which altogether bring around 30%
improvement in my testing.

1. Do less string processing on tracepoints names and push more of the
   check into the if-ladder.

2. Pull out common db key and ctx processing and cache common values in
   local vars.

3. Key value pair parsing is faster with a regexp.

4. Avoid sorting the db hash multiple times if possible.

v2:
 * Use faster key-value splitting method. (John Harrison)

v3:
 * Fix floating-point to int time conversion.

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

diff --git a/scripts/trace.pl b/scripts/trace.pl
index ade0a9154bd7..539024a4dbbd 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -356,110 +356,92 @@ my $prev_freq = 0;
 my $prev_freq_ts = 0;
 while (<>) {
my @fields;
-   my @tmp;
my $tp_name;
-   my $time;
my %tp;
-   my $key;
+   my ($time, $ctx, $ring, $seqno, $orig_ctx, $key);
 
chomp;
@fields = split ' ';
 
+   chop $fields[3];
+   $time = int($fields[3] * 100.0 + 0.5);
+
$tp_name = $fields[4];
-   @tmp = split ':', $tp_name, 2;
-   next unless $tmp[0] eq 'i915';
-   $tp_name = $tmp[1];
-   chop $tp_name;
 
-   chop $fields[3];
-   $time = $fields[3] * 100.0;
splice @fields, 0, 5;
 
foreach my $f (@fields) {
-   my @kv = split '=|,', $f;
-
-   $kv[0] = 'global' if $kv[0] eq 'global_seqno';
+   my ($k, $v);
 
-   $tp{$kv[0]} = $kv[1];
+   next unless $f =~ m/=/;
+   ($k, $v) = ($`, $');
+   $k = 'global' if $k eq 'global_seqno';
+   chop $v if substr($v, -1, 1) eq ',';
+   $tp{$k} = $v;
}
 
next if exists $tp{'ring'} and exists $ignore_ring{$tp{'ring'}};
 
-   if ($tp_name eq 'i915_gem_request_wait_begin') {
-   my %rw;
+   if (exists $tp{'ring'} and exists $tp{'ctx'} and exists $tp{'seqno'}) {
+   $ring = $tp{'ring'};
+   $ctx = $tp{'ctx'};
+   $seqno = $tp{'seqno'};
+
+   $orig_ctx = $ctx;
+   $ctx = sanitize_ctx($ctx, $ring);
+   $key = db_key($ring, $ctx, $seqno);
+   }
 
-   $tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
+   if ($tp_name eq 'i915:i915_gem_request_wait_begin:') {
+   my %rw;
 
next if exists $reqwait{$key};
 
$rw{'key'} = $key;
-   $rw{'ring'} = $tp{'ring'};
-   $rw{'seqno'} = $tp{'seqno'};
-   $rw{'ctx'} = $tp{'ctx'};
+   $rw{'ring'} = $ring;
+   $rw{'seqno'} = $seqno;
+   $rw{'ctx'} = $ctx;
$rw{'start'} = $time;
$reqwait{$key} = \%rw;
-   next;
-   } elsif ($tp_name eq 'i915_gem_request_wait_end') {
-   $tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
-
+   } elsif ($tp_name eq 'i915:i915_gem_request_wait_end:') {
next unless exists $reqwait{$key};
 
$reqwait{$key}->{'end'} = $time;
-   next;
-   } elsif ($tp_name eq 'i915_gem_request_add') {
-   my $orig_ctx = $tp{'ctx'};
-
-   $tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
-
+   } elsif ($tp_name eq 'i915:i915_gem_request_add:') {
if (exists $queue{$key}) {
$ctxdb{$orig_ctx}++;
-   $tp{'ctx'} = sanitize_ctx($orig_ctx, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
+   $ctx = sanitize_ctx($orig_ctx, $ring);
+   $key = db_key($ring, $ctx, $seqno);
}
 
$queue{$key} = $time;
-   next;
-   } elsif ($tp_name eq 'i915_gem_request_submit') {
-   $tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
-
+   } elsif ($tp_name eq 'i915:i915_gem_request_submit:') {
die if exists $submit{$key};
die unless exists $queue{$key};
 
$submit{$key} = $time;
-   next;
-   } elsif ($tp_name eq 'i915_gem_request_in') {
+   } elsif ($tp_name eq 'i915:i915_gem_request_in:') {
my %req;
 
-   $tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
-
die