Re: [Intel-gfx] DRM Inquiry
On Wed, 13 Jun 2018, John Sledge wrote: > I like to understand how the DRM_DP_AUX_CHARDEV=y kick off. Try 'git grep DRM_DP_AUX_CHARDEV' in your kernel git repo, and see how it affects conditional compilation. This list isn't kernel development 101. You still didn't say what your end goal is. Forget everything about DP AUX and the chardev and so on, just tell us what you're trying to achieve. Maybe you're asking about X, but you really want to know about Y. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Problems in intel_panel_fitter.1
On Tue, 12 Jun 2018, e...@thyrsus.com wrote:
> This is automatically generated email about markup problems in a man
> page for which you appear to be responsible. If you are not the right
> person or list, please tell me so I can correct my database.
>
> See http://catb.org/~esr/doclifter/bugs.html for details on how and
> why these patches were generated. Feel free to email me with any
> questions. Note: These patches do not change the modification date of
> any manual page. You may wish to do that by hand.
>
> I apologize if this message seems spammy or impersonal. The volume of
> markup bugs I am tracking is over five hundred - there is no real
> alternative to generating bugmail from a database and template.
>
> --
> Eric S. Raymond
> Problems with intel_panel_fitter.1:
>
> My translator trips over a useless command in list markup.
The man pages have been written in reStructuredText and converted to
manual pages using rst2man(1) since intel-gpu-tools version 1.15,
specifically commit cc7387f17ce5 ("man: rewrite manual pages in
reStructuredText").
Based on the dates in the diff, I'm guessing this is no longer a
problem.
BR,
Jani.
>
> --- intel_panel_fitter.1-unpatched2013-05-25 10:53:50.568627955 -0400
> +++ intel_panel_fitter.1 2013-05-25 10:54:08.112627627 -0400
> @@ -30,7 +30,6 @@
> .TP
> .B -h
> prints the help message.
> -.SS
>
> .SH EXAMPLES
> .TP
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gtt: Only keep gen6 page directories pinned while active
== Series Details == Series: drm/i915/gtt: Only keep gen6 page directories pinned while active URL : https://patchwork.freedesktop.org/series/44649/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309_full -> Patchwork_9281_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9281_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9281_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9281_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9281_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: NOTRUN -> INCOMPLETE (fdo#103359, k.org#198133) igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560) igt@drv_selftest@mock_scatterlist: shard-glk: NOTRUN -> DMESG-WARN (fdo#103667) igt@gem_exec_schedule@pi-ringfull-bsd: shard-glk: NOTRUN -> FAIL (fdo#103158) igt@gem_exec_suspend@basic-s4-devices: shard-hsw: PASS -> FAIL (fdo#105900) +1 igt@gem_render_tiled_blits@basic: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) igt@perf_pmu@busy-accuracy-50-vcs1: shard-snb: SKIP -> INCOMPLETE (fdo#105411) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#105363, fdo#102887) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt: shard-glk: FAIL (fdo#103167, fdo#104724) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9281 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9281: 493a78101b233088ae05d4d3b80cf76efa60d69b @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9281/shards.html ___ 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/gvt: Enable KVMGT for BXT
On 06/13/2018 09:30 AM, Chris Wilson wrote: Quoting Zhenyu Wang (2018-06-13 04:44:12) On 2018.06.11 10:09:52 +0100, Chris Wilson wrote: Quoting Patchwork (2018-06-11 10:05:46) == Series Details == Series: drm/i915/gvt: Enable KVMGT for BXT URL : https://patchwork.freedesktop.org/series/44551/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4299 -> Patchwork_9253 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44551/revisions/1/mbox/ While we have your attention, please note that all the gvtdvm machines are failing on suspend. Could you please investigate as it means we have no coverage at all for the impact on gvt of any patch? Chris, where can we check current gvt-d config on CI machine? Better ask Tomi. I do believe he's changed the current config again to avoid the failure, but it would be wise for those fails to not exist. -Chris The changes are covered in bug https://bugs.freedesktop.org/show_bug.cgi?id=105600 I did revert the gvtd qemu command line changes to make the testing usable again. I'm a bit concerned about this, because the commandline seems to be half magic numbers and non-obvious options, and if they are changed then VM isn't working as well. Tomi -- Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: Adds psrwake options for all platforms
From: Vathsala Nagaraju
Adds new psrwake options defined in the below table.
PlatformPSR wake options vbt version
KBL/CFL/WHL All
SKL All PV releases (Check for 203+ might help but cannot be
foolproof)
BXT Uses old interpretation.
CNL/ICL+All
GLK All
For SKL, we will continue to use older interpretation for the above reason.
v2: Jani
Keep the bdb version check.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Puthikorn Voravootivat
Cc: Dhinakaran Pandiyan
Signed-off-by: Vathsala Nagaraju
---
drivers/gpu/drm/i915/intel_bios.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 465dff4..5517ca7 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -710,7 +710,8 @@ static int intel_bios_ssc_frequency(struct drm_i915_private
*dev_priv,
* New psr options 0=500us, 1=100us, 2=2500us, 3=0us
* Old decimal value is wake up time in multiples of 100 us.
*/
- if (bdb->version >= 209 && IS_GEN9_BC(dev_priv)) {
+ if (bdb->version >= 209 && ((INTEL_GEN(dev_priv) >= 10) ||
+ (IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv {
switch (psr_table->tp1_wakeup_time) {
case 0:
dev_priv->vbt.psr.tp1_wakeup_time_us = 500;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/icl: Add allowed DP rates for Icelake
On Tue, 12 Jun 2018, Rodrigo Vivi wrote: > Do we really want BIT everywhere?! I think I'd go for everywhere except part of a register field value: #define SINGLE_BIT_OKAY BIT(25) #define FIELD_SHIFT 20 #define FIELD_MASK (0xf << 20) #define FIELD_FOO_PLEASE_NO BIT(20) /* Don't do this */ #define FIELD_FOO (1 << 20) /* This is consistent */ #define FIELD_BAR (2 << 20) #define FIELD_BAZ (3 << 20) BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > On Tue, 12 Jun 2018, Lucas De Marchi wrote: > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula wrote: > >> > >> On Thu, 31 May 2018, Lucas De Marchi wrote: > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > >> >> specific case to indicate a PCH system without south display. > >> > > >> > Then let's go ahead and document it? > >> > >> Please avoid sending suggestion patches in-reply-to existing > >> series. This confused patchwork and screwed up CI for the series, which > >> was already a resend just to get CI. :( > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > a hundred words explaining :( ... > > I feel you, a patch is more precise. > > > IMO pw is trying to be smarter than it should here or not being smart > > enough. Nonetheless I won't do that anymore. > > I think there were earlier complaints about what it did recognize and > what it didn't. I'd be open to only accepting new versions of patches > from whoever sent the original patch. Or requiring patch subjects don't > start with "Re:". Or both. No matter what you do here it will misbehave in some scenarios and break someone's workflow :< Originally we required the patches to have X-Mailer set to git-send-email, which seems reasonable, but that annoyed people because their servers were stripping out those headers. Other people send out the patches by feeding them to the drafts folder through IMAP and then sending them out. This, depending on the provider's configuration, also gobbles up a thing or two. Because of the above I am not sure about trusting "Re:" and matching "From:" headers as good enough indicators either. It just adds more opaque "smartness". I already can foresee questions asking "why my v2 was not picked up?" and someone would have to debug it down the line. Was the address different (+XYZ before @)? Has that someone used --subject-prefix=re:? Is it an actual bug? Etc. > I was annoyed, but I'm perhaps more annoyed that you can't do this > without confusing patchwork. In the end, I wouldn't want to hamper > review by blocking something that comes naturally to people. > > Arek? Just add the following header: "X-Patchwork-Hint: comment" to emails that you type out manually. For mutt it's as easy as adding: "my_hdr X-Patchwork-Hint: comment" to your .muttrc https://github.com/dlespiau/patchwork/commit/148f10115525 -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/psr: Adds psrwake options for all platforms (rev2)
== Series Details ==
Series: drm/i915/psr: Adds psrwake options for all platforms (rev2)
URL : https://patchwork.freedesktop.org/series/44601/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e6bea8c90022 drm/i915/psr: Adds psrwake options for all platforms
-:36: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#36: FILE: drivers/gpu/drm/i915/intel_bios.c:714:
+ if (bdb->version >= 209 && ((INTEL_GEN(dev_priv) >= 10) ||
+ (IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv {
total: 0 errors, 0 warnings, 1 checks, 9 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DRM Inquiry
Hi Jani, The end goal was already achieve by the advice you gave the DRM_DP_AUX_CHARDEV.I just like to extend my knowledge into DRM such as a scenario having a kernel version that doesn't have the DRM_DP_AUX_CHARDEV yet. Would it possible to implement specific DRM_DP_AUX_CHARDEV to it. Thanks,John On Wednesday, June 13, 2018, 3:07:14 PM GMT+8, Jani Nikula wrote: On Wed, 13 Jun 2018, John Sledge wrote: > I like to understand how the DRM_DP_AUX_CHARDEV=y kick off. Try 'git grep DRM_DP_AUX_CHARDEV' in your kernel git repo, and see how it affects conditional compilation. This list isn't kernel development 101. You still didn't say what your end goal is. Forget everything about DP AUX and the chardev and so on, just tell us what you're trying to achieve. Maybe you're asking about X, but you really want to know about Y. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Adds psrwake options for all platforms (rev2)
== Series Details == Series: drm/i915/psr: Adds psrwake options for all platforms (rev2) URL : https://patchwork.freedesktop.org/series/44601/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309 -> Patchwork_9282 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44601/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9282 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106725, fdo#106248) igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: fi-glk-j4005: PASS -> FAIL (fdo#106765) igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: PASS -> FAIL (fdo#100368) igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-glk-j4005: PASS -> FAIL (fdo#103481) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 fdo#106765 https://bugs.freedesktop.org/show_bug.cgi?id=106765 == Participating hosts (43 -> 37) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9282 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9282: e6bea8c90022b9d1b768a6ae2ba1ac3dd22502e5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e6bea8c90022 drm/i915/psr: Adds psrwake options for all platforms == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9282/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/psr: Adds psrwake options for all platforms (rev2)
== Series Details == Series: drm/i915/psr: Adds psrwake options for all platforms (rev2) URL : https://patchwork.freedesktop.org/series/44601/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309_full -> Patchwork_9282_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9282_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9282_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9282_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9282_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: NOTRUN -> INCOMPLETE (k.org#198133, fdo#103359) igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560) igt@drv_selftest@mock_scatterlist: shard-glk: NOTRUN -> DMESG-WARN (fdo#103667) igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: PASS -> INCOMPLETE (fdo#106023, fdo#103665) igt@kms_flip@2x-flip-vs-dpms: shard-hsw: PASS -> DMESG-WARN (fdo#102614) igt@kms_flip@2x-plain-flip-ts-check: shard-hsw: PASS -> FAIL (fdo#100368) +1 igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-x-tiled: shard-glk: NOTRUN -> FAIL (fdo#103822, fdo#104724) igt@kms_sysfs_edid_timing: shard-glk: NOTRUN -> WARN (fdo#100047) igt@perf_pmu@busy-accuracy-50-vcs1: shard-snb: SKIP -> INCOMPLETE (fdo#105411) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt: shard-glk: FAIL (fdo#104724, fdo#103167) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9282 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9282: e6bea8c90022b9d1b768a6ae2ba1ac3dd22502e5 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9282/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: add support for perf configuration queries
Quoting Lionel Landwerlin (2018-06-12 19:54:41) > Listing configurations at the moment is supported only through sysfs. > This might cause issues for applications wanting to list > configurations from a container where sysfs isn't available. > > This change adds a way to query the number of configurations and their > content through the i915 query uAPI. > > v2: Fix sparse warnings (Lionel) > Add support to query configuration using uuid (Lionel) > > Signed-off-by: Lionel Landwerlin For uAPI changes, please always reference the respective userspace patches and it's bonus if the patch title is in the fashion of "Add perf configuration query uAPI" for easy spotting by maintainers. Now it's only the last word of the commit message that highlights it's about new "uAPI". Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: make plane func structs const
No reason not to be const.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2c16c3a3cdea..4bb8c12c333f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13346,7 +13346,7 @@ static bool intel_cursor_format_mod_supported(struct
drm_plane *_plane,
format == DRM_FORMAT_ARGB;
}
-static struct drm_plane_funcs skl_plane_funcs = {
+static const struct drm_plane_funcs skl_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = intel_plane_destroy,
@@ -13357,7 +13357,7 @@ static struct drm_plane_funcs skl_plane_funcs = {
.format_mod_supported = skl_plane_format_mod_supported,
};
-static struct drm_plane_funcs i965_plane_funcs = {
+static const struct drm_plane_funcs i965_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = intel_plane_destroy,
@@ -13368,7 +13368,7 @@ static struct drm_plane_funcs i965_plane_funcs = {
.format_mod_supported = i965_plane_format_mod_supported,
};
-static struct drm_plane_funcs i8xx_plane_funcs = {
+static const struct drm_plane_funcs i8xx_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = intel_plane_destroy,
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Adds psrwake options for all platforms
On Tue, Jun 12, 2018 at 10:49:09AM +0530, vathsala nagaraju wrote:
> From: Vathsala Nagaraju
>
> Adds new psrwake options defined in the below table.
> Platform PSR wake options vbt version
> KBL/CFL/WHL All
> SKL All PV releases (Check for 203+ might help but cannot be
> foolproof)
> BXT Uses old interpretation.
> CNL/ICL+ All
> GLK All
>
> For SKL, we will continue to use older interpretation for the above reason.
>
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Puthikorn Voravootivat
> Cc: Dhinakaran Pandiyan
>
> Signed-off-by: Vathsala Nagaraju
> ---
> drivers/gpu/drm/i915/intel_bios.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 465dff4..010ff68 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -710,7 +710,8 @@ static int intel_bios_ssc_frequency(struct
> drm_i915_private *dev_priv,
>* New psr options 0=500us, 1=100us, 2=2500us, 3=0us
>* Old decimal value is wake up time in multiples of 100 us.
>*/
> - if (bdb->version >= 209 && IS_GEN9_BC(dev_priv)) {
> + if ((INTEL_GEN(dev_priv) >= 10) ||
> + (IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))) {
That doesn't match your commit message.
> switch (psr_table->tp1_wakeup_time) {
> case 0:
> dev_priv->vbt.psr.tp1_wakeup_time_us = 500;
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make plane func structs const
== Series Details == Series: drm/i915: make plane func structs const URL : https://patchwork.freedesktop.org/series/44685/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309 -> Patchwork_9283 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44685/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9283 that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@basic: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106743) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106743 https://bugs.freedesktop.org/show_bug.cgi?id=106743 == Participating hosts (43 -> 37) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9283 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9283: 92ec47d0c1122bdced67c921eb70bea6b02868d3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 92ec47d0c112 drm/i915: make plane func structs const == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9283/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/opregion: move acpi notifier to dev_priv
Get rid of the silly static variable.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 31 ---
drivers/gpu/drm/i915/intel_opregion.h | 1 +
2 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index c58e5f53bab0..e034b4166d32 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -608,16 +608,16 @@ void intel_opregion_asle_intr(struct drm_i915_private
*dev_priv)
#define ACPI_EV_LID(1<<1)
#define ACPI_EV_DOCK (1<<2)
-static struct intel_opregion *system_opregion;
-
+/*
+ * The only video events relevant to opregion are 0x80. These indicate either a
+ * docking event, lid switch or display switch request. In Linux, these are
+ * handled by the dock, button and video drivers.
+ */
static int intel_opregion_video_event(struct notifier_block *nb,
unsigned long val, void *data)
{
- /* The only video events relevant to opregion are 0x80. These indicate
- either a docking event, lid switch or display switch request. In
- Linux, these are handled by the dock, button and video drivers.
- */
-
+ struct intel_opregion *opregion = container_of(nb, struct
intel_opregion,
+ acpi_notifier);
struct acpi_bus_event *event = data;
struct opregion_acpi *acpi;
int ret = NOTIFY_OK;
@@ -625,10 +625,7 @@ static int intel_opregion_video_event(struct
notifier_block *nb,
if (strcmp(event->device_class, ACPI_VIDEO_CLASS) != 0)
return NOTIFY_DONE;
- if (!system_opregion)
- return NOTIFY_DONE;
-
- acpi = system_opregion->acpi;
+ acpi = opregion->acpi;
if (event->type == 0x80 && ((acpi->cevt & 1) == 0))
ret = NOTIFY_BAD;
@@ -638,10 +635,6 @@ static int intel_opregion_video_event(struct
notifier_block *nb,
return ret;
}
-static struct notifier_block intel_opregion_notifier = {
- .notifier_call = intel_opregion_video_event,
-};
-
/*
* Initialise the DIDL field in opregion. This passes a list of devices to
* the firmware. Values are defined by section B.4.2 of the ACPI specification
@@ -797,8 +790,8 @@ void intel_opregion_register(struct drm_i915_private
*dev_priv)
opregion->acpi->csts = 0;
opregion->acpi->drdy = 1;
- system_opregion = opregion;
- register_acpi_notifier(&intel_opregion_notifier);
+ opregion->acpi_notifier.notifier_call =
intel_opregion_video_event;
+ register_acpi_notifier(&opregion->acpi_notifier);
}
if (opregion->asle) {
@@ -822,8 +815,8 @@ void intel_opregion_unregister(struct drm_i915_private
*dev_priv)
if (opregion->acpi) {
opregion->acpi->drdy = 0;
- system_opregion = NULL;
- unregister_acpi_notifier(&intel_opregion_notifier);
+ unregister_acpi_notifier(&opregion->acpi_notifier);
+ opregion->acpi_notifier.notifier_call = NULL;
}
/* just clear all opregion memory pointers now */
diff --git a/drivers/gpu/drm/i915/intel_opregion.h
b/drivers/gpu/drm/i915/intel_opregion.h
index e0e437ba9e51..e8498a8cda3d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.h
+++ b/drivers/gpu/drm/i915/intel_opregion.h
@@ -49,6 +49,7 @@ struct intel_opregion {
u32 vbt_size;
u32 *lid_state;
struct work_struct asle_work;
+ struct notifier_block acpi_notifier;
};
#define OPREGION_SIZE(8 * 1024)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/opregion: move acpi notifier to dev_priv
Quoting Jani Nikula (2018-06-13 12:39:27) > Get rid of the silly static variable. > > Signed-off-by: Jani Nikula Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: make skl plane and planar format tables const
No reason not to be const.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 344c0e709b19..412782f3b065 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1256,7 +1256,7 @@ static const uint32_t vlv_plane_formats[] = {
DRM_FORMAT_VYUY,
};
-static uint32_t skl_plane_formats[] = {
+static const uint32_t skl_plane_formats[] = {
DRM_FORMAT_RGB565,
DRM_FORMAT_ABGR,
DRM_FORMAT_ARGB,
@@ -1268,7 +1268,7 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
};
-static uint32_t skl_planar_formats[] = {
+static const uint32_t skl_planar_formats[] = {
DRM_FORMAT_RGB565,
DRM_FORMAT_ABGR,
DRM_FORMAT_ARGB,
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/perf: make oa format tables const
No reason not to be const.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 881a992305ec..447407fee3b8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -315,7 +315,7 @@ static u32 i915_oa_max_sample_rate = 10;
* code assumes all reports have a power-of-two size and ~(size - 1) can
* be used as a mask to align the OA tail pointer.
*/
-static struct i915_oa_format hsw_oa_formats[I915_OA_FORMAT_MAX] = {
+static const struct i915_oa_format hsw_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A13]= { 0, 64 },
[I915_OA_FORMAT_A29]= { 1, 128 },
[I915_OA_FORMAT_A13_B8_C8] = { 2, 128 },
@@ -326,7 +326,7 @@ static struct i915_oa_format
hsw_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_C4_B8] = { 7, 64 },
};
-static struct i915_oa_format gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
+static const struct i915_oa_format gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A12]= { 0, 64 },
[I915_OA_FORMAT_A12_B8_C8] = { 2, 128 },
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: make oa format tables const
On 13/06/18 12:49, Jani Nikula wrote:
No reason not to be const.
Signed-off-by: Jani Nikula
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 881a992305ec..447407fee3b8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -315,7 +315,7 @@ static u32 i915_oa_max_sample_rate = 10;
* code assumes all reports have a power-of-two size and ~(size - 1) can
* be used as a mask to align the OA tail pointer.
*/
-static struct i915_oa_format hsw_oa_formats[I915_OA_FORMAT_MAX] = {
+static const struct i915_oa_format hsw_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A13]= { 0, 64 },
[I915_OA_FORMAT_A29]= { 1, 128 },
[I915_OA_FORMAT_A13_B8_C8] = { 2, 128 },
@@ -326,7 +326,7 @@ static struct i915_oa_format
hsw_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_C4_B8] = { 7, 64 },
};
-static struct i915_oa_format gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
+static const struct i915_oa_format gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A12]= { 0, 64 },
[I915_OA_FORMAT_A12_B8_C8] = { 2, 128 },
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
___
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: make plane func structs const
== Series Details == Series: drm/i915: make plane func structs const URL : https://patchwork.freedesktop.org/series/44685/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309_full -> Patchwork_9283_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9283_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9283_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9283_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9283_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: NOTRUN -> FAIL (fdo#105347) igt@drv_selftest@mock_scatterlist: shard-glk: NOTRUN -> DMESG-WARN (fdo#103667) igt@gem_exec_schedule@pi-ringfull-bsd: shard-glk: NOTRUN -> FAIL (fdo#103158) igt@gem_mmap_gtt@coherency: shard-glk: NOTRUN -> FAIL (fdo#100587) igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: PASS -> INCOMPLETE (fdo#103665, fdo#106023) igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105189) igt@kms_flip_tiling@flip-x-tiled: shard-glk: NOTRUN -> FAIL (fdo#104724) +1 igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc: shard-glk: NOTRUN -> FAIL (fdo#104724, fdo#103167) igt@kms_setmode@basic: shard-glk: NOTRUN -> FAIL (fdo#99912) igt@kms_sysfs_edid_timing: shard-glk: NOTRUN -> WARN (fdo#100047) igt@perf_pmu@busy-accuracy-50-vcs1: shard-snb: SKIP -> INCOMPLETE (fdo#105411) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt: shard-glk: FAIL (fdo#104724, fdo#103167) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9283 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9283: 92ec47d0c1122bdced67c921eb70bea6b02868d3 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9283/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freede
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/opregion: move acpi notifier to dev_priv
== Series Details == Series: drm/i915/opregion: move acpi notifier to dev_priv URL : https://patchwork.freedesktop.org/series/44694/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309 -> Patchwork_9284 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9284 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9284, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44694/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9284: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9284 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_switch@basic-default-heavy: fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719) +1 igt@kms_flip@basic-plain-flip: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-WARN (fdo#106607) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106607 https://bugs.freedesktop.org/show_bug.cgi?id=106607 == Participating hosts (43 -> 38) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9284 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9284: 2084fb72b973bdb184a8c568502cdd444afb378c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2084fb72b973 drm/i915/opregion: move acpi notifier to dev_priv == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9284/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: make skl plane and planar format tables const
On Wed, Jun 13, 2018 at 02:46:20PM +0300, Jani Nikula wrote:
> No reason not to be const.
>
> Signed-off-by: Jani Nikula
Or we can go with
https://patchwork.freedesktop.org/patch/226880/
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 344c0e709b19..412782f3b065 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1256,7 +1256,7 @@ static const uint32_t vlv_plane_formats[] = {
> DRM_FORMAT_VYUY,
> };
>
> -static uint32_t skl_plane_formats[] = {
> +static const uint32_t skl_plane_formats[] = {
> DRM_FORMAT_RGB565,
> DRM_FORMAT_ABGR,
> DRM_FORMAT_ARGB,
> @@ -1268,7 +1268,7 @@ static uint32_t skl_plane_formats[] = {
> DRM_FORMAT_VYUY,
> };
>
> -static uint32_t skl_planar_formats[] = {
> +static const uint32_t skl_planar_formats[] = {
> DRM_FORMAT_RGB565,
> DRM_FORMAT_ABGR,
> DRM_FORMAT_ARGB,
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make plane func structs const
On Wed, Jun 13, 2018 at 01:24:22PM +0300, Jani Nikula wrote:
> No reason not to be const.
>
> Signed-off-by: Jani Nikula
https://patchwork.freedesktop.org/patch/226875/
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2c16c3a3cdea..4bb8c12c333f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13346,7 +13346,7 @@ static bool intel_cursor_format_mod_supported(struct
> drm_plane *_plane,
> format == DRM_FORMAT_ARGB;
> }
>
> -static struct drm_plane_funcs skl_plane_funcs = {
> +static const struct drm_plane_funcs skl_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy = intel_plane_destroy,
> @@ -13357,7 +13357,7 @@ static struct drm_plane_funcs skl_plane_funcs = {
> .format_mod_supported = skl_plane_format_mod_supported,
> };
>
> -static struct drm_plane_funcs i965_plane_funcs = {
> +static const struct drm_plane_funcs i965_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy = intel_plane_destroy,
> @@ -13368,7 +13368,7 @@ static struct drm_plane_funcs i965_plane_funcs = {
> .format_mod_supported = i965_plane_format_mod_supported,
> };
>
> -static struct drm_plane_funcs i8xx_plane_funcs = {
> +static const struct drm_plane_funcs i8xx_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy = intel_plane_destroy,
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 0/2] Enable Dynamic cdclk and HDA together on GLK
On Tue, Jun 12, 2018 at 02:58:45PM -0700, Abhay Kumar wrote: > Patches needed to change cdclk to 2*BCLK before accessing HDA Codec. > > Ville Syrjälä (2): > drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled > drm/i915: Shut off PW2 when changing cdclk on glk Patchwork is probably totally confused by the threading here, so I doubt you will get any testing report for this. Also these two alone aren't sufficient. You'll need at least the other two patches from the pw2 toggle branch. > > drivers/gpu/drm/i915/i915_drv.h | 3 ++ > drivers/gpu/drm/i915/i915_reg.h | 4 ++ > drivers/gpu/drm/i915/intel_audio.c | 67 > +++-- > drivers/gpu/drm/i915/intel_cdclk.c | 43 +++-- > drivers/gpu/drm/i915/intel_display.c| 7 +++- > drivers/gpu/drm/i915/intel_drv.h| 7 > drivers/gpu/drm/i915/intel_runtime_pm.c | 34 + > 7 files changed, 140 insertions(+), 25 deletions(-) > > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/12] drm/i915: Constify all plane_funcs structs
On Fri, 01 Jun 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> plane_funcs can be cosnt. Make them so.
>
> v2: Rebase due to per-platforms plane_funcs
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 29940520a171..f0b269a2bc64 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13331,7 +13331,7 @@ static bool intel_cursor_format_mod_supported(struct
> drm_plane *_plane,
> format == DRM_FORMAT_ARGB;
> }
>
> -static struct drm_plane_funcs skl_plane_funcs = {
> +static const struct drm_plane_funcs skl_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy = intel_plane_destroy,
> @@ -13342,7 +13342,7 @@ static struct drm_plane_funcs skl_plane_funcs = {
> .format_mod_supported = skl_plane_format_mod_supported,
> };
>
> -static struct drm_plane_funcs i965_plane_funcs = {
> +static const struct drm_plane_funcs i965_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy = intel_plane_destroy,
> @@ -13353,7 +13353,7 @@ static struct drm_plane_funcs i965_plane_funcs = {
> .format_mod_supported = i965_plane_format_mod_supported,
> };
>
> -static struct drm_plane_funcs i8xx_plane_funcs = {
> +static const struct drm_plane_funcs i8xx_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy = intel_plane_destroy,
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make plane func structs const
On Wed, 13 Jun 2018, Ville Syrjälä wrote:
> On Wed, Jun 13, 2018 at 01:24:22PM +0300, Jani Nikula wrote:
>> No reason not to be const.
>>
>> Signed-off-by: Jani Nikula
>
> https://patchwork.freedesktop.org/patch/226875/
Okay, rb on that.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 2c16c3a3cdea..4bb8c12c333f 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -13346,7 +13346,7 @@ static bool intel_cursor_format_mod_supported(struct
>> drm_plane *_plane,
>> format == DRM_FORMAT_ARGB;
>> }
>>
>> -static struct drm_plane_funcs skl_plane_funcs = {
>> +static const struct drm_plane_funcs skl_plane_funcs = {
>> .update_plane = drm_atomic_helper_update_plane,
>> .disable_plane = drm_atomic_helper_disable_plane,
>> .destroy = intel_plane_destroy,
>> @@ -13357,7 +13357,7 @@ static struct drm_plane_funcs skl_plane_funcs = {
>> .format_mod_supported = skl_plane_format_mod_supported,
>> };
>>
>> -static struct drm_plane_funcs i965_plane_funcs = {
>> +static const struct drm_plane_funcs i965_plane_funcs = {
>> .update_plane = drm_atomic_helper_update_plane,
>> .disable_plane = drm_atomic_helper_disable_plane,
>> .destroy = intel_plane_destroy,
>> @@ -13368,7 +13368,7 @@ static struct drm_plane_funcs i965_plane_funcs = {
>> .format_mod_supported = i965_plane_format_mod_supported,
>> };
>>
>> -static struct drm_plane_funcs i8xx_plane_funcs = {
>> +static const struct drm_plane_funcs i8xx_plane_funcs = {
>> .update_plane = drm_atomic_helper_update_plane,
>> .disable_plane = drm_atomic_helper_disable_plane,
>> .destroy = intel_plane_destroy,
>> --
>> 2.11.0
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make skl plane and planar format tables const
On Wed, 13 Jun 2018, Ville Syrjälä wrote:
> On Wed, Jun 13, 2018 at 02:46:20PM +0300, Jani Nikula wrote:
>> No reason not to be const.
>>
>> Signed-off-by: Jani Nikula
>
> Or we can go with
> https://patchwork.freedesktop.org/patch/226880/
Fine by me.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>> b/drivers/gpu/drm/i915/intel_sprite.c
>> index 344c0e709b19..412782f3b065 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -1256,7 +1256,7 @@ static const uint32_t vlv_plane_formats[] = {
>> DRM_FORMAT_VYUY,
>> };
>>
>> -static uint32_t skl_plane_formats[] = {
>> +static const uint32_t skl_plane_formats[] = {
>> DRM_FORMAT_RGB565,
>> DRM_FORMAT_ABGR,
>> DRM_FORMAT_ARGB,
>> @@ -1268,7 +1268,7 @@ static uint32_t skl_plane_formats[] = {
>> DRM_FORMAT_VYUY,
>> };
>>
>> -static uint32_t skl_planar_formats[] = {
>> +static const uint32_t skl_planar_formats[] = {
>> DRM_FORMAT_RGB565,
>> DRM_FORMAT_ABGR,
>> DRM_FORMAT_ARGB,
>> --
>> 2.11.0
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make skl plane and planar format tables const
== Series Details == Series: drm/i915: make skl plane and planar format tables const URL : https://patchwork.freedesktop.org/series/44696/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309 -> Patchwork_9285 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9285 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9285, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44696/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9285: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9285 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@gem_ringfill@basic-default-hang: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9285 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9285: 82dc16264a2198e1afc2b3d49f1f7ab7a2e883c2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 82dc16264a21 drm/i915: make skl plane and planar format tables const == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9285/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 7/7] drm/i915: add a sysfs entry to let users set sseu configs
Quoting Tvrtko Ursulin (2018-06-12 15:02:07)
>
> On 12/06/2018 11:52, Lionel Landwerlin wrote:
> > On 12/06/18 11:37, Chris Wilson wrote:
> >> Quoting Lionel Landwerlin (2018-06-12 11:33:34)
> >>> On 12/06/18 10:20, Joonas Lahtinen wrote:
> Quoting Chris Wilson (2018-06-11 18:02:37)
> > Quoting Lionel Landwerlin (2018-06-11 14:46:07)
> >> On 11/06/18 13:10, Tvrtko Ursulin wrote:
> >>> On 30/05/2018 15:33, Lionel Landwerlin wrote:
> There are concerns about denial of service around the per
> context sseu
> configuration capability. In a previous commit introducing the
> capability we allowed it only for capable users. This changes
> adds a
> new debugfs entry to let any user configure its own context
> powergating setup.
> >>> As far as I understood it, Joonas' concerns here are:
> >>>
> >>> 1) That in the containers use case individual containers wouldn't be
> >>> able to turn on the sysfs toggle for them.
> >>>
> >>> 2) That also in the containers use case if box admin turns on the
> >>> feature, some containers would potentially start negatively
> >>> affecting
> >>> the others (via the accumulated cost of slice re-configuration on
> >>> context switching).
> >>>
> >>> I am not familiar with typical container setups to be authoritative
> >>> here, but intuitively I find it reasonable that a low-level hardware
> >>> switch like this would be under the control of a master domain
> >>> administrator. ("If you are installing our product in the container
> >>> environment, make sure your system administrator enables this
> >>> hardware
> >>> feature.", "Note to system administrators: Enabling this features
> >>> may
> >>> negatively affect the performance of other containers.")
> >>>
> >>> Alternative proposal is for the i915 to apply an "or" filter on all
> >>> requested masks and in that way ensure dynamic re-configuration
> >>> doesn't happen on context switches, but driven from userspace via
> >>> ioctls.
> >>>
> >>> In other words, should _all_ userspace agree between themselves that
> >>> they want to turn off a slice, they would then need to send out a
> >>> concerted ioctl storm, where number of needed ioctls equals the
> >>> number
> >>> of currently active contexts. (This may have its own performance
> >>> consequences caused by the barriers needed to modify all context
> >>> images.)
> >>>
> >>> This was deemed acceptable the the media use case, but my concern is
> >>> the approach is not elegant and will tie us with the "or" policy in
> >>> the ABI. (Performance concerns I haven't evaluated yet, but they
> >>> also
> >>> may be significant.)
> >>>
> >>> If we go back thinking about the containers use case, then it
> >>> transpires that even though the "or" policy does prevent one
> >>> container
> >>> from affecting the other from one angle, it also prevents one
> >>> container from exercising the feature unless all containers
> >>> co-operate.
> >>>
> >>> As such, we can view the original problem statement where we have an
> >>> issue if not everyone co-operates, as conceptually the same just
> >>> from
> >>> an opposite angle. (Rather than one container incurring the
> >>> increased
> >>> cost of context switches to the rest, we would have one container
> >>> preventing the optimized slice configuration to the other.)
> >>>
> >>> From this follows that both proposals require complete
> >>> co-operation
> >>> from all running userspace to avoid complete control of the feature.
> >>>
> >>> Since the balance between the benefit of optimized slice
> >>> configuration
> >>> (or penalty of suboptimal one), versus the penalty of increased
> >>> context switch times, cannot be know by the driver (barring
> >>> venturing
> >>> into the heuristics territory), that is another reason why I find
> >>> the
> >>> "or" policy in the driver questionable.
> >>>
> >>> We can also ask a question of - If we go with the "or" policy, why
> >>> require N per-context ioctls to modify the global GPU configuration
> >>> and not instead add a global driver ioctl to modify the state?
> >>>
> >>> If a future hardware requires, or enables, the per-context behaviour
> >>> in a more efficient way, we could then revisit the problem space.
> >>>
> >>> In the mean time I see the "or" policy solution as adding some ABI
> >>> which doesn't do anything for many use cases without any way for the
> >>> sysadmin to enable it. At the same time master sysfs knob at least
> >>> enables the sysadmin to make a decision. Here I am thinking about a
> >>> random client environment where not all userspace co-operates,
> >>> but
Re: [Intel-gfx] [PATCH] drm/i915: Make closing request flush mandatory
Quoting Chris Wilson (2018-06-12 13:51:35) > For symmetry, simplicity and ensuring the request is always truly idle > upon its completion, always emit the closing flush prior to emitting the > request breadcrumb. Previously, we would only emit the flush if we had > started a user batch, but this just leaves all the other paths open to > speculation (do they affect the GPU caches or not?) With mm switching, a > key requirement is that the GPU is flushed and invalidated before hand, > so for absolute safety, we want that closing flush be mandatory. > > Signed-off-by: Chris Wilson No word about perf impact? The patch description matches what it does. Assuming we're not murdering any testcases; Reviewed-by: Joonas Lahtinen Regards, Joonas > --- > drivers/gpu/drm/i915/i915_gem.c| 4 ++-- > drivers/gpu/drm/i915/i915_gem_context.c| 9 + > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++-- > drivers/gpu/drm/i915/i915_request.c| 18 ++ > drivers/gpu/drm/i915/i915_request.h| 4 +--- > drivers/gpu/drm/i915/selftests/huge_pages.c| 2 +- > .../drm/i915/selftests/i915_gem_coherency.c| 4 ++-- > .../gpu/drm/i915/selftests/i915_gem_context.c | 4 ++-- > drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- > .../gpu/drm/i915/selftests/intel_hangcheck.c | 16 > drivers/gpu/drm/i915/selftests/intel_lrc.c | 2 +- > .../gpu/drm/i915/selftests/intel_workarounds.c | 2 +- > 12 files changed, 24 insertions(+), 47 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 93efd92362db..8dd4d35655af 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3213,7 +3213,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv, > rq = i915_request_alloc(engine, > dev_priv->kernel_context); > if (!IS_ERR(rq)) > - __i915_request_add(rq, false); > + i915_request_add(rq); > } > } > > @@ -5332,7 +5332,7 @@ static int __intel_engines_record_defaults(struct > drm_i915_private *i915) > if (engine->init_context) > err = engine->init_context(rq); > > - __i915_request_add(rq, true); > + i915_request_add(rq); > if (err) > goto err_active; > } > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c > b/drivers/gpu/drm/i915/i915_gem_context.c > index b2c7ac1b074d..ef6ea4bcd773 100644 > --- a/drivers/gpu/drm/i915/i915_gem_context.c > +++ b/drivers/gpu/drm/i915/i915_gem_context.c > @@ -700,14 +700,7 @@ int i915_gem_switch_to_kernel_context(struct > drm_i915_private *i915) > i915_timeline_sync_set(rq->timeline, &prev->fence); > } > > - /* > -* Force a flush after the switch to ensure that all rendering > -* and operations prior to switching to the kernel context > hits > -* memory. This should be guaranteed by the previous request, > -* but an extra layer of paranoia before we declare the system > -* idle (on suspend etc) is advisable! > -*/ > - __i915_request_add(rq, true); > + i915_request_add(rq); > } > > return 0; > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 2d2eb3075960..60dc2a865f5f 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -921,7 +921,7 @@ static void reloc_gpu_flush(struct reloc_cache *cache) > i915_gem_object_unpin_map(cache->rq->batch->obj); > i915_gem_chipset_flush(cache->rq->i915); > > - __i915_request_add(cache->rq, true); > + i915_request_add(cache->rq); > cache->rq = NULL; > } > > @@ -2438,7 +2438,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, > trace_i915_request_queue(eb.request, eb.batch_flags); > err = eb_submit(&eb); > err_request: > - __i915_request_add(eb.request, err == 0); > + i915_request_add(eb.request); > add_to_client(eb.request, file); > > if (fences) > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index 9092f5464c24..e1dbb544046f 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -1018,14 +1018,13 @@ i915_request_await_object(struct i915_request *to, > * request is not being tracked for completion but the work itself is > * going to happen on the hardware. This would be a Bad Thing(tm). > */ > -void __i915_request_add(struct i915_request *request, bool flush_caches) > +void i915_request_add(
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: make oa format tables const
== Series Details == Series: drm/i915/perf: make oa format tables const URL : https://patchwork.freedesktop.org/series/44697/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309 -> Patchwork_9286 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44697/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9286 that come from known issues: === IGT changes === Issues hit igt@gem_ringfill@basic-default-hang: fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719) igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 == Participating hosts (43 -> 38) == Missing(5): fi-ctg-p8600 fi-byt-squawks fi-ilk-m540 fi-bxt-dsi fi-bsw-cyan == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9286 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9286: e9e26f1ea6e7cbad5132e9fcbc61672fb06172a5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e9e26f1ea6e7 drm/i915/perf: make oa format tables const == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9286/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] [RFC] Add support to force specific module load
On Tue, May 29, 2018 at 09:45:20PM -0300, Rodrigo Siqueira wrote:
> This patch adds a new option to force the use of a module specified from
> the command line. The force command expects a module name which will be
> used on the target test (changing the standard behavior). This feature
> can be useful for developers that have to create a new module since it
> is possible to use some of the tests already provided by IGT (e.g.,
> kms_color, core, etc.) as a start point. Additionally, it can
> also be useful for someone that wants to implement a new set of tests
> for a specific driver because the developer can first check the behavior
> of any test in the target module. It is important to highlight, that a
> force option can produce unexpected results and developers should be
> aware of that.
Is this meant for testing replacement drivers for hardware with
already existing drivers? If not, I'm not sure what the goal is here.
Setting a forced module target in this patch changes which module is
loaded by the kernel, but the driver that's opened by IGT is
unchanged. Force-loading my-fancy-driver.ko still makes
drm_open_driver(DRIVER_INTEL) open the one driven by i915.ko, and
drm_open_driver(DRIVER_ANY) still opens the first one that is
recognized.
If this is for testing new drivers for not-already-supported devices,
you need to instead force what drm_open_driver(DRIVER_ANY) will open,
and not reject unknown devices.
Some additional drive-by feedback below.
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index fae6f86f..1d2ba178 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -258,6 +258,7 @@ static int __open_device(const char *base, int offset,
> unsigned int chipset)
> static int __open_driver(const char *base, int offset, unsigned int chipset)
> {
> static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
> + const char* target;
> static const struct module {
> unsigned int bit;
> const char *module;
> @@ -276,13 +277,19 @@ static int __open_driver(const char *base, int offset,
> unsigned int chipset)
> if (fd != -1)
> return fd;
>
> + target = get_target_module();
> +
> pthread_mutex_lock(&mutex);
> - for (const struct module *m = modules; m->module; m++) {
> - if (chipset & m->bit) {
> - if (m->modprobe)
> - m->modprobe(m->module);
> - else
> - modprobe(m->module);
> + if (target) {
> + modprobe(target);
> + } else {
> + for (const struct module *m = modules; m->module; m++) {
> + if (chipset & m->bit) {
> + if (m->modprobe)
> + m->modprobe(m->module);
> + else
> + modprobe(m->module);
> + }
> }
> }
> pthread_mutex_unlock(&mutex);
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 5092a3f0..ed66eae1 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -286,6 +286,7 @@ enum {
> OPT_DESCRIPTION,
> OPT_DEBUG,
> OPT_INTERACTIVE_DEBUG,
> + OPT_FORCE_MODULE,
> OPT_HELP = 'h'
> };
>
> @@ -303,6 +304,20 @@ static pthread_mutex_t log_buffer_mutex =
> PTHREAD_MUTEX_INITIALIZER;
> GKeyFile *igt_key_file;
> #endif
>
> +char *target_module;
> +
> +void set_target_module(char *target)
> +{
> + if (!target)
> +igt_warn("No module specified, keep default behaviour");
> + target_module = target;
> +}
> +
> +const char *get_target_module(void)
> +{
> + return target_module;
> +}
> +
> char *igt_frame_dump_path;
>
> const char *igt_test_name(void)
> @@ -555,6 +570,7 @@ static void print_usage(const char *help_str, bool
> output_on_stderr)
> " --debug[=log-domain]\n"
> " --interactive-debug[=domain]\n"
> " --help-description\n"
> +" --force-module \n"
> " --help\n");
> if (help_str)
> fprintf(f, "%s\n", help_str);
> @@ -666,6 +682,7 @@ static int common_init(int *argc, char **argv,
> {"debug", optional_argument, 0, OPT_DEBUG},
> {"interactive-debug", optional_argument, 0,
> OPT_INTERACTIVE_DEBUG},
> {"help", 0, 0, OPT_HELP},
> + {"force-module", required_argument, 0, OPT_FORCE_MODULE},
> {0, 0, 0, 0}
> };
> char *short_opts;
> @@ -763,6 +780,9 @@ static int common_init(int *argc, char **argv,
> print_test_description();
> ret = -1;
> goto out;
> + case OPT_FORCE_MODULE:
> + set_target_module(strdup(optarg));
> + break;
> case OPT_HELP:
> print_usage(help_str, false);
> ret = -1;
> diff --git a/lib/igt_cor
Re: [Intel-gfx] [PATCH] drm/i915: Make closing request flush mandatory
Quoting Joonas Lahtinen (2018-06-13 13:54:01) > Quoting Chris Wilson (2018-06-12 13:51:35) > > For symmetry, simplicity and ensuring the request is always truly idle > > upon its completion, always emit the closing flush prior to emitting the > > request breadcrumb. Previously, we would only emit the flush if we had > > started a user batch, but this just leaves all the other paths open to > > speculation (do they affect the GPU caches or not?) With mm switching, a > > key requirement is that the GPU is flushed and invalidated before hand, > > so for absolute safety, we want that closing flush be mandatory. > > > > Signed-off-by: Chris Wilson > > No word about perf impact? The patch description matches what it does. There's no change to the normal execution paths. There may be a change on interrupted execution paths, but they are already returning to userspace empty handed and not as relevant to performance. We are just making sure the odd ones don't have any odd side effects. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI
Op 24-05-18 om 14:54 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> When encountering a connector with the scaling mode property both
> intel and modesetting ddxs sometimes add tons of DBLSCAN modes
> to the output's mode list. The idea presumably being that since the
> output will be going through the panel fitter anyway we can pretend
> to use any kind of mode.
>
> Sadly that means we can't reject user modes with the DBLSCAN flag
> until we know whether we're going to be using the panel's native
> mode or the user mode directly. Doing otherwise means X clients using
> xf86vidmode/xrandr will get a protocol error (and often self
> terminate as a result) when the kernel refuses to use the requested
> mode with the DBLSCAN flag.
>
> To undo the regression we'll move the DBLSCAN checks into the
> connector->mode_valid() and encoder->compute_config() hooks.
>
> Cc: Vito Caputo
> Reported-by: Vito Caputo
> Fixes: e995ca0b8139 ("drm/i915: Provide a device level .mode_valid() hook")
> References: https://lkml.org/lkml/2018/5/21/715
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_crt.c | 20
> drivers/gpu/drm/i915/intel_display.c | 16 +---
> drivers/gpu/drm/i915/intel_dp.c | 6 ++
> drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
> drivers/gpu/drm/i915/intel_dsi.c | 6 ++
> drivers/gpu/drm/i915/intel_dvo.c | 6 ++
> drivers/gpu/drm/i915/intel_hdmi.c| 6 ++
> drivers/gpu/drm/i915/intel_lvds.c| 5 +
> drivers/gpu/drm/i915/intel_sdvo.c| 6 ++
> drivers/gpu/drm/i915/intel_tv.c | 12 ++--
> 10 files changed, 84 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 211d601cd1b1..95aa29cf2d9c 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -304,6 +304,9 @@ intel_crt_mode_valid(struct drm_connector *connector,
> int max_dotclk = dev_priv->max_dotclk_freq;
> int max_clock;
>
> + if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> + return MODE_NO_DBLESCAN;
> +
> if (mode->clock < 25000)
> return MODE_CLOCK_LOW;
>
> @@ -337,6 +340,12 @@ static bool intel_crt_compute_config(struct
> intel_encoder *encoder,
>struct intel_crtc_state *pipe_config,
>struct drm_connector_state *conn_state)
> {
> + struct drm_display_mode *adjusted_mode =
> + &pipe_config->base.adjusted_mode;
> +
> + if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> + return false;
> +
> return true;
> }
>
> @@ -344,6 +353,12 @@ static bool pch_crt_compute_config(struct intel_encoder
> *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state)
> {
> + struct drm_display_mode *adjusted_mode =
> + &pipe_config->base.adjusted_mode;
> +
> + if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> + return false;
> +
> pipe_config->has_pch_encoder = true;
>
> return true;
> @@ -354,6 +369,11 @@ static bool hsw_crt_compute_config(struct intel_encoder
> *encoder,
> struct drm_connector_state *conn_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct drm_display_mode *adjusted_mode =
> + &pipe_config->base.adjusted_mode;
> +
> + if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> + return false;
>
> pipe_config->has_pch_encoder = true;
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8b385176ce3c..02651298a99b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14443,12 +14443,22 @@ static enum drm_mode_status
> intel_mode_valid(struct drm_device *dev,
>const struct drm_display_mode *mode)
> {
> + /*
> + * Can't reject DBLSCAN here because Xorg ddxen can add piles
> + * of DBLSCAN modes to the output's mode list when they detect
> + * the scaling mode property on the connector. And they don't
> + * ask the kernel to validate those modes in any way until
> + * modeset time at which point the client gets a protocol error.
> + * So in order to not upset those clients we silently ignore the
> + * DBLSCAN flag on such connectors. For other connectors we will
> + * reject modes with the DBLSCAN flag in encoder->compute_config().
> + * And we always reject DBLSCAN modes in connector->mode_valid()
> + * as we never want such modes on the connector's mode list.
> + */
> +
> if (mode->vscan > 1)
> return MODE_NO_VSCAN;
>
> - if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return MODE_NO_DBLESCAN;
> -
>
[Intel-gfx] [PATCH 3/5] drm/i915: Make the hexdump row offset visually distinct
Currently we use %08x for the row offset, and %08x for the binary contents of the buffer. This makes it very easily to confuse the two, so switch to using [%04x] for the start-of-row offset. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index d7f757fb8401..875bd466f3bf 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -1258,7 +1258,7 @@ static void hexdump(struct drm_printer *m, const void *buf, size_t len) rowsize, sizeof(u32), line, sizeof(line), false) >= sizeof(line)); - drm_printf(m, "%08zx %s\n", pos, line); + drm_printf(m, "[%04zx] %s\n", pos, line); prev = buf + pos; skip = false; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Dump the ringbuffer of the active request for debugging
Sometimes we need to see what instructions we emitted for a request to
try and gather a glimmer of insight into what the GPU is doing when it
stops responding.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 35 ++
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d278fed8cb31..d7f757fb8401 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1443,12 +1443,10 @@ void intel_engine_dump(struct intel_engine_cs *engine,
rq = i915_gem_find_active_request(engine);
if (rq) {
+ void *ring;
+ int size;
+
print_request(m, rq, "\t\tactive ");
- drm_printf(m,
- "\t\t[head %04x, postfix %04x, tail %04x, batch
0x%08x_%08x]\n",
- rq->head, rq->postfix, rq->tail,
- rq->batch ? upper_32_bits(rq->batch->node.start) :
~0u,
- rq->batch ? lower_32_bits(rq->batch->node.start) :
~0u);
drm_printf(m, "\t\tring->start: 0x%08x\n",
i915_ggtt_offset(rq->ring->vma));
drm_printf(m, "\t\tring->head: 0x%08x\n",
@@ -1459,6 +1457,33 @@ void intel_engine_dump(struct intel_engine_cs *engine,
rq->ring->emit);
drm_printf(m, "\t\tring->space: 0x%08x\n",
rq->ring->space);
+
+ drm_printf(m,
+ "[head %04x, postfix %04x, tail %04x, batch
0x%08x_%08x]:\n",
+ rq->head, rq->postfix, rq->tail,
+ rq->batch ? upper_32_bits(rq->batch->node.start) :
~0u,
+ rq->batch ? lower_32_bits(rq->batch->node.start) :
~0u);
+
+ size = rq->tail - rq->head;
+ if (rq->tail < rq->head)
+ size += rq->ring->size;
+
+ ring = kmalloc(size, GFP_ATOMIC);
+ if (ring) {
+ const void *vaddr = rq->ring->vaddr;
+ unsigned int head = rq->head;
+ unsigned int len = 0;
+
+ if (rq->tail < head) {
+ len = rq->ring->size - head;
+ memcpy(ring, vaddr + head, len);
+ head = 0;
+ }
+ memcpy(ring + len, vaddr + head, size - len);
+
+ hexdump(m, ring, size);
+ kfree(ring);
+ }
}
rcu_read_unlock();
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915/gtt: Only keep gen6 page directories pinned while active
In order to be able to evict the gen6 ppgtt, we have to unpin it at some
point. We can simply use our context activity tracking to know when the
ppgtt is no longer in use by hardware, and so only keep it pinned while
being used a request.
For the kernel_context (and thus aliasing_ppgtt), it remains pinned at
all times, as the kernel_context itself is pinned at all times.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Matthew Auld
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 36 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 5
drivers/gpu/drm/i915/intel_ringbuffer.c | 28 +++
3 files changed, 54 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c6949da3423f..317f27a9d78e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1912,7 +1912,6 @@ static void gen6_ppgtt_cleanup(struct i915_address_space
*vm)
{
struct gen6_hw_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
- i915_vma_unpin(ppgtt->vma);
i915_vma_destroy(ppgtt->vma);
gen6_ppgtt_free_pd(ppgtt);
@@ -1998,10 +1997,19 @@ static struct i915_vma *pd_vma_create(struct
gen6_hw_ppgtt *ppgtt, int size)
return vma;
}
-static int gen6_ppgtt_pin(struct i915_hw_ppgtt *base)
+int gen6_ppgtt_pin(struct i915_hw_ppgtt *base)
{
struct gen6_hw_ppgtt *ppgtt = to_gen6_ppgtt(base);
+ /*
+* Workaround the limited maximum vma->pin_count and the aliasing_ppgtt
+* which will be pinned into every active context.
+* (When vma->pin_count becomes atomic, I expect we will naturally
+* need a larger, unpacked, type and kill this redundancy.)
+*/
+ if (ppgtt->pin_count++)
+ return 0;
+
/*
* PPGTT PDEs reside in the GGTT and consists of 512 entries. The
* allocator works in address space sizes, so it's multiplied by page
@@ -2012,6 +2020,17 @@ static int gen6_ppgtt_pin(struct i915_hw_ppgtt *base)
PIN_GLOBAL | PIN_HIGH);
}
+void gen6_ppgtt_unpin(struct i915_hw_ppgtt *base)
+{
+ struct gen6_hw_ppgtt *ppgtt = to_gen6_ppgtt(base);
+
+ GEM_BUG_ON(!ppgtt->pin_count);
+ if (--ppgtt->pin_count)
+ return;
+
+ i915_vma_unpin(ppgtt->vma);
+}
+
static struct i915_hw_ppgtt *gen6_ppgtt_create(struct drm_i915_private *i915)
{
struct i915_ggtt * const ggtt = &i915->ggtt;
@@ -2053,21 +2072,8 @@ static struct i915_hw_ppgtt *gen6_ppgtt_create(struct
drm_i915_private *i915)
if (err)
goto err_vma;
- err = gen6_ppgtt_pin(&ppgtt->base);
- if (err)
- goto err_pd;
-
- DRM_DEBUG_DRIVER("Allocated pde space (%lldM) at GTT entry: %llx\n",
-ppgtt->vma->node.size >> 20,
-ppgtt->vma->node.start / PAGE_SIZE);
-
- DRM_DEBUG_DRIVER("Adding PPGTT at offset %x\n",
-ppgtt->base.pd.base.ggtt_offset << 10);
-
return &ppgtt->base;
-err_pd:
- gen6_ppgtt_free_pd(ppgtt);
err_vma:
i915_vma_destroy(ppgtt->vma);
err_scratch:
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 6e9acd99ecc6..d7b7b4afe060 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -412,6 +412,8 @@ struct gen6_hw_ppgtt {
struct i915_vma *vma;
gen6_pte_t __iomem *pd_addr;
+
+ unsigned int pin_count;
};
#define __to_gen6_ppgtt(base) container_of(base, struct gen6_hw_ppgtt, base)
@@ -625,6 +627,9 @@ static inline void i915_ppgtt_put(struct i915_hw_ppgtt
*ppgtt)
kref_put(&ppgtt->ref, i915_ppgtt_release);
}
+int gen6_ppgtt_pin(struct i915_hw_ppgtt *base);
+void gen6_ppgtt_unpin(struct i915_hw_ppgtt *base);
+
void i915_check_and_clear_faults(struct drm_i915_private *dev_priv);
void i915_gem_suspend_gtt_mappings(struct drm_i915_private *dev_priv);
void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 4a9f44c61edd..06a1b61bee42 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1181,6 +1181,27 @@ static void intel_ring_context_destroy(struct
intel_context *ce)
__i915_gem_object_release_unless_active(ce->state->obj);
}
+static int __context_pin_ppgtt(struct i915_gem_context *ctx)
+{
+ struct i915_hw_ppgtt *ppgtt;
+ int err = 0;
+
+ ppgtt = ctx->ppgtt ?: ctx->i915->mm.aliasing_ppgtt;
+ if (ppgtt)
+ err = gen6_ppgtt_pin(ppgtt);
+
+ return err;
+}
+
+static void __context_unpin_ppgtt(struct i915_gem_context *ctx)
+{
+ struct i915_hw_ppgtt *ppgtt;
+
+ ppgtt = ctx->ppgtt ?: ctx->i915->mm.a
[Intel-gfx] [PATCH 4/5] drm/i915: Show CCID in engine dumps
For debugging context issues, knowing what context the GPU is loading/using is helpful. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 875bd466f3bf..5a663dda9fdc 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -1273,6 +1273,8 @@ static void intel_engine_print_registers(const struct intel_engine_cs *engine, &engine->execlists; u64 addr; + if (engine->id == RCS && IS_GEN(dev_priv, 5, 7)) + drm_printf(m, "\tCCID: 0x%08x\n", I915_READ(CCID)); drm_printf(m, "\tRING_START: 0x%08x\n", I915_READ(RING_START(engine->mmio_base))); drm_printf(m, "\tRING_HEAD: 0x%08x\n", -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Supply the extended state flags for forced context load
Provide the extended state (or resource streamer bits for Haswell) flags
when doing a forced restore of the current context by temporarily loading
the kernel context.
Fixes: 1fc719d13ac0 ("drm/i915/ringbuffer: Brute force context restore")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index dda671e0a680..4a9f44c61edd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1556,7 +1556,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_SET_CONTEXT;
*cs++ = i915_ggtt_offset(to_intel_context(i915->kernel_context,
engine)->state) |
- MI_MM_SPACE_GTT |
+ flags |
MI_RESTORE_INHIBIT;
}
--
2.17.1
___
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/opregion: move acpi notifier to dev_priv
== Series Details == Series: drm/i915/opregion: move acpi notifier to dev_priv URL : https://patchwork.freedesktop.org/series/44694/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309_full -> Patchwork_9284_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9284_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9284_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9284_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9284_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: NOTRUN -> INCOMPLETE (k.org#198133, fdo#103359) igt@drv_selftest@mock_scatterlist: shard-glk: NOTRUN -> DMESG-WARN (fdo#103667) igt@gem_exec_schedule@pi-ringfull-bsd: shard-glk: NOTRUN -> FAIL (fdo#103158) igt@gem_mmap_gtt@coherency: shard-glk: NOTRUN -> FAIL (fdo#100587) igt@kms_cursor_legacy@flip-vs-cursor-atomic: shard-glk: NOTRUN -> FAIL (fdo#102670) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105189) igt@kms_flip@plain-flip-ts-check: shard-glk: NOTRUN -> FAIL (fdo#100368) igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc: shard-glk: NOTRUN -> FAIL (fdo#103167, fdo#104724) igt@kms_setmode@basic: shard-glk: NOTRUN -> FAIL (fdo#99912) igt@kms_sysfs_edid_timing: shard-glk: NOTRUN -> WARN (fdo#100047) igt@perf_pmu@busy-accuracy-50-vcs1: shard-snb: SKIP -> INCOMPLETE (fdo#105411) Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt: shard-glk: FAIL (fdo#103167, fdo#104724) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9284 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9284: 2084fb72b973bdb184a8c568502cdd444afb378c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9284/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Supply the extended state flags for forced context load
== Series Details == Series: series starting with [1/5] drm/i915: Supply the extended state flags for forced context load URL : https://patchwork.freedesktop.org/series/44703/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4310 -> Patchwork_9287 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9287 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9287, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44703/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9287: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s4-devices: fi-snb-2520m: PASS -> DMESG-WARN == Known issues == Here are the changes found in Patchwork_9287 that come from known issues: === IGT changes === Issues hit igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) igt@gem_exec_suspend@basic-s4-devices: fi-hsw-peppy: PASS -> FAIL (fdo#105900) fi-hsw-4770r: PASS -> FAIL (fdo#105900) igt@kms_chamelium@dp-crc-fast: fi-kbl-7500u: PASS -> FAIL (fdo#103841) igt@kms_flip@basic-flip-vs-dpms: fi-skl-6700hq: PASS -> DMESG-WARN (fdo#105998) fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@kms_flip@basic-plain-flip: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@gem_ctx_create@basic-files: fi-glk-j4005: DMESG-WARN (fdo#105719) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-skl-6700hq: DMESG-WARN (fdo#105998) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#105998 https://bugs.freedesktop.org/show_bug.cgi?id=105998 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (43 -> 38) == Missing(5): fi-ctg-p8600 fi-byt-squawks fi-ilk-m540 fi-bxt-dsi fi-bsw-cyan == Build changes == * Linux: CI_DRM_4310 -> Patchwork_9287 CI_DRM_4310: 5945ab6707472bde0c3bc12836252b487ecfeb72 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4518: e4908004547b63131352fbc0ddcdb1d3d55480e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9287: c1384e70203bbbde6f9fc4db21f2a608f75d1d3d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c1384e70203b drm/i915/gtt: Only keep gen6 page directories pinned while active 7c612ae91cd5 drm/i915: Show CCID in engine dumps 584d28cba8b8 drm/i915: Make the hexdump row offset visually distinct 68bdd66e124a drm/i915: Dump the ringbuffer of the active request for debugging cc8b1343f906 drm/i915: Supply the extended state flags for forced context load == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9287/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: make skl plane and planar format tables const
== Series Details == Series: drm/i915: make skl plane and planar format tables const URL : https://patchwork.freedesktop.org/series/44696/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309_full -> Patchwork_9285_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9285_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9285_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9285_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9285_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@mock_scatterlist: shard-glk: NOTRUN -> DMESG-WARN (fdo#103667) igt@drv_suspend@shrink: shard-kbl: PASS -> INCOMPLETE (fdo#106886, fdo#103665) igt@gem_exec_schedule@pi-ringfull-bsd: shard-glk: NOTRUN -> FAIL (fdo#103158) igt@gem_mmap_gtt@coherency: shard-glk: NOTRUN -> FAIL (fdo#100587) igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: PASS -> INCOMPLETE (fdo#103665, fdo#106023) igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: PASS -> FAIL (fdo#105767) igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: NOTRUN -> FAIL (fdo#102887) igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@flip-vs-panning-vs-hang: shard-snb: PASS -> DMESG-WARN (fdo#103821) igt@kms_flip_tiling@flip-x-tiled: shard-glk: NOTRUN -> FAIL (fdo#103822, fdo#104724) +1 igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc: shard-glk: NOTRUN -> FAIL (fdo#103167, fdo#104724) igt@kms_setmode@basic: shard-glk: NOTRUN -> FAIL (fdo#99912) igt@kms_sysfs_edid_timing: shard-glk: NOTRUN -> WARN (fdo#100047) igt@perf_pmu@busy-accuracy-50-vcs1: shard-snb: SKIP -> INCOMPLETE (fdo#105411) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#105363, fdo#102887) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt: shard-glk: FAIL (fdo#103167, fdo#104724) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9285 CI_DRM_4309: 2740c5b0d0f40092
[Intel-gfx] [PATCH 1/2] drm/i915: Disallow interlaced modes on g4x DP outputs
From: Ville Syrjälä Looks like interlaced DP output doesn't work on g4x either. Not all that surprising considering we already established that interlaced DP output is busted on VLV/CHV. Cc: sta...@vger.kernel.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 40ffd9163175..6068986fd985 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1869,7 +1869,7 @@ intel_dp_compute_config(struct intel_encoder *encoder, conn_state->scaling_mode); } - if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) && + if (HAS_GMCH_DISPLAY(dev_priv) && adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) return false; @@ -6351,7 +6351,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, drm_connector_init(dev, connector, &intel_dp_connector_funcs, type); drm_connector_helper_add(connector, &intel_dp_connector_helper_funcs); - if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) + if (!HAS_GMCH_DISPLAY(dev_priv)) connector->interlace_allowed = true; connector->doublescan_allowed = 0; -- 2.16.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Turn off g4x DP port in .post_disable()
From: Ville Syrjälä
While Bspec doesn't list a specific sequence for turning off the DP port
on g4x we are getting an underrun if the port is disabled in the
.disable() hook. Looks like the pipe stops when the port stops, and by
that time the plane disable may not have completed yet. Also the plane(s)
seem to end up in some wonky state when this happens as they also signal
another underrun immediately after we turn them back on during the next
enable sequence.
We could add a vblank wait in .disable() to avoid wedging the planes,
but I assume we're still tripping up the pipe in some way. So it seems
better to me to just follow the ILK+ sequence and turn off the DP port
in .post_disable() instead. This sequence doesn't seem to suffer from
this problem. Could be it was always the intended sequence for DP and
the gen4 bspec was just never updated to include it.
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6068986fd985..5f09a8015c89 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2803,16 +2803,6 @@ static void intel_disable_dp(struct intel_encoder
*encoder,
static void g4x_disable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
-{
- intel_disable_dp(encoder, old_crtc_state, old_conn_state);
-
- /* disable the port before the pipe on g4x */
- intel_dp_link_down(encoder, old_crtc_state);
-}
-
-static void ilk_disable_dp(struct intel_encoder *encoder,
- const struct intel_crtc_state *old_crtc_state,
- const struct drm_connector_state *old_conn_state)
{
intel_disable_dp(encoder, old_crtc_state, old_conn_state);
}
@@ -2828,13 +2818,19 @@ static void vlv_disable_dp(struct intel_encoder
*encoder,
intel_disable_dp(encoder, old_crtc_state, old_conn_state);
}
-static void ilk_post_disable_dp(struct intel_encoder *encoder,
+static void g4x_post_disable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state
*old_conn_state)
{
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
enum port port = encoder->port;
+ /*
+* Bspec does not list a specific disable sequence for g4x DP.
+* Follow the ilk+ sequence (disable pipe before the port) for
+* g4x DP as it does not suffer from underruns like the normal
+* g4x modeset sequence (disable pipe after the port).
+*/
intel_dp_link_down(encoder, old_crtc_state);
/* Only ilk+ has port A */
@@ -6450,15 +6446,11 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder->enable = vlv_enable_dp;
intel_encoder->disable = vlv_disable_dp;
intel_encoder->post_disable = vlv_post_disable_dp;
- } else if (INTEL_GEN(dev_priv) >= 5) {
- intel_encoder->pre_enable = g4x_pre_enable_dp;
- intel_encoder->enable = g4x_enable_dp;
- intel_encoder->disable = ilk_disable_dp;
- intel_encoder->post_disable = ilk_post_disable_dp;
- } else {
+ } else{
intel_encoder->pre_enable = g4x_pre_enable_dp;
intel_encoder->enable = g4x_enable_dp;
intel_encoder->disable = g4x_disable_dp;
+ intel_encoder->post_disable = g4x_post_disable_dp;
}
intel_dig_port->dp.output_reg = output_reg;
--
2.16.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/2] drm/i915: Disallow interlaced modes on g4x DP outputs
== Series Details == Series: series starting with [1/2] drm/i915: Disallow interlaced modes on g4x DP outputs URL : https://patchwork.freedesktop.org/series/44705/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4310 -> Patchwork_9288 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9288 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9288, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44705/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9288: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9288 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-flip-vs-dpms: fi-skl-6700hq: PASS -> DMESG-WARN (fdo#105998) fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000, fdo#106097) igt@kms_flip@basic-plain-flip: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-skl-guc: PASS -> FAIL (fdo#103191, fdo#104724) Possible fixes igt@gem_ctx_create@basic-files: fi-glk-j4005: DMESG-WARN (fdo#105719) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#105998 https://bugs.freedesktop.org/show_bug.cgi?id=105998 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 == Participating hosts (43 -> 38) == Missing(5): fi-byt-j1900 fi-ctg-p8600 fi-byt-squawks fi-bsw-cyan fi-ilk-m540 == Build changes == * Linux: CI_DRM_4310 -> Patchwork_9288 CI_DRM_4310: 5945ab6707472bde0c3bc12836252b487ecfeb72 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4518: e4908004547b63131352fbc0ddcdb1d3d55480e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9288: 7cb1506cc8c1032620b14ac2d4c196a65d0bfd1e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7cb1506cc8c1 drm/i915: Turn off g4x DP port in .post_disable() 3956b8c00b4f drm/i915: Disallow interlaced modes on g4x DP outputs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9288/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/perf: make oa format tables const
== Series Details == Series: drm/i915/perf: make oa format tables const URL : https://patchwork.freedesktop.org/series/44697/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4309_full -> Patchwork_9286_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9286_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9286_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9286_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9286_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@mock_scatterlist: shard-glk: NOTRUN -> DMESG-WARN (fdo#103667) igt@gem_exec_big: shard-hsw: PASS -> INCOMPLETE (fdo#103540) igt@gem_exec_schedule@pi-ringfull-bsd: shard-glk: NOTRUN -> FAIL (fdo#103158) igt@gem_mmap_gtt@coherency: shard-glk: NOTRUN -> FAIL (fdo#100587) igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: PASS -> INCOMPLETE (fdo#106023, fdo#103665) igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: NOTRUN -> FAIL (fdo#104724) igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc: shard-glk: NOTRUN -> FAIL (fdo#103167, fdo#104724) igt@kms_setmode@basic: shard-glk: NOTRUN -> FAIL (fdo#99912) igt@kms_sysfs_edid_timing: shard-glk: NOTRUN -> WARN (fdo#100047) igt@perf_pmu@busy-accuracy-50-vcs1: shard-snb: SKIP -> INCOMPLETE (fdo#105411) Possible fixes igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt: shard-glk: FAIL (fdo#103167, fdo#104724) -> PASS igt@kms_rotation_crc@primary-rotation-180: shard-snb: FAIL (fdo#103925, fdo#104724) -> SKIP fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4309 -> Patchwork_9286 CI_DRM_4309: 2740c5b0d0f40092355b329a62ede8cced7f64b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4517: e94ce40798e35d2e3c4494f50b617908066bbf8b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9286: e9e26f1ea6e7cbad5132e9fcbc61672fb06172a5 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel
[Intel-gfx] Patch "x86/cpufeature: Remove cpu_has_clflush" has been added to the 4.4-stable tree
This is a note to let you know that I've just added the patch titled
x86/cpufeature: Remove cpu_has_clflush
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-cpufeature-remove-cpu_has_clflush.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From 906bf7fda2c9cf5c1762ec607943ed54b6c5b203 Mon Sep 17 00:00:00 2001
From: Borislav Petkov
Date: Tue, 29 Mar 2016 17:41:59 +0200
Subject: x86/cpufeature: Remove cpu_has_clflush
From: Borislav Petkov
commit 906bf7fda2c9cf5c1762ec607943ed54b6c5b203 upstream.
Use the fast variant in the DRM code.
Signed-off-by: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Link: http://lkml.kernel.org/r/1459266123-21878-7-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/cpufeature.h |1 -
arch/x86/kernel/cpu/intel.c|2 +-
arch/x86/kernel/tce_64.c |2 +-
arch/x86/mm/pageattr.c |2 +-
drivers/gpu/drm/drm_cache.c|6 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
6 files changed, 7 insertions(+), 8 deletions(-)
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -378,7 +378,6 @@ extern const char * const x86_bug_flags[
#define cpu_has_aesboot_cpu_has(X86_FEATURE_AES)
#define cpu_has_avxboot_cpu_has(X86_FEATURE_AVX)
#define cpu_has_avx2 boot_cpu_has(X86_FEATURE_AVX2)
-#define cpu_has_clflushboot_cpu_has(X86_FEATURE_CLFLUSH)
#define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
#define cpu_has_xsaves boot_cpu_has(X86_FEATURE_XSAVES)
#define cpu_has_hypervisor boot_cpu_has(X86_FEATURE_HYPERVISOR)
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -455,7 +455,7 @@ static void init_intel(struct cpuinfo_x8
set_cpu_cap(c, X86_FEATURE_PEBS);
}
- if (c->x86 == 6 && cpu_has_clflush &&
+ if (c->x86 == 6 && boot_cpu_has(X86_FEATURE_CLFLUSH) &&
(c->x86_model == 29 || c->x86_model == 46 || c->x86_model == 47))
set_cpu_bug(c, X86_BUG_CLFLUSH_MONITOR);
--- a/arch/x86/kernel/tce_64.c
+++ b/arch/x86/kernel/tce_64.c
@@ -40,7 +40,7 @@
static inline void flush_tce(void* tceaddr)
{
/* a single tce can't cross a cache line */
- if (cpu_has_clflush)
+ if (boot_cpu_has(X86_FEATURE_CLFLUSH))
clflush(tceaddr);
else
wbinvd();
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1481,7 +1481,7 @@ static int change_page_attr_set_clr(unsi
* error case we fall back to cpa_flush_all (which uses
* WBINVD):
*/
- if (!ret && cpu_has_clflush) {
+ if (!ret && boot_cpu_has(X86_FEATURE_CLFLUSH)) {
if (cpa.flags & (CPA_PAGES_ARRAY | CPA_ARRAY)) {
cpa_flush_array(addr, numpages, cache,
cpa.flags, pages);
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -72,7 +72,7 @@ drm_clflush_pages(struct page *pages[],
{
#if defined(CONFIG_X86)
- if (cpu_has_clflush) {
+ if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
drm_cache_flush_clflush(pages, num_pages);
return;
}
@@ -105,7 +105,7 @@ void
drm_clflush_sg(struct sg_table *st)
{
#if defined(CONFIG_X86)
- if (cpu_has_clflush) {
+ if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
struct sg_page_iter sg_iter;
mb();
@@ -129,7 +129,7 @@ void
drm_clflush_virt_range(void *addr, unsigned long length)
{
#if defined(CONFIG_X86)
- if (cpu_has_clflush) {
+ if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
const int size = boot_cpu_data.x86_clflush_size;
void *end = addr + length;
addr = (void *)(((unsigned long)addr) & -size);
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -466,7 +466,7 @@ i915_gem_execbuffer_relocate_entry(struc
ret = relocate_entry_cpu(obj, reloc, target_offset);
else if (obj->map_and_fenceable)
ret = relocate_entry_gtt(obj, reloc, target_offset);
- else if (cpu_has_clflush)
+ else if (static_cpu_has(X86_FEATURE_CLFLUSH))
ret = relocate_entry_clflush(obj, reloc, target_offset);
else {
WARN_ONCE(1, "Impossible case in relocation handling\n");
Patches currently in stable-queue which might be from b...@suse.de are
queue-4.4/x86-fpu-disable-mpx-when-eagerfpu-is-off.pa
[Intel-gfx] Patch "x86/mm/pat, x86/cpufeature: Remove cpu_has_pat" has been added to the 4.4-stable tree
This is a note to let you know that I've just added the patch titled x86/mm/pat, x86/cpufeature: Remove cpu_has_pat to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-mm-pat-x86-cpufeature-remove-cpu_has_pat.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. From 568a58e5dfbcb88011cad7f87ed046aa00f19d1a Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Tue, 29 Mar 2016 17:42:01 +0200 Subject: x86/mm/pat, x86/cpufeature: Remove cpu_has_pat From: Borislav Petkov commit 568a58e5dfbcb88011cad7f87ed046aa00f19d1a upstream. Signed-off-by: Borislav Petkov Acked-by: Daniel Vetter Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: intel-gfx@lists.freedesktop.org Link: http://lkml.kernel.org/r/1459266123-21878-9-git-send-email...@alien8.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/cpufeature.h |1 - drivers/gpu/drm/i915/i915_gem.c |2 +- 2 files changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -380,7 +380,6 @@ extern const char * const x86_bug_flags[ #define cpu_has_avx2 boot_cpu_has(X86_FEATURE_AVX2) #define cpu_has_clflushboot_cpu_has(X86_FEATURE_CLFLUSH) #define cpu_has_gbpagesboot_cpu_has(X86_FEATURE_GBPAGES) -#define cpu_has_patboot_cpu_has(X86_FEATURE_PAT) #define cpu_has_x2apic boot_cpu_has(X86_FEATURE_X2APIC) #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE) #define cpu_has_xsaves boot_cpu_has(X86_FEATURE_XSAVES) --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1730,7 +1730,7 @@ i915_gem_mmap_ioctl(struct drm_device *d if (args->flags & ~(I915_MMAP_WC)) return -EINVAL; - if (args->flags & I915_MMAP_WC && !cpu_has_pat) + if (args->flags & I915_MMAP_WC && !boot_cpu_has(X86_FEATURE_PAT)) return -ENODEV; obj = drm_gem_object_lookup(dev, file, args->handle); Patches currently in stable-queue which might be from b...@suse.de are queue-4.4/x86-fpu-disable-mpx-when-eagerfpu-is-off.patch queue-4.4/x86-fpu-disable-avx-when-eagerfpu-is-off.patch queue-4.4/x86-cpufeature-remove-cpu_has_xmm2.patch queue-4.4/x86-cpufeature-remove-unused-and-seldomly-used-cpu_has_xx-macros.patch queue-4.4/x86-cpufeature-replace-cpu_has_avx2-with-boot_cpu_has-usage.patch queue-4.4/x86-cpufeature-replace-cpu_has_aes-with-boot_cpu_has-usage.patch queue-4.4/x86-fpu-fix-eager-fpu-handling-on-legacy-fpu-machines.patch queue-4.4/x86-cpufeature-remove-cpu_has_pse.patch queue-4.4/x86-cpufeature-remove-cpu_has_osxsave.patch queue-4.4/x86-mm-pat-x86-cpufeature-remove-cpu_has_pat.patch queue-4.4/x86-fpu-revert-x86-fpu-disable-avx-when-eagerfpu-is-off.patch queue-4.4/x86-cpufeature-remove-cpu_has_gbpages.patch queue-4.4/x86-fpu-fix-early-fpu-command-line-parsing.patch queue-4.4/x86-cpufeature-remove-cpu_has_x2apic.patch queue-4.4/x86-cpufeature-remove-cpu_has_clflush.patch queue-4.4/x86-cpufeature-remove-cpu_has_arch_perfmon.patch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Patch "x86/cpufeature: Remove cpu_has_clflush" has been added to the 4.4-stable tree
== Series Details == Series: Patch "x86/cpufeature: Remove cpu_has_clflush" has been added to the 4.4-stable tree URL : https://patchwork.freedesktop.org/series/44707/ State : failure == Summary == Applying: Patch "x86/cpufeature: Remove cpu_has_clflush" has been added to the 4.4-stable tree error: sha1 information is lacking or useless (arch/x86/include/asm/cpufeature.h). error: could not build fake ancestor Patch failed at 0001 Patch "x86/cpufeature: Remove cpu_has_clflush" has been added to the 4.4-stable tree Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Patch "x86/mm/pat, x86/cpufeature: Remove cpu_has_pat" has been added to the 4.4-stable tree
== Series Details == Series: Patch "x86/mm/pat, x86/cpufeature: Remove cpu_has_pat" has been added to the 4.4-stable tree URL : https://patchwork.freedesktop.org/series/44708/ State : failure == Summary == Applying: Patch "x86/mm/pat, x86/cpufeature: Remove cpu_has_pat" has been added to the 4.4-stable tree error: sha1 information is lacking or useless (arch/x86/include/asm/cpufeature.h). error: could not build fake ancestor Patch failed at 0001 Patch "x86/mm/pat, x86/cpufeature: Remove cpu_has_pat" has been added to the 4.4-stable tree Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/icl: Add allowed DP rates for Icelake
Em Qua, 2018-06-13 às 11:07 +0300, Jani Nikula escreveu: > On Tue, 12 Jun 2018, Rodrigo Vivi wrote: > > Do we really want BIT everywhere?! > > I think I'd go for everywhere except part of a register field value: > While I completely agree with your reasoning, this means we'll kinda always want to blacklist the BIT_MACRO checkpath type because checkpatch won't know about these exceptions, which means we won't actually need to convert everything to BIT() since no false negative emails anyway. Anyway, I submitted a patch to fix the spacing issues, I'd love to have some comments from the maintainers on it. Thanks, Paulo > #define SINGLE_BIT_OKAY BIT(25) > #define FIELD_SHIFT 20 > #define FIELD_MASK(0xf << 20) > #define FIELD_FOO_PLEASE_NO BIT(20) /* Don't do > this */ > #define FIELD_FOO (1 << 20) /* This is > consistent */ > #define FIELD_BAR (2 << 20) > #define FIELD_BAZ (3 << 20) > > > BR, > Jani. > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Adds psrwake options for all platforms
On Wed, 2018-06-13 at 09:41 +0300, Jani Nikula wrote:
> On Wed, 13 Jun 2018, "Nagaraju, Vathsala" m> wrote:
> >
> > On 6/12/2018 2:30 PM, Jani Nikula wrote:
> > >
> > > On Tue, 12 Jun 2018, vathsala nagaraju > > om> wrote:
> > > >
> > > > From: Vathsala Nagaraju
> > > >
> > > > Adds new psrwake options defined in the below table.
> > > > PlatformPSR wake options vbt version
> > > > KBL/CFL/WHL All
> > > > SKL All PV releases (Check for 203+ might help
> > > > but cannot be foolproof)
> > > > BXT Uses old interpretation.
> > > > CNL/ICL+All
> > > > GLK All
> > > >
> > > > For SKL, we will continue to use older interpretation for the
> > > > above reason.
> > > >
> > > > Cc: Jani Nikula
> > > > Cc: Rodrigo Vivi
> > > > Cc: Puthikorn Voravootivat
> > > > Cc: Dhinakaran Pandiyan
> > > >
> > > > Signed-off-by: Vathsala Nagaraju
> > > > ---
> > > > drivers/gpu/drm/i915/intel_bios.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > > > b/drivers/gpu/drm/i915/intel_bios.c
> > > > index 465dff4..010ff68 100644
> > > > --- a/drivers/gpu/drm/i915/intel_bios.c
> > > > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > > > @@ -710,7 +710,8 @@ static int intel_bios_ssc_frequency(struct
> > > > drm_i915_private *dev_priv,
> > > > * New psr options 0=500us, 1=100us, 2=2500us, 3=0us
> > > > * Old decimal value is wake up time in multiples of
> > > > 100 us.
> > > > */
> > > > - if (bdb->version >= 209 && IS_GEN9_BC(dev_priv)) {
> > > > + if ((INTEL_GEN(dev_priv) >= 10) ||
> > > > + (IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))) {
> > > Please keep the version check.
> > Sure. For SKL , shall we use older interpretation for all bdb
> > version as
> > vbt team cannot confirm bdb version for SKL?
> I guess.
>
Why not change the version check to >= 203, if that's what PV releases
had as per your commit message? With the current code, Linux and
Windows set 500 us and 2.5 ms respectively on my laptop.
> BR,
> Jani.
>
>
> >
> >
> > >
> > > Please tell anyone who asks, and also those who don't, that *all*
> > > of the
> > > VBT changes should be based on the *version*, and *none* of them
> > > should
> > > be based on the *platform*.
> > >
> > > BR,
> > > Jani.
> > >
> > > >
> > > > switch (psr_table->tp1_wakeup_time) {
> > > > case 0:
> > > > dev_priv->vbt.psr.tp1_wakeup_time_us
> > > > = 500;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/ddi: Check transcoder instead of port when setting HDMI infoframe
The only requirement by BSpec for setting the HDMI infoframes is on DDI
platforms to do that before enabling the HDMI transcoder function, see
VIDEO_DIP_CTL bit 16. Accordingly check for the transcoder function
disabled state instead of the port's disabled state on DDI platforms.
This is needed by the next patch as it will set the infoframe during
crtc disabling where the port is still enabled.
Suggested-by: Ville Syrjälä
Cc: Vandita Kulkarni
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_hdmi.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index b7a95fd0663b..29d586f5cedb 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -59,6 +59,15 @@ assert_hdmi_port_disabled(struct intel_hdmi *intel_hdmi)
"HDMI port enabled, expecting disabled\n");
}
+static void
+assert_hdmi_transcoder_func_disabled(struct drm_i915_private *dev_priv,
+enum transcoder cpu_transcoder)
+{
+ WARN(I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder)) &
+TRANS_DDI_FUNC_ENABLE,
+"HDMI transcoder function enabled, expecting disabled\n");
+}
+
struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder)
{
struct intel_digital_port *intel_dig_port =
@@ -838,11 +847,11 @@ static void hsw_set_infoframes(struct drm_encoder
*encoder,
const struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
- struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
u32 val = I915_READ(reg);
- assert_hdmi_port_disabled(intel_hdmi);
+ assert_hdmi_transcoder_func_disabled(dev_priv,
+crtc_state->cpu_transcoder);
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] drm/i915/icl: Fix HDMI infoframe setting
On ICL setting the HDMI infoframe requires the pipe clock to be enabled, this patchset makes sure this is the case both during enabling and disabling the output. After discussing with Ville, the only constraint seems to be wrt. other platforms is that the infoframe is set when the transcoder function is disabled, see patch 3 for details. Cc: Vandita Kulkarni Cc: Paulo Zanoni Cc: Ville Syrjälä Imre Deak (5): drm/i915/ddi: s/crtc->config/old_crtc_state in haswell_crtc_disable() drm/i915/ddi: Push pipe clock enabling to encoders drm/i915/ddi: Check transcoder instead of port when setting HDMI infoframe drm/i915/ddi: Set HDMI infoframes with pipe clocks enabled drm/i915/ddi: Removed unused var from hsw_write_infoframe() drivers/gpu/drm/i915/intel_crt.c | 4 drivers/gpu/drm/i915/intel_ddi.c | 12 ++-- drivers/gpu/drm/i915/intel_display.c | 10 ++ drivers/gpu/drm/i915/intel_hdmi.c| 16 +++- 4 files changed, 27 insertions(+), 15 deletions(-) -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915/ddi: Removed unused var from hsw_write_infoframe()
Cc: Vandita Kulkarni Cc: Paulo Zanoni Cc: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_hdmi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 29d586f5cedb..bd928e83dfc7 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -390,14 +390,11 @@ static void hsw_write_infoframe(struct drm_encoder *encoder, struct drm_i915_private *dev_priv = to_i915(dev); enum transcoder cpu_transcoder = crtc_state->cpu_transcoder; i915_reg_t ctl_reg = HSW_TVIDEO_DIP_CTL(cpu_transcoder); - i915_reg_t data_reg; int data_size = type == DP_SDP_VSC ? VIDEO_DIP_VSC_DATA_SIZE : VIDEO_DIP_DATA_SIZE; int i; u32 val = I915_READ(ctl_reg); - data_reg = hsw_dip_data_reg(dev_priv, cpu_transcoder, type, 0); - val &= ~hsw_infoframe_enable(type); I915_WRITE(ctl_reg, val); -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915/ddi: s/crtc->config/old_crtc_state in haswell_crtc_disable()
crtc->config points to the old crtc state at the point display.crtc_disable() is called, so use the more descriptive pointer instead. Cc: Vandita Kulkarni Cc: Paulo Zanoni Cc: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0ddb9b5952a5..d9170e514825 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5824,8 +5824,8 @@ static void haswell_crtc_disable(struct intel_crtc_state *old_crtc_state, if (!transcoder_is_dsi(cpu_transcoder)) intel_disable_pipe(old_crtc_state); - if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST)) - intel_ddi_set_vc_payload_alloc(intel_crtc->config, false); + if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) + intel_ddi_set_vc_payload_alloc(old_crtc_state, false); if (!transcoder_is_dsi(cpu_transcoder)) intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder); @@ -5836,7 +5836,7 @@ static void haswell_crtc_disable(struct intel_crtc_state *old_crtc_state, ironlake_pfit_disable(intel_crtc, false); if (!transcoder_is_dsi(cpu_transcoder)) - intel_ddi_disable_pipe_clock(intel_crtc->config); + intel_ddi_disable_pipe_clock(old_crtc_state); intel_encoders_post_disable(crtc, old_crtc_state, old_state); -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/ddi: Push pipe clock enabling to encoders
On ICL the pipe clock needs to be enabled before setting the HDMI
infoframe, but these steps are in the reverse order atm. Move the pipe
clock enabling to the encoders, so reordering of the two steps can be
done in a clean way.
No functional change.
Cc: Vandita Kulkarni
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_crt.c | 4
drivers/gpu/drm/i915/intel_ddi.c | 8
drivers/gpu/drm/i915/intel_display.c | 6 --
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 211d601cd1b1..8daf170302a0 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -232,6 +232,8 @@ static void hsw_post_disable_crt(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ intel_ddi_disable_pipe_clock(old_crtc_state);
+
pch_post_disable_crt(encoder, old_crtc_state, old_conn_state);
lpt_disable_pch_transcoder(dev_priv);
@@ -268,6 +270,8 @@ static void hsw_pre_enable_crt(struct intel_encoder
*encoder,
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
dev_priv->display.fdi_link_train(crtc, crtc_state);
+
+ intel_ddi_enable_pipe_clock(crtc_state);
}
static void hsw_enable_crt(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 84c9b0766fed..bfa451ac9f09 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2921,6 +2921,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_dp_stop_link_train(intel_dp);
icl_enable_phy_clock_gating(dig_port);
+
+ intel_ddi_enable_pipe_clock(crtc_state);
}
static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
@@ -2959,6 +2961,8 @@ static void intel_ddi_pre_enable_hdmi(struct
intel_encoder *encoder,
intel_dig_port->set_infoframes(&encoder->base,
crtc_state->has_infoframe,
crtc_state, conn_state);
+
+ intel_ddi_enable_pipe_clock(crtc_state);
}
static void intel_ddi_pre_enable(struct intel_encoder *encoder,
@@ -3025,6 +3029,8 @@ static void intel_ddi_post_disable_dp(struct
intel_encoder *encoder,
bool is_mst = intel_crtc_has_type(old_crtc_state,
INTEL_OUTPUT_DP_MST);
+ intel_ddi_disable_pipe_clock(old_crtc_state);
+
/*
* Power down sink before disabling the port, otherwise we end
* up getting interrupts from the sink on detecting link loss.
@@ -3064,6 +3070,8 @@ static void intel_ddi_post_disable_hdmi(struct
intel_encoder *encoder,
struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
struct intel_hdmi *intel_hdmi = &dig_port->hdmi;
+ intel_ddi_disable_pipe_clock(old_crtc_state);
+
intel_disable_ddi_buf(encoder);
dig_port->set_infoframes(&encoder->base, false,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d9170e514825..a846f891aaf9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5646,9 +5646,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_encoders_pre_enable(crtc, pipe_config, old_state);
- if (!transcoder_is_dsi(cpu_transcoder))
- intel_ddi_enable_pipe_clock(pipe_config);
-
if (intel_crtc_has_dp_encoder(intel_crtc->config))
intel_dp_set_m_n(intel_crtc, M1_N1);
@@ -5835,9 +5832,6 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
else
ironlake_pfit_disable(intel_crtc, false);
- if (!transcoder_is_dsi(cpu_transcoder))
- intel_ddi_disable_pipe_clock(old_crtc_state);
-
intel_encoders_post_disable(crtc, old_crtc_state, old_state);
if (INTEL_GEN(dev_priv) >= 11)
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915/ddi: Set HDMI infoframes with pipe clocks enabled
On ICL for setting the HDMI infoframe the pipe clock needs to be enabled, otherwise accessing the VIDEO_DIP_CTL register will hang the machine. Cc: Vandita Kulkarni Cc: Paulo Zanoni Cc: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_ddi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index bfa451ac9f09..08336a66d5c6 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2958,11 +2958,11 @@ static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder, if (IS_GEN9_BC(dev_priv)) skl_ddi_set_iboost(encoder, level, INTEL_OUTPUT_HDMI); + intel_ddi_enable_pipe_clock(crtc_state); + intel_dig_port->set_infoframes(&encoder->base, crtc_state->has_infoframe, crtc_state, conn_state); - - intel_ddi_enable_pipe_clock(crtc_state); } static void intel_ddi_pre_enable(struct intel_encoder *encoder, @@ -3070,13 +3070,13 @@ static void intel_ddi_post_disable_hdmi(struct intel_encoder *encoder, struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base); struct intel_hdmi *intel_hdmi = &dig_port->hdmi; + dig_port->set_infoframes(&encoder->base, false, +old_crtc_state, old_conn_state); + intel_ddi_disable_pipe_clock(old_crtc_state); intel_disable_ddi_buf(encoder); - dig_port->set_infoframes(&encoder->base, false, -old_crtc_state, old_conn_state); - intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain); intel_ddi_clk_disable(encoder); -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler wrote: > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > On Tue, 12 Jun 2018, Lucas De Marchi wrote: > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula wrote: > > >> > > >> On Thu, 31 May 2018, Lucas De Marchi wrote: > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > >> >> specific case to indicate a PCH system without south display. > > >> > > > >> > Then let's go ahead and document it? > > >> > > >> Please avoid sending suggestion patches in-reply-to existing > > >> series. This confused patchwork and screwed up CI for the series, which > > >> was already a resend just to get CI. :( > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > > a hundred words explaining :( ... > > > > I feel you, a patch is more precise. > > > > > IMO pw is trying to be smarter than it should here or not being smart > > > enough. Nonetheless I won't do that anymore. > > > > I think there were earlier complaints about what it did recognize and > > what it didn't. I'd be open to only accepting new versions of patches > > from whoever sent the original patch. Or requiring patch subjects don't > > start with "Re:". Or both. > > No matter what you do here it will misbehave in some scenarios and > break someone's workflow :< > > Originally we required the patches to have X-Mailer set to > git-send-email, which seems reasonable, but that annoyed people because > their servers were stripping out those headers. > > Other people send out the patches by feeding them to the drafts folder > through IMAP and then sending them out. This, depending on the > provider's configuration, also gobbles up a thing or two. > > Because of the above I am not sure about trusting "Re:" and matching > "From:" headers as good enough indicators either. > > It just adds more opaque "smartness". I already can foresee questions > asking "why my v2 was not picked up?" and someone would have to debug it > down the line. > > Was the address different (+XYZ before @)? Has that someone used > --subject-prefix=re:? Is it an actual bug? Etc. > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > without confusing patchwork. In the end, I wouldn't want to hamper > > review by blocking something that comes naturally to people. > > > > Arek? > > Just add the following header: > "X-Patchwork-Hint: comment" > to emails that you type out manually. > > For mutt it's as easy as adding: > "my_hdr X-Patchwork-Hint: comment" > to your .muttrc This may not work for the same reasons you pointed out that wouldn't work if people are sending patches. Is there a format I can use that will not trigger patchwork from parsing a _reply_? Does removing the "" help? Under the hood does it use git am --scissors or similar? Lucas De Marchi > > https://github.com/dlespiau/patchwork/commit/148f10115525 > > -- > Cheers, > Arek -- Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/icl: Fix HDMI infoframe setting
== Series Details == Series: drm/i915/icl: Fix HDMI infoframe setting URL : https://patchwork.freedesktop.org/series/44709/ State : failure == Summary == Applying: drm/i915/ddi: s/crtc->config/old_crtc_state in haswell_crtc_disable() Applying: drm/i915/ddi: Push pipe clock enabling to encoders error: sha1 information is lacking or useless (drivers/gpu/drm/i915/intel_ddi.c). error: could not build fake ancestor Patch failed at 0002 drm/i915/ddi: Push pipe clock enabling to encoders Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Adds psrwake options for all platforms
On Wed, 2018-06-13 at 10:32 -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-06-13 at 09:41 +0300, Jani Nikula wrote:
> >
> > On Wed, 13 Jun 2018, "Nagaraju, Vathsala" > co
> > m> wrote:
> > >
> > >
> > > On 6/12/2018 2:30 PM, Jani Nikula wrote:
> > > >
> > > >
> > > > On Tue, 12 Jun 2018, vathsala nagaraju > > > .c
> > > > om> wrote:
> > > > >
> > > > >
> > > > > From: Vathsala Nagaraju
> > > > >
> > > > > Adds new psrwake options defined in the below table.
> > > > > Platform PSR wake options vbt version
> > > > > KBL/CFL/WHL All
> > > > > SKL All PV releases (Check for 203+ might help
> > > > > but cannot be foolproof)
> > > > > BXT Uses old interpretation.
> > > > > CNL/ICL+ All
> > > > > GLK All
> > > > >
> > > > > For SKL, we will continue to use older interpretation for the
> > > > > above reason.
> > > > >
> > > > > Cc: Jani Nikula
> > > > > Cc: Rodrigo Vivi
> > > > > Cc: Puthikorn Voravootivat
> > > > > Cc: Dhinakaran Pandiyan
> > > > >
> > > > > Signed-off-by: Vathsala Nagaraju > > > > >
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_bios.c | 3 ++-
> > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > > > > b/drivers/gpu/drm/i915/intel_bios.c
> > > > > index 465dff4..010ff68 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_bios.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > > > > @@ -710,7 +710,8 @@ static int
> > > > > intel_bios_ssc_frequency(struct
> > > > > drm_i915_private *dev_priv,
> > > > > * New psr options 0=500us, 1=100us, 2=2500us,
> > > > > 3=0us
> > > > > * Old decimal value is wake up time in multiples
> > > > > of
> > > > > 100 us.
> > > > > */
> > > > > - if (bdb->version >= 209 && IS_GEN9_BC(dev_priv)) {
> > > > > + if ((INTEL_GEN(dev_priv) >= 10) ||
> > > > > + (IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv)))
> > > > > {
> > > > Please keep the version check.
> > > Sure. For SKL , shall we use older interpretation for all bdb
> > > version as
> > > vbt team cannot confirm bdb version for SKL?
> > I guess.
> >
> Why not change the version check to >= 203, if that's what PV
> releases
> had as per your commit message? With the current code, Linux and
> Windows set 500 us and 2.5 ms respectively on my laptop.
Said laptop is a SKL with bdb version 205.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Wed, Jun 13, 2018 at 10:09 AM Lucas De Marchi wrote: > > On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler > wrote: > > > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > > On Tue, 12 Jun 2018, Lucas De Marchi wrote: > > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula > > > > wrote: > > > >> > > > >> On Thu, 31 May 2018, Lucas De Marchi wrote: > > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > > >> >> specific case to indicate a PCH system without south display. > > > >> > > > > >> > Then let's go ahead and document it? > > > >> > > > >> Please avoid sending suggestion patches in-reply-to existing > > > >> series. This confused patchwork and screwed up CI for the series, which > > > >> was already a resend just to get CI. :( > > > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > > > a hundred words explaining :( ... > > > > > > I feel you, a patch is more precise. > > > > > > > IMO pw is trying to be smarter than it should here or not being smart > > > > enough. Nonetheless I won't do that anymore. > > > > > > I think there were earlier complaints about what it did recognize and > > > what it didn't. I'd be open to only accepting new versions of patches > > > from whoever sent the original patch. Or requiring patch subjects don't > > > start with "Re:". Or both. > > > > No matter what you do here it will misbehave in some scenarios and > > break someone's workflow :< > > > > Originally we required the patches to have X-Mailer set to > > git-send-email, which seems reasonable, but that annoyed people because > > their servers were stripping out those headers. > > > > Other people send out the patches by feeding them to the drafts folder > > through IMAP and then sending them out. This, depending on the > > provider's configuration, also gobbles up a thing or two. > > > > Because of the above I am not sure about trusting "Re:" and matching > > "From:" headers as good enough indicators either. > > > > It just adds more opaque "smartness". I already can foresee questions > > asking "why my v2 was not picked up?" and someone would have to debug it > > down the line. > > > > Was the address different (+XYZ before @)? Has that someone used > > --subject-prefix=re:? Is it an actual bug? Etc. > > > > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > > without confusing patchwork. In the end, I wouldn't want to hamper > > > review by blocking something that comes naturally to people. > > > > > > Arek? > > > > Just add the following header: > > "X-Patchwork-Hint: comment" > > to emails that you type out manually. > > > > For mutt it's as easy as adding: > > "my_hdr X-Patchwork-Hint: comment" > > to your .muttrc > > This may not work for the same reasons you pointed out that wouldn't > work if people are sending patches. Is there a format I can use that > will not trigger patchwork from parsing a _reply_? Does removing the > "" help? Under the hood does it use git am --scissors or > similar? Humn... it has its own parser. So if I read https://github.com/dlespiau/patchwork/blob/master/patchwork/parser.py#L36 correctly, it should be just a matter of omitting the "diff | ---" lines (or prepending with a "#"). It does make things more difficult if the other person would use "git am --scissors" though. Lucas De Marchi > > > Lucas De Marchi > > > > > https://github.com/dlespiau/patchwork/commit/148f10115525 > > > > -- > > Cheers, > > Arek > > > > -- > Lucas De Marchi -- Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] drm/i915/ddi: Push pipe clock enabling to encoders
On ICL the pipe clock needs to be enabled before setting the HDMI
infoframe, but these steps are in the reverse order atm. Move the pipe
clock enabling to the encoders, so reordering of the two steps can be
done in a clean way.
No functional change.
v2:
- Rebased on drm-tip.
Cc: Vandita Kulkarni
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_crt.c | 4
drivers/gpu/drm/i915/intel_ddi.c | 8
drivers/gpu/drm/i915/intel_display.c | 6 --
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 211d601cd1b1..8daf170302a0 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -232,6 +232,8 @@ static void hsw_post_disable_crt(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ intel_ddi_disable_pipe_clock(old_crtc_state);
+
pch_post_disable_crt(encoder, old_crtc_state, old_conn_state);
lpt_disable_pch_transcoder(dev_priv);
@@ -268,6 +270,8 @@ static void hsw_pre_enable_crt(struct intel_encoder
*encoder,
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
dev_priv->display.fdi_link_train(crtc, crtc_state);
+
+ intel_ddi_enable_pipe_clock(crtc_state);
}
static void hsw_enable_crt(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ca73387bd596..df0e64a9721a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2639,6 +2639,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
+
+ intel_ddi_enable_pipe_clock(crtc_state);
}
static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
@@ -2672,6 +2674,8 @@ static void intel_ddi_pre_enable_hdmi(struct
intel_encoder *encoder,
intel_dig_port->set_infoframes(&encoder->base,
crtc_state->has_infoframe,
crtc_state, conn_state);
+
+ intel_ddi_enable_pipe_clock(crtc_state);
}
static void intel_ddi_pre_enable(struct intel_encoder *encoder,
@@ -2738,6 +2742,8 @@ static void intel_ddi_post_disable_dp(struct
intel_encoder *encoder,
bool is_mst = intel_crtc_has_type(old_crtc_state,
INTEL_OUTPUT_DP_MST);
+ intel_ddi_disable_pipe_clock(old_crtc_state);
+
/*
* Power down sink before disabling the port, otherwise we end
* up getting interrupts from the sink on detecting link loss.
@@ -2763,6 +2769,8 @@ static void intel_ddi_post_disable_hdmi(struct
intel_encoder *encoder,
struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
struct intel_hdmi *intel_hdmi = &dig_port->hdmi;
+ intel_ddi_disable_pipe_clock(old_crtc_state);
+
intel_disable_ddi_buf(encoder);
dig_port->set_infoframes(&encoder->base, false,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f8bbfc7ce7ce..cd10e83ec456 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5646,9 +5646,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_encoders_pre_enable(crtc, pipe_config, old_state);
- if (!transcoder_is_dsi(cpu_transcoder))
- intel_ddi_enable_pipe_clock(pipe_config);
-
if (intel_crtc_has_dp_encoder(intel_crtc->config))
intel_dp_set_m_n(intel_crtc, M1_N1);
@@ -5835,9 +5832,6 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
else
ironlake_pfit_disable(intel_crtc, false);
- if (!transcoder_is_dsi(cpu_transcoder))
- intel_ddi_disable_pipe_clock(old_crtc_state);
-
intel_encoders_post_disable(crtc, old_crtc_state, old_state);
if (INTEL_GEN(dev_priv) >= 11)
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/ddi: s/crtc->config/old_crtc_state in haswell_crtc_disable()
On Wed, Jun 13, 2018 at 08:07:06PM +0300, Imre Deak wrote: > crtc->config points to the old crtc state at the point > display.crtc_disable() is called, so use the more descriptive pointer > instead. I see one more crtc->config in there. Either way Reviewed-by: Ville Syrjälä > > Cc: Vandita Kulkarni > Cc: Paulo Zanoni > Cc: Ville Syrjälä > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_display.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 0ddb9b5952a5..d9170e514825 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -5824,8 +5824,8 @@ static void haswell_crtc_disable(struct > intel_crtc_state *old_crtc_state, > if (!transcoder_is_dsi(cpu_transcoder)) > intel_disable_pipe(old_crtc_state); > > - if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST)) > - intel_ddi_set_vc_payload_alloc(intel_crtc->config, false); > + if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) > + intel_ddi_set_vc_payload_alloc(old_crtc_state, false); > > if (!transcoder_is_dsi(cpu_transcoder)) > intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder); > @@ -5836,7 +5836,7 @@ static void haswell_crtc_disable(struct > intel_crtc_state *old_crtc_state, > ironlake_pfit_disable(intel_crtc, false); > > if (!transcoder_is_dsi(cpu_transcoder)) > - intel_ddi_disable_pipe_clock(intel_crtc->config); > + intel_ddi_disable_pipe_clock(old_crtc_state); > > intel_encoders_post_disable(crtc, old_crtc_state, old_state); > > -- > 2.13.2 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/ddi: Push pipe clock enabling to encoders
On Wed, Jun 13, 2018 at 08:27:46PM +0300, Imre Deak wrote:
> On ICL the pipe clock needs to be enabled before setting the HDMI
> infoframe, but these steps are in the reverse order atm. Move the pipe
> clock enabling to the encoders, so reordering of the two steps can be
> done in a clean way.
>
> No functional change.
>
> v2:
> - Rebased on drm-tip.
>
> Cc: Vandita Kulkarni
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_crt.c | 4
> drivers/gpu/drm/i915/intel_ddi.c | 8
> drivers/gpu/drm/i915/intel_display.c | 6 --
> 3 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 211d601cd1b1..8daf170302a0 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -232,6 +232,8 @@ static void hsw_post_disable_crt(struct intel_encoder
> *encoder,
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>
> + intel_ddi_disable_pipe_clock(old_crtc_state);
> +
> pch_post_disable_crt(encoder, old_crtc_state, old_conn_state);
>
> lpt_disable_pch_transcoder(dev_priv);
> @@ -268,6 +270,8 @@ static void hsw_pre_enable_crt(struct intel_encoder
> *encoder,
> intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
>
> dev_priv->display.fdi_link_train(crtc, crtc_state);
> +
> + intel_ddi_enable_pipe_clock(crtc_state);
> }
>
> static void hsw_enable_crt(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ca73387bd596..df0e64a9721a 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2639,6 +2639,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> intel_dp_start_link_train(intel_dp);
> if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> intel_dp_stop_link_train(intel_dp);
> +
> + intel_ddi_enable_pipe_clock(crtc_state);
> }
>
> static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> @@ -2672,6 +2674,8 @@ static void intel_ddi_pre_enable_hdmi(struct
> intel_encoder *encoder,
> intel_dig_port->set_infoframes(&encoder->base,
> crtc_state->has_infoframe,
> crtc_state, conn_state);
> +
> + intel_ddi_enable_pipe_clock(crtc_state);
> }
>
> static void intel_ddi_pre_enable(struct intel_encoder *encoder,
> @@ -2738,6 +2742,8 @@ static void intel_ddi_post_disable_dp(struct
> intel_encoder *encoder,
> bool is_mst = intel_crtc_has_type(old_crtc_state,
> INTEL_OUTPUT_DP_MST);
>
> + intel_ddi_disable_pipe_clock(old_crtc_state);
> +
> /*
>* Power down sink before disabling the port, otherwise we end
>* up getting interrupts from the sink on detecting link loss.
> @@ -2763,6 +2769,8 @@ static void intel_ddi_post_disable_hdmi(struct
> intel_encoder *encoder,
> struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
> struct intel_hdmi *intel_hdmi = &dig_port->hdmi;
>
> + intel_ddi_disable_pipe_clock(old_crtc_state);
> +
> intel_disable_ddi_buf(encoder);
>
> dig_port->set_infoframes(&encoder->base, false,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f8bbfc7ce7ce..cd10e83ec456 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5646,9 +5646,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
>
> intel_encoders_pre_enable(crtc, pipe_config, old_state);
>
> - if (!transcoder_is_dsi(cpu_transcoder))
> - intel_ddi_enable_pipe_clock(pipe_config);
> -
> if (intel_crtc_has_dp_encoder(intel_crtc->config))
> intel_dp_set_m_n(intel_crtc, M1_N1);
>
> @@ -5835,9 +5832,6 @@ static void haswell_crtc_disable(struct
> intel_crtc_state *old_crtc_state,
> else
> ironlake_pfit_disable(intel_crtc, false);
>
> - if (!transcoder_is_dsi(cpu_transcoder))
> - intel_ddi_disable_pipe_clock(old_crtc_state);
> -
> intel_encoders_post_disable(crtc, old_crtc_state, old_state);
>
> if (INTEL_GEN(dev_priv) >= 11)
> --
> 2.13.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915/ddi: Check transcoder instead of port when setting HDMI infoframe
On Wed, Jun 13, 2018 at 08:07:08PM +0300, Imre Deak wrote:
> The only requirement by BSpec for setting the HDMI infoframes is on DDI
> platforms to do that before enabling the HDMI transcoder function, see
> VIDEO_DIP_CTL bit 16. Accordingly check for the transcoder function
> disabled state instead of the port's disabled state on DDI platforms.
> This is needed by the next patch as it will set the infoframe during
> crtc disabling where the port is still enabled.
>
> Suggested-by: Ville Syrjälä
> Cc: Vandita Kulkarni
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
Seems sensible.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index b7a95fd0663b..29d586f5cedb 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -59,6 +59,15 @@ assert_hdmi_port_disabled(struct intel_hdmi *intel_hdmi)
>"HDMI port enabled, expecting disabled\n");
> }
>
> +static void
> +assert_hdmi_transcoder_func_disabled(struct drm_i915_private *dev_priv,
> + enum transcoder cpu_transcoder)
> +{
> + WARN(I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder)) &
> + TRANS_DDI_FUNC_ENABLE,
> + "HDMI transcoder function enabled, expecting disabled\n");
> +}
> +
> struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder)
> {
> struct intel_digital_port *intel_dig_port =
> @@ -838,11 +847,11 @@ static void hsw_set_infoframes(struct drm_encoder
> *encoder,
> const struct drm_connector_state *conn_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> - struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
> u32 val = I915_READ(reg);
>
> - assert_hdmi_port_disabled(intel_hdmi);
> + assert_hdmi_transcoder_func_disabled(dev_priv,
> + crtc_state->cpu_transcoder);
>
> val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
>VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
> --
> 2.13.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/ddi: Set HDMI infoframes with pipe clocks enabled
On Wed, Jun 13, 2018 at 08:07:09PM +0300, Imre Deak wrote: > On ICL for setting the HDMI infoframe the pipe clock needs to be > enabled, otherwise accessing the VIDEO_DIP_CTL register will hang the > machine. > > Cc: Vandita Kulkarni > Cc: Paulo Zanoni > Cc: Ville Syrjälä > Signed-off-by: Imre Deak Looks safe to me. Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_ddi.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index bfa451ac9f09..08336a66d5c6 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -2958,11 +2958,11 @@ static void intel_ddi_pre_enable_hdmi(struct > intel_encoder *encoder, > if (IS_GEN9_BC(dev_priv)) > skl_ddi_set_iboost(encoder, level, INTEL_OUTPUT_HDMI); > > + intel_ddi_enable_pipe_clock(crtc_state); > + > intel_dig_port->set_infoframes(&encoder->base, > crtc_state->has_infoframe, > crtc_state, conn_state); > - > - intel_ddi_enable_pipe_clock(crtc_state); > } > > static void intel_ddi_pre_enable(struct intel_encoder *encoder, > @@ -3070,13 +3070,13 @@ static void intel_ddi_post_disable_hdmi(struct > intel_encoder *encoder, > struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base); > struct intel_hdmi *intel_hdmi = &dig_port->hdmi; > > + dig_port->set_infoframes(&encoder->base, false, > + old_crtc_state, old_conn_state); > + > intel_ddi_disable_pipe_clock(old_crtc_state); > > intel_disable_ddi_buf(encoder); > > - dig_port->set_infoframes(&encoder->base, false, > - old_crtc_state, old_conn_state); > - > intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain); > > intel_ddi_clk_disable(encoder); > -- > 2.13.2 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915/ddi: Removed unused var from hsw_write_infoframe()
On Wed, Jun 13, 2018 at 08:07:10PM +0300, Imre Deak wrote:
> Cc: Vandita Kulkarni
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
Looks like I forgot to remove it in ffc85daba535 ("drm/i915:
Fix AVI/HDMI/SPD infoframes on HSW+")
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 29d586f5cedb..bd928e83dfc7 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -390,14 +390,11 @@ static void hsw_write_infoframe(struct drm_encoder
> *encoder,
> struct drm_i915_private *dev_priv = to_i915(dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> i915_reg_t ctl_reg = HSW_TVIDEO_DIP_CTL(cpu_transcoder);
> - i915_reg_t data_reg;
> int data_size = type == DP_SDP_VSC ?
> VIDEO_DIP_VSC_DATA_SIZE : VIDEO_DIP_DATA_SIZE;
> int i;
> u32 val = I915_READ(ctl_reg);
>
> - data_reg = hsw_dip_data_reg(dev_priv, cpu_transcoder, type, 0);
> -
> val &= ~hsw_infoframe_enable(type);
> I915_WRITE(ctl_reg, val);
>
> --
> 2.13.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI
On Thu, May 24, 2018 at 04:30:10PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI > URL : https://patchwork.freedesktop.org/series/43698/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4230_full -> Patchwork_9104_full = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_9104_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_9104_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/43698/revisions/1/mbox/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_9104_full: > > === IGT changes === > > Possible regressions > > igt@drv_selftest@live_gtt: > shard-kbl: PASS -> FAIL Selftest blew up for some reason: <4>[ 177.975101] RIP: 0010:i915_vma_destroy+0x1fd/0x410 [i915] ... <4>[ 177.975202] __igt_write_huge+0xf7/0x2d0 [i915] > > > Warnings > > igt@gem_exec_schedule@deep-bsd1: > shard-kbl: SKIP -> PASS > > igt@pm_rc6_residency@rc6-accuracy: > shard-snb: PASS -> SKIP Test requirement not met in function __real_main198, file ../tests/pm_rc6_residency.c:217: Test requirement: wait_for_rc6() Subtest rc6-accuracy: SKIP meh > > > == Known issues == > > Here are the changes found in Patchwork_9104_full that come from known > issues: > > === IGT changes === > > Issues hit > > igt@drv_selftest@live_hugepages: > shard-kbl: PASS -> INCOMPLETE (fdo#103665) > > igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: > shard-glk: PASS -> FAIL (fdo#105703) > > igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: > shard-hsw: PASS -> FAIL (fdo#103060) > > igt@kms_flip@plain-flip-fb-recreate: > shard-glk: PASS -> FAIL (fdo#100368) > > igt@kms_setmode@basic: > shard-apl: PASS -> FAIL (fdo#99912) > > igt@perf_pmu@busy-double-start-vcs0: > shard-snb: PASS -> FAIL (fdo#105106) > > > Possible fixes > > igt@drv_selftest@live_gtt: > shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS > > igt@drv_selftest@live_hangcheck: > shard-apl: DMESG-FAIL (fdo#106560) -> PASS > > igt@gem_ppgtt@blt-vs-render-ctx0: > shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS > > igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: > shard-glk: FAIL (fdo#105703) -> PASS > > igt@kms_flip@2x-flip-vs-expired-vblank: > shard-hsw: FAIL (fdo#102887) -> PASS > > igt@kms_flip@2x-plain-flip-fb-recreate: > shard-glk: FAIL (fdo#100368) -> PASS > > igt@kms_flip@flip-vs-expired-vblank-interruptible: > shard-glk: FAIL (fdo#102887, fdo#105363) -> PASS > > igt@kms_flip@modeset-vs-vblank-race-interruptible: > shard-hsw: FAIL (fdo#103060) -> PASS > > igt@kms_flip_tiling@flip-x-tiled: > shard-glk: FAIL (fdo#104724) -> PASS > > igt@pm_rpm@modeset-non-lpsp-stress: > shard-hsw: DMESG-WARN (fdo#102614) -> PASS > > > fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 > fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 > fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 > fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 > fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 > fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 > fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 > fdo#105106 https://bugs.freedesktop.org/show_bug.cgi?id=105106 > fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 > fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 > fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 > fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 > fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 > k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 > > > == Participating hosts (5 -> 5) == > > No changes in participating hosts > > > == Build changes == > > * Linux: CI_DRM_4230 -> Patchwork_9104 > > CI_DRM_4230: 097c5e2d7cf300d1f9855a550bfdd5150410ffc4 @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_9104: 82368323f7e2a1fbe3822bd2da4e1860f8ca418d @ > git://anongit.freedesktop.org/gfx-ci/linux > > == Logs == > > For
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix HDMI infoframe setting (rev2)
== Series Details == Series: drm/i915/icl: Fix HDMI infoframe setting (rev2) URL : https://patchwork.freedesktop.org/series/44709/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4310 -> Patchwork_9292 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9292 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9292, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44709/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9292: === IGT changes === Warnings igt@pm_rpm@basic-rte: fi-glk-j4005: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9292 that come from known issues: === IGT changes === Issues hit igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128) igt@kms_flip@basic-plain-flip: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@gem_ctx_create@basic-files: fi-glk-j4005: DMESG-WARN (fdo#105719) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-skl-6700hq: DMESG-WARN (fdo#105998) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#105998 https://bugs.freedesktop.org/show_bug.cgi?id=105998 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan == Build changes == * Linux: CI_DRM_4310 -> Patchwork_9292 CI_DRM_4310: 5945ab6707472bde0c3bc12836252b487ecfeb72 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4518: e4908004547b63131352fbc0ddcdb1d3d55480e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9292: ad3a408add830019cdc9a2fc9c42e5936cfb257a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ad3a408add83 drm/i915/ddi: Removed unused var from hsw_write_infoframe() 202ced9ca8e9 drm/i915/ddi: Set HDMI infoframes with pipe clocks enabled e82917f25ee4 drm/i915/ddi: Check transcoder instead of port when setting HDMI infoframe 88485a65980f drm/i915/ddi: Push pipe clock enabling to encoders 9061d9ab6e4e drm/i915/ddi: s/crtc->config/old_crtc_state in haswell_crtc_disable() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9292/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: Allow DBLSCAN user modes with eDP/LVDS/DSI
On Wed, Jun 13, 2018 at 04:48:29PM +0200, Maarten Lankhorst wrote:
> Op 24-05-18 om 14:54 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > When encountering a connector with the scaling mode property both
> > intel and modesetting ddxs sometimes add tons of DBLSCAN modes
> > to the output's mode list. The idea presumably being that since the
> > output will be going through the panel fitter anyway we can pretend
> > to use any kind of mode.
> >
> > Sadly that means we can't reject user modes with the DBLSCAN flag
> > until we know whether we're going to be using the panel's native
> > mode or the user mode directly. Doing otherwise means X clients using
> > xf86vidmode/xrandr will get a protocol error (and often self
> > terminate as a result) when the kernel refuses to use the requested
> > mode with the DBLSCAN flag.
> >
> > To undo the regression we'll move the DBLSCAN checks into the
> > connector->mode_valid() and encoder->compute_config() hooks.
> >
> > Cc: Vito Caputo
> > Reported-by: Vito Caputo
> > Fixes: e995ca0b8139 ("drm/i915: Provide a device level .mode_valid() hook")
> > References: https://lkml.org/lkml/2018/5/21/715
> > Signed-off-by: Ville Syrjälä
> > ---
>
> Reviewed-by: Maarten Lankhorst
Thanks. Pushed to dinq with
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106804
Tested-by: Arkadiusz Miskiewicz
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/4] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
From: Ville Syrjälä
CDCLK has to be at least twice the BLCK regardless of audio. Audio
driver has to probe using this hook and increase the clock even in
absence of any display.
v2: Use atomic refcount for get_power, put_power so that we can
call each once(Abhay).
v3: Reset power well 2 to avoid any transaction on iDisp link
during cdclk change(Abhay).
v4: Remove Power well 2 reset workaround(Ville).
Signed-off-by: Ville Syrjälä
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_reg.h | 4 +++
drivers/gpu/drm/i915/intel_audio.c | 67 +---
drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
drivers/gpu/drm/i915/intel_display.c | 7 +++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
6 files changed, 87 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6104d7115054..a4a386a5db69 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1702,6 +1702,7 @@ struct drm_i915_private {
unsigned int hpll_freq;
unsigned int fdi_pll_freq;
unsigned int czclk_freq;
+ u32 get_put_refcount;
struct {
/*
@@ -1719,6 +1720,8 @@ struct drm_i915_private {
struct intel_cdclk_state actual;
/* The current hardware cdclk state */
struct intel_cdclk_state hw;
+
+ int force_min_cdclk;
} cdclk;
/**
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 987def26ce82..cef770184245 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8869,6 +8869,10 @@ enum skl_power_gate {
* SKL Clocks
*/
+/* Power well 2 */
+#define POWER_WELL_2 _MMIO(0x45404)
+#define POWER_WELL_2_REQUEST (1<<31)
+
/* CDCLK_CTL */
#define CDCLK_CTL _MMIO(0x46000)
#define CDCLK_FREQ_SEL_MASK (3 << 26)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 3ea566f99450..ca8f04c7cbb3 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
if (!connector->eld[0])
return;
-
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id,
connector->name,
@@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private
*dev_priv)
}
}
+static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
+ bool enable)
+{
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_atomic_state *state;
+ int ret;
+
+ drm_modeset_acquire_init(&ctx, 0);
+ state = drm_atomic_state_alloc(&dev_priv->drm);
+ if (WARN_ON(!state))
+ return;
+
+ state->acquire_ctx = &ctx;
+
+retry:
+ to_intel_atomic_state(state)->modeset = true;
+ to_intel_atomic_state(state)->cdclk.force_min_cdclk =
+ enable ? 2 * 96000 : 0;
+
+ /*
+* Protects dev_priv->cdclk.force_min_cdclk
+* Need to lock this here in case we have no active pipes
+* and thus wouldn't lock it during the commit otherwise.
+*/
+ ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
&ctx);
+ if (!ret)
+ ret = drm_atomic_commit(state);
+
+ if (ret == -EDEADLK) {
+ drm_atomic_state_clear(state);
+ drm_modeset_backoff(&ctx);
+ goto retry;
+ }
+
+ WARN_ON(ret);
+
+ drm_atomic_state_put(state);
+
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+}
+
static void i915_audio_component_get_power(struct device *kdev)
{
- intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
+ struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
+
+ dev_priv->get_put_refcount++;
+
+ /* Force cdclk to 2*BCLK during first time get power call */
+ if (dev_priv->get_put_refcount == 1)
+ if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ glk_force_audio_cdclk(dev_priv, true);
+
+ intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
}
static void i915_audio_component_put_power(struct device *kdev)
{
- intel_display_power_put(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
+ struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
+
+ dev_priv->get_put_refcount--;
+
+ /* Force required cdclk during last time put power call */
+ if (dev_priv->get_put_refcount == 0)
+ if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ glk_force_audio_cdclk(dev_priv, false);
+
+ intel_display_power_put(dev_pr
[Intel-gfx] [PATCH v4 3/4] drm/i915: Lock gmbus/aux mutexes while changing cdclk
From: Ville Syrjälä
gmbus/aux may be clocked by cdclk, thus we should make sure no
transfers are ongoing while the cdclk frequency is being changed.
We do that by simply grabbing all the gmbus/aux mutexes. No one
else should be holding any more than one of those at a time so
the lock ordering here shouldn't matter.
An alternative apporach would be the introduction of a cdclk
rwsem. Cdclk reprogramming would take the write lock, all users
of cdclk would take the read lock.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/intel_cdclk.c | 25 +
drivers/gpu/drm/i915/intel_i2c.c | 1 -
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4cdd70de5ed0..2a30369b9df9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -899,6 +899,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
mutex_init(&dev_priv->av_mutex);
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
+ mutex_init(&dev_priv->gmbus_mutex);
i915_memcpy_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 0f0aea900ceb..ebfafef7bf88 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2078,6 +2078,9 @@ void intel_dump_cdclk_state(const struct
intel_cdclk_state *cdclk_state,
void intel_set_cdclk(struct drm_i915_private *dev_priv,
const struct intel_cdclk_state *cdclk_state)
{
+ struct intel_encoder *encoder;
+ unsigned int aux_mutex_lockclass = 0;
+
if (!intel_cdclk_changed(&dev_priv->cdclk.hw, cdclk_state))
return;
@@ -2086,8 +2089,30 @@ void intel_set_cdclk(struct drm_i915_private *dev_priv,
intel_dump_cdclk_state(cdclk_state, "Changing CDCLK to");
+ /*
+* Lock aux/gmbus while we change cdclk in case the
+* those functions use cdclk. Not all platforms/ports
+* do, but we'll lock them all for simplicity. All other
+* users of cdclk (apart from audio) should be off on
+* account of the pipes being off.
+*/
+ for_each_intel_dp(&dev_priv->drm, encoder) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
+
+ mutex_lock_nested(&intel_dp->aux.hw_mutex,
+ aux_mutex_lockclass++);
+ }
+ mutex_lock(&dev_priv->gmbus_mutex);
+
dev_priv->display.set_cdclk(dev_priv, cdclk_state);
+ for_each_intel_dp(&dev_priv->drm, encoder) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
+
+ mutex_unlock(&intel_dp->aux.hw_mutex);
+ }
+ mutex_unlock(&dev_priv->gmbus_mutex);
+
if (WARN(intel_cdclk_changed(&dev_priv->cdclk.hw, cdclk_state),
"cdclk state doesn't match!\n")) {
intel_dump_cdclk_state(&dev_priv->cdclk.hw, "[hw state]");
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 61729bf84e08..14bc8889596e 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -781,7 +781,6 @@ int intel_setup_gmbus(struct drm_i915_private *dev_priv)
i915_mmio_reg_offset(PCH_GPIOA) -
i915_mmio_reg_offset(GPIOA);
- mutex_init(&dev_priv->gmbus_mutex);
init_waitqueue_head(&dev_priv->gmbus_wait_queue);
for (pin = 0; pin < ARRAY_SIZE(dev_priv->gmbus); pin++) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/4] Enable Dynamic cdclk and HDA together on GLK
Patches needed to change cdclk to 2*BCLK before accessing HDA Codec. Ville Syrjälä (4): drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled drm/i915: Introduce for_each_intel_dp() drm/i915: Lock gmbus/aux mutexes while changing cdclk drm/i915: Shut off PW2 when changing cdclk on glk drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 3 ++ drivers/gpu/drm/i915/i915_reg.h | 4 ++ drivers/gpu/drm/i915/intel_audio.c | 67 ++-- drivers/gpu/drm/i915/intel_cdclk.c | 68 +++-- drivers/gpu/drm/i915/intel_display.c| 7 +++- drivers/gpu/drm/i915/intel_display.h| 4 ++ drivers/gpu/drm/i915/intel_dp.c | 38 -- drivers/gpu/drm/i915/intel_drv.h| 21 ++ drivers/gpu/drm/i915/intel_i2c.c| 1 - drivers/gpu/drm/i915/intel_runtime_pm.c | 34 + 11 files changed, 191 insertions(+), 57 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/4] drm/i915: Introduce for_each_intel_dp()
From: Ville Syrjälä
Add a convenience macro for iterating DP encoders.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.h | 4
drivers/gpu/drm/i915/intel_dp.c | 38 +++-
drivers/gpu/drm/i915/intel_drv.h | 14 +
3 files changed, 25 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index c88185ed7594..e153d0e925d8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -284,6 +284,10 @@ struct intel_link_m_n {
&(dev)->mode_config.encoder_list, \
base.head)
+#define for_each_intel_dp(dev, intel_encoder) \
+ for_each_intel_encoder(dev, intel_encoder) \
+ for_each_if(intel_encoder_is_dp(intel_encoder))
+
#define for_each_intel_connector_iter(intel_connector, iter) \
while ((intel_connector =
to_intel_connector(drm_connector_list_iter_next(iter
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 37b9f62aeb6e..fcc7c5465d48 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -583,14 +583,8 @@ static enum pipe vlv_find_free_pps(struct drm_i915_private
*dev_priv)
* We don't have power sequencer currently.
* Pick one that's not used by other ports.
*/
- for_each_intel_encoder(&dev_priv->drm, encoder) {
- struct intel_dp *intel_dp;
-
- if (encoder->type != INTEL_OUTPUT_DP &&
- encoder->type != INTEL_OUTPUT_EDP)
- continue;
-
- intel_dp = enc_to_intel_dp(&encoder->base);
+ for_each_intel_dp(&dev_priv->drm, encoder) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
if (encoder->type == INTEL_OUTPUT_EDP) {
WARN_ON(intel_dp->active_pipe != INVALID_PIPE &&
@@ -782,19 +776,8 @@ void intel_power_sequencer_reset(struct drm_i915_private
*dev_priv)
* should use them always.
*/
- for_each_intel_encoder(&dev_priv->drm, encoder) {
- struct intel_dp *intel_dp;
-
- if (encoder->type != INTEL_OUTPUT_DP &&
- encoder->type != INTEL_OUTPUT_EDP &&
- encoder->type != INTEL_OUTPUT_DDI)
- continue;
-
- intel_dp = enc_to_intel_dp(&encoder->base);
-
- /* Skip pure DVI/HDMI DDI encoders */
- if (!i915_mmio_reg_valid(intel_dp->output_reg))
- continue;
+ for_each_intel_dp(&dev_priv->drm, encoder) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
WARN_ON(intel_dp->active_pipe != INVALID_PIPE);
@@ -3078,16 +3061,9 @@ static void vlv_steal_power_sequencer(struct
drm_i915_private *dev_priv,
lockdep_assert_held(&dev_priv->pps_mutex);
- for_each_intel_encoder(&dev_priv->drm, encoder) {
- struct intel_dp *intel_dp;
- enum port port;
-
- if (encoder->type != INTEL_OUTPUT_DP &&
- encoder->type != INTEL_OUTPUT_EDP)
- continue;
-
- intel_dp = enc_to_intel_dp(&encoder->base);
- port = dp_to_dig_port(intel_dp)->base.port;
+ for_each_intel_dp(&dev_priv->drm, encoder) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
+ enum port port = encoder->port;
WARN(intel_dp->active_pipe == pipe,
"stealing pipe %c power sequencer from active (e)DP port
%c\n",
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0da17ad056ec..c77942adda22 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1282,6 +1282,20 @@ static inline struct intel_dp *enc_to_intel_dp(struct
drm_encoder *encoder)
return &enc_to_dig_port(encoder)->dp;
}
+static inline bool intel_encoder_is_dp(struct intel_encoder *encoder)
+{
+ switch (encoder->type) {
+ case INTEL_OUTPUT_DP:
+ case INTEL_OUTPUT_EDP:
+ return true;
+ case INTEL_OUTPUT_DDI:
+ /* Skip pure HDMI/DVI DDI encoders */
+ return
i915_mmio_reg_valid(enc_to_intel_dp(&encoder->base)->output_reg);
+ default:
+ return false;
+ }
+}
+
static inline struct intel_digital_port *
dp_to_dig_port(struct intel_dp *intel_dp)
{
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/4] drm/i915: Shut off PW2 when changing cdclk on glk
From: Ville Syrjälä
Apparently the audio hardware gets confused if it's powered up when
change the cdclk frequency. Force PW2 (which is where audio lives)
off when we do the cdclk reprogramming.
This is a rather big hack. If something is using PW2 when we do this
things wil break. I don't think there should be anything active on
the display side since we've turned off all the pipes and we've locked
out gmbus and aux, but I may be overlooking something. The problem
is more on the audio side. If audio is active when we do this PW2
toggle I'm sure something "interesting" will happen. But presumably
something would also happen if we just changed cdclk without the PW2
toggle.
A better fix would involve somehow forcing everything to drop
their PW2 references, which isn't trivial. And to make the audio driver
participate in this scheme we'd definitely need some kind of pre/post
cdclk change notify hooks in the audio component so that i915 can
actually inform the audio driver that the cdclk is going to be changed.
Either that or the audio driver would have to promise never to touch
the hardware when the pipes are off (which is how the VLV/CHV LPE
audio driver works IIRC).
Even with this hacky scheme it would make more sense to me to have
the pre/post cdclk change hooks so that the audio driver is actually
informed when the cdclk change/pw2 toggle will occur. What the audio
driver would do to prepare itself I don't actually know.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 14 ++
drivers/gpu/drm/i915/intel_drv.h| 5 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 34 +
3 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index ebfafef7bf88..206f573c89b1 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1356,6 +1356,7 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
{
int cdclk = cdclk_state->cdclk;
int vco = cdclk_state->vco;
+ bool enable_pw2 = false;
u32 val, divider;
int ret;
@@ -1381,6 +1382,14 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
}
/*
+* On GLK HDA apparently gets confused if
+* cdclk is changed while PW2 is on
+*/
+ if (IS_GEMINILAKE(dev_priv))
+ enable_pw2 = intel_display_power_toggle_start(dev_priv,
+ SKL_DISP_PW_2);
+
+ /*
* Inform power controller of upcoming frequency change. BSpec
* requires us to wait up to 150usec, but that leads to timeouts;
* the 2ms used here is based on experiment.
@@ -1437,6 +1446,11 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
}
intel_update_cdclk(dev_priv);
+
+ if (IS_GEMINILAKE(dev_priv))
+ intel_display_power_toggle_end(dev_priv,
+ SKL_DISP_PW_2,
+ enable_pw2);
}
static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c77942adda22..e92ea5eff46f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1964,6 +1964,11 @@ bool intel_display_power_get_if_enabled(struct
drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
+bool intel_display_power_toggle_start(struct drm_i915_private *dev_priv,
+ enum i915_power_well_id power_well_id);
+void intel_display_power_toggle_end(struct drm_i915_private *dev_priv,
+ enum i915_power_well_id power_well_id,
+ bool enable);
void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
u8 req_slices);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 53a6eaa9671a..86a4b788e224 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2809,6 +2809,40 @@ static void skl_display_core_uninit(struct
drm_i915_private *dev_priv)
usleep_range(10, 30); /* 10 us delay per Bspec */
}
+bool intel_display_power_toggle_start(struct drm_i915_private *dev_priv,
+ enum i915_power_well_id power_well_id)
+{
+ struct i915_power_domains *power_domains = &dev_priv->power_domains;
+ struct i915_power_well *well = lookup_power_well(dev_priv,
power_well_id);
+ bool was_enabled;
+
+ mutex_lock(&power_domains->lock);
+
+ was_enabled = well->hw_enabled;
+
+
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable Dynamic cdclk and HDA together on GLK
== Series Details ==
Series: Enable Dynamic cdclk and HDA together on GLK
URL : https://patchwork.freedesktop.org/series/44713/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
08c10018dfc7 drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is
enabled
-:54: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#54: FILE: drivers/gpu/drm/i915/i915_reg.h:8886:
+#define POWER_WELL_2_REQUEST (1<<31)
^
-:76: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#76: FILE: drivers/gpu/drm/i915/intel_audio.c:716:
+static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
+ bool enable)
-:221: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (16, 25)
#221: FILE: drivers/gpu/drm/i915/intel_cdclk.c:2401:
if (IS_GEMINILAKE(dev_priv)) {
+cdclk =
glk_calc_cdclk(intel_state->cdclk.force_min_cdclk);
total: 0 errors, 1 warnings, 2 checks, 229 lines checked
b521f169b581 drm/i915: Introduce for_each_intel_dp()
-:21: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#21: FILE: drivers/gpu/drm/i915/intel_display.h:288:
+#define for_each_intel_dp(dev, intel_encoder) \
+ for_each_intel_encoder(dev, intel_encoder) \
+ for_each_if(intel_encoder_is_dp(intel_encoder))
-:21: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_encoder' - possible
side-effects?
#21: FILE: drivers/gpu/drm/i915/intel_display.h:288:
+#define for_each_intel_dp(dev, intel_encoder) \
+ for_each_intel_encoder(dev, intel_encoder) \
+ for_each_if(intel_encoder_is_dp(intel_encoder))
total: 1 errors, 0 warnings, 1 checks, 86 lines checked
5e2850c0c5ad drm/i915: Lock gmbus/aux mutexes while changing cdclk
2fde8d7211a8 drm/i915: Shut off PW2 when changing cdclk on glk
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable Dynamic cdclk and HDA together on GLK
== Series Details == Series: Enable Dynamic cdclk and HDA together on GLK URL : https://patchwork.freedesktop.org/series/44713/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled -O:drivers/gpu/drm/i915/intel_cdclk.c:2169:29: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2158:29: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_cdclk.c:2210:29: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_cdclk.c:2210:29: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2199:29: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2199:29: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3681:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3684:16: warning: expression using sizeof(void) Commit: drm/i915: Introduce for_each_intel_dp() Okay! Commit: drm/i915: Lock gmbus/aux mutexes while changing cdclk Okay! Commit: drm/i915: Shut off PW2 when changing cdclk on glk Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable Dynamic cdclk and HDA together on GLK
== Series Details == Series: Enable Dynamic cdclk and HDA together on GLK URL : https://patchwork.freedesktop.org/series/44713/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4311 -> Patchwork_9293 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44713/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9293 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) +1 igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-skl-6700hq: DMESG-WARN (fdo#105998) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105998 https://bugs.freedesktop.org/show_bug.cgi?id=105998 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan == Build changes == * Linux: CI_DRM_4311 -> Patchwork_9293 CI_DRM_4311: 875eebee4a444f5b7ba146754e91118ff3c11ad5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4518: e4908004547b63131352fbc0ddcdb1d3d55480e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9293: 2fde8d7211a81ad3f1360aaeb17484b1b43bdef8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2fde8d7211a8 drm/i915: Shut off PW2 when changing cdclk on glk 5e2850c0c5ad drm/i915: Lock gmbus/aux mutexes while changing cdclk b521f169b581 drm/i915: Introduce for_each_intel_dp() 08c10018dfc7 drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9293/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: Kill delays when activating psr back.
The immediate enabling was actually not an issue for the
HW perspective for core platforms that have HW tracking.
HW will wait few identical idle frames before transitioning
to actual psr active anyways.
Now that we removed VLV/CHV out of the picture completely
we can safely remove any delays.
Note that this patch also remove the delayed activation
on HSW and BDW introduced by commit 'd0ac896a477d
("drm/i915: Delay first PSR activation.")'. This was
introduced to fix a blank screen on VLV/CHV and also
masked some frozen screens on other core platforms.
Probably the same that we are now properly hunting and fixing.
v2:(DK): Remove unnecessary WARN_ONs and make some other
VLV | CHV more readable.
v3: Do it regardless the timer rework.
v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable.
v5: Kill remaining items and fully rework activation functions.
v6: Rebase on top of VLV/CHV clean-up and keep the reactivation
on a regular non-delayed work to avoid extra delays on exit
calls and allow us to add few more safety checks before
real activation.
Cc: Dhinakaran Pandiyan
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 --
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_psr.c| 29 +++--
3 files changed, 8 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 769ab9745834..948b973af067 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2660,8 +2660,6 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
dev_priv->psr.busy_frontbuffer_bits);
- seq_printf(m, "Re-enable work scheduled: %s\n",
- yesno(work_busy(&dev_priv->psr.work.work)));
if (dev_priv->psr.psr2_enabled)
enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be8c2f0823c4..19defe73b156 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -613,7 +613,7 @@ struct i915_psr {
bool sink_support;
struct intel_dp *enabled;
bool active;
- struct delayed_work work;
+ struct work_struct work;
unsigned busy_frontbuffer_bits;
bool sink_psr2_support;
bool link_standby;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 71dfe541740f..ef0f4741a95d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -671,21 +671,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
dev_priv->psr.enable_source(intel_dp, crtc_state);
dev_priv->psr.enabled = intel_dp;
- if (INTEL_GEN(dev_priv) >= 9) {
- intel_psr_activate(intel_dp);
- } else {
- /*
-* FIXME: Activation should happen immediately since this
-* function is just called after pipe is fully trained and
-* enabled.
-* However on some platforms we face issues when first
-* activation follows a modeset so quickly.
-* - On HSW/BDW we get a recoverable frozen screen until
-* next exit-activate sequence.
-*/
- schedule_delayed_work(&dev_priv->psr.work,
-
msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
- }
+ intel_psr_activate(intel_dp);
unlock:
mutex_unlock(&dev_priv->psr.lock);
@@ -768,8 +754,6 @@ void intel_psr_disable(struct intel_dp *intel_dp,
dev_priv->psr.enabled = NULL;
mutex_unlock(&dev_priv->psr.lock);
-
- cancel_delayed_work_sync(&dev_priv->psr.work);
}
static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
@@ -805,10 +789,13 @@ static bool psr_wait_for_idle(struct drm_i915_private
*dev_priv)
static void intel_psr_work(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
- container_of(work, typeof(*dev_priv), psr.work.work);
+ container_of(work, typeof(*dev_priv), psr.work);
mutex_lock(&dev_priv->psr.lock);
+ if (!dev_priv->psr.enabled)
+ goto unlock;
+
/*
* We have to make sure PSR is ready for re-enable
* otherwise it keeps disabled until next full enable/disable cycle.
@@ -949,9 +936,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
}
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
- if (!work_busy(&dev_priv->psr.work.work))
- schedule_delayed_work(&dev_priv->psr.work,
- msecs_to_jiffies(100));
Re: [Intel-gfx] [CI 1/2] drm/i915/icl: Add allowed DP rates for Icelake
Em Ter, 2018-06-12 às 11:37 -0700, Manasi Navare escreveu:
> On Tue, Jun 12, 2018 at 03:15:53PM +0300, Ville Syrjälä wrote:
> > On Mon, Jun 11, 2018 at 03:26:54PM -0700, Paulo Zanoni wrote:
> > > From: Manasi Navare
> > >
> > > For ICL, on Combo PHY the allowed max rates are:
> > > - HBR3 8.1 eDP (DDIA)
> > > - HBR2 5.4 DisplayPort (DDIB)
> > > and for MG PHY/TC DDI Ports allowed DP rates are:
> > > - HBR3 8.1 DisplayPort (DP alternate mode, DP over TBT,
> > > - DP on legacy connector - DDIC/D/E/F)
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Jani Nikula
> > > Reviewed-by: James Ausmus
> > > Signed-off-by: Manasi Navare
> > > Signed-off-by: James Ausmus
> > > [Paulo: bikeshed to keep future platforms on "else".]
> > > Signed-off-by: Paulo Zanoni
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 21 +++--
> > > 1 file changed, 19 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 37b9f62aeb6e..8371159cc192 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -256,6 +256,20 @@ static int cnl_max_source_rate(struct
> > > intel_dp *intel_dp)
> > > return 81;
> > > }
> > >
> > > +static int icl_max_source_rate(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_digital_port *dig_port =
> > > dp_to_dig_port(intel_dp);
> > > + enum port port = dig_port->base.port;
> > > +
> > > + /* On Combo PHY port A max speed is HBR3 for all Vccio
> > > voltages
> > > + * and on Combo PHY Port B the maximum supported is
> > > HBR2.
> > > + */
> >
> > And what about the other ports? If port B is the only
> > exception why are we even discussing port A specifically
> > here?
>
> All the MG PHY ports (C/D/E/F) support a max of HBR3 that is 81
> but for
> Combo PHY ports which is Port A or B, HBR3 only supported for Port A
> but for Port B it is max of HBR2 which is 54 hence the comment
> for Combo PHY
> ports and if port B then just return HBR2
I think Ville's point was that having a comment that only discusses
ports A and B on code that handles all ports gives the impression that
perhaps the code is "forgetting" to consider the other ports, or
something like that. Which makes sense to me.
Perhaps to address this issue we could either reword the comment to
include C-F or simply just remove it, since the commit message should
be enough and the comment only says what the code says.
>
> Manasi
>
> >
> > > + if (port == PORT_B)
> > > + return 54;
> > > +
> > > + return 81;
> > > +}
> > > +
> > > static void
> > > intel_dp_set_source_rates(struct intel_dp *intel_dp)
> > > {
> > > @@ -285,10 +299,13 @@ intel_dp_set_source_rates(struct intel_dp
> > > *intel_dp)
> > > /* This should only be done once */
> > > WARN_ON(intel_dp->source_rates || intel_dp-
> > > >num_source_rates);
> > >
> > > - if (IS_CANNONLAKE(dev_priv)) {
> > > + if (INTEL_GEN(dev_priv) >= 10) {
> > > source_rates = cnl_rates;
> > > size = ARRAY_SIZE(cnl_rates);
> > > - max_rate = cnl_max_source_rate(intel_dp);
> > > + if (INTEL_GEN(dev_priv) == 10)
> > > + max_rate =
> > > cnl_max_source_rate(intel_dp);
> > > + else
> > > + max_rate =
> > > icl_max_source_rate(intel_dp);
> > > } else if (IS_GEN9_LP(dev_priv)) {
> > > source_rates = bxt_rates;
> > > size = ARRAY_SIZE(bxt_rates);
> > > --
> > > 2.14.4
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Ville Syrjälä
> > Intel
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> ___
> Intel-gfx 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 v3 4/7] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
On Tue, 2018-06-05 at 22:45 +, Souza, Jose wrote:
> On Tue, 2018-05-22 at 16:58 -0700, Dhinakaran Pandiyan wrote:
> >
> > On Thu, 2018-05-17 at 15:21 -0700, José Roberto de Souza wrote:
> > >
> > > eDP spec states that sink device will do a short pulse in HPD
> > > line when there is a PSR/PSR2 error that needs to be handled by
> > > source, this is handling the first and most simples error:
> > > DP_PSR_SINK_INTERNAL_ERROR.
> > >
> > > Here taking the safest approach and disabling PSR(at least until
> > > the next modeset), to avoid multiple rendering issues due to
> > > bad pannels.
> > >
> > > v3:
> > > disabling PSR instead of exiting on error
> > >
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Rodrigo Vivi
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 2 ++
> > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_psr.c | 62 +-
> > > --
> > > --
> > > --
> > > 3 files changed, 52 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index b86da48fd38e..fa2851d4fb36 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4479,6 +4479,8 @@ intel_dp_short_pulse(struct intel_dp
> > > *intel_dp)
> > > if (intel_dp_needs_link_retrain(intel_dp))
> > > return false;
> > >
> > > + intel_psr_short_pulse(intel_dp);
> > > +
> > > if (intel_dp->compliance.test_type ==
> > > DP_TEST_LINK_TRAINING)
> > > {
> > > DRM_DEBUG_KMS("Link Training Compliance Test
> > > requested\n");
> > > /* Send a Hotplug Uevent to userspace to start
> > > modeset */
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 4508be628450..892da65358e9 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1921,6 +1921,7 @@ void intel_psr_compute_config(struct
> > > intel_dp
> > > *intel_dp,
> > > struct intel_crtc_state
> > > *crtc_state);
> > > void intel_psr_irq_control(struct drm_i915_private *dev_priv,
> > > bool
> > > debug);
> > > void intel_psr_irq_handler(struct drm_i915_private *dev_priv,
> > > u32
> > > psr_iir);
> > > +void intel_psr_short_pulse(struct intel_dp *intel_dp);
> > >
> > > /* intel_runtime_pm.c */
> > > int intel_power_domains_init(struct drm_i915_private *);
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index d88799482875..60797c8f9f0e 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -741,6 +741,23 @@ static void hsw_psr_disable(struct intel_dp
> > > *intel_dp)
> > > psr_aux_io_power_put(intel_dp);
> > > }
> > >
> > > +static void psr_disable(struct intel_dp *intel_dp)
nit: How about __psr_disable()? Might be worth checking other files
what the right convention is.
> > > +{+ struct intel_digital_port *intel_dig_port =
> > > dp_to_dig_port(intel_dp);
> > > + struct drm_device *dev = intel_dig_port->base.base.dev;
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > +
> > > + if (!dev_priv->psr.enabled)
> > > + return;
> > > +
> > > + dev_priv->psr.disable_source(intel_dp);
> > > +
> > > + /* Disable PSR on Sink */
> > > + drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, 0);
> > > + dev_priv->psr.enabled = NULL;
> > > + cancel_delayed_work_sync(&dev_priv->psr.work);
> > > +}
> > > +
> > > /**
> > > * intel_psr_disable - Disable PSR
> > > * @intel_dp: Intel DP
> > > @@ -762,20 +779,8 @@ void intel_psr_disable(struct intel_dp
> > > *intel_dp,
> > > return;
> > >
> > > mutex_lock(&dev_priv->psr.lock);
> > > - if (!dev_priv->psr.enabled) {
> > > - mutex_unlock(&dev_priv->psr.lock);
> > > - return;
> > > - }
> > > -
> > > - dev_priv->psr.disable_source(intel_dp);
> > > -
> > > - /* Disable PSR on Sink */
> > > - drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, 0);
> > > -
> > > - dev_priv->psr.enabled = NULL;
> > > + psr_disable(intel_dp);
> > > mutex_unlock(&dev_priv->psr.lock);
> > > -
> > > - cancel_delayed_work_sync(&dev_priv->psr.work);
> > > }
> > >
> > > static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
> > > @@ -1014,3 +1019,34 @@ void intel_psr_init(struct
> > > drm_i915_private
> > > *dev_priv)
> > > dev_priv->psr.setup_vsc = hsw_psr_setup_vsc;
> > >
> > > }
> > > +
> > > +void intel_psr_short_pulse(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_digital_port *intel_dig_port =
> > > dp_to_dig_port(intel_dp);
> > > + struct drm_device *dev = intel_dig_port->base.base.dev;
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > + struct i915_psr *psr = &dev_priv->psr;
> > > + uint8_t val;
> > > +
> > > + if (!HAS_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
> > > + return;
> > CAN_PSR(dev_priv)
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Kill delays when activating psr back.
== Series Details == Series: drm/i915/psr: Kill delays when activating psr back. URL : https://patchwork.freedesktop.org/series/44715/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4311 -> Patchwork_9294 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9294 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9294, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44715/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9294: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9294 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106725, fdo#106248) igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128) igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) Possible fixes igt@gem_ctx_create@basic-files: fi-glk-j4005: DMESG-WARN (fdo#105719) -> PASS igt@gem_exec_gttfill@basic: fi-byt-n2820: FAIL (fdo#106744) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan == Build changes == * Linux: CI_DRM_4311 -> Patchwork_9294 CI_DRM_4311: 875eebee4a444f5b7ba146754e91118ff3c11ad5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4518: e4908004547b63131352fbc0ddcdb1d3d55480e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9294: 5191095d6bf24d10318f10ed6e2a01287730ae32 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5191095d6bf2 drm/i915/psr: Kill delays when activating psr back. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9294/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/7] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
On Wed, 2018-06-13 at 13:17 -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2018-06-05 at 22:45 +, Souza, Jose wrote:
> > On Tue, 2018-05-22 at 16:58 -0700, Dhinakaran Pandiyan wrote:
> > >
> > > On Thu, 2018-05-17 at 15:21 -0700, José Roberto de Souza wrote:
> > > >
> > > > eDP spec states that sink device will do a short pulse in HPD
> > > > line when there is a PSR/PSR2 error that needs to be handled by
> > > > source, this is handling the first and most simples error:
> > > > DP_PSR_SINK_INTERNAL_ERROR.
> > > >
> > > > Here taking the safest approach and disabling PSR(at least
> > > > until
> > > > the next modeset), to avoid multiple rendering issues due to
> > > > bad pannels.
> > > >
> > > > v3:
> > > > disabling PSR instead of exiting on error
> > > >
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Rodrigo Vivi
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 2 ++
> > > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > > drivers/gpu/drm/i915/intel_psr.c | 62
> > > > +-
> > > > --
> > > > --
> > > > --
> > > > 3 files changed, 52 insertions(+), 13 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index b86da48fd38e..fa2851d4fb36 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -4479,6 +4479,8 @@ intel_dp_short_pulse(struct intel_dp
> > > > *intel_dp)
> > > > if (intel_dp_needs_link_retrain(intel_dp))
> > > > return false;
> > > >
> > > > + intel_psr_short_pulse(intel_dp);
> > > > +
> > > > if (intel_dp->compliance.test_type ==
> > > > DP_TEST_LINK_TRAINING)
> > > > {
> > > > DRM_DEBUG_KMS("Link Training Compliance Test
> > > > requested\n");
> > > > /* Send a Hotplug Uevent to userspace to start
> > > > modeset */
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 4508be628450..892da65358e9 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -1921,6 +1921,7 @@ void intel_psr_compute_config(struct
> > > > intel_dp
> > > > *intel_dp,
> > > > struct intel_crtc_state
> > > > *crtc_state);
> > > > void intel_psr_irq_control(struct drm_i915_private *dev_priv,
> > > > bool
> > > > debug);
> > > > void intel_psr_irq_handler(struct drm_i915_private *dev_priv,
> > > > u32
> > > > psr_iir);
> > > > +void intel_psr_short_pulse(struct intel_dp *intel_dp);
> > > >
> > > > /* intel_runtime_pm.c */
> > > > int intel_power_domains_init(struct drm_i915_private *);
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index d88799482875..60797c8f9f0e 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -741,6 +741,23 @@ static void hsw_psr_disable(struct
> > > > intel_dp
> > > > *intel_dp)
> > > > psr_aux_io_power_put(intel_dp);
> > > > }
> > > >
> > > > +static void psr_disable(struct intel_dp *intel_dp)
>
> nit: How about __psr_disable()? Might be worth checking other files
> what the right convention is.
It varies from file to file but inside of intel_psr.c we are not adding
"__" so better keep that, right?
>
> > > > +{+ struct intel_digital_port *intel_dig_port =
> > > > dp_to_dig_port(intel_dp);
> > > > + struct drm_device *dev = intel_dig_port-
> > > > >base.base.dev;
> > > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > > +
> > > > + if (!dev_priv->psr.enabled)
> > > > + return;
> > > > +
> > > > + dev_priv->psr.disable_source(intel_dp);
> > > > +
> > > > + /* Disable PSR on Sink */
> > > > + drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, 0);
> > > > + dev_priv->psr.enabled = NULL;
> > > > + cancel_delayed_work_sync(&dev_priv->psr.work);
> > > > +}
> > > > +
> > > > /**
> > > > * intel_psr_disable - Disable PSR
> > > > * @intel_dp: Intel DP
> > > > @@ -762,20 +779,8 @@ void intel_psr_disable(struct intel_dp
> > > > *intel_dp,
> > > > return;
> > > >
> > > > mutex_lock(&dev_priv->psr.lock);
> > > > - if (!dev_priv->psr.enabled) {
> > > > - mutex_unlock(&dev_priv->psr.lock);
> > > > - return;
> > > > - }
> > > > -
> > > > - dev_priv->psr.disable_source(intel_dp);
> > > > -
> > > > - /* Disable PSR on Sink */
> > > > - drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, 0);
> > > > -
> > > > - dev_priv->psr.enabled = NULL;
> > > > + psr_disable(intel_dp);
> > > > mutex_unlock(&dev_priv->psr.lock);
> > > > -
> > > > - cancel_delayed_work_sync(&dev_priv->psr.work);
> > > > }
> > > >
> > > > static bool psr_wait_for_idle(struct drm_i915_private
> > > > *dev_priv
Re: [Intel-gfx] [CI 1/2] drm/i915/icl: Add allowed DP rates for Icelake
On Wed, Jun 13, 2018 at 12:42:20PM -0700, Paulo Zanoni wrote:
> Em Ter, 2018-06-12 às 11:37 -0700, Manasi Navare escreveu:
> > On Tue, Jun 12, 2018 at 03:15:53PM +0300, Ville Syrjälä wrote:
> > > On Mon, Jun 11, 2018 at 03:26:54PM -0700, Paulo Zanoni wrote:
> > > > From: Manasi Navare
> > > >
> > > > For ICL, on Combo PHY the allowed max rates are:
> > > > - HBR3 8.1 eDP (DDIA)
> > > > - HBR2 5.4 DisplayPort (DDIB)
> > > > and for MG PHY/TC DDI Ports allowed DP rates are:
> > > > - HBR3 8.1 DisplayPort (DP alternate mode, DP over TBT,
> > > > - DP on legacy connector - DDIC/D/E/F)
> > > >
> > > > Cc: Rodrigo Vivi
> > > > Cc: Jani Nikula
> > > > Reviewed-by: James Ausmus
> > > > Signed-off-by: Manasi Navare
> > > > Signed-off-by: James Ausmus
> > > > [Paulo: bikeshed to keep future platforms on "else".]
> > > > Signed-off-by: Paulo Zanoni
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 21 +++--
> > > > 1 file changed, 19 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 37b9f62aeb6e..8371159cc192 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -256,6 +256,20 @@ static int cnl_max_source_rate(struct
> > > > intel_dp *intel_dp)
> > > > return 81;
> > > > }
> > > >
> > > > +static int icl_max_source_rate(struct intel_dp *intel_dp)
> > > > +{
> > > > + struct intel_digital_port *dig_port =
> > > > dp_to_dig_port(intel_dp);
> > > > + enum port port = dig_port->base.port;
> > > > +
> > > > + /* On Combo PHY port A max speed is HBR3 for all Vccio
> > > > voltages
> > > > +* and on Combo PHY Port B the maximum supported is
> > > > HBR2.
> > > > +*/
> > >
> > > And what about the other ports? If port B is the only
> > > exception why are we even discussing port A specifically
> > > here?
> >
> > All the MG PHY ports (C/D/E/F) support a max of HBR3 that is 81
> > but for
> > Combo PHY ports which is Port A or B, HBR3 only supported for Port A
> > but for Port B it is max of HBR2 which is 54 hence the comment
> > for Combo PHY
> > ports and if port B then just return HBR2
>
> I think Ville's point was that having a comment that only discusses
> ports A and B on code that handles all ports gives the impression that
> perhaps the code is "forgetting" to consider the other ports, or
> something like that. Which makes sense to me.
>
> Perhaps to address this issue we could either reword the comment to
> include C-F or simply just remove it, since the commit message should
> be enough and the comment only says what the code says.
>
Yes I agree. Lets remove the comment in the code since the commit message
covers that part.
Should I send a new revision for this with comment removed?
Manasi
> >
> > Manasi
> >
> > >
> > > > + if (port == PORT_B)
> > > > + return 54;
> > > > +
> > > > + return 81;
> > > > +}
> > > > +
> > > > static void
> > > > intel_dp_set_source_rates(struct intel_dp *intel_dp)
> > > > {
> > > > @@ -285,10 +299,13 @@ intel_dp_set_source_rates(struct intel_dp
> > > > *intel_dp)
> > > > /* This should only be done once */
> > > > WARN_ON(intel_dp->source_rates || intel_dp-
> > > > >num_source_rates);
> > > >
> > > > - if (IS_CANNONLAKE(dev_priv)) {
> > > > + if (INTEL_GEN(dev_priv) >= 10) {
> > > > source_rates = cnl_rates;
> > > > size = ARRAY_SIZE(cnl_rates);
> > > > - max_rate = cnl_max_source_rate(intel_dp);
> > > > + if (INTEL_GEN(dev_priv) == 10)
> > > > + max_rate =
> > > > cnl_max_source_rate(intel_dp);
> > > > + else
> > > > + max_rate =
> > > > icl_max_source_rate(intel_dp);
> > > > } else if (IS_GEN9_LP(dev_priv)) {
> > > > source_rates = bxt_rates;
> > > > size = ARRAY_SIZE(bxt_rates);
> > > > --
> > > > 2.14.4
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > ___
> > Intel-gfx 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] [CI 1/2] drm/i915/icl: Add allowed DP rates for Icelake
Em Qua, 2018-06-13 às 13:15 -0700, Manasi Navare escreveu:
> On Wed, Jun 13, 2018 at 12:42:20PM -0700, Paulo Zanoni wrote:
> > Em Ter, 2018-06-12 às 11:37 -0700, Manasi Navare escreveu:
> > > On Tue, Jun 12, 2018 at 03:15:53PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Jun 11, 2018 at 03:26:54PM -0700, Paulo Zanoni wrote:
> > > > > From: Manasi Navare
> > > > >
> > > > > For ICL, on Combo PHY the allowed max rates are:
> > > > > - HBR3 8.1 eDP (DDIA)
> > > > > - HBR2 5.4 DisplayPort (DDIB)
> > > > > and for MG PHY/TC DDI Ports allowed DP rates are:
> > > > > - HBR3 8.1 DisplayPort (DP alternate mode, DP over TBT,
> > > > > - DP on legacy connector - DDIC/D/E/F)
> > > > >
> > > > > Cc: Rodrigo Vivi
> > > > > Cc: Jani Nikula
> > > > > Reviewed-by: James Ausmus
> > > > > Signed-off-by: Manasi Navare
> > > > > Signed-off-by: James Ausmus
> > > > > [Paulo: bikeshed to keep future platforms on "else".]
> > > > > Signed-off-by: Paulo Zanoni
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_dp.c | 21 +++--
> > > > > 1 file changed, 19 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 37b9f62aeb6e..8371159cc192 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -256,6 +256,20 @@ static int cnl_max_source_rate(struct
> > > > > intel_dp *intel_dp)
> > > > > return 81;
> > > > > }
> > > > >
> > > > > +static int icl_max_source_rate(struct intel_dp *intel_dp)
> > > > > +{
> > > > > + struct intel_digital_port *dig_port =
> > > > > dp_to_dig_port(intel_dp);
> > > > > + enum port port = dig_port->base.port;
> > > > > +
> > > > > + /* On Combo PHY port A max speed is HBR3 for all
> > > > > Vccio
> > > > > voltages
> > > > > + * and on Combo PHY Port B the maximum supported is
> > > > > HBR2.
> > > > > + */
> > > >
> > > > And what about the other ports? If port B is the only
> > > > exception why are we even discussing port A specifically
> > > > here?
> > >
> > > All the MG PHY ports (C/D/E/F) support a max of HBR3 that is
> > > 81
> > > but for
> > > Combo PHY ports which is Port A or B, HBR3 only supported for
> > > Port A
> > > but for Port B it is max of HBR2 which is 54 hence the
> > > comment
> > > for Combo PHY
> > > ports and if port B then just return HBR2
> >
> > I think Ville's point was that having a comment that only discusses
> > ports A and B on code that handles all ports gives the impression
> > that
> > perhaps the code is "forgetting" to consider the other ports, or
> > something like that. Which makes sense to me.
> >
> > Perhaps to address this issue we could either reword the comment to
> > include C-F or simply just remove it, since the commit message
> > should
> > be enough and the comment only says what the code says.
> >
>
> Yes I agree. Lets remove the comment in the code since the commit
> message
> covers that part.
> Should I send a new revision for this with comment removed?
Feel free to do it, otherwise I can do it while applying since it's a
trivial change.
Thanks,
Paulo
>
> Manasi
>
> > >
> > > Manasi
> > >
> > > >
> > > > > + if (port == PORT_B)
> > > > > + return 54;
> > > > > +
> > > > > + return 81;
> > > > > +}
> > > > > +
> > > > > static void
> > > > > intel_dp_set_source_rates(struct intel_dp *intel_dp)
> > > > > {
> > > > > @@ -285,10 +299,13 @@ intel_dp_set_source_rates(struct
> > > > > intel_dp
> > > > > *intel_dp)
> > > > > /* This should only be done once */
> > > > > WARN_ON(intel_dp->source_rates || intel_dp-
> > > > > > num_source_rates);
> > > > >
> > > > >
> > > > > - if (IS_CANNONLAKE(dev_priv)) {
> > > > > + if (INTEL_GEN(dev_priv) >= 10) {
> > > > > source_rates = cnl_rates;
> > > > > size = ARRAY_SIZE(cnl_rates);
> > > > > - max_rate = cnl_max_source_rate(intel_dp);
> > > > > + if (INTEL_GEN(dev_priv) == 10)
> > > > > + max_rate =
> > > > > cnl_max_source_rate(intel_dp);
> > > > > + else
> > > > > + max_rate =
> > > > > icl_max_source_rate(intel_dp);
> > > > > } else if (IS_GEN9_LP(dev_priv)) {
> > > > > source_rates = bxt_rates;
> > > > > size = ARRAY_SIZE(bxt_rates);
> > > > > --
> > > > > 2.14.4
> > > > >
> > > > > ___
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > ___
> > > In
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Disallow interlaced modes on g4x DP outputs
== Series Details == Series: series starting with [1/2] drm/i915: Disallow interlaced modes on g4x DP outputs URL : https://patchwork.freedesktop.org/series/44705/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4310_full -> Patchwork_9288_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9288_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9288_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9288_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +1 igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS igt@pm_rc6_residency@rc6-accuracy: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9288_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560) igt@gem_wait@await-bsd2: shard-snb: SKIP -> INCOMPLETE (fdo#105411) igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#102887) igt@kms_flip@dpms-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@perf@blocking: shard-hsw: PASS -> FAIL (fdo#102252) Possible fixes igt@drv_selftest@live_gtt: shard-glk: FAIL (fdo#105347) -> PASS igt@drv_selftest@live_hangcheck: shard-apl: DMESG-FAIL (fdo#106560) -> PASS igt@drv_suspend@shrink: shard-snb: FAIL -> PASS igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +2 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4310 -> Patchwork_9288 CI_DRM_4310: 5945ab6707472bde0c3bc12836252b487ecfeb72 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4518: e4908004547b63131352fbc0ddcdb1d3d55480e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9288: 7cb1506cc8c1032620b14ac2d4c196a65d0bfd1e @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9288/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/24] drm/i915/icl: compute the TBT PLL registers
Em Sex, 2018-06-08 às 13:19 -0700, Srivatsa, Anusha escreveu:
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > Behalf Of
> > Paulo Zanoni
> > Sent: Monday, May 21, 2018 5:26 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Zanoni, Paulo R
> > Subject: [Intel-gfx] [PATCH 15/24] drm/i915/icl: compute the TBT
> > PLL registers
> >
> > Use the hardcoded tables provided by our spec.
> >
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/intel_dpll_mgr.c | 25
> > -
> > 1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index 72f15e727d07..8a34733de1ea 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -2452,6 +2452,16 @@ static const struct skl_wrpll_params
> > icl_dp_combo_pll_19_2MHz_values[] = {
> > .pdiv = 0x1 /* 2 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio =
> > 0}, };
> >
> > +static const struct skl_wrpll_params icl_tbt_pll_24MHz_values = {
> > + .dco_integer = 0x151, .dco_fraction = 0x4000,
> > + .pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0,
> > .qdiv_ratio = 0, };
> > +
> > +static const struct skl_wrpll_params icl_tbt_pll_19_2MHz_values =
> > {
> > + .dco_integer = 0x1A5, .dco_fraction = 0x7000,
> > + .pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0,
> > .qdiv_ratio = 0, };
> > +
> > static bool icl_calc_dp_combo_pll(struct drm_i915_private
> > *dev_priv, int clock,
> > struct skl_wrpll_params
> > *pll_params) { @@ -
> > 2494,6 +2504,14 @@ static bool icl_calc_dp_combo_pll(struct
> > drm_i915_private
> > *dev_priv, int clock,
> > return true;
> > }
> >
> > +static bool icl_calc_tbt_pll(struct drm_i915_private *dev_priv,
> > int clock,
> > +struct skl_wrpll_params *pll_params)
> > {
> > + *pll_params = dev_priv->cdclk.hw.ref == 24000 ?
> > + icl_tbt_pll_24MHz_values :
> > icl_tbt_pll_19_2MHz_values;
> > + return true;
> > +}
> > +
> > static bool icl_calc_dpll_state(struct intel_crtc_state
> > *crtc_state,
> > struct intel_encoder *encoder, int
> > clock,
> > struct intel_dpll_hw_state *pll_state)
> > @@ -
> > 2501,9 +2519,12 @@ static bool icl_calc_dpll_state(struct
> > intel_crtc_state
> > *crtc_state,
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > uint32_t cfgcr0, cfgcr1;
> > struct skl_wrpll_params pll_params = { 0 };
> > + bool is_tbt = encoder->port >= PORT_C;
> > bool ret;
> >
> > - if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> > + if (is_tbt)
> > + ret = icl_calc_tbt_pll(dev_priv, clock,
> > &pll_params);
> > + else if (intel_crtc_has_type(crtc_state,
> > INTEL_OUTPUT_HDMI))
> > ret = cnl_ddi_calculate_wrpll(clock, dev_priv,
> > &pll_params);
> > else
> > ret = icl_calc_dp_combo_pll(dev_priv, clock,
> > &pll_params); @@ -
> > 2513,6 +2534,8 @@ static bool icl_calc_dpll_state(struct
> > intel_crtc_state
> > *crtc_state,
> >
> > cfgcr0 = DPLL_CFGCR0_DCO_FRACTION(pll_params.dco_fraction) |
> > pll_params.dco_integer;
> > + if (is_tbt)
> > + cfgcr0 |= DPLL_CFGCR0_SSC_ENABLE_ICL;
>
> Paulo,
> TBT has some TBT specific CFGCR0 registers which needs to be
> configured here.
I did recheck the spec and it says to disable SSC, so the line above is
clearly wrong (did it change since I wrote it?), but I don't see
anything we're failing to set on CFGCR0. Can you please clarify what
you think is missing? Maybe you're referring to something that's on
patch 14?
Thanks,
Paulo
>
> Anusha
> > cfgcr1 = DPLL_CFGCR1_QDIV_RATIO(pll_params.qdiv_ratio) |
> > DPLL_CFGCR1_QDIV_MODE(pll_params.qdiv_mode) |
> > --
> > 2.14.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/7] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
On Wed, 2018-06-13 at 20:02 +, Souza, Jose wrote:
> On Wed, 2018-06-13 at 13:17 -0700, Dhinakaran Pandiyan wrote:
> >
> > On Tue, 2018-06-05 at 22:45 +, Souza, Jose wrote:
> > >
> > > On Tue, 2018-05-22 at 16:58 -0700, Dhinakaran Pandiyan wrote:
> > > >
> > > >
> > > > On Thu, 2018-05-17 at 15:21 -0700, José Roberto de Souza wrote:
> > > > >
> > > > >
> > > > > eDP spec states that sink device will do a short pulse in HPD
> > > > > line when there is a PSR/PSR2 error that needs to be handled
> > > > > by
> > > > > source, this is handling the first and most simples error:
> > > > > DP_PSR_SINK_INTERNAL_ERROR.
> > > > >
> > > > > Here taking the safest approach and disabling PSR(at least
> > > > > until
> > > > > the next modeset), to avoid multiple rendering issues due to
> > > > > bad pannels.
> > > > >
> > > > > v3:
> > > > > disabling PSR instead of exiting on error
> > > > >
> > > > > Cc: Dhinakaran Pandiyan
> > > > > Cc: Rodrigo Vivi
> > > > > Signed-off-by: José Roberto de Souza
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_dp.c | 2 ++
> > > > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > > > drivers/gpu/drm/i915/intel_psr.c | 62
> > > > > +-
> > > > > --
> > > > > --
> > > > > --
> > > > > 3 files changed, 52 insertions(+), 13 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index b86da48fd38e..fa2851d4fb36 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -4479,6 +4479,8 @@ intel_dp_short_pulse(struct intel_dp
> > > > > *intel_dp)
> > > > > if (intel_dp_needs_link_retrain(intel_dp))
> > > > > return false;
> > > > >
> > > > > + intel_psr_short_pulse(intel_dp);
> > > > > +
> > > > > if (intel_dp->compliance.test_type ==
> > > > > DP_TEST_LINK_TRAINING)
> > > > > {
> > > > > DRM_DEBUG_KMS("Link Training Compliance Test
> > > > > requested\n");
> > > > > /* Send a Hotplug Uevent to userspace to
> > > > > start
> > > > > modeset */
> > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > > index 4508be628450..892da65358e9 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > > @@ -1921,6 +1921,7 @@ void intel_psr_compute_config(struct
> > > > > intel_dp
> > > > > *intel_dp,
> > > > > struct intel_crtc_state
> > > > > *crtc_state);
> > > > > void intel_psr_irq_control(struct drm_i915_private
> > > > > *dev_priv,
> > > > > bool
> > > > > debug);
> > > > > void intel_psr_irq_handler(struct drm_i915_private
> > > > > *dev_priv,
> > > > > u32
> > > > > psr_iir);
> > > > > +void intel_psr_short_pulse(struct intel_dp *intel_dp);
> > > > >
> > > > > /* intel_runtime_pm.c */
> > > > > int intel_power_domains_init(struct drm_i915_private *);
> > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > > index d88799482875..60797c8f9f0e 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > > @@ -741,6 +741,23 @@ static void hsw_psr_disable(struct
> > > > > intel_dp
> > > > > *intel_dp)
> > > > > psr_aux_io_power_put(intel_dp);
> > > > > }
> > > > >
> > > > > +static void psr_disable(struct intel_dp *intel_dp)
> > nit: How about __psr_disable()? Might be worth checking other files
> > what the right convention is.
> It varies from file to file but inside of intel_psr.c we are not
> adding
> "__" so better keep that, right?
Sure, either way is okay with me.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 15/24] drm/i915/icl: compute the TBT PLL registers
Use the hardcoded tables provided by our spec.
v2:
- SSC stays disabled.
- Use intel_port_is_tc().
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 132fe63e042a..205cc723fb26 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2452,6 +2452,16 @@ static const struct skl_wrpll_params
icl_dp_combo_pll_19_2MHz_values[] = {
.pdiv = 0x1 /* 2 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
};
+static const struct skl_wrpll_params icl_tbt_pll_24MHz_values = {
+ .dco_integer = 0x151, .dco_fraction = 0x4000,
+ .pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0,
+};
+
+static const struct skl_wrpll_params icl_tbt_pll_19_2MHz_values = {
+ .dco_integer = 0x1A5, .dco_fraction = 0x7000,
+ .pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0,
+};
+
static bool icl_calc_dp_combo_pll(struct drm_i915_private *dev_priv, int clock,
struct skl_wrpll_params *pll_params)
{
@@ -2494,6 +2504,14 @@ static bool icl_calc_dp_combo_pll(struct
drm_i915_private *dev_priv, int clock,
return true;
}
+static bool icl_calc_tbt_pll(struct drm_i915_private *dev_priv, int clock,
+struct skl_wrpll_params *pll_params)
+{
+ *pll_params = dev_priv->cdclk.hw.ref == 24000 ?
+ icl_tbt_pll_24MHz_values : icl_tbt_pll_19_2MHz_values;
+ return true;
+}
+
static bool icl_calc_dpll_state(struct intel_crtc_state *crtc_state,
struct intel_encoder *encoder, int clock,
struct intel_dpll_hw_state *pll_state)
@@ -2503,7 +2521,9 @@ static bool icl_calc_dpll_state(struct intel_crtc_state
*crtc_state,
struct skl_wrpll_params pll_params = { 0 };
bool ret;
- if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ if (intel_port_is_tc(dev_priv, encoder->port))
+ ret = icl_calc_tbt_pll(dev_priv, clock, &pll_params);
+ else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
ret = cnl_ddi_calculate_wrpll(clock, dev_priv, &pll_params);
else
ret = icl_calc_dp_combo_pll(dev_priv, clock, &pll_params);
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH V2] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
From: Clint Taylor
On GLK NUC platforms the HDMI retiming buffer needs additional disabled
time to correctly sync to a faster incoming signal.
When measured on a scope the highspeed lines of the HDMI clock turn off
for ~400uS during a normal resolution change. The HDMI retimer on the
GLK NUC appears to require at least a full frame of quiet time before a
new faster clock can be correctly sync'd. The worst case scenario appears
to be 23.98Hz modes which requires a wait of 41.25ms. Add a quirk to the
driver for GLK NUC that waits 42ms.
V2: Add more devices to the quirk list
Cc: Imre Deak
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 8
drivers/gpu/drm/i915/intel_display.c | 19 +++
3 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be8c2f0..da196b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -656,6 +656,7 @@ enum intel_sbi_destination {
#define QUIRK_BACKLIGHT_PRESENT (1<<3)
#define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
#define QUIRK_INCREASE_T12_DELAY (1<<6)
+#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ca73387..bc3d012 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1791,6 +1791,9 @@ void intel_ddi_enable_transcoder_func(const struct
intel_crtc_state *crtc_state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
}
+/* Quirk time computed based on 24fps frame time of 41.25ms */
+#define DDI_DISABLED_QUIRK_TIME 42
+
void intel_ddi_disable_transcoder_func(struct drm_i915_private *dev_priv,
enum transcoder cpu_transcoder)
{
@@ -1800,6 +1803,11 @@ void intel_ddi_disable_transcoder_func(struct
drm_i915_private *dev_priv,
val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK |
TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
val |= TRANS_DDI_PORT_NONE;
I915_WRITE(reg, val);
+
+ if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME) {
+ msleep(DDI_DISABLED_QUIRK_TIME);
+ DRM_DEBUG_KMS("Quirk Increase DDI disabled time\n");
+ }
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8251e18..40e0306 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14749,6 +14749,17 @@ static void quirk_increase_t12_delay(struct drm_device
*dev)
DRM_INFO("Applying T12 delay quirk\n");
}
+/* GeminiLake NUC HDMI outputs require additional off time
+ * this allows the onboard retimer to correctly sync to signal
+ */
+static void quirk_increase_ddi_disabled_time(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->quirks |= QUIRK_INCREASE_DDI_DISABLED_TIME;
+ DRM_INFO("Applying Increase DDI Disabled quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -14835,6 +14846,14 @@ static int intel_dmi_reverse_brightness(const struct
dmi_system_id *id)
/* Toshiba Satellite P50-C-18C */
{ 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
+
+ /* GeminiLake NUC */
+ { 0x3185, 0x8086, 0x2072, quirk_increase_ddi_disabled_time },
+ { 0x3184, 0x8086, 0x2072, quirk_increase_ddi_disabled_time },
+ /* ASRock ITX*/
+ { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
+ { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
+
};
static void intel_init_quirks(struct drm_device *dev)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for More ICL display patches (rev12)
== Series Details == Series: More ICL display patches (rev12) URL : https://patchwork.freedesktop.org/series/43546/ State : failure == Summary == Applying: drm/i915/icl: Extend AUX F interrupts to ICL Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_irq.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_irq.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_irq.c error: Failed to merge in the changes. Patch failed at 0001 drm/i915/icl: Extend AUX F interrupts to ICL Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev2)
== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev2) URL : https://patchwork.freedesktop.org/series/6/ State : warning == Summary == $ dim checkpatch origin/drm-tip 40e1ef81c43c drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. -:30: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #30: FILE: drivers/gpu/drm/i915/i915_drv.h:659: +#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7) ^ total: 0 errors, 0 warnings, 1 checks, 58 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev2)
== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev2) URL : https://patchwork.freedesktop.org/series/6/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. -drivers/gpu/drm/i915/selftests/../i915_drv.h:3681:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3682:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix HDMI infoframe setting (rev2)
== Series Details == Series: drm/i915/icl: Fix HDMI infoframe setting (rev2) URL : https://patchwork.freedesktop.org/series/44709/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4310_full -> Patchwork_9292_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9292_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9292_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9292_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP +1 igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9292_full that come from known issues: === IGT changes === Issues hit igt@gem_wait@await-bsd2: shard-snb: SKIP -> INCOMPLETE (fdo#105411) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: PASS -> FAIL (fdo#102887) igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) Possible fixes igt@drv_suspend@shrink: shard-snb: FAIL -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_flip@2x-plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS igt@kms_setmode@basic: shard-hsw: FAIL (fdo#99912) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: FAIL (fdo#105347) -> INCOMPLETE (k.org#198133, fdo#103359) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4310 -> Patchwork_9292 CI_DRM_4310: 5945ab6707472bde0c3bc12836252b487ecfeb72 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4518: e4908004547b63131352fbc0ddcdb1d3d55480e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9292: ad3a408add830019cdc9a2fc9c42e5936cfb257a @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9292/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915/guc: New interface files for GuC starting in Gen11
On 5/29/2018 7:59 AM, Michal Wajdeczko wrote:
Hi,
On Fri, 25 May 2018 23:59:35 +0200, Oscar Mateo
wrote:
GuC interface has been redesigned (or cleaned up, rather) starting
with Gen11, as a stepping stone towards a new branching strategy
that helps maintain backwards compatibility with previous Gens, as
well as sideward compatibility with other OSes.
The interface is split in two header files: one for the KMD and one
for clients of the GuC (which, in our case, happens to be the KMD
as well). SLPC interface files will come at a later date.
Could we get eyes on the new interface header files, to make sure the
GuC team is moving in the right direction?
Signed-off-by: Oscar Mateo
Cc: Joonas Lahtinen
Cc: Kevin Rogovin
Cc: John A Spotswood
Cc: Anusha Srivatsa
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Michel Thierry
Cc: Chris Wilson
Cc: Michał Winiarski
Cc: Tomasz Lis
Cc: Jon Ewins
Cc: Sujaritha Sundaresan
Cc: Jalpa Patel
Cc: Jackie Li
---
drivers/gpu/drm/i915/intel_guc_client_interface.h | 255 +++
drivers/gpu/drm/i915/intel_guc_kmd_interface.h | 847
++
2 files changed, 1102 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_guc_client_interface.h
create mode 100644 drivers/gpu/drm/i915/intel_guc_kmd_interface.h
can we name these files as:
drivers/gpu/drm/i915/intel_guc_interface.h
drivers/gpu/drm/i915/intel_guc_interface_client.h
or
drivers/gpu/drm/i915/intel_guc_defs.h
drivers/gpu/drm/i915/intel_guc_defs_client.h
or
drivers/gpu/drm/i915/guc/guc.h
drivers/gpu/drm/i915/guc/guc_client.h
I'm fine with any of these names.
diff --git a/drivers/gpu/drm/i915/intel_guc_client_interface.h
b/drivers/gpu/drm/i915/intel_guc_client_interface.h
new file mode 100644
index 000..1ef91a7
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_client_interface.h
@@ -0,0 +1,255 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef _INTEL_GUC_CLIENT_INTERFACE_H_
+#define _INTEL_GUC_CLIENT_INTERFACE_H_
+
need to include types.h for u32
Will do.
+#pragma pack(1)
+
+/*
+ ** Engines
**
+
*/
no fancy markups, please
Ok.
+
+#define GUC_MAX_ENGINE_INSTANCE_PER_CLASS 4
+#define GUC_MAX_SCHEDULABLE_ENGINE_CLASS 5
+#define GUC_MAX_ENGINE_CLASS_COUNT 6
+#define GUC_ENGINE_INVALID 6
hmm, why not 7 or 127 ?
maybe if we need value for INVALID we should use 0 or -1 (~0)
I'll pass this comment to the GuC team.
+
+/* Engine Class that uKernel can schedule on. This is just a SW
enumeration.
+ * HW configuration will depend on the Platform and SKU
+ */
+enum uk_engine_class {
why there is new prefix "uk" ?
uk stands for uKernel. In this case, I'm guessing it is used to
differentiate between the engine class defined by hardware vs. the one
defined by the uKernel.
+ UK_RENDER_ENGINE_CLASS = 0,
+ UK_VDECENC_ENGINE_CLASS = 1,
+ UK_VE_ENGINE_CLASS = 2,
+ UK_BLT_COPY_ENGINE_CLASS = 3,
+ UK_RESERVED_ENGINE_CLASS = 4,
+ UK_OTHER_ENGINE_CLASS = 5,
either use valid names or drop RESERVED/OTHER as values
from 0 to GUC_MAX_ENGINE_CLASS_COUNT are 'reserved' by
definition unless explicitly defined ;)
I'll drop them.
+};
as we don't use enum in binary struct definitions, then maybe we
should define all engine classes with #define as:
#define ENGINE_CLASS_INVALID 0
#define ENGINE_CLASS_ALL 0
#define ENGINE_CLASS_RENDER 1
#define ENGINE_CLASS_VDECENC 2
...
#define ENGINE_CLASS_MAX 7
I can pass this comment to the GuC team. Or we can use defines for the
Linux header files, but then we might start deviating again from a
common interface naming.
what if future HW will support more than 7 engine classes
or they will be so different that they deserve separate id?
why
I imagine that's what the reserved is for. I cannot think of many more
engine classes, but I probably lack imagination.
+
+/* Engine Instance that uKernel can schedule on */
+enum uk_engine_instance {
+ UK_ENGINE_INSTANCE_0 = 0,
+ UK_ENGINE_INSTANCE_1 = 1,
+ UK_ENGINE_INSTANCE_2 = 2,
+ UK_ENGINE_INSTANCE_3 = 3,
+ UK_INVALID_ENGINE_INSTANCE = GUC_MAX_ENGINE_INSTANCE_PER_CLASS,
+ UK_ENGINE_ALL_INSTANCES = UK_INVALID_ENGINE_INSTANCE
+};
I'm not sure why we would need this enum as we already have
GUC_MAX_ENGINE_INSTANCE_PER_CLASS and can easily identify
instance as [0 ... GUC_MAX_ENGINE_INSTANCE_PER_CLASS), or
maybe more intuitive would be use normal indexing and use 0
to indicate INVALID/AUTO/ALL instance ?
#define ENGINE_INSTANCE_INVALID 0
#define ENGINE_INSTANCE_ALL 0
#define ENGINE_INSTANCE_MAX 4
I can pass this comment along.
+
+/* Target Engine fiel
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev2)
== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev2) URL : https://patchwork.freedesktop.org/series/6/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4311 -> Patchwork_9296 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/6/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9296 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128) igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence: fi-glk-j4005: PASS -> FAIL (fdo#103481) Possible fixes igt@gem_ctx_create@basic-files: fi-glk-j4005: DMESG-WARN (fdo#105719) -> PASS igt@gem_exec_gttfill@basic: fi-byt-n2820: FAIL (fdo#106744) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-skl-6700hq: DMESG-WARN (fdo#105998) -> PASS +1 igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#105998 https://bugs.freedesktop.org/show_bug.cgi?id=105998 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan == Build changes == * Linux: CI_DRM_4311 -> Patchwork_9296 CI_DRM_4311: 875eebee4a444f5b7ba146754e91118ff3c11ad5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4518: e4908004547b63131352fbc0ddcdb1d3d55480e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9296: 40e1ef81c43c81cb2c4b0306dbf1b4705e5f4e76 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 40e1ef81c43c drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9296/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/24] drm/i915/icl: Support for TC North Display interrupts
+Chris
On Mon, May 21, 2018 at 05:25:38PM -0700, Paulo Zanoni wrote:
> From: Dhinakaran Pandiyan
>
> The hotplug interrupts for the ports can be routed to either North
> Display or South Display depending on the output mode. DP Alternate or
> DP over TBT outputs will have hotplug interrupts routed to the North
> Display while interrupts for legacy modes will be routed to the South
> Display in PCH. This patch adds hotplug interrupt handling support for
> DP Alternate mode.
>
> Cc: Jani Nikula
> Cc: Anusha Srivatsa
> Signed-off-by: Dhinakaran Pandiyan
> [Paulo: coding style changes]
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_irq.c | 95
> +++--
> drivers/gpu/drm/i915/i915_reg.h | 20 +
> 2 files changed, 112 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index dde938bbfb0a..9bcec5fdb9d0 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -115,6 +115,13 @@ static const u32 hpd_bxt[HPD_NUM_PINS] = {
> [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
> };
>
> +static const u32 hpd_tc_gen11[HPD_NUM_PINS] = {
> + [HPD_PORT_C] = GEN11_TC1_HOTPLUG,
> + [HPD_PORT_D] = GEN11_TC2_HOTPLUG,
> + [HPD_PORT_E] = GEN11_TC3_HOTPLUG,
> + [HPD_PORT_F] = GEN11_TC4_HOTPLUG
> +};
> +
> /* IIR can theoretically queue up two events. Be paranoid. */
> #define GEN8_IRQ_RESET_NDX(type, which) do { \
> I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> @@ -1549,6 +1556,22 @@ static void gen8_gt_irq_handler(struct
> drm_i915_private *i915,
> }
> }
>
> +static bool gen11_port_hotplug_long_detect(enum port port, u32 val)
> +{
> + switch (port) {
> + case PORT_C:
> + return val & GEN11_HOTPLUG_CTL_LONG_DETECT(PORT_TC1);
> + case PORT_D:
> + return val & GEN11_HOTPLUG_CTL_LONG_DETECT(PORT_TC2);
> + case PORT_E:
> + return val & GEN11_HOTPLUG_CTL_LONG_DETECT(PORT_TC3);
> + case PORT_F:
> + return val & GEN11_HOTPLUG_CTL_LONG_DETECT(PORT_TC4);
> + default:
> + return false;
> + }
> +}
> +
> static bool bxt_port_hotplug_long_detect(enum port port, u32 val)
> {
> switch (port) {
> @@ -2590,6 +2613,25 @@ static void bxt_hpd_irq_handler(struct
> drm_i915_private *dev_priv,
> intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
> }
>
> +static void gen11_hpd_irq_handler(struct drm_i915_private *dev_priv, u32 iir)
> +{
> + u32 pin_mask = 0, long_mask = 0;
> + u32 trigger_tc, dig_hotplug_reg;
> +
> + trigger_tc = iir & GEN11_DE_TC_HOTPLUG_MASK;
> + if (trigger_tc) {
> + dig_hotplug_reg = I915_READ(GEN11_TC_HOTPLUG_CTL);
> + I915_WRITE(GEN11_TC_HOTPLUG_CTL, dig_hotplug_reg);
> +
> + intel_get_hpd_pins(dev_priv, &pin_mask, &long_mask, trigger_tc,
> +dig_hotplug_reg, hpd_tc_gen11,
> +gen11_port_hotplug_long_detect);
> + intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
> + } else {
> + DRM_ERROR("Unexpected DE HPD interrupt 0x%08x\n", iir);
> + }
> +}
> +
> static irqreturn_t
> gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
> {
> @@ -2626,6 +2668,17 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> DRM_ERROR("The master control interrupt lied (DE
> MISC)!\n");
> }
>
> + if (INTEL_GEN(dev_priv) >= 11 && (master_ctl & GEN11_DE_HPD_IRQ)) {
> + iir = I915_READ(GEN11_DE_HPD_IIR);
> + if (iir) {
> + I915_WRITE(GEN11_DE_HPD_IIR, iir);
> + ret = IRQ_HANDLED;
> + gen11_hpd_irq_handler(dev_priv, iir);
I think the same question as for the 2nd patch remains here. Shouldn't
we being re-enabling the master interrupt before doing any further
processing?
However all gens are like that. A change here seems to belong on a
different patch... it's also the case for previous gens. Chris, is there
anything different you are seeing on gen11?
Lucas De Marchi
> + } else {
> + DRM_ERROR("The master control interrupt lied, (DE
> HPD)!\n");
> + }
> + }
> +
> if (master_ctl & GEN8_DE_PORT_IRQ) {
> iir = I915_READ(GEN8_DE_PORT_IIR);
> if (iir) {
> @@ -3492,6 +3545,7 @@ static void gen11_irq_reset(struct drm_device *dev)
>
> GEN3_IRQ_RESET(GEN8_DE_PORT_);
> GEN3_IRQ_RESET(GEN8_DE_MISC_);
> + GEN3_IRQ_RESET(GEN11_DE_HPD_);
> GEN3_IRQ_RESET(GEN11_GU_MISC_);
> GEN3_IRQ_RESET(GEN8_PCU_);
> }
> @@ -3610,6 +3664,34 @@ static void ibx_hpd_irq_setup(struct drm_i915_private
> *dev_priv)
> ibx_hpd_detection_setup(dev_priv);
> }
>
> +static void gen11_hpd_detection_setup(struct drm_i915_private *dev_priv)
> +{
> + u32 hotplu
Re: [Intel-gfx] [PATCH 05/24] drm/i915/icp: Add Interrupt Support
On Tue, May 29, 2018 at 05:04:58PM -0700, Lucas De Marchi wrote:
> On Thu, May 24, 2018 at 05:43:24PM -0700, Lucas De Marchi wrote:
> > On Thu, May 24, 2018 at 05:45:43PM -0700, Dhinakaran Pandiyan wrote:
> > > On Thu, 2018-05-24 at 16:53 -0700, Lucas De Marchi wrote:
> > > > On Mon, May 21, 2018 at 05:25:39PM -0700, Paulo Zanoni wrote:
> > > > >
> > > > > From: Anusha Srivatsa
> > > > >
> > > > > This patch addresses Interrupts from south display engine (SDE).
> > > > >
> > > > > ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC.
> > > > > Introduce these registers and their intended values.
> > > > >
> > > > > Introduce icp_irq_handler().
> > > > >
> > > > > Cc: Paulo Zanoni
> > > > > Cc: Dhinakaran Pandiyan
> > > > > Cc: Ville Syrjala
> > > > > Signed-off-by: Anusha Srivatsa
> > > > > [Paulo: coding style bikesheds and rebases].
> > > > > Signed-off-by: Paulo Zanoni
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_irq.c | 134
> > > > > +++-
> > > > > drivers/gpu/drm/i915/i915_reg.h | 40
> > > > > 2 files changed, 172 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > index 9bcec5fdb9d0..6b109991786f 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > @@ -122,6 +122,15 @@ static const u32 hpd_tc_gen11[HPD_NUM_PINS] =
> > > > > {
> > > > > [HPD_PORT_F] = GEN11_TC4_HOTPLUG
> > > > > };
> > > > >
> > > > > +static const u32 hpd_icp[HPD_NUM_PINS] = {
> > > > > + [HPD_PORT_A] = ICP_DDIA_HOTPLUG,
> > > > > + [HPD_PORT_B] = ICP_DDIB_HOTPLUG,
> > > > > + [HPD_PORT_C] = ICP_TC1_HOTPLUG,
> > > > > + [HPD_PORT_D] = ICP_TC2_HOTPLUG,
> > > > > + [HPD_PORT_E] = ICP_TC3_HOTPLUG,
> > > > > + [HPD_PORT_F] = ICP_TC4_HOTPLUG
> > > > > +};
> > > > > +
> > > > > /* IIR can theoretically queue up two events. Be paranoid. */
> > > > > #define GEN8_IRQ_RESET_NDX(type, which) do { \
> > > > > I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> > > > > @@ -1586,6 +1595,34 @@ static bool
> > > > > bxt_port_hotplug_long_detect(enum port port, u32 val)
> > > > > }
> > > > > }
> > > > >
> > > > > +static bool icp_ddi_port_hotplug_long_detect(enum port port, u32
> > > > > val)
> > > > > +{
> > > > > + switch (port) {
> > > > > + case PORT_A:
> > > > > + return val & ICP_DDIA_HPD_LONG_DETECT;
> > > > > + case PORT_B:
> > > > > + return val & ICP_DDIB_HPD_LONG_DETECT;
> > > > > + default:
> > > > > + return false;
> > > > > + }
> > > > > +}
> > > > > +
> > > > > +static bool icp_tc_port_hotplug_long_detect(enum port port, u32
> > > > > val)
> > > > > +{
> > > > > + switch (port) {
> > > > > + case PORT_C:
> > > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC1);
> > > > > + case PORT_D:
> > > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC2);
> > > > > + case PORT_E:
> > > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC3);
> > > > > + case PORT_F:
> > > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC4);
> > > > > + default:
> > > > > + return false;
> > > > > + }
> > > > > +}
> > > > > +
> > > > > static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
> > > > > {
> > > > > switch (port) {
> > > > > @@ -2377,6 +2414,43 @@ static void cpt_irq_handler(struct
> > > > > drm_i915_private *dev_priv, u32 pch_iir)
> > > > > cpt_serr_int_handler(dev_priv);
> > > > > }
> > > > >
> > > > > +static void icp_irq_handler(struct drm_i915_private *dev_priv, u32
> > > > > pch_iir)
> > > > > +{
> > > > > + u32 ddi_hotplug_trigger = pch_iir & ICP_SDE_DDI_MASK;
> > > > > + u32 tc_hotplug_trigger = pch_iir & ICP_SDE_TC_MASK;
> > > > > + u32 pin_mask = 0, long_mask = 0;
> > > > > +
> > > > > + if (ddi_hotplug_trigger) {
> > > > > + u32 dig_hotplug_reg;
> > > > > +
> > > > > + dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_DDI);
> > > > > + I915_WRITE(SHOTPLUG_CTL_DDI, dig_hotplug_reg);
> > > > > +
> > > > > + intel_get_hpd_pins(dev_priv, &pin_mask,
> > > > > &long_mask,
> > > > > + ddi_hotplug_trigger,
> > > > > + dig_hotplug_reg, hpd_icp,
> > > > > + icp_ddi_port_hotplug_long_detec
> > > > > t);
> > > > > + }
> > > > > +
> > > > > + if (tc_hotplug_trigger) {
> > > > > + u32 dig_hotplug_reg;
> > > > > +
> > > > > + dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_TC);
> > > > > + I915_WRITE(SHOTPLUG_CTL_TC, dig_hotplug_reg);
> > > > > +
> > > > > + intel_get_hpd_pins(dev_priv, &pin_mask,
> > > > > &long_mask,
> > > > > + tc_hotplug_trigger,
> > > > > +
