Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read
On Tue, 02 Jan 2018, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2018-01-02 19:12:18)
>> On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote:
>> > + edid = drm_get_edid(connector, i2c);
>> > +
>> > + if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
>> > + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO
>> > bit-banging\n");
>> > + intel_gmbus_force_bit(i2c, true);
>> > + edid = drm_get_edid(connector, i2c);
>> > + intel_gmbus_force_bit(i2c, false);
>> > + }
>>
>> Approach seems fine for this case.
>> I just wonder what would be the risks of forcing this bit and edid read when
>> nothing is present on the other end?
>
> Should be no more risky than using GMBUS as the bit-banging is the
> underlying HW protocol; it should just be adding an extra delay to
> the disconnected probe. Offset against the chance that it fixes
> detection of borderline devices.
>
> I would say that given the explanation above, the question is why not
> apply it universally? (Bonus points for including the explanation as
> comments.)
I'm wondering, is gmbus too fast for the adapters, does gmbus generally
have different timing for the ack/nak as described in the commit message
than bit banging, or are the adapters just plain buggy? Do we have any
control over gmbus timings (don't have the time to peruse the bpsec just
now)?
BR,
Jani.
> -Chris
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events
On 12/28/2017 10:43 PM, Lionel Landwerlin wrote: On 26/12/17 05:32, Sagar Arun Kamble wrote: On 12/22/2017 3:46 PM, Lionel Landwerlin wrote: On 22/12/17 09:30, Sagar Arun Kamble wrote: On 12/21/2017 6:29 PM, Lionel Landwerlin wrote: Some more findings I made while playing with this series & GPUTop. Turns out the 2ms drift per second is due to timecounter. Adding the delta this way : https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R607 Eliminates the drift. I see two imp. changes 1. approximation of start time during init_timecounter 2. overflow handling in delta accumulation. With these incorporated, I guess timecounter should also work in same fashion. I think the arithmetic in timecounter is inherently lossy and that's why we're seeing a drift. Could you share details about platform, scenario in which 2ms drift per second is being seen with timecounter. I did not observe this on SKL. The 2ms drift was on SKL GT4. I have checked the timecounter arithmetic. Accuracy is very high (of the order of micro ns per tick). I interpreted maxsec parameter in calculation of mult/shift using clocks_calc_mult_shift function as total time covered by counter but actually it controls the conversion accuracy. Since we want best possible accuracy passing zero should be preferred there. For instance below are the mult/shift values and time reported for 10 minutes with these values for SKL GT2 12mhz. As you can see drift due to calculation is only about 2us. We should check by passing zero to clocks_calc_mult_shift and delta handling new added with timecounter on SKL GT4. 2ms is huge drift and it is very unlikely related to these calculations. maxsec, mult, shift, tick time (mult/2^shift), total time (10*60*1200 * tick time), drift due to calculation 0, 2796202667, 25, 83.3334326, 600,000,000,071.525, 71ns 3000, 174762667, 21, 83.3349227, 600,000,001,144.409, 1144ns 6000, 87381333, 20, 83.3301544, 599,999,997,711.181, 2289ns With the patch above, I'm seeing only a ~40us drift over ~7seconds of recording both perf tracepoints & i915 perf reports. I'm tracking the kernel tracepoints adding gem requests and the i915 perf reports. Here a screenshot at the beginning of the 7s recording : https://i.imgur.com/hnexgjQ.png (you can see the gem request add before the work starts in the i915 perf reports). At the end of the recording, the gem requests appear later than the work in the i915 perf report : https://i.imgur.com/oCd0C9T.png Looks like we need to have error margin of only few microseconds :) I'll try to prepare some IGT tests that show the drift using perf & i915 perf, so we can run those on different platforms. I tend to mostly test on a SKL GT4 & KBL GT2, but BXT definitely needs more attention... Could we be using it wrong? if we use two changes highlighted above with timecounter maybe we will get same results as your current implementation. In the patch above, I think there is still a drift because of the potential fractional part loss at every delta we add. But it should only be a fraction of a nanosecond multiplied by the number of reports over a period of time. With a report every 1us, that should still be much less than a 1ms of drift over 1s. timecounter interface takes care of fractional parts so that should help us. we can either go with timecounter or our own implementation provided conversions are precise. Looking at clocks_calc_mult_shift(), it seems clear to me that there is less precision when using timecounter : /* * Find the conversion shift/mult pair which has the best * accuracy and fits the maxsec conversion range: */ We can improve upon this by passing zero as maxsec to clocks_calc_mult_shift. On the other hand, there is a performance penalty for doing a div64 for every report. We can probably do better by always computing the clock using the entire delta rather than the accumulated delta. issue is that the reported clock cycles in the OA report is 32bits LSB of GPU TS whereas counter is 36bits. Hence we will need to accumulate the delta. ofc there is assumption that two reports can't be spaced with count value of 0x apart. You're right :) I thought maybe we could do this : Look at teduhe opening period parameter, if it's superior to the period of timestamps wrapping, make sure we schle some work on kernel context to generate a context switch report (like at least once every 6 minutes on gen9). Looks fine to me. Timelines of perf i915 tracepoints & OA reports now make a lot more sense. There is still the issue that reading the CPU clock & the RCS timestamp is inherently not atomic. So there is a delta there. I think we should add a new i915 perf record type to express the delta that we measure this way : https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd5
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
For comparison, here's another one produced by the same kernel, on the same laptop, but a different hard drive. The OS was installed on a USB stick that I'd boot the laptop off of. Recently I started getting lags when copying to / from the stick, so I moved the OS to an external SSD. Everything else stayed the same, and booting the same kernel resulted in the same type of freeze. On Tue, Jan 02, 2018 at 04:39:22PM -0500, Alexandru Chirvasitu wrote: > Attached. Crashed quite a bit faster than before this time. > > It always seems to have something to do with opening and alt-tabbing > between windows. This time what produced the crash was an attempt to > open a new terminal. > > The hanging happened right after issuing the keyboard shortcut, before > the focus had time to switch to the newly-opened terminal window. > > Still unable to crash it reliably though, so there's no telling how > promptly I can produce these. > > > > > On Tue, Jan 02, 2018 at 04:53:45PM +, Chris Wilson wrote: > > Quoting Alexandru Chirvasitu (2018-01-01 21:13:57) > > > All right, we're in business with the new dmesg: It hung again, with a > > > 4.15-rc6 kernel with kasan support. > > > > > > The new dmesg is attached; the trace is longer now, as you expected. > > > > Ok, still the same poison but kasan didn't report a use-after-free. Odd. > > > > Can you disable CONFIG_SLAB_MERGE_DEFAULT and try again? This will stop > > anyone else from overwriting the i915_dependency. > > -Chris > [0.00] microcode: microcode updated early to revision 0x62, date = > 2017-04-27 > [0.00] Linux version 4.15.0-rc6-x-void-noslb (root@axiomatic) (gcc > version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) #1 SMP PREEMPT Tue > Jan 2 13:03:34 EST 2018 > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc6-x-void-noslb > root=UUID=66d5a55f-8ca3-47a1-850d-a0886325481c ro loglevel=4 slub_debug=P > page_poison=1 > [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point > registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' > [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 > [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 > [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 > [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 > bytes, using 'compacted' format. > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable > [0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved > [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved > [0.00] BIOS-e820: [mem 0x0010-0x86ebbfff] usable > [0.00] BIOS-e820: [mem 0x86ebc000-0x871bbfff] ACPI NVS > [0.00] BIOS-e820: [mem 0x871bc000-0x880e2fff] usable > [0.00] BIOS-e820: [mem 0x880e3000-0x880e3fff] ACPI NVS > [0.00] BIOS-e820: [mem 0x880e4000-0x880e4fff] reserved > [0.00] BIOS-e820: [mem 0x880e5000-0x8c227fff] usable > [0.00] BIOS-e820: [mem 0x8c228000-0x8cb97fff] reserved > [0.00] BIOS-e820: [mem 0x8cb98000-0x8cc67fff] usable > [0.00] BIOS-e820: [mem 0x8cc68000-0x8cfe1fff] ACPI NVS > [0.00] BIOS-e820: [mem 0x8cfe2000-0x8d3fdfff] reserved > [0.00] BIOS-e820: [mem 0x8d3fe000-0x8d3fefff] usable > [0.00] BIOS-e820: [mem 0x8d3ff000-0x8fff] reserved > [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved > [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved > [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved > [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved > [0.00] BIOS-e820: [mem 0xff00-0x] reserved > [0.00] BIOS-e820: [mem 0x0001-0x00086eff] usable > [0.00] NX (Execute Disable) protection: active > [0.00] random: fast init done > [0.00] SMBIOS 3.0.0 present. > [0.00] DMI: Notebook N24_25BU/N24_25BU, BIOS > 5.12 02/17/2017 > [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved > [0.00] e820: remove [mem 0x000a-0x000f] usable > [0.00] e820: last_pfn = 0x86f000 max_arch_pfn = 0x4 > [0.00] MTRR default type: write-back > [0.00] MTRR
[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [v2,1/2] drm/i915/guc : Decoupling ADS and logs from submission
== Series Details == Series: series starting with [v2,1/2] drm/i915/guc : Decoupling ADS and logs from submission URL : https://patchwork.freedesktop.org/series/35913/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-indfb-draw-mmap-gtt: skip -> PASS (shard-hsw) fdo#101623 +1 Subgroup fbc-1p-primscrn-cur-indfb-onoff: pass -> SKIP (shard-snb) Test kms_flip: Subgroup blt-wf_vblank-vs-modeset: skip -> PASS (shard-hsw) Subgroup dpms-off-confusion-interruptible: skip -> PASS (shard-hsw) Subgroup vblank-vs-dpms-suspend: pass -> INCOMPLETE (shard-hsw) fdo#103540 Test drm_read: Subgroup short-buffer-block: skip -> PASS (shard-hsw) Test kms_vblank: Subgroup wait-busy: skip -> PASS (shard-hsw) Test pm_rpm: Subgroup modeset-stress-extra-wait: skip -> PASS (shard-hsw) Test kms_plane: Subgroup plane-position-hole-dpms-pipe-c-planes: incomplete -> PASS (shard-hsw) Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 Test gem_tiled_swapping: Subgroup non-threaded: incomplete -> PASS (shard-snb) fdo#104218 +1 Test kms_draw_crc: Subgroup draw-method-xrgb-mmap-wc-untiled: pass -> SKIP (shard-snb) Subgroup draw-method-xrgb-blt-untiled: pass -> SKIP (shard-snb) fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218 shard-hswtotal:2646 pass:1507 dwarn:1 dfail:0 fail:12 skip:1125 time:9153s shard-snbtotal:2713 pass:1305 dwarn:1 dfail:0 fail:12 skip:1395 time:8116s Blacklisted hosts: shard-apltotal:2713 pass:1681 dwarn:1 dfail:0 fail:30 skip:1001 time:13679s shard-kbltotal:2713 pass:1802 dwarn:2 dfail:0 fail:31 skip:878 time:10993s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7597/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/guc : Decoupling ADS and logs from submission
== Series Details == Series: series starting with [v2,1/2] drm/i915/guc : Decoupling ADS and logs from submission URL : https://patchwork.freedesktop.org/series/35913/ State : success == Summary == Series 35913v1 series starting with [v2,1/2] drm/i915/guc : Decoupling ADS and logs from submission https://patchwork.freedesktop.org/api/1.0/series/35913/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_psr_sink_crc: Subgroup psr_basic: dmesg-warn -> PASS (fi-skl-6700hq) fdo#101144 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:433s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:442s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:385s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:500s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:275s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:490s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:498s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:493s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:466s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:262s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:522s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:407s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:416s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:423s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:461s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:421s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:476s fi-kbl-7560u total:288 pass:268 dwarn:1 dfail:0 fail:0 skip:19 time:508s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:463s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:514s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:590s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:444s fi-skl-6600u total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:521s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:538s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:509s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:487s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:447s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:544s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:411s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-cnl-y total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:612s fi-glk-dsi total:288 pass:256 dwarn:0 dfail:0 fail:2 skip:30 time:482s df8878303090dde6e5046c262455a815b7148f4e drm-tip: 2018y-01m-02d-15h-31m-30s UTC integration manifest bf59e1d3e74b drm/i915/guc : GEM_BUG_ON on invoking GuC reset function dee25a390ef5 drm/i915/guc : Decoupling ADS and logs from submission == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7597/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Attached. Crashed quite a bit faster than before this time. It always seems to have something to do with opening and alt-tabbing between windows. This time what produced the crash was an attempt to open a new terminal. The hanging happened right after issuing the keyboard shortcut, before the focus had time to switch to the newly-opened terminal window. Still unable to crash it reliably though, so there's no telling how promptly I can produce these. On Tue, Jan 02, 2018 at 04:53:45PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-01 21:13:57) > > All right, we're in business with the new dmesg: It hung again, with a > > 4.15-rc6 kernel with kasan support. > > > > The new dmesg is attached; the trace is longer now, as you expected. > > Ok, still the same poison but kasan didn't report a use-after-free. Odd. > > Can you disable CONFIG_SLAB_MERGE_DEFAULT and try again? This will stop > anyone else from overwriting the i915_dependency. > -Chris [0.00] microcode: microcode updated early to revision 0x62, date = 2017-04-27 [0.00] Linux version 4.15.0-rc6-x-void-noslb (root@axiomatic) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) #1 SMP PREEMPT Tue Jan 2 13:03:34 EST 2018 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc6-x-void-noslb root=UUID=66d5a55f-8ca3-47a1-850d-a0886325481c ro loglevel=4 slub_debug=P page_poison=1 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable [0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x86ebbfff] usable [0.00] BIOS-e820: [mem 0x86ebc000-0x871bbfff] ACPI NVS [0.00] BIOS-e820: [mem 0x871bc000-0x880e2fff] usable [0.00] BIOS-e820: [mem 0x880e3000-0x880e3fff] ACPI NVS [0.00] BIOS-e820: [mem 0x880e4000-0x880e4fff] reserved [0.00] BIOS-e820: [mem 0x880e5000-0x8c227fff] usable [0.00] BIOS-e820: [mem 0x8c228000-0x8cb97fff] reserved [0.00] BIOS-e820: [mem 0x8cb98000-0x8cc67fff] usable [0.00] BIOS-e820: [mem 0x8cc68000-0x8cfe1fff] ACPI NVS [0.00] BIOS-e820: [mem 0x8cfe2000-0x8d3fdfff] reserved [0.00] BIOS-e820: [mem 0x8d3fe000-0x8d3fefff] usable [0.00] BIOS-e820: [mem 0x8d3ff000-0x8fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00086eff] usable [0.00] NX (Execute Disable) protection: active [0.00] random: fast init done [0.00] SMBIOS 3.0.0 present. [0.00] DMI: Notebook N24_25BU/N24_25BU, BIOS 5.12 02/17/2017 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x86f000 max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00C000 mask 7FC000 uncachable [0.00] 1 base 00A000 mask 7FE000 uncachable [0.00] 2 base 009000 mask 7FF000 uncachable [0.00] 3 base 008E00 mask 7FFE00 uncachable [0.00] 4 base 008D80 mask 7FFF80 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] 8 disabled [
[Intel-gfx] [v2 PATCH 2/2] drm/i915/guc : GEM_BUG_ON on invoking GuC reset function
Instead of returning -EINVAL, GEM_BUG_ON when GuC reset is invoked for
platforms not supporting as we don't expect to invoke it.
v2: re-wording commit message and subject (Sagar)
Signed-off-by: Sujaritha Sundaresan
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_uncore.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 89547b61..94e1fb3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1936,8 +1936,7 @@ int intel_reset_guc(struct drm_i915_private *dev_priv)
{
int ret;
- if (!HAS_GUC(dev_priv))
- return -EINVAL;
+ GEM_BUG_ON(!HAS_GUC(dev_priv));
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
ret = gen6_hw_domain_reset(dev_priv, GEN9_GRDOM_GUC);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v2 PATCH 1/2] drm/i915/guc : Decoupling ADS and logs from submission
The Additional Data Struct (ADS) contains objects that are required by
GuC post FW load and are not necessarily submission-only. Even with
submission disabled we may require something inside the ADS, so it
makes more sense for them to be always created.
Similarly, we need to access GuC logs and even if GuC submission
is disabled, to debug issues with GuC loading or with whatever we're using
GuC for.
v2: re-wording commit message (Sagar)
Signed-off-by: Sujaritha Sundaresan
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/intel_guc.c| 18
drivers/gpu/drm/i915/intel_guc_ads.c| 151
drivers/gpu/drm/i915/intel_guc_ads.h| 33 ++
drivers/gpu/drm/i915/intel_guc_submission.c | 134
5 files changed, 203 insertions(+), 134 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_guc_ads.c
create mode 100644 drivers/gpu/drm/i915/intel_guc_ads.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 091aef2..4d9e2f8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -83,6 +83,7 @@ i915-y += i915_cmd_parser.o \
i915-y += intel_uc.o \
intel_uc_fw.o \
intel_guc.o \
+ intel_guc_ads.o \
intel_guc_ct.o \
intel_guc_fw.o \
intel_guc_log.o \
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 3c6bf5a..50b4725 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -23,6 +23,7 @@
*/
#include "intel_guc.h"
+#include "intel_guc_ads.h"
#include "intel_guc_submission.h"
#include "i915_drv.h"
@@ -163,10 +164,25 @@ int intel_guc_init(struct intel_guc *guc)
return ret;
GEM_BUG_ON(!guc->shared_data);
+ ret = intel_guc_log_create(guc);
+ if (ret)
+ goto err_shared;
+
+ ret = intel_guc_ads_create(guc);
+ if (ret)
+ goto err_log;
+ GEM_BUG_ON(!guc->ads_vma);
+
/* We need to notify the guc whenever we change the GGTT */
i915_ggtt_enable_guc(dev_priv);
return 0;
+
+err_log:
+ intel_guc_log_destroy(guc);
+err_shared:
+ guc_shared_data_destroy(guc);
+ return ret;
}
void intel_guc_fini(struct intel_guc *guc)
@@ -174,6 +190,8 @@ void intel_guc_fini(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
i915_ggtt_disable_guc(dev_priv);
+ intel_guc_ads_destroy(guc);
+ intel_guc_log_destroy(guc);
guc_shared_data_destroy(guc);
}
diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c
b/drivers/gpu/drm/i915/intel_guc_ads.c
new file mode 100644
index 000..f6066bc
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_ads.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright © 2014-2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_guc_ads.h"
+#include "intel_uc.h"
+#include "i915_drv.h"
+
+/*
+ * The Additional Data Struct (ADS) has pointers for different buffers used by
+ * the GuC. One single gem object contains the ADS struct itself (guc_ads), the
+ * scheduling policies (guc_policies), a structure describing a collection of
+ * register sets (guc_mmio_reg_state) and some extra pages for the GuC to save
+ * its internal state for sleep.
+ */
+
+static void guc_policy_init(struct guc_policy *policy)
+{
+ policy->execution_quantum = POLICY_DEFAULT_EXECUTION_QUANTUM_US;
+ policy->preemption_time = POLICY_DEFAULT_PREEMPTION_TIME_US;
+ policy->fault_time = POLICY_DEFAULT_FAULT_TIME_US;
+ policy->policy_flags = 0;
+}
+
+static void guc_policies_init(struct guc_policies *policies)
+{
+ struct guc_policy *policy;
+ u32 p, i;
+
+
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Assert we do not try to wait on an invalid seqno
== Series Details == Series: drm/i915: Assert we do not try to wait on an invalid seqno URL : https://patchwork.freedesktop.org/series/35911/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc: pass -> SKIP (shard-snb) fdo#101623 +3 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 +1 Test kms_cursor_legacy: Subgroup flip-vs-cursor-varying-size: pass -> FAIL (shard-snb) fdo#102670 Test gem_tiled_swapping: Subgroup non-threaded: incomplete -> PASS (shard-hsw) fdo#104218 Test kms_flip: Subgroup blt-wf_vblank-vs-modeset: skip -> PASS (shard-hsw) Subgroup dpms-off-confusion-interruptible: skip -> PASS (shard-hsw) Test drm_read: Subgroup short-buffer-block: skip -> PASS (shard-hsw) Test kms_vblank: Subgroup wait-busy: skip -> PASS (shard-hsw) Test pm_rpm: Subgroup modeset-stress-extra-wait: skip -> PASS (shard-hsw) Test drv_suspend: Subgroup debugfs-reader-hibernate: fail -> SKIP (shard-snb) fdo#103375 Test kms_plane: Subgroup plane-position-hole-dpms-pipe-c-planes: incomplete -> PASS (shard-hsw) fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 shard-hswtotal:2713 pass:1535 dwarn:1 dfail:0 fail:13 skip:1164 time:9384s shard-snbtotal:2698 pass:1295 dwarn:1 dfail:0 fail:14 skip:1387 time:7793s Blacklisted hosts: shard-apltotal:2713 pass:1680 dwarn:1 dfail:0 fail:30 skip:1001 time:13742s shard-kbltotal:2702 pass:1795 dwarn:1 dfail:0 fail:28 skip:877 time:10756s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7596/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v10] tests/kms_frontbuffer_tracking: Including DRRS test coverage
On Mon, Jan 01, 2018 at 01:45:32PM +, Lohith BS wrote:
> Dynamic Refresh Rate Switch(DRRS) is used to switch the panel's
> refresh rate to the lowest vrefresh supported by panel, when frame is
> not flipped for more than a Sec.
>
> In kernel, DRRS uses the front buffer tracking infrastructure.
> Hence DRRS test coverage is added along with other frontbuffer tracking
> based features such as FBC and PSR tests.
>
> Here, we are testing DRRS with other features in all possible
> combinations, in all required test cases, to capture any possible
> regression.
>
> v2: Addressed the comments and suggestions from Vlad, Marius.
> The signoff details from the earlier work are also included.
>
> v3: Modified vblank rate calculation by using reply-sequence,
> provided by drmWaitVBlank, as suggested by Chris Wilson.
>
> v4: As suggested from Chris Wilson and Daniel Vetter
> 1) Avoided using pthread for calculating vblank refresh rate,
>instead used drmWaitVBlank reply sequence.
> 2) Avoided using kernel-specific info like transitional delays,
>instead polling mechanism with timeout is used.
> 3) Included edp-DRRS as a subtest in kms_frontbuffer_tracking.c,
>instead of having a separate test.
>
> v5: This patch adds DRRS as a new feature in the
> kms_frontbuffer_tracking IGT.
> DRRS switch to lower vrefresh rate is tested at slow-draw subtest.
>
> Note:
> 1) Currently kernel doesn't have support to enable and disable
>the DRRS feature dynamically(as in case of PSR). Hence if the
>panel supports DRRS it will be enabled by default.
>
> This is in continuation of last patch
> "https://patchwork.freedesktop.org/patch/162726/";
>
> v6: This patch adds runtime enable and disable feature for testing DRRS
>
> v7: This patch adds runtime enable and disable feature for testing DRRS
> through debugfs entry "i915_drrs_ctl".
>
> v8: Commit message is updated to reflect current implementation.
>
> v9: Addressed Paulo Zanoni comments.
> Check for DRRS_LOW at tests with OFFSCREEN + FBS_INDIVIDUAL.
>
> v10: Corrected DRRS state expectation in suspend related subtests.
>
> Signed-off-by: Lohith BS
> Signed-off-by: aknautiy
> ---
> tests/kms_frontbuffer_tracking.c | 188
> +--
> 1 file changed, 179 insertions(+), 9 deletions(-)
>
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index 1601cab..1039c9e 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -34,7 +34,7 @@
>
>
> IGT_TEST_DESCRIPTION("Test the Kernel's frontbuffer tracking mechanism and "
> - "its related features: FBC and PSR");
> + "its related features: FBC, PSR and DRRS");
>
> /*
> * One of the aspects of this test is that, for every subtest, we try
> different
> @@ -105,8 +105,9 @@ struct test_mode {
> FEATURE_NONE = 0,
> FEATURE_FBC = 1,
> FEATURE_PSR = 2,
> - FEATURE_COUNT = 4,
> - FEATURE_DEFAULT = 4,
> + FEATURE_DRRS = 4,
> + FEATURE_COUNT = 8,
> + FEATURE_DEFAULT = 8,
> } feature;
>
> /* Possible pixel formats. We just use FORMAT_DEFAULT for most tests and
> @@ -156,6 +157,7 @@ struct rect {
> struct {
> int fd;
> int debugfs;
> + int drrs_debugfs_fd;
> drmModeResPtr res;
> drmModeConnectorPtr connectors[MAX_CONNECTORS];
> drmModeEncoderPtr encoders[MAX_ENCODERS];
> @@ -182,6 +184,15 @@ struct {
> .can_test = false,
> };
>
> +#define MAX_DRRS_STATUS_BUF_LEN 256
> +
> +struct {
> + bool can_test;
> + bool is_psr_drrs_combo;
Why do you need this is_psr_drrs_combo at all?
> +} drrs = {
> + .can_test = false,
> + .is_psr_drrs_combo = false,
> +};
>
> #define SINK_CRC_SIZE 12
> typedef struct {
> @@ -825,6 +836,64 @@ static void psr_print_status(void)
> igt_info("PSR status:\n%s\n", buf);
> }
>
> +void drrs_set(unsigned int val)
> +{
> + char buf[2];
> +
> + igt_debug("Manually %sabling DRRS. %llu\n", val ? "en" : "dis", val);
> + snprintf(buf, sizeof(buf), "%d", val);
> + igt_assert_eq(write(drm.drrs_debugfs_fd,
> + buf, strlen(buf)), strlen(buf));
> +}
> +
> +static bool is_drrs_high(void)
> +{
> + char buf[MAX_DRRS_STATUS_BUF_LEN];
> +
> + debugfs_read("i915_drrs_status", buf);
> + return strstr(buf, "DRRS_HIGH_RR");
> +}
> +
> +static bool is_drrs_low(void)
> +{
> + char buf[MAX_DRRS_STATUS_BUF_LEN];
> +
> + debugfs_read("i915_drrs_status", buf);
> + return strstr(buf, "DRRS_LOW_RR");
> +}
> +
> +static bool is_drrs_supported(void)
> +{
> + char buf[MAX_DRRS_STATUS_BUF_LEN];
> +
> + debugfs_read("i915_drrs_status", buf);
> + return strstr(buf, "DRRS Supported: Yes");
> +}
> +
> +static bool is_drrs_inactive(void)
> +{
> + char buf[
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Assert we do not try to wait on an invalid seqno
== Series Details == Series: drm/i915: Assert we do not try to wait on an invalid seqno URL : https://patchwork.freedesktop.org/series/35911/ State : success == Summary == Series 35911v1 drm/i915: Assert we do not try to wait on an invalid seqno https://patchwork.freedesktop.org/api/1.0/series/35911/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> PASS (fi-elk-e7500) fdo#103989 +1 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-kbl-r) fdo#104172 +1 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:438s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:441s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:383s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:498s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:276s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:491s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:494s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:479s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:462s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:262s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:518s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:414s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:427s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:467s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:424s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:481s fi-kbl-7560u total:288 pass:268 dwarn:1 dfail:0 fail:0 skip:19 time:509s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:468s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:510s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:591s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:446s fi-skl-6600u total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:520s fi-skl-6700hqtotal:288 pass:261 dwarn:1 dfail:0 fail:0 skip:26 time:539s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:505s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:488s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:447s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:525s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:410s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:579s fi-cnl-y total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:606s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:481s df8878303090dde6e5046c262455a815b7148f4e drm-tip: 2018y-01m-02d-15h-31m-30s UTC integration manifest acb631e1c325 drm/i915: Assert we do not try to wait on an invalid seqno == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7596/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/glk: Disable Guc and HuC on GLK
>-Original Message- >From: Wajdeczko, Michal >Sent: Wednesday, December 27, 2017 12:53 PM >To: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha > >Cc: Vivi, Rodrigo >Subject: Re: [PATCH] drm/i915/glk: Disable Guc and HuC on GLK > >On Sat, 23 Dec 2017 01:05:14 +0100, Anusha Srivatsa > wrote: > >> Since the firmwares are released yet to public repo, > ^^^ >s/released/not released Oooops Thanks a lot for the catch. Anusha >> disable them on Geminilake. >> >> v2: Remove the firmware versions (Michal) >> >> Cc: Michal Wajdeczko >> Cc: Rodrigo Vivi >> Signed-off-by: Anusha Srivatsa >> --- >Reviewed-by: Michal Wajdeczko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/glk: Disable Guc and HuC on GLK
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Thursday, December 28, 2017 8:08 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Wajdeczko, Michal
>
>Subject: Re: [PATCH] drm/i915/glk: Disable Guc and HuC on GLK
>
>On Sat, Dec 23, 2017 at 12:05:14AM +, Anusha Srivatsa wrote:
>> Since the firmwares are released yet to public repo, disable them on
>> Geminilake.
>>
>> v2: Remove the firmware versions (Michal)
>>
>> Cc: Michal Wajdeczko
>> Cc: Rodrigo Vivi
>> Signed-off-by: Anusha Srivatsa
>
>Fixes: 90f192c8241e ("drm/i915/GuC/GLK: Load GuC on GLK")
>Fixes: db5ba0d8931e ("drm/i915/GLK/HuC: Load HuC on GLK")
>Cc: # v4.13+
>
>What about a revert on those 2 patches?
Revert touches source files which no longer I would prefer having this
patch instead.
>I'm fine with one patch approach, but the fixes tag needs to be here anyways.
Yes, thanks for pointing the suitable tags.
>> ---
>> drivers/gpu/drm/i915/intel_guc_fw.c | 4
>> drivers/gpu/drm/i915/intel_huc.c| 4
>> 2 files changed, 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
>> b/drivers/gpu/drm/i915/intel_guc_fw.c
>> index cbc51c9..252b475 100644
>> --- a/drivers/gpu/drm/i915/intel_guc_fw.c
>> +++ b/drivers/gpu/drm/i915/intel_guc_fw.c
>> @@ -82,10 +82,6 @@ static void guc_fw_select(struct intel_uc_fw *guc_fw)
>> guc_fw->path = I915_KBL_GUC_UCODE;
>> guc_fw->major_ver_wanted = KBL_FW_MAJOR;
>> guc_fw->minor_ver_wanted = KBL_FW_MINOR;
>> -} else if (IS_GEMINILAKE(dev_priv)) {
>> -guc_fw->path = I915_GLK_GUC_UCODE;
>> -guc_fw->major_ver_wanted = GLK_FW_MAJOR;
>> -guc_fw->minor_ver_wanted = GLK_FW_MINOR;
>
>But also, please it is mandatory to also remove the now unused
>I915_GLK_GUC_UCODE, GLK_FW_MAJOR, and GLK_FW_MINOR
Will change in next revision.
Thanks a lot for the feedback.
>> } else {
>> DRM_WARN("%s: No firmware known for this platform!\n",
>> intel_uc_fw_type_repr(guc_fw->type));
>> diff --git a/drivers/gpu/drm/i915/intel_huc.c
>> b/drivers/gpu/drm/i915/intel_huc.c
>> index 974be3d..3f28ae0 100644
>> --- a/drivers/gpu/drm/i915/intel_huc.c
>> +++ b/drivers/gpu/drm/i915/intel_huc.c
>> @@ -103,10 +103,6 @@ static void huc_fw_select(struct intel_uc_fw *huc_fw)
>> huc_fw->path = I915_KBL_HUC_UCODE;
>> huc_fw->major_ver_wanted = KBL_HUC_FW_MAJOR;
>> huc_fw->minor_ver_wanted = KBL_HUC_FW_MINOR;
>> -} else if (IS_GEMINILAKE(dev_priv)) {
>> -huc_fw->path = I915_GLK_HUC_UCODE;
>> -huc_fw->major_ver_wanted = GLK_HUC_FW_MAJOR;
>> -huc_fw->minor_ver_wanted = GLK_HUC_FW_MINOR;
>
>and unused I915_GLK_HUC_UCODE, GLK_HUC_FW_MAJOR, and
>GLK_HUC_FW_MINOR.
Sure.
BR,
Anusha
>> } else {
>> DRM_WARN("%s: No firmware known for this platform!\n",
>> intel_uc_fw_type_repr(huc_fw->type));
>> --
>> 2.7.4
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)
Quoting Rodrigo Vivi (2018-01-02 19:21:08) > On Sat, Dec 30, 2017 at 12:53:58PM +, Jiri Kosina wrote: > > On Sat, 30 Dec 2017, Jiri Kosina wrote: > > > > > Seems like disabling RC6 on the kernel command line works this around, > > > and > > > I can dock / undock several times in a row with the image always coming > > > up properly on the external display. > > > > > > On the first undock, the WARN_ONCE() below triggers, so I believe each > > > undock leaks memory. > > > > > > [ 38.755084] Failed to release pages: bind_count=1, pages_pin_count=1, > > > pin_global=0 > > > [ 38.755138] WARNING: CPU: 3 PID: 96 at > > > ../drivers/gpu/drm/i915/i915_gem_userptr.c:89 cancel_userptr+0xe5/0xf0 > > > [i915] Not a leak, just a warning the shadow pte are stale due to someone pinning a (gfx) vma. > > OK, I am seeing this warning with current Linus' tree (5aa90a845) even > > without any attempt to dock/undock, so it's probably unrelated to external > > outputs and it only by coincidence appeared originally at the same time I > > docked the machine. > > > > So there are two separate issues on this machine with latest kernel > > (neither of them probably being regression): > > > > - I have to disable i915 RC6 at the kernel cmdline, otherwise external > > (dock) display gets output only randomly (seems like always only on > > first dock) > > Joonas, Chris, time to bring rc6_enable back on next-fixes before we > remove this support entirely? No. It's precisely because of this mistake (thinking that rc6 has anything to do with the issue when it's the consequential shotgun disabling of rpm) that the modparam is not coming back. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Assert we do not try to wait on an invalid seqno
We should never insert the invalid seqno into the wait tree, so assert we do not. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index 6cfffa68f71a..bb985bfc279c 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c @@ -396,6 +396,8 @@ static bool __intel_engine_add_wait(struct intel_engine_cs *engine, bool first, armed; u32 seqno; + GEM_BUG_ON(!wait->seqno); + /* Insert the request into the retirement ordered list * of waiters by walking the rbtree. If we are the oldest * seqno in the tree (the first to be retired), then -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read
Quoting Rodrigo Vivi (2018-01-02 19:12:18)
> On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote:
> > + edid = drm_get_edid(connector, i2c);
> > +
> > + if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
> > + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO
> > bit-banging\n");
> > + intel_gmbus_force_bit(i2c, true);
> > + edid = drm_get_edid(connector, i2c);
> > + intel_gmbus_force_bit(i2c, false);
> > + }
>
> Approach seems fine for this case.
> I just wonder what would be the risks of forcing this bit and edid read when
> nothing is present on the other end?
Should be no more risky than using GMBUS as the bit-banging is the
underlying HW protocol; it should just be adding an extra delay to
the disconnected probe. Offset against the chance that it fixes
detection of borderline devices.
I would say that given the explanation above, the question is why not
apply it universally? (Bonus points for including the explanation as
comments.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)
On Sat, Dec 30, 2017 at 12:53:58PM +, Jiri Kosina wrote: > On Sat, 30 Dec 2017, Jiri Kosina wrote: > > > Seems like disabling RC6 on the kernel command line works this around, and > > I can dock / undock several times in a row with the image always coming > > up properly on the external display. > > > > On the first undock, the WARN_ONCE() below triggers, so I believe each > > undock leaks memory. > > > > [ 38.755084] Failed to release pages: bind_count=1, pages_pin_count=1, > > pin_global=0 > > [ 38.755138] WARNING: CPU: 3 PID: 96 at > > ../drivers/gpu/drm/i915/i915_gem_userptr.c:89 cancel_userptr+0xe5/0xf0 > > [i915] > > OK, I am seeing this warning with current Linus' tree (5aa90a845) even > without any attempt to dock/undock, so it's probably unrelated to external > outputs and it only by coincidence appeared originally at the same time I > docked the machine. > > So there are two separate issues on this machine with latest kernel > (neither of them probably being regression): > > - I have to disable i915 RC6 at the kernel cmdline, otherwise external > (dock) display gets output only randomly (seems like always only on > first dock) Joonas, Chris, time to bring rc6_enable back on next-fixes before we remove this support entirely? > > - the warning, which triggers at not really deterministic time after boot, > but usually rather quickly Jiri, could you please report these issues separately on bugs.freedesktop.org? Are them regressions? Possible bisect? Please attach the dmesg booting with drm.debug=0x1e > > -- > Jiri Kosina > SUSE Labs > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read
On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote:
> The ACK/NACK implementation as found in e.g. the G965 has the falling
> clock edge and the release of the data line after the ACK for the received
> byte happen at the same time.
>
> This is conformant with the I2C specification, which allows a zero hold
> time, see footnote [3]: "A device must internally provide a hold time of
> at least 300 ns for the SDA signal (with respect to the V IH(min) of the
> SCL signal) to bridge the undefined region of the falling edge of SCL."
>
> Some HDMI-to-VGA converters apparently fail to adhere to this requirement
> and latch SDA at the falling clock edge, so instead of an ACK
> sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the
> transfer.
>
> The bitbanging releases the data line for the ACK only 1/4 bit time after
> the falling clock edge, so a slave will see the correct value no matter
> if it samples at the rising or the falling clock edge or in the center.
>
> Fallback to bitbanging is already done for the CRT connector.
>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92685
s/Bug:/Bugzilla:
Did we get the confirmation that this also fix the Skylake issue
initially reported?
>
> Signed-off-by: Stefan Brüns
>
> ---
>
> Changes in v2:
> - Fix/enhance commit message, no code changes
>
> drivers/gpu/drm/i915/intel_hdmi.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 4dea833f9d1b..847cda4c017c 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1573,12 +1573,20 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> struct edid *edid;
> bool connected = false;
> + struct i2c_adapter *i2c;
>
> intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>
> - edid = drm_get_edid(connector,
> - intel_gmbus_get_adapter(dev_priv,
> - intel_hdmi->ddc_bus));
> + i2c = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> +
> + edid = drm_get_edid(connector, i2c);
> +
> + if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
> + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO
> bit-banging\n");
> + intel_gmbus_force_bit(i2c, true);
> + edid = drm_get_edid(connector, i2c);
> + intel_gmbus_force_bit(i2c, false);
> + }
Approach seems fine for this case.
I just wonder what would be the risks of forcing this bit and edid read when
nothing is present on the other end?
>
> intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
>
> --
> 2.15.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-firmware Pull Request (CNL:DMC)
Hi Josh, Ben, Kyle, Please consider pulling i915 updates to linux-firmware.git. The following changes since commit 2567e092339cd3403d697dc2e0967c31b7acb989: nvidia: add GP108 signed firmware (2017-12-21 08:08:05 -0500) are available in the git repository at: https://cgit.freedesktop.org/drm/drm-firmware/ master for you to fetch changes up to 4a77cab4a02712fc7b37b55c120eec61fe7e3f32: linux-firmware: DMC firmware for cannonlake v1.07 (2018-01-02 10:52:43 -0800) Anusha Srivatsa (1): linux-firmware: DMC firmware for cannonlake v1.07 WHENCE | 2 ++ i915/cnl_dmc_ver1_07.bin | Bin 0 -> 11268 bytes 2 files changed, 2 insertions(+) create mode 100644 i915/cnl_dmc_ver1_07.bin Thanks In Advance, Anusha Srivatsa ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/19] drm/i915: Delete defunct i915_gem_request_assign()
On Tue, Jan 02, 2018 at 03:12:17PM +, Chris Wilson wrote:
> i915_gem_request_assign() is not used since commit 77f0d0e925e8
> ("drm/i915/execlists: Pack the count into the low bits of the
> port.request"), so remove the defunct code
>
> References: 77f0d0e925e8 ("drm/i915/execlists: Pack the count into the low
> bits of the port.request")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_gem_request.h | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.h
> b/drivers/gpu/drm/i915/i915_gem_request.h
> index 0d6d39f19506..04ee289d6cab 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -245,18 +245,6 @@ i915_gem_request_put(struct drm_i915_gem_request *req)
> dma_fence_put(&req->fence);
> }
>
> -static inline void i915_gem_request_assign(struct drm_i915_gem_request
> **pdst,
> -struct drm_i915_gem_request *src)
> -{
> - if (src)
> - i915_gem_request_get(src);
> -
> - if (*pdst)
> - i915_gem_request_put(*pdst);
> -
> - *pdst = src;
> -}
> -
> /**
> * i915_gem_request_global_seqno - report the current global seqno
> * @request - the request
> --
> 2.15.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Grab power domain in skl_pipe_wm_get_hw_state()
On Tue, 2017-12-19 at 13:16 +0100, Maarten Lankhorst wrote: > This should get rid of unclaimed register debug warnings, if > it still happens we should put this in a intel_crtc->active check.. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104172 The bugzilla indicates this is a regression from "drm/i915: Restore GT performance in headless mode with DMC loaded", which seems a bit odd to me. That patch should not have disabled a power well which was enabled before. If anything, it should fix unclaimed register accesses. > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/intel_pm.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index ab6f1b770891..52d157c00535 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -5477,6 +5477,11 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc, > int level, max_level; > enum plane_id plane_id; > uint32_t val; > + enum intel_display_power_domain power_domain; > + > + power_domain = POWER_DOMAIN_PIPE(pipe); > + if (!intel_display_power_get_if_enabled(dev_priv, power_domain)) > + return; > > max_level = ilk_wm_max_level(dev_priv); > > @@ -5500,10 +5505,9 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc, > skl_wm_level_from_reg_val(val, &wm->trans_wm); > } > > - if (!intel_crtc->active) > - return; > - Doing a power_domain_get_if_enabled() before reading the register seems like the right thing to do, but is power_get_if_enabled() expected to be correct at this point? The reason I ask is, modeset_get_crtc_power_domains() is called after skl_wm_get_hw_state(). So, doesn't that mean the pipe power domain might not have been acquired even if the CRTC is active. > out->linetime = I915_READ(PIPE_WM_LINETIME(pipe)); > + > + intel_display_power_put(dev_priv, power_domain); > } > > void skl_wm_get_hw_state(struct drm_device *dev) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-01 21:13:57) > All right, we're in business with the new dmesg: It hung again, with a > 4.15-rc6 kernel with kasan support. > > The new dmesg is attached; the trace is longer now, as you expected. Ok, still the same poison but kasan didn't report a use-after-free. Odd. Can you disable CONFIG_SLAB_MERGE_DEFAULT and try again? This will stop anyone else from overwriting the i915_dependency. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/19] drm/i915: Delete defunct i915_gem_request_assign()
== Series Details == Series: series starting with [01/19] drm/i915: Delete defunct i915_gem_request_assign() URL : https://patchwork.freedesktop.org/series/35907/ State : success == Summary == Test perf: Subgroup blocking: pass -> FAIL (shard-hsw) fdo#102252 Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render: pass -> FAIL (shard-snb) fdo#101623 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 shard-hswtotal:2713 pass:1537 dwarn:1 dfail:0 fail:11 skip:1164 time:9366s shard-snbtotal:2713 pass:1309 dwarn:1 dfail:0 fail:12 skip:1391 time:8034s Blacklisted hosts: shard-apltotal:2713 pass:1686 dwarn:2 dfail:0 fail:24 skip:1001 time:13601s shard-kbltotal:2638 pass:1754 dwarn:2 dfail:0 fail:24 skip:856 time:10606s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7595/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/19] drm/i915: Delete defunct i915_gem_request_assign()
== Series Details == Series: series starting with [01/19] drm/i915: Delete defunct i915_gem_request_assign() URL : https://patchwork.freedesktop.org/series/35907/ State : success == Summary == Series 35907v1 series starting with [01/19] drm/i915: Delete defunct i915_gem_request_assign() https://patchwork.freedesktop.org/api/1.0/series/35907/revisions/1/mbox/ Test kms_psr_sink_crc: Subgroup psr_basic: pass -> DMESG-WARN (fi-kbl-7560u) fdo#104260 fdo#104260 https://bugs.freedesktop.org/show_bug.cgi?id=104260 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:442s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:437s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:496s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:492s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:494s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:474s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:466s fi-elk-e7500 total:224 pass:163 dwarn:15 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:262s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:533s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:407s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:412s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:427s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:473s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:427s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:482s fi-kbl-7560u total:288 pass:268 dwarn:1 dfail:0 fail:0 skip:19 time:519s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:469s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:522s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:590s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:536s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:556s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:510s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:496s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:445s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:543s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:409s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:595s fi-cnl-y total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:608s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:480s cb4a985c7468c976c1dd14f074af9a90ca1ccbe3 drm-tip: 2018y-01m-02d-07h-03m-19s UTC integration manifest ff619504838b drm/i915/execlists: Repeat CSB mmio until it returns a sensible result 5827b73f76ed drm/i915/execlists: Tidy enabling execlists 6898f2145a02 drm/i915/execlists: Record elsp offset during engine setup a3a280a89ada drm/i915/execlists: Clear context-switch interrupt earlier in the reset 185f582ded23 drm/i915: Hold rpm wakeref for modifying the global seqno 1eb145e9c1b4 drm/i915: Reconstruct active state on starting busy-stats ffda5ae57ecb drm/i915: Reduce spinlock hold time during notify_ring() interrupt 33b284a59712 drm/i915: Drop request reference for the signaler thread e23396cb15d1 drm/i915/execlists: Reduce list_for_each_safe+list_safe_reset_next 7d21a324df0f drm/i915/execlists: Assert there are no simple cycles in the dependencies 1ad1b09f0578 drm/i915: Assert all signalers we depended on did indeed signal df9cb3486224 drm/i915: Shrink the request kmem_cache on allocation error 0dafa49eaebc drm/i915: Shrink the GEM kmem_caches upon idling 399b8c5e46ca drm/i915: Move i915_gem_retire_work_handler f5d461e71c8e drm/i915: Only attempt to scan the requested number of shrinker slabs bd979726a978 drm/i915: Use our singlethreaded wq for freeing objects 527d7f8894a4 drm/i915/fence: Separate timeout mechanism for awaiting on dma-fences 1437a2200d8d drm/i915: Only defer freeing of fence callback when also using the timer e8c13084868a drm/i915: Delete defunct i915_gem_request_assign() == Logs == For more details see: https://inte
Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Tweak igt_ggtt_page to speed it up
Quoting Matthew Auld (2018-01-02 10:36:09) > On 23 December 2017 at 11:04, Chris Wilson wrote: > > Reduce the number of GGTT PTE operations to speed the test up, but we > > reduce the likelihood of spotting a coherency error in those operations. > > However, Broxton is sporadically timing on this test, presumably because > > its GGTT operations are all uncached. > > > > Signed-off-by: Chris Wilson > Reviewed-by: Matthew Auld Ta, picked up. It's not enough yet to prevent the random oom upsetting CI, but hopefully a step forward. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/19] drm/i915: Only attempt to scan the requested number of shrinker slabs
Since commit 4e773c3a8a69 ("drm/i915: Wire up shrinkctl->nr_scanned"),
we track the number of objects we scan and do not wish to exceed that as
it will overly penalise our own slabs under mempressure. Given that we
now know the target number of objects to scan, use that as our guide for
deciding to shrink as opposed to the number of objects we manage to
shrink (which doesn't correspond to the numbers we report to shrinkctl).
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 9029ed04879c..0e158f9287c4 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -363,13 +363,13 @@ i915_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
I915_SHRINK_BOUND |
I915_SHRINK_UNBOUND |
I915_SHRINK_PURGEABLE);
- if (freed < sc->nr_to_scan)
+ if (sc->nr_scanned < sc->nr_to_scan)
freed += i915_gem_shrink(i915,
sc->nr_to_scan - sc->nr_scanned,
&sc->nr_scanned,
I915_SHRINK_BOUND |
I915_SHRINK_UNBOUND);
- if (freed < sc->nr_to_scan && current_is_kswapd()) {
+ if (sc->nr_scanned < sc->nr_to_scan && current_is_kswapd()) {
intel_runtime_pm_get(i915);
freed += i915_gem_shrink(i915,
sc->nr_to_scan - sc->nr_scanned,
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/19] drm/i915: Use our singlethreaded wq for freeing objects
As freeing the objects require serialisation on struct_mutex, we should prefer to use our singlethreaded driver wq that is dedicated to work requiring struct_mutex (hence serialised).The benefit should be less clutter on the system wq, allowing it to make progress even when the driver/struct_mutex is heavily contended. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index ba9f67c256f4..4808011264ae 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4732,7 +4732,7 @@ static void __i915_gem_free_object_rcu(struct rcu_head *head) * detour through a worker. */ if (llist_add(&obj->freed, &i915->mm.free_list)) - schedule_work(&i915->mm.free_work); + queue_work(i915->wq, &i915->mm.free_work); } void i915_gem_free_object(struct drm_gem_object *gem_obj) -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/19] drm/i915/execlists: Repeat CSB mmio until it returns a sensible result
Even though we wait until the HW has sent us its first CS interrupt
before believing that it is powered on, a read from the powercontext
saved CSB registers may still return garbage. So we must wait a little
bit for the right result. This, of course, assumes that we always see an
invalid result when the powercontext is not loaded, otherwise we will
attempt to read stale data.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2b2c61ed81db..1734fdef052a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -806,7 +806,8 @@ static void execlists_submission_tasklet(unsigned long data)
execlists->csb_head = -1; /* force mmio read of CSB
ptrs */
}
- /* The write will be ordered by the uncached read (itself
+ /*
+* The write will be ordered by the uncached read (itself
* a memory barrier), so we do not need another in the form
* of a locked instruction. The race between the interrupt
* handler and the split test/clear is harmless as we order
@@ -818,8 +819,20 @@ static void execlists_submission_tasklet(unsigned long
data)
*/
__clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
if (unlikely(execlists->csb_head == -1)) { /* following a reset
*/
- head = readl(dev_priv->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
- tail = GEN8_CSB_WRITE_PTR(head);
+ do {
+ head = readl(dev_priv->regs +
+
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
+ tail = GEN8_CSB_WRITE_PTR(head);
+ /*
+* We have to wait until the powercontext has
+* been loaded by the GPU before it starts
+* reporting correctly. As we sometimes see
+* an CS interrupt before we are able to
+* read from the powercontext saved
+* register, we repeat the read. Baffling and
+* quite scary.
+*/
+ } while (unlikely(tail >= GEN8_CSB_ENTRIES));
head = GEN8_CSB_READ_PTR(head);
execlists->csb_head = head;
} else {
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/19] drm/i915/fence: Separate timeout mechanism for awaiting on dma-fences
As the timeout mechanism has grown more and more complicated, using
multiple deferred tasks and more than doubling the size of our struct,
split the two implementations to streamline the simpler no-timeout
callback variant.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_sw_fence.c | 61 +++-
1 file changed, 40 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 5fcb428b2dfe..1de5173e53a2 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -365,18 +365,31 @@ int i915_sw_fence_await_sw_fence_gfp(struct i915_sw_fence
*fence,
struct i915_sw_dma_fence_cb {
struct dma_fence_cb base;
struct i915_sw_fence *fence;
+};
+
+struct i915_sw_dma_fence_cb_timer {
+ struct i915_sw_dma_fence_cb base;
struct dma_fence *dma;
struct timer_list timer;
struct irq_work work;
struct rcu_head rcu;
};
+static void dma_i915_sw_fence_wake(struct dma_fence *dma,
+ struct dma_fence_cb *data)
+{
+ struct i915_sw_dma_fence_cb *cb = container_of(data, typeof(*cb), base);
+
+ i915_sw_fence_complete(cb->fence);
+ kfree(cb);
+}
+
static void timer_i915_sw_fence_wake(struct timer_list *t)
{
- struct i915_sw_dma_fence_cb *cb = from_timer(cb, t, timer);
+ struct i915_sw_dma_fence_cb_timer *cb = from_timer(cb, t, timer);
struct i915_sw_fence *fence;
- fence = xchg(&cb->fence, NULL);
+ fence = xchg(&cb->base.fence, NULL);
if (!fence)
return;
@@ -388,27 +401,24 @@ static void timer_i915_sw_fence_wake(struct timer_list *t)
i915_sw_fence_complete(fence);
}
-static void dma_i915_sw_fence_wake(struct dma_fence *dma,
- struct dma_fence_cb *data)
+static void dma_i915_sw_fence_wake_timer(struct dma_fence *dma,
+struct dma_fence_cb *data)
{
- struct i915_sw_dma_fence_cb *cb = container_of(data, typeof(*cb), base);
+ struct i915_sw_dma_fence_cb_timer *cb =
+ container_of(data, typeof(*cb), base.base);
struct i915_sw_fence *fence;
- fence = xchg(&cb->fence, NULL);
+ fence = xchg(&cb->base.fence, NULL);
if (fence)
i915_sw_fence_complete(fence);
- if (cb->dma){
- irq_work_queue(&cb->work);
- return;
- }
-
- kfree(cb);
+ irq_work_queue(&cb->work);
}
static void irq_i915_sw_fence_work(struct irq_work *wrk)
{
- struct i915_sw_dma_fence_cb *cb = container_of(wrk, typeof(*cb), work);
+ struct i915_sw_dma_fence_cb_timer *cb =
+ container_of(wrk, typeof(*cb), work);
del_timer_sync(&cb->timer);
dma_fence_put(cb->dma);
@@ -422,6 +432,7 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
gfp_t gfp)
{
struct i915_sw_dma_fence_cb *cb;
+ dma_fence_func_t func;
int ret;
debug_fence_assert(fence);
@@ -430,7 +441,10 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
if (dma_fence_is_signaled(dma))
return 0;
- cb = kmalloc(sizeof(*cb), gfp);
+ cb = kmalloc(timeout ?
+sizeof(struct i915_sw_dma_fence_cb_timer) :
+sizeof(struct i915_sw_dma_fence_cb),
+gfp);
if (!cb) {
if (!gfpflags_allow_blocking(gfp))
return -ENOMEM;
@@ -441,21 +455,26 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
cb->fence = fence;
i915_sw_fence_await(fence);
- cb->dma = NULL;
+ func = dma_i915_sw_fence_wake;
if (timeout) {
- cb->dma = dma_fence_get(dma);
- init_irq_work(&cb->work, irq_i915_sw_fence_work);
+ struct i915_sw_dma_fence_cb_timer *timer =
+ container_of(cb, typeof(*timer), base);
- timer_setup(&cb->timer,
+ timer->dma = dma_fence_get(dma);
+ init_irq_work(&timer->work, irq_i915_sw_fence_work);
+
+ timer_setup(&timer->timer,
timer_i915_sw_fence_wake, TIMER_IRQSAFE);
- mod_timer(&cb->timer, round_jiffies_up(jiffies + timeout));
+ mod_timer(&timer->timer, round_jiffies_up(jiffies + timeout));
+
+ func = dma_i915_sw_fence_wake_timer;
}
- ret = dma_fence_add_callback(dma, &cb->base, dma_i915_sw_fence_wake);
+ ret = dma_fence_add_callback(dma, &cb->base, func);
if (ret == 0) {
ret = 1;
} else {
- dma_i915_sw_fence_wake(dma, &cb->base);
+ func(dma, &cb->base);
if (ret == -ENOENT) /* fence already
[Intel-gfx] [PATCH 17/19] drm/i915/execlists: Record elsp offset during engine setup
Currently, we record the elsp register offset inside init-hw but we only need to do it once during engine setup (after we know the mmio iomapping). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 5295059b6318..2e1adbaaec2f 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1494,9 +1494,6 @@ static int gen8_init_common_ring(struct intel_engine_cs *engine) execlists->csb_head = -1; execlists->active = 0; - execlists->elsp = - dev_priv->regs + i915_mmio_reg_offset(RING_ELSP(engine)); - /* After a GPU reset, we may have requests to replay */ if (execlists->first) tasklet_schedule(&execlists->tasklet); @@ -2005,6 +2002,9 @@ static int logical_ring_init(struct intel_engine_cs *engine) if (ret) goto error; + engine->execlists.elsp = + engine->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine)); + return 0; error: -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/19] drm/i915: Shrink the GEM kmem_caches upon idling
When we finally decide the gpu is idle, that is a good time to shrink
our kmem_caches.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b3c2258ebadc..9d59d64df0a3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4709,6 +4709,21 @@ i915_gem_retire_work_handler(struct work_struct *work)
}
}
+static void shrink_caches(struct drm_i915_private *i915)
+{
+ /*
+* kmem_cache_shrink() discards empty slabs and reorders partially
+* filled slabs to prioritise allocating from the mostly full slabs,
+* with the aim of reducing fragmentation.
+*/
+ kmem_cache_shrink(i915->priorities);
+ kmem_cache_shrink(i915->dependencies);
+ kmem_cache_shrink(i915->requests);
+ kmem_cache_shrink(i915->luts);
+ kmem_cache_shrink(i915->vmas);
+ kmem_cache_shrink(i915->objects);
+}
+
static inline bool
new_requests_since_last_retire(const struct drm_i915_private *i915)
{
@@ -4796,6 +4811,13 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
i915_queue_hangcheck(dev_priv);
}
+
+ rcu_barrier();
+
+ if (!new_requests_since_last_retire(dev_priv)) {
+ __i915_gem_free_work(&dev_priv->mm.free_work);
+ shrink_caches(dev_priv);
+ }
}
int i915_gem_suspend(struct drm_i915_private *dev_priv)
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/19] drm/i915/execlists: Clear context-switch interrupt earlier in the reset
Move the clearing of the CS-interrupt into the engine reset phase,
before the current init-hw phase. This helps clarify that we clear the
pending interrupts prior to any restarting of the execlists.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ffc20d7b754e..5295059b6318 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1491,18 +1491,6 @@ static int gen8_init_common_ring(struct intel_engine_cs
*engine)
GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
- /*
-* Clear any pending interrupt state.
-*
-* We do it twice out of paranoia that some of the IIR are double
-* buffered, and if we only reset it once there may still be
-* an interrupt pending.
-*/
- I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
- GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
- I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
- GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
execlists->csb_head = -1;
execlists->active = 0;
@@ -1549,6 +1537,24 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
return init_workarounds_ring(engine);
}
+static void reset_irq(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+
+ /*
+* Clear any pending interrupt state.
+*
+* We do it twice out of paranoia that some of the IIR are double
+* buffered, and if we only reset it once there may still be
+* an interrupt pending.
+*/
+ I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
+ GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
+ I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
+ GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
+ clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+}
+
static void reset_common_ring(struct intel_engine_cs *engine,
struct drm_i915_gem_request *request)
{
@@ -1558,6 +1564,9 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
GEM_TRACE("%s seqno=%x\n",
engine->name, request ? request->global_seqno : 0);
+
+ reset_irq(engine);
+
spin_lock_irqsave(&engine->timeline->lock, flags);
/*
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/19] drm/i915: Reconstruct active state on starting busy-stats
We have a hole in our busy-stat accounting if the pmu is enabled during
a long running batch, the pmu will not start accumulating busy-time
until the next context switch. This then fails tests that are only
sampling a single batch.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ebdcbcbacb3c..c2f01ff96ce1 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1946,8 +1946,15 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
spin_lock_irqsave(&engine->stats.lock, flags);
if (engine->stats.enabled == ~0)
goto busy;
- if (engine->stats.enabled++ == 0)
+ if (engine->stats.enabled++ == 0) {
engine->stats.enabled_at = ktime_get();
+
+ /* XXX submission method oblivious */
+ engine->stats.active = port_count(&engine->execlists.port[1]);
+ engine->stats.active += port_count(&engine->execlists.port[0]);
+ if (engine->stats.active)
+ engine->stats.start = engine->stats.enabled_at;
+ }
spin_unlock_irqrestore(&engine->stats.lock, flags);
return 0;
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/19] drm/i915: Reduce spinlock hold time during notify_ring() interrupt
By taking advantage of the RCU protection of the request and task
structs, we can find the appropriate signaler under the spinlock and
then release the spinlock before waking the task and signaling the
fence.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3517c6548e2c..843a1560d875 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1065,7 +1065,9 @@ static void ironlake_rps_change_irq_handler(struct
drm_i915_private *dev_priv)
static void notify_ring(struct intel_engine_cs *engine)
{
+ const u32 seqno = intel_engine_get_seqno(engine);
struct drm_i915_gem_request *rq = NULL;
+ struct task_struct *tsk = NULL;
struct intel_wait *wait;
if (!engine->breadcrumbs.irq_armed)
@@ -1074,12 +1076,13 @@ static void notify_ring(struct intel_engine_cs *engine)
atomic_inc(&engine->irq_count);
set_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
+ rcu_read_lock();
+
spin_lock(&engine->breadcrumbs.irq_lock);
wait = engine->breadcrumbs.irq_wait;
if (wait) {
- bool wakeup = engine->irq_seqno_barrier;
-
- /* We use a callback from the dma-fence to submit
+ /*
+* We use a callback from the dma-fence to submit
* requests after waiting on our own requests. To
* ensure minimum delay in queuing the next request to
* hardware, signal the fence now rather than wait for
@@ -1090,29 +1093,30 @@ static void notify_ring(struct intel_engine_cs *engine)
* and to handle coalescing of multiple seqno updates
* and many waiters.
*/
- if (i915_seqno_passed(intel_engine_get_seqno(engine),
- wait->seqno)) {
- struct drm_i915_gem_request *waiter = wait->request;
-
- wakeup = true;
- if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- &waiter->fence.flags) &&
- intel_wait_check_request(wait, waiter))
- rq = i915_gem_request_get(waiter);
+ if (i915_seqno_passed(seqno, wait->seqno)) {
+ tsk = wait->tsk;
+ rq = wait->request;
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+&rq->fence.flags) ||
+ intel_wait_check_request(wait, rq))
+ rq = NULL;
+ } else {
+ if (engine->irq_seqno_barrier &&
+ i915_seqno_passed(seqno, wait->seqno - 1))
+ tsk = wait->tsk;
}
-
- if (wakeup)
- wake_up_process(wait->tsk);
} else {
if (engine->breadcrumbs.irq_armed)
__intel_engine_disarm_breadcrumbs(engine);
}
spin_unlock(&engine->breadcrumbs.irq_lock);
- if (rq) {
+ if (rq)
dma_fence_signal(&rq->fence);
- i915_gem_request_put(rq);
- }
+ if (tsk)
+ wake_up_process(tsk);
+
+ rcu_read_unlock();
trace_intel_engine_notify(engine, wait);
}
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/19] drm/i915/execlists: Tidy enabling execlists
Move the register settings for enabling execlists into its own function
for clarity.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2e1adbaaec2f..2b2c61ed81db 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1467,9 +1467,20 @@ static u8 gtiir[] = {
[VECS] = 3,
};
-static int gen8_init_common_ring(struct intel_engine_cs *engine)
+static void enable_execlists(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
+
+ I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x);
+ I915_WRITE(RING_MODE_GEN7(engine),
+ _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+ I915_WRITE(RING_HWS_PGA(engine->mmio_base),
+ engine->status_page.ggtt_offset);
+ POSTING_READ(RING_HWS_PGA(engine->mmio_base));
+}
+
+static int gen8_init_common_ring(struct intel_engine_cs *engine)
+{
struct intel_engine_execlists * const execlists = &engine->execlists;
int ret;
@@ -1480,13 +1491,7 @@ static int gen8_init_common_ring(struct intel_engine_cs
*engine)
intel_engine_reset_breadcrumbs(engine);
intel_engine_init_hangcheck(engine);
- I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x);
- I915_WRITE(RING_MODE_GEN7(engine),
- _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
- I915_WRITE(RING_HWS_PGA(engine->mmio_base),
- engine->status_page.ggtt_offset);
- POSTING_READ(RING_HWS_PGA(engine->mmio_base));
-
+ enable_execlists(engine);
DRM_DEBUG_DRIVER("Execlists enabled for %s\n", engine->name);
GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
@@ -1913,6 +1918,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs
*engine)
intel_engine_cleanup_common(engine);
lrc_destroy_wa_ctx(engine);
+
engine->i915 = NULL;
dev_priv->engine[engine->id] = NULL;
kfree(engine);
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/19] drm/i915: Hold rpm wakeref for modifying the global seqno
To modify the global seqno may require rewriting a few registers, which requires us to hold the rpm wakeref. We must therefore take it around the call to i915_gem_set_global_seqno() in debugfs, on behalf of the user. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index d81cb2513069..2bb63073d73f 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -988,7 +988,10 @@ i915_next_seqno_set(void *data, u64 val) if (ret) return ret; + intel_runtime_pm_get(dev_priv); ret = i915_gem_set_global_seqno(dev, val); + intel_runtime_pm_put(dev_priv); + mutex_unlock(&dev->struct_mutex); return ret; -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/19] drm/i915: Assert all signalers we depended on did indeed signal
Back up our comment that all signalers should have been signaled before
we ourselves were retired with an assert to that effect.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_request.c | 9 -
drivers/gpu/drm/i915/i915_gem_request.h | 6 ++
drivers/gpu/drm/i915/intel_lrc.c| 9 ++---
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index b5213a926ced..a24c6a87953c 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -161,12 +161,16 @@ i915_priotree_fini(struct drm_i915_private *i915, struct
i915_priotree *pt)
GEM_BUG_ON(!list_empty(&pt->link));
- /* Everyone we depended upon (the fences we wait to be signaled)
+ /*
+* Everyone we depended upon (the fences we wait to be signaled)
* should retire before us and remove themselves from our list.
* However, retirement is run independently on each timeline and
* so we may be called out-of-order.
*/
list_for_each_entry_safe(dep, next, &pt->signalers_list, signal_link) {
+
GEM_BUG_ON(!i915_gem_request_completed(priotree_to_request(dep->signaler)));
+ GEM_BUG_ON(!list_empty(&dep->dfs_link));
+
list_del(&dep->wait_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(i915, dep);
@@ -174,6 +178,9 @@ i915_priotree_fini(struct drm_i915_private *i915, struct
i915_priotree *pt)
/* Remove ourselves from everyone who depends upon us */
list_for_each_entry_safe(dep, next, &pt->waiters_list, wait_link) {
+ GEM_BUG_ON(dep->signaler != pt);
+ GEM_BUG_ON(!list_empty(&dep->dfs_link));
+
list_del(&dep->signal_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(i915, dep);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h
b/drivers/gpu/drm/i915/i915_gem_request.h
index 04ee289d6cab..5753ab3aaff5 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -227,6 +227,12 @@ to_request(struct dma_fence *fence)
return container_of(fence, struct drm_i915_gem_request, fence);
}
+static inline struct drm_i915_gem_request *
+priotree_to_request(struct i915_priotree *pt)
+{
+ return container_of(pt, struct drm_i915_gem_request, priotree);
+}
+
static inline struct drm_i915_gem_request *
i915_gem_request_get(struct drm_i915_gem_request *req)
{
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 739c33b07c59..007aec9d95c9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -973,15 +973,10 @@ static void execlists_submit_request(struct
drm_i915_gem_request *request)
spin_unlock_irqrestore(&engine->timeline->lock, flags);
}
-static struct drm_i915_gem_request *pt_to_request(struct i915_priotree *pt)
-{
- return container_of(pt, struct drm_i915_gem_request, priotree);
-}
-
static struct intel_engine_cs *
pt_lock_engine(struct i915_priotree *pt, struct intel_engine_cs *locked)
{
- struct intel_engine_cs *engine = pt_to_request(pt)->engine;
+ struct intel_engine_cs *engine = priotree_to_request(pt)->engine;
GEM_BUG_ON(!locked);
@@ -1037,7 +1032,7 @@ static void execlists_schedule(struct
drm_i915_gem_request *request, int prio)
* engines.
*/
list_for_each_entry(p, &pt->signalers_list, signal_link) {
- if
(i915_gem_request_completed(pt_to_request(p->signaler)))
+ if
(i915_gem_request_completed(priotree_to_request(p->signaler)))
continue;
GEM_BUG_ON(p->signaler->priority < pt->priority);
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/19] drm/i915/execlists: Reduce list_for_each_safe+list_safe_reset_next
After staring at the list_for_each_safe macros for a bit, our current
invocation of list_safe_reset_next in execlists_schedule() simply
reduces to list_for_each.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8c9d6cef2482..ffc20d7b754e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1024,7 +1024,7 @@ static void execlists_schedule(struct
drm_i915_gem_request *request, int prio)
* end result is a topological list of requests in reverse order, the
* last element in the list is the request we must execute first.
*/
- list_for_each_entry_safe(dep, p, &dfs, dfs_link) {
+ list_for_each_entry(dep, &dfs, dfs_link) {
struct i915_priotree *pt = dep->signaler;
/*
@@ -1043,8 +1043,6 @@ static void execlists_schedule(struct
drm_i915_gem_request *request, int prio)
if (prio > READ_ONCE(p->signaler->priority))
list_move_tail(&p->dfs_link, &dfs);
}
-
- list_safe_reset_next(dep, p, dfs_link);
}
/*
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/19] drm/i915: Drop request reference for the signaler thread
If we remember to cancel the signaler on a request when retiring it
(after we know that the request has been signaled), we do not need to
carry an additional request in the signaler itself. This prevents an
issue whereby the signaler threads may be delayed and hold on to
thousands of request references, causing severe memory fragmentation and
premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL
and frequent use of inter-engine fences).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 6 +-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 111 +++
2 files changed, 59 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index a24c6a87953c..af2493164686 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -441,7 +441,10 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
spin_lock_irq(&request->lock);
if (request->waitboost)
atomic_dec(&request->i915->gt_pm.rps.num_waiters);
- dma_fence_signal_locked(&request->fence);
+ if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &request->fence.flags))
+ dma_fence_signal_locked(&request->fence);
+ if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags))
+ intel_engine_cancel_signaling(request);
spin_unlock_irq(&request->lock);
i915_priotree_fini(request->i915, &request->priotree);
@@ -730,6 +733,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
/* No zalloc, must clear what we need by hand */
req->global_seqno = 0;
+ req->signaling.wait.seqno = 0;
req->file_priv = NULL;
req->batch = NULL;
req->capture_list = NULL;
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 58c624f982d9..6cfffa68f71a 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -642,6 +642,38 @@ static void signaler_set_rtpriority(void)
sched_setscheduler_nocheck(current, SCHED_FIFO, ¶m);
}
+static void __intel_engine_remove_signal(struct intel_engine_cs *engine,
+struct drm_i915_gem_request *request)
+{
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+
+ lockdep_assert_held(&b->rb_lock);
+
+ /*
+* Wake up all other completed waiters and select the
+* next bottom-half for the next user interrupt.
+*/
+ __intel_engine_remove_wait(engine, &request->signaling.wait);
+
+ /*
+* Find the next oldest signal. Note that as we have
+* not been holding the lock, another client may
+* have installed an even older signal than the one
+* we just completed - so double check we are still
+* the oldest before picking the next one.
+*/
+ if (request->signaling.wait.seqno) {
+ if (request == rcu_access_pointer(b->first_signal)) {
+ struct rb_node *rb = rb_next(&request->signaling.node);
+ rcu_assign_pointer(b->first_signal,
+ rb ? to_signaler(rb) : NULL);
+ }
+
+ rb_erase(&request->signaling.node, &b->signals);
+ request->signaling.wait.seqno = 0;
+ }
+}
+
static int intel_breadcrumbs_signaler(void *arg)
{
struct intel_engine_cs *engine = arg;
@@ -670,36 +702,18 @@ static int intel_breadcrumbs_signaler(void *arg)
request = i915_gem_request_get_rcu(request);
rcu_read_unlock();
if (signal_complete(request)) {
- local_bh_disable();
- dma_fence_signal(&request->fence);
- local_bh_enable(); /* kick start the tasklets */
-
- spin_lock_irq(&b->rb_lock);
-
- /* Wake up all other completed waiters and select the
-* next bottom-half for the next user interrupt.
-*/
- __intel_engine_remove_wait(engine,
- &request->signaling.wait);
-
- /* Find the next oldest signal. Note that as we have
-* not been holding the lock, another client may
-* have installed an even older signal than the one
-* we just completed - so double check we are still
-* the oldest before picking the next one.
-*/
- if (request == rcu_access_pointer(b->first_signal)) {
- struct rb_node *rb =
- rb_next(&request->signaling.node);
- rcu_
[Intel-gfx] [PATCH 06/19] drm/i915: Move i915_gem_retire_work_handler
In preparation for the next patch, move i915_gem_retire_work_handler()
later to avoid a forward declaration.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 228
1 file changed, 114 insertions(+), 114 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4808011264ae..b3c2258ebadc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3310,120 +3310,6 @@ bool i915_gem_unset_wedged(struct drm_i915_private
*i915)
return true;
}
-static void
-i915_gem_retire_work_handler(struct work_struct *work)
-{
- struct drm_i915_private *dev_priv =
- container_of(work, typeof(*dev_priv), gt.retire_work.work);
- struct drm_device *dev = &dev_priv->drm;
-
- /* Come back later if the device is busy... */
- if (mutex_trylock(&dev->struct_mutex)) {
- i915_gem_retire_requests(dev_priv);
- mutex_unlock(&dev->struct_mutex);
- }
-
- /* Keep the retire handler running until we are finally idle.
-* We do not need to do this test under locking as in the worst-case
-* we queue the retire worker once too often.
-*/
- if (READ_ONCE(dev_priv->gt.awake)) {
- i915_queue_hangcheck(dev_priv);
- queue_delayed_work(dev_priv->wq,
- &dev_priv->gt.retire_work,
- round_jiffies_up_relative(HZ));
- }
-}
-
-static inline bool
-new_requests_since_last_retire(const struct drm_i915_private *i915)
-{
- return (READ_ONCE(i915->gt.active_requests) ||
- work_pending(&i915->gt.idle_work.work));
-}
-
-static void
-i915_gem_idle_work_handler(struct work_struct *work)
-{
- struct drm_i915_private *dev_priv =
- container_of(work, typeof(*dev_priv), gt.idle_work.work);
- bool rearm_hangcheck;
- ktime_t end;
-
- if (!READ_ONCE(dev_priv->gt.awake))
- return;
-
- /*
-* Wait for last execlists context complete, but bail out in case a
-* new request is submitted.
-*/
- end = ktime_add_ms(ktime_get(), I915_IDLE_ENGINES_TIMEOUT);
- do {
- if (new_requests_since_last_retire(dev_priv))
- return;
-
- if (intel_engines_are_idle(dev_priv))
- break;
-
- usleep_range(100, 500);
- } while (ktime_before(ktime_get(), end));
-
- rearm_hangcheck =
- cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
-
- if (!mutex_trylock(&dev_priv->drm.struct_mutex)) {
- /* Currently busy, come back later */
- mod_delayed_work(dev_priv->wq,
-&dev_priv->gt.idle_work,
-msecs_to_jiffies(50));
- goto out_rearm;
- }
-
- /*
-* New request retired after this work handler started, extend active
-* period until next instance of the work.
-*/
- if (new_requests_since_last_retire(dev_priv))
- goto out_unlock;
-
- /*
-* Be paranoid and flush a concurrent interrupt to make sure
-* we don't reactivate any irq tasklets after parking.
-*
-* FIXME: Note that even though we have waited for execlists to be idle,
-* there may still be an in-flight interrupt even though the CSB
-* is now empty. synchronize_irq() makes sure that a residual interrupt
-* is completed before we continue, but it doesn't prevent the HW from
-* raising a spurious interrupt later. To complete the shield we should
-* coordinate disabling the CS irq with flushing the interrupts.
-*/
- synchronize_irq(dev_priv->drm.irq);
-
- intel_engines_park(dev_priv);
- i915_gem_timelines_park(dev_priv);
-
- i915_pmu_gt_parked(dev_priv);
-
- GEM_BUG_ON(!dev_priv->gt.awake);
- dev_priv->gt.awake = false;
- rearm_hangcheck = false;
-
- if (INTEL_GEN(dev_priv) >= 6)
- gen6_rps_idle(dev_priv);
-
- intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
-
- intel_runtime_pm_put(dev_priv);
-out_unlock:
- mutex_unlock(&dev_priv->drm.struct_mutex);
-
-out_rearm:
- if (rearm_hangcheck) {
- GEM_BUG_ON(!dev_priv->gt.awake);
- i915_queue_hangcheck(dev_priv);
- }
-}
-
void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
{
struct drm_i915_private *i915 = to_i915(gem->dev);
@@ -4798,6 +4684,120 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
}
}
+static void
+i915_gem_retire_work_handler(struct work_struct *work)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(work, typeof(*dev_priv), gt.retire_work.work);
+ struct drm_device *dev =
[Intel-gfx] [PATCH 01/19] drm/i915: Delete defunct i915_gem_request_assign()
i915_gem_request_assign() is not used since commit 77f0d0e925e8
("drm/i915/execlists: Pack the count into the low bits of the
port.request"), so remove the defunct code
References: 77f0d0e925e8 ("drm/i915/execlists: Pack the count into the low bits
of the port.request")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_request.h | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h
b/drivers/gpu/drm/i915/i915_gem_request.h
index 0d6d39f19506..04ee289d6cab 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -245,18 +245,6 @@ i915_gem_request_put(struct drm_i915_gem_request *req)
dma_fence_put(&req->fence);
}
-static inline void i915_gem_request_assign(struct drm_i915_gem_request **pdst,
- struct drm_i915_gem_request *src)
-{
- if (src)
- i915_gem_request_get(src);
-
- if (*pdst)
- i915_gem_request_put(*pdst);
-
- *pdst = src;
-}
-
/**
* i915_gem_request_global_seqno - report the current global seqno
* @request - the request
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/19] drm/i915: Shrink the request kmem_cache on allocation error
If we fail to allocate a new request, make sure we recover the pages
that are in the process of being freed by inserting an RCU barrier.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index d575109f7a7f..b5213a926ced 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -689,6 +689,9 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
if (ret)
goto err_unreserve;
+ kmem_cache_shrink(dev_priv->requests);
+ rcu_barrier();
+
req = kmem_cache_alloc(dev_priv->requests, GFP_KERNEL);
if (!req) {
ret = -ENOMEM;
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/19] drm/i915: Only defer freeing of fence callback when also using the timer
Without an accompanying timer (for internal fences), we can free the
fence callback immediately as we do not need to employ the RCU barrier
to serialise with the timer. By avoiding the RCU delay, we can avoid the
extra mempressure under heavy inter-engine request utilisation.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_sw_fence.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 3669f5eeb91e..5fcb428b2dfe 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -398,7 +398,12 @@ static void dma_i915_sw_fence_wake(struct dma_fence *dma,
if (fence)
i915_sw_fence_complete(fence);
- irq_work_queue(&cb->work);
+ if (cb->dma){
+ irq_work_queue(&cb->work);
+ return;
+ }
+
+ kfree(cb);
}
static void irq_i915_sw_fence_work(struct irq_work *wrk)
@@ -437,10 +442,12 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
i915_sw_fence_await(fence);
cb->dma = NULL;
- timer_setup(&cb->timer, timer_i915_sw_fence_wake, TIMER_IRQSAFE);
- init_irq_work(&cb->work, irq_i915_sw_fence_work);
if (timeout) {
cb->dma = dma_fence_get(dma);
+ init_irq_work(&cb->work, irq_i915_sw_fence_work);
+
+ timer_setup(&cb->timer,
+ timer_i915_sw_fence_wake, TIMER_IRQSAFE);
mod_timer(&cb->timer, round_jiffies_up(jiffies + timeout));
}
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/19] drm/i915/execlists: Assert there are no simple cycles in the dependencies
The dependency chain must be an acyclic graph. This is checked by the
swfence, but for sanity, also do a simple check that we do not corrupt
our list iteration in execlists_schedule() by a shallow dependency
cycle.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 007aec9d95c9..8c9d6cef2482 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1006,7 +1006,8 @@ static void execlists_schedule(struct
drm_i915_gem_request *request, int prio)
stack.signaler = &request->priotree;
list_add(&stack.dfs_link, &dfs);
- /* Recursively bump all dependent priorities to match the new request.
+ /*
+* Recursively bump all dependent priorities to match the new request.
*
* A naive approach would be to use recursion:
* static void update_priorities(struct i915_priotree *pt, prio) {
@@ -1026,12 +1027,15 @@ static void execlists_schedule(struct
drm_i915_gem_request *request, int prio)
list_for_each_entry_safe(dep, p, &dfs, dfs_link) {
struct i915_priotree *pt = dep->signaler;
- /* Within an engine, there can be no cycle, but we may
+ /*
+* Within an engine, there can be no cycle, but we may
* refer to the same dependency chain multiple times
* (redundant dependencies are not eliminated) and across
* engines.
*/
list_for_each_entry(p, &pt->signalers_list, signal_link) {
+ GEM_BUG_ON(p == dep); /* no cycles! */
+
if
(i915_gem_request_completed(priotree_to_request(p->signaler)))
continue;
@@ -1043,7 +1047,8 @@ static void execlists_schedule(struct
drm_i915_gem_request *request, int prio)
list_safe_reset_next(dep, p, dfs_link);
}
- /* If we didn't need to bump any existing priorities, and we haven't
+ /*
+* If we didn't need to bump any existing priorities, and we haven't
* yet submitted this request (i.e. there is no potential race with
* execlists_submit_request()), we can set our own priority and skip
* acquiring the engine locks.
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev5)
== Series Details == Series: tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev5) URL : https://patchwork.freedesktop.org/series/32888/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-rgb565-draw-mmap-wc: pass -> FAIL (shard-snb) fdo#101623 +60 Subgroup fbc-rgb101010-draw-mmap-cpu: pass -> FAIL (shard-snb) fdo#103167 +43 Subgroup fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-1p-offscren-pri-indfb-draw-mmap-wc: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-1p-primscrn-cur-indfb-onoff: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-rgb101010-draw-blt: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-1p-primscrn-pri-indfb-draw-mmap-wc: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-tilingchange: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-1p-primscrn-spr-indfb-onoff: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-rgb101010-draw-pwrite: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-gtt: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-rgb565-draw-mmap-cpu: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-rgb101010-draw-mmap-gtt: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-1p-primscrn-cur-indfb-draw-mmap-wc: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-1p-primscrn-pri-indfb-draw-pwrite: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: pass -> FAIL (shard-snb) pass -> FAIL (shard-hsw) Subgroup fbc-suspend: pass -> FAIL (shard-hsw) fdo#103540 Test kms_flip: Subgroup wf_vblank-vs-modeset-interruptible: dmesg-warn -> PASS (shard-hsw) fdo#102614 Test gem_tiled_swapping: Subgroup non-threaded: pass -> INCOMPLETE (shard-snb) fdo#104218 Test drv_suspend: Subgroup fence-restore-tiled2untiled-hibernate: dmesg-fail -> FAIL (shard-snb) fdo#103375 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 shard-hswtotal:3283 pass:1470 dwarn:1 dfail:0 fail:79 skip:1733 time:9220s shard-snbtotal:3242 pass:1230 dwarn:1 dfail:0 fail:78 skip:1932 time:7792s Blacklisted hosts: shard-apltotal:3261 pass:1591 dwarn:1 dfail:0 fail:97 skip:1570 time:13183s shard-kbltotal:3265 pass:1672 dwarn:42 dfail:2 fail:98 skip:1450 time:10596s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_734/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fixes that failed to cleanly apply to v4.15-rc1
On Tue, 28 Nov 2017, Joonas Lahtinen wrote:
> Hello,
>
> TL;DR Reply with backported patches for v4.15-rc1 latest TODAY
>
> Dear patch authors/Cc:s, the following patches failed to cleanly
> backport to v4.15-rc1, if you believe they still are valid patches to
> be included in drm-intel-fixes, please backport them and send them as a
> REPLY TO THIS EMAIL before the END OF TODAY.
>
> The patches that failed to cherry-pick:
> 8cf80a2e4b31 ("drm/i915/gvt: Rename reserved ring buffer")
> f2880e04f3a5 ("drm/i915/gvt: Move request alloc to dispatch_workload path
> only")
> 0cfecb7c4b9b ("Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl,
> glk"")
Update for -rc6
f745e9cc7e40 ("drm/i915/gvt: Add missing breaks in switch statement")
4e889d62b89d ("drm/i915/gvt: Fix pipe A enable as default for vgpu")
53421c2fe99c ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev5)
== Series Details == Series: tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev5) URL : https://patchwork.freedesktop.org/series/32888/ State : success == Summary == IGT patchset tested on top of latest successful build 4cd4cc4873fc1c916b6bf7b058b12294e16dfd98 lib: Convert sw_sync to use sync_file uapi imported from the kernel with latest DRM-Tip kernel build CI_DRM_3586 16432d39f2cb drm-tip: 2017y-12m-30d-02h-25m-26s UTC integration manifest Testlist changes: +++ 570 lines --- 0 lines Test debugfs_test: Subgroup read_all_entries: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-kbl-r) fdo#104172 +1 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:438s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:437s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:498s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:500s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:479s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:469s fi-elk-e7500 total:224 pass:163 dwarn:14 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:265s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:406s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:413s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:429s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:479s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:431s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:482s fi-kbl-7560u total:288 pass:268 dwarn:1 dfail:0 fail:0 skip:19 time:521s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:521s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:594s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-skl-6600u total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:530s fi-skl-6700hqtotal:288 pass:261 dwarn:1 dfail:0 fail:0 skip:26 time:557s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:517s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:504s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:442s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:417s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:596s fi-cnl-y total:265 pass:239 dwarn:0 dfail:0 fail:0 skip:25 fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:481s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_734/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/selftests: Allow random array allocation to fail
On 23 December 2017 at 11:04, Chris Wilson wrote: > From the selftests, we don't want to force an oom and would rather > ENOMEM be reported. In this case, we would rather the allocation for the > random array to fail. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Tweak igt_ggtt_page to speed it up
On 23 December 2017 at 11:04, Chris Wilson wrote: > Reduce the number of GGTT PTE operations to speed the test up, but we > reduce the likelihood of spotting a coherency error in those operations. > However, Broxton is sporadically timing on this test, presumably because > its GGTT operations are all uncached. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ 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: Try EDID bitbanging on HDMI after failed read (rev2)
== Series Details == Series: drm/i915: Try EDID bitbanging on HDMI after failed read (rev2) URL : https://patchwork.freedesktop.org/series/35770/ State : success == Summary == Series 35770v2 drm/i915: Try EDID bitbanging on HDMI after failed read https://patchwork.freedesktop.org/api/1.0/series/35770/revisions/2/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-kbl-r) fdo#104172 +1 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:436s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:440s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:383s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:494s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:276s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:494s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:482s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:471s fi-elk-e7500 total:224 pass:163 dwarn:15 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:264s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:528s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:411s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:425s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:478s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:432s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:474s fi-kbl-7560u total:288 pass:268 dwarn:1 dfail:0 fail:0 skip:19 time:521s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:468s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:525s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:588s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-skl-6600u total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:534s fi-skl-6700hqtotal:288 pass:261 dwarn:1 dfail:0 fail:0 skip:26 time:557s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:503s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:505s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:449s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:561s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:417s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:586s fi-cnl-y total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:628s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:489s 16432d39f2cbdc7a8798df3ebb4f7c882fb23132 drm-tip: 2017y-12m-30d-02h-25m-26s UTC integration manifest 9e520a26a878 drm/i915: Try EDID bitbanging on HDMI after failed read == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7594/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Add generic fbdev emulation
== Series Details == Series: drm: Add generic fbdev emulation URL : https://patchwork.freedesktop.org/series/35873/ State : warning == Summary == Series 35873v1 drm: Add generic fbdev emulation https://patchwork.freedesktop.org/api/1.0/series/35873/revisions/1/mbox/ Test core_prop_blob: Subgroup basic: pass -> DMESG-WARN (fi-elk-e7500) Test debugfs_test: Subgroup read_all_entries: dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989 Test drv_getparams_basic: Subgroup basic-eu-total: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-subslice-total: pass -> DMESG-WARN (fi-elk-e7500) Test drv_hangman: Subgroup error-state-basic: pass -> DMESG-WARN (fi-elk-e7500) Test gem_basic: Subgroup bad-close: pass -> DMESG-WARN (fi-elk-e7500) Subgroup create-close: pass -> DMESG-WARN (fi-elk-e7500) Subgroup create-fd-close: pass -> DMESG-WARN (fi-elk-e7500) Test gem_busy: Subgroup basic-busy-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-hang-default: pass -> DMESG-WARN (fi-elk-e7500) Test gem_close_race: Subgroup basic-process: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-threads: pass -> DMESG-WARN (fi-elk-e7500) Test gem_cpu_reloc: Subgroup basic: pass -> DMESG-WARN (fi-elk-e7500) Test gem_cs_tlb: Subgroup basic-default: pass -> DMESG-WARN (fi-elk-e7500) Test gem_exec_basic: Subgroup basic-bsd: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-render: pass -> DMESG-WARN (fi-elk-e7500) Subgroup gtt-bsd: pass -> DMESG-WARN (fi-elk-e7500) Subgroup gtt-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup gtt-render: pass -> DMESG-WARN (fi-elk-e7500) Subgroup readonly-bsd: pass -> DMESG-WARN (fi-elk-e7500) Subgroup readonly-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup readonly-render: pass -> DMESG-WARN (fi-elk-e7500) Test gem_exec_create: Subgroup basic: pass -> DMESG-WARN (fi-elk-e7500) Test gem_exec_fence: Subgroup basic-busy-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-wait-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-await-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup await-hang-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup nb-await-default: pass -> DMESG-WARN (fi-elk-e7500) Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-batch-kernel-default-wb: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-uc-pro-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-uc-prw-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-uc-ro-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-uc-rw-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-uc-set-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-wb-pro-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-wb-prw-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-wb-ro-before-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-wb-ro-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-wb-rw-before-default: pass -> DMESG-WARN (fi-elk-e7500) Subgroup basic-wb-rw-default: pass -> DMESG-WARN (fi-elk-e7500) WARNING: Long output truncated fi-ilk-650 failed to collect. IGT log at Patchwork_7593/fi-ilk-650/igt.log 16432d39f2cbdc7a8798df3ebb4f7c882fb23132 drm-tip: 2017y-12m-30d-02h-25m-26s UTC integration manifest 2d7b02fbcdc1 drm/vc4: Test generic fbdev emulation 5e8d502b385b drm/fb-helper: Add generic fbdev emulation cca8dc2718b2 drm: Handle fbdev emulation in core 0fb70b30a370 drm/prime: Clear drm_gem_object->dma_buf on release 62fa7d13869e drm/fb-helper: Don't restore if fbdev is not in use 105bcaf70f49 drm/fb-helper: Ensure driver module is pinned in fb_open() dcec14502862 drm: provide management functions for drm_file == Log
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix Limited Range Color Handling (rev2)
== Series Details == Series: drm/i915: Fix Limited Range Color Handling (rev2) URL : https://patchwork.freedesktop.org/series/35725/ State : success == Summary == Series 35725v2 drm/i915: Fix Limited Range Color Handling https://patchwork.freedesktop.org/api/1.0/series/35725/revisions/2/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +1 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-kbl-r) fdo#104172 +1 Test prime_vgem: Subgroup basic-fence-flip: fail -> PASS (fi-bwr-2160) fdo#103182 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172 fdo#103182 https://bugs.freedesktop.org/show_bug.cgi?id=103182 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:435s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:491s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:275s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:488s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:473s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:472s fi-elk-e7500 total:224 pass:163 dwarn:14 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:261s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:412s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:421s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:474s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:428s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7560u total:288 pass:268 dwarn:1 dfail:0 fail:0 skip:19 time:519s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:522s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:583s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:444s fi-skl-6600u total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:523s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:550s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:506s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:494s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:546s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:409s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:592s fi-cnl-y total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:628s fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_7592/fi-bdw-gvtdvm/igt.log fi-glk-dsi failed to collect. IGT log at Patchwork_7592/fi-glk-dsi/igt.log 8cb9e9870b50ddf65ebe233d38194cafdd811d03 drm-tip: 2017y-12m-28d-17h-00m-27s UTC integration manifest 9f0a777e5ff0 drm/i915: Fix Limited Range Color Handling == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7592/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove redundant ELD connector type update
== Series Details == Series: drm/i915: remove redundant ELD connector type update URL : https://patchwork.freedesktop.org/series/35853/ State : success == Summary == Series 35853v1 drm/i915: remove redundant ELD connector type update https://patchwork.freedesktop.org/api/1.0/series/35853/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> PASS (fi-elk-e7500) fdo#103989 +2 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-kbl-r) fdo#104172 +1 Test kms_psr_sink_crc: Subgroup psr_basic: pass -> DMESG-WARN (fi-skl-6700hq) fdo#101144 Test prime_vgem: Subgroup basic-fence-flip: fail -> PASS (fi-bwr-2160) fdo#103182 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#103182 https://bugs.freedesktop.org/show_bug.cgi?id=103182 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:437s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:384s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:496s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:274s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:493s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:495s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:473s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:464s fi-elk-e7500 total:224 pass:163 dwarn:15 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:262s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:532s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:401s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:412s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:422s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:479s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:426s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:480s fi-kbl-7560u total:288 pass:268 dwarn:1 dfail:0 fail:0 skip:19 time:523s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:464s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:523s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:579s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:437s fi-skl-6600u total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:531s fi-skl-6700hqtotal:288 pass:261 dwarn:1 dfail:0 fail:0 skip:26 time:554s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:510s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:497s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:447s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:554s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:406s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:598s fi-cnl-y total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:644s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:482s 8cb9e9870b50ddf65ebe233d38194cafdd811d03 drm-tip: 2017y-12m-28d-17h-00m-27s UTC integration manifest f7024e1c0874 drm/i915: remove redundant ELD connector type update == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7591/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 3/3] tests/kms_cursor_legacy: Rework the 2x-*-vs-cursor-* tests.
Op 22-12-17 om 09:55 schreef Mika Kahola: > On Thu, 2017-12-07 at 14:40 +0100, Maarten Lankhorst wrote: >> Using the fancy new DRM_CAP_CRTC_IN_VBLANK_EVENT cap I can finally >> make this test the work I originally intended to. >> >> For the !modeset case that means performing a pageflip on both >> crtc's, >> then requeueing as soon as the event is delivered and then check the >> vblank counter against the original value, it should be advanced by >> 1. >> >> The modeset case is slightly more complicated, ideally it's handled >> the same, but if we can't perform a modeset and pageflip at the same >> time, fall back to queueing both in a single commit, in which case >> we can say nothing about the vblank counter. >> >> There is a small race between flip_done and hw_done, so make >> flip_nonblocking retry for a second when encountering -EBUSY. >> > Reviewed-by: Mika Kahola Thanks, pushed. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
