[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Implement display WA #1142:kbl, cfl, cml
== Series Details == Series: drm/i915: Implement display WA #1142:kbl, cfl, cml URL : https://patchwork.freedesktop.org/series/82073/ State : success == Summary == CI Bug Log - changes from CI_DRM_9053_full -> Patchwork_18569_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18569_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#198]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl7/igt@gem_ctx_isolation@preservation...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-skl5/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@i915_selftest@mock@contexts: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([i915#1635] / [i915#2278]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-apl8/igt@i915_selftest@m...@contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-apl1/igt@i915_selftest@m...@contexts.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#198] / [i915#2278]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl4/igt@i915_selftest@m...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-skl2/igt@i915_selftest@m...@requests.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#300]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl10/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-skl9/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [i915#265]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@psr2_suspend: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-iclb2/igt@kms_psr@psr2_suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-iclb4/igt@kms_psr@psr2_suspend.html * igt@kms_setmode@basic: - shard-apl: [PASS][15] -> [FAIL][16] ([i915#1635] / [i915#31]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-apl1/igt@kms_setm...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-apl7/igt@kms_setm...@basic.html - shard-skl: [PASS][17] -> [FAIL][18] ([i915#31]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl8/igt@kms_setm...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-skl7/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-kbl1/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-kbl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@kms_vblank@pipe-b-query-busy: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / [i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-apl6/igt@kms_vbl...@pipe-b-query-busy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-apl3/igt@kms_vbl...@pipe-b-query-busy.html * igt@kms_vblank@pipe-d-wait-idle: - shard-tglb: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-tglb3/igt@kms_vbl...@pipe-d-wait-idle.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/shard-tglb2/igt@kms_vbl...@pipe-d-wait-idle.html * igt@perf@polling-parameterized: - shard-glk: [PASS][25] -> [FAIL][26] ([i915#1542]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-glk4/igt@p...@polling-parameterized.html [26]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add plane .{min, max}_width() and .max_height() vfuncs
== Series Details ==
Series: drm/i915: Add plane .{min, max}_width() and .max_height() vfuncs
URL : https://patchwork.freedesktop.org/series/82071/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9053_full -> Patchwork_18568_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_18568_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-iclb2/igt@feature_discov...@psr2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-iclb3/igt@feature_discov...@psr2.html
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#198])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl7/igt@gem_ctx_isolation@preservation...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-skl9/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][5] -> [SKIP][6] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-tglb3/igt@gem_huc_c...@huc-copy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-tglb6/igt@gem_huc_c...@huc-copy.html
* igt@i915_module_load@reload:
- shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +6 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl4/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-skl5/igt@i915_module_l...@reload.html
* igt@i915_selftest@mock@contexts:
- shard-apl: [PASS][9] -> [INCOMPLETE][10] ([i915#1635] /
[i915#2278])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-apl8/igt@i915_selftest@m...@contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-apl6/igt@i915_selftest@m...@contexts.html
* igt@kms_flip@flip-vs-expired-vblank@b-edp1:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#79])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl4/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html
* igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +3
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1:
- shard-skl: [PASS][15] -> [FAIL][16] ([i915#2122])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-skl1/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
* igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping:
- shard-iclb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-iclb5/igt@kms_plane_scal...@pipe-b-scaler-with-clipping-clamping.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-iclb3/igt@kms_plane_scal...@pipe-b-scaler-with-clipping-clamping.html
* igt@kms_psr@psr2_suspend:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-iclb2/igt@kms_psr@psr2_suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-iclb4/igt@kms_psr@psr2_suspend.html
* igt@kms_setmode@basic:
- shard-skl: [PASS][23] -> [FAIL][24] ([i915#31])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl8/igt@kms_setm...@basic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/shard-skl10/igt@kms_setm...@basic.html
* igt@kms_vblank@pipe-d-wait-idle:
- shard-tglb: [PASS][25] -> [DMESG-WARN][26] ([i915#1982]) +1
similar issue
[25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add support for LTTPR non-transparent link training mode (rev2)
== Series Details == Series: drm/i915: Add support for LTTPR non-transparent link training mode (rev2) URL : https://patchwork.freedesktop.org/series/81968/ State : success == Summary == CI Bug Log - changes from CI_DRM_9053_full -> Patchwork_18567_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18567_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-iclb2/igt@feature_discov...@psr2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-iclb1/igt@feature_discov...@psr2.html * igt@i915_selftest@live@gt_heartbeat: - shard-skl: [PASS][3] -> [DMESG-FAIL][4] ([i915#541]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl7/igt@i915_selftest@live@gt_heartbeat.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-skl6/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#72]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl10/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-skl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#79]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#2122]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-skl6/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / [i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-apl3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-pgflip-blt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-apl1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-pgflip-blt.html * igt@kms_psr@psr2_suspend: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-iclb2/igt@kms_psr@psr2_suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-iclb4/igt@kms_psr@psr2_suspend.html * igt@kms_setmode@basic: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#31]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl8/igt@kms_setm...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-skl3/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-d-wait-idle: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-tglb3/igt@kms_vbl...@pipe-d-wait-idle.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-tglb7/igt@kms_vbl...@pipe-d-wait-idle.html Possible fixes * igt@gem_ctx_param@vm: - shard-skl: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +5 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-skl10/igt@gem_ctx_pa...@vm.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/shard-skl6/igt@gem_ctx_pa...@vm.html * igt@gem_ctx_persistence@engines-mixed-process@rcs0: - shard-glk: [FAIL][23] ([i915#2374]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/shard-glk7/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html [24]:
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
cc back a few others who were unintentionally dropped from the thread earlier.
Someone (at Google) helped me dig into this a little more and they
found a document titled "eDP Backlight Brightness bit alignment" sent
out for review in January 2017. I registered for a new account (google
is a member) and have access to the document; here is the URL for
those who also have access:
https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth,
it seems like Lyude's contact Bill Lempesis uploaded this
change-request document, so I think we can reach out to him if we have
further questions. It's actually unclear to me what the status of this
change request is, and whether it's been officially accepted. But I
think it can be seen as some official advice on how we can move
forward here.
Basically, this is a change request to the spec which acknowledges
that, despite the original spec implying that the
most-significant-bits were relevant here, many implementations used
the least-significant-bits. In defense of most-significant it laid out
some similar arguments to what Ville was saying. But it ends up
saying:
> Unfortunately, the most common interpretation that we have
> encountered is case 1 in the example above. TCON vendors
> tend to align the valid bits to the LSBs, not the MSBs.
Instead of changing the default defined functionality (as some earlier
version of this doc apparently suggested), this doc prefers to
allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future
backlight devices can specify to the Source how to program them:
00: the current functionality, i,e. no defined interpretation
01: aligned to most-significant bits
10: aligned to least-significant bits
11: reserved
It also says "[Sources] should only need panel-specific workarounds
for the currently available panels."
So I believe this document is an acknowledgement of many
implementations having their alignment to the least-significant bits,
and (to my eyes) clearly validates that the spec "should" be the
opposite. If we believe the doc's claim that "the most common
interpretation" is least-significant, it seems to me that it would
require more quirks if we made most-significant the default
implementation.
Ville mentioned at some point earlier that we should try to match the
spec, whereas Lyude mentioned we should prefer to do what the majority
of machines do. What do you both think of this new development?
I will also look into whether my specific device supports this
extension, and in that case I'll volunteer to implement this new
functionality in the driver.
Thanks for your time,
Kevin
On Tue, Sep 22, 2020 at 3:30 PM Lyude Paul wrote:
>
> Hi! Since I got dropped from the thread, many responses inline
>
> On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> > +Lyude
> > I notice that Lyude email was somehow dropped from the thread.
> > Lyude was the person who submitted the patch for Thinkpad and should
> > know the OUI of the panel.
>
> no need - currently because of some confusion that got caused by the Intel HDR
> backlight interface being the only backlight interface that works properly on
> a lot of panels (many panels will advertise both interfaces, but might only
> work with the Intel one), we actually rely on a small allowlist of "approved"
> panels for enabling DPCD backlight control.
>
> …however, many of these panels are annoying and don't actually provide a
> reliable enough OUID to use for quirk detection, which is why we had to add
> EDID quirk detection as a temporary workaround for this. The current list of
> panels lives in drm_dp_helper.c:
>
> /*
> * Some devices have unreliable OUIDs where they don't set the device ID
> * correctly, and as a result we need to use the EDID for finding additional
> * DP quirks in such cases.
> */
> static const struct edid_quirk edid_quirk_list[] = {
> /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
> * only supports DPCD backlight controls
> */
> { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> /*
> * Some Dell CML 2020 systems have panels support both AUX and PWM
> * backlight control, and some only support AUX backlight control. All
> * said panels start up in AUX mode by default, and we don't have any
> * support for disabling HDR mode on these panels which would be
> * required to switch to PWM backlight control mode (plus, I'm not
> * even sure we want PWM backlight controls over DPCD backlight
> * controls anyway...). Until we have a better way of detecting these,
> * force DPCD backlight mode on all of them.
> */
> { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement display WA #1142:kbl, cfl, cml
== Series Details ==
Series: drm/i915: Implement display WA #1142:kbl, cfl, cml
URL : https://patchwork.freedesktop.org/series/82073/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9053 -> Patchwork_18569
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/index.html
Known issues
Here are the changes found in Patchwork_18569 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
* igt@vgem_basic@unload:
- fi-kbl-x1275: [PASS][9] -> [DMESG-WARN][10] ([i915#62] / [i915#92]
/ [i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-kbl-x1275/igt@vgem_ba...@unload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-kbl-x1275/igt@vgem_ba...@unload.html
Possible fixes
* {igt@core_hotunplug@unbind-rebind}:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
* igt@gem_flink_basic@basic:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@gem_flink_ba...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_module_load@reload:
- {fi-ehl-1}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-ehl-1/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-ehl-1/igt@i915_module_l...@reload.html
- fi-tgl-y: [DMESG-WARN][17] ([i915#1982] / [k.org#205379]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-tgl-y: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@kms_busy@ba...@flip.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18569/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-y: [DMESG-WARN][25] ([i915#2411]) -> [DMESG-WARN][26]
([i915#2411] / [i915#402])
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
[26]:
Re: [Intel-gfx] [PATCH] drm/i915: Uninitialized variable in i915_gem_object_map_page()
Hi Dan,
On Thu, 24 Sep 2020 11:18:30 +0300 Dan Carpenter
wrote:
>
> The "i" iterator is never set to zero. This probably doesn't affect
> testing because GCC sometimes initializes variables and also we have a
> new pluggin to initialize stack variables to zero.
>
> Fixes: 7edd32a9e614 ("drm/i915: use vmap in i915_gem_object_map")
> Signed-off-by: Dan Carpenter
> ---
> Hi Andrew, this should probably go through the -mm tree and get folded
> into the original patch.
Added to linux-next today.
--
Cheers,
Stephen Rothwell
pgp88gODqn6_D.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v9,01/11] HAX to make DSC work on the icelake test system
== Series Details == Series: series starting with [v9,01/11] HAX to make DSC work on the icelake test system URL : https://patchwork.freedesktop.org/series/82068/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9050_full -> Patchwork_18566_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18566_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18566_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18566_full: ### IGT changes ### Possible regressions * igt@kms_flip@2x-nonexisting-fb-interruptible@ac-vga1-hdmi-a1: - shard-hsw: NOTRUN -> [INCOMPLETE][1] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-hsw4/igt@kms_flip@2x-nonexisting-fb-interrupti...@ac-vga1-hdmi-a1.html Known issues Here are the changes found in Patchwork_18566_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-glk: [PASS][2] -> [FAIL][3] ([i915#2389]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-glk7/igt@gem_exec_reloc@basic-many-act...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-glk3/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_whisper@basic-fds-forked-all: - shard-glk: [PASS][4] -> [DMESG-WARN][5] ([i915#118] / [i915#95]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-glk1/igt@gem_exec_whis...@basic-fds-forked-all.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-glk4/igt@gem_exec_whis...@basic-fds-forked-all.html * igt@gem_userptr_blits@process-exit-busy: - shard-skl: [PASS][6] -> [DMESG-WARN][7] ([i915#1982]) +12 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl4/igt@gem_userptr_bl...@process-exit-busy.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-skl4/igt@gem_userptr_bl...@process-exit-busy.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-skl: [PASS][8] -> [TIMEOUT][9] ([i915#1958] / [i915#2424]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl4/igt@gem_userptr_bl...@sync-unmap-cycles.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-skl4/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][10] -> [TIMEOUT][11] ([i915#1958]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl5/igt@gem_userptr_bl...@unsync-unmap-cycles.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-skl5/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1436] / [i915#716]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl10/igt@gen9_exec_pa...@allowed-single.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-skl6/igt@gen9_exec_pa...@allowed-single.html * igt@kms_cursor_legacy@cursor-vs-flip-toggle: - shard-hsw: [PASS][14] -> [FAIL][15] ([i915#2370]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-hsw7/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html * igt@kms_flip@flip-vs-suspend@a-vga1: - shard-hsw: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-hsw1/igt@kms_flip@flip-vs-susp...@a-vga1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-hsw6/igt@kms_flip@flip-vs-susp...@a-vga1.html * igt@kms_flip@plain-flip-ts-check@a-dp1: - shard-kbl: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-kbl1/igt@kms_flip@plain-flip-ts-ch...@a-dp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/shard-kbl4/igt@kms_flip@plain-flip-ts-ch...@a-dp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html [21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add plane .{min, max}_width() and .max_height() vfuncs
== Series Details ==
Series: drm/i915: Add plane .{min, max}_width() and .max_height() vfuncs
URL : https://patchwork.freedesktop.org/series/82071/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9053 -> Patchwork_18568
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/index.html
Known issues
Here are the changes found in Patchwork_18568 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- fi-tgl-y: [PASS][3] -> [INCOMPLETE][4] ([i915#2089] /
[i915#2268])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-tgl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92] /
[i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@vgem_ba...@setversion.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-tgl-y/igt@vgem_ba...@setversion.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][11] -> [DMESG-WARN][12] ([i915#2203])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-skl-guc/igt@vgem_ba...@unload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-ehl-1}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-ehl-1/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-ehl-1/igt@i915_module_l...@reload.html
- fi-tgl-y: [DMESG-WARN][15] ([i915#1982] / [k.org#205379]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [DMESG-WARN][23] ([i915#402]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) ->
[DMESG-WARN][26] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18568/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
*
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add support for LTTPR non-transparent link training mode (rev2)
== Series Details ==
Series: drm/i915: Add support for LTTPR non-transparent link training mode
(rev2)
URL : https://patchwork.freedesktop.org/series/81968/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9053 -> Patchwork_18567
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/index.html
Known issues
Here are the changes found in Patchwork_18567 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@vgem_ba...@setversion.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-tgl-y/igt@vgem_ba...@setversion.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-skl-guc/igt@vgem_ba...@unload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@gem_flink_basic@basic:
- fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@gem_flink_ba...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_module_load@reload:
- {fi-ehl-1}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-ehl-1/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-ehl-1/igt@i915_module_l...@reload.html
- fi-tgl-y: [DMESG-WARN][13] ([i915#1982] / [k.org#205379]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][15] ([i915#62] / [i915#95]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-tgl-y/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_flip@basic-flip-vs-modeset@b-dp1:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[PASS][24] +35 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18567/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][26] +7 similar issues
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9053/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[26]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Nuke lspcon_downsampling
== Series Details == Series: series starting with [1/3] drm/i915: Nuke lspcon_downsampling URL : https://patchwork.freedesktop.org/series/82067/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9050_full -> Patchwork_18565_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18565_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18565_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18565_full: ### IGT changes ### Possible regressions * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-glk: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-glk2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-glk1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html Known issues Here are the changes found in Patchwork_18565_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2389]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-glk7/igt@gem_exec_reloc@basic-many-act...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-glk2/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-glk2/igt@gem_exec_whis...@basic-queues-priority.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-glk1/igt@gem_exec_whis...@basic-queues-priority.html * igt@gem_userptr_blits@process-exit-busy: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +10 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl4/igt@gem_userptr_bl...@process-exit-busy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-skl2/igt@gem_userptr_bl...@process-exit-busy.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#300]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl5/igt@kms_cursor_...@pipe-a-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#2122]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl10/igt@kms_flip@plain-flip-ts-check-interrupti...@b-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-skl6/igt@kms_flip@plain-flip-ts-check-interrupti...@b-edp1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-tglb3/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-tglb6/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#1779]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-iclb2/igt@kms_plane_multi...@atomic-pipe-c-tiling-yf.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-iclb7/igt@kms_plane_multi...@atomic-pipe-c-tiling-yf.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-iclb2/igt@kms_psr2_su@page_flip.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-iclb6/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_vblank@pipe-b-query-busy: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / [i915#1982]) [21]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add support for LTTPR non-transparent link training mode (rev2)
== Series Details == Series: drm/i915: Add support for LTTPR non-transparent link training mode (rev2) URL : https://patchwork.freedesktop.org/series/81968/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:598:21:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/3] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
== Series Details ==
Series: series starting with [v4,1/3] drm/i915/display: Ignore
IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
URL : https://patchwork.freedesktop.org/series/82066/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9050_full -> Patchwork_18564_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_18564_full:
### Piglit changes ###
Possible regressions
*
spec@glsl-1.30@execution@interpolation@interpolation-flat-gl_frontsecondarycolor-smooth-distance
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [CRASH][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/pig-icl-1065g7/spec@glsl-1.30@execution@interpolation@interpolation-flat-gl_frontsecondarycolor-smooth-distance.html
*
spec@glsl-1.30@execution@interpolation@interpolation-smooth-other-smooth-distance
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][2] +7 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/pig-icl-1065g7/spec@glsl-1.30@execution@interpolat...@interpolation-smooth-other-smooth-distance.html
New tests
-
New tests have been introduced between CI_DRM_9050_full and
Patchwork_18564_full:
### New Piglit tests (10) ###
*
spec@glsl-1.30@execution@interpolation@interpolation-flat-gl_backcolor-smooth-none:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-1.30@execution@interpolation@interpolation-flat-gl_backsecondarycolor-flat-distance:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-1.30@execution@interpolation@interpolation-flat-gl_frontcolor-flat-fixed:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-1.30@execution@interpolation@interpolation-flat-gl_frontsecondarycolor-smooth-distance:
- Statuses : 1 crash(s)
- Exec time: [0.34] s
*
spec@glsl-1.30@execution@interpolation@interpolation-none-gl_frontsecondarycolor-smooth-distance:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-1.30@execution@interpolation@interpolation-noperspective-gl_backcolor-flat-fixed:
- Statuses : 1 crash(s)
- Exec time: [0.37] s
*
spec@glsl-1.30@execution@interpolation@interpolation-noperspective-gl_backsecondarycolor-flat-vertex:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-1.30@execution@interpolation@interpolation-noperspective-gl_frontcolor-flat-vertex:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-1.30@execution@interpolation@interpolation-smooth-gl_backcolor-smooth-vertex:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-1.30@execution@interpolation@interpolation-smooth-other-smooth-distance:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18564_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_userptr_blits@unsync-unmap-cycles:
- shard-skl: [PASS][3] -> [TIMEOUT][4] ([i915#1958])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl5/igt@gem_userptr_bl...@unsync-unmap-cycles.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/shard-skl6/igt@gem_userptr_bl...@unsync-unmap-cycles.html
* igt@i915_selftest@mock@contexts:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#198] /
[i915#2278])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl10/igt@i915_selftest@m...@contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/shard-skl9/igt@i915_selftest@m...@contexts.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +7 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl7/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/shard-skl2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@busy-flip@b-hdmi-a2:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#275])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-glk8/igt@kms_flip@busy-f...@b-hdmi-a2.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/shard-glk2/igt@kms_flip@busy-f...@b-hdmi-a2.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-edp1:
- shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#198]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/shard-skl3/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html
[12]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/11] mm: update the documentation for vfree
== Series Details == Series: series starting with [01/11] mm: update the documentation for vfree URL : https://patchwork.freedesktop.org/series/82063/ State : success == Summary == CI Bug Log - changes from CI_DRM_9049_full -> Patchwork_18563_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18563_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-iclb2/igt@feature_discov...@psr2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-iclb7/igt@feature_discov...@psr2.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2389]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-glk4/igt@gem_exec_reloc@basic-many-act...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-glk3/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_whisper@basic-fds-forked-all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-glk6/igt@gem_exec_whis...@basic-fds-forked-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-glk9/igt@gem_exec_whis...@basic-fds-forked-all.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][7] -> [SKIP][8] ([i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-tglb1/igt@gem_huc_c...@huc-copy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-skl: [PASS][9] -> [TIMEOUT][10] ([i915#1958] / [i915#2424]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl4/igt@gem_userptr_bl...@sync-unmap-cycles.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl5/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#198] / [i915#2278]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl2/igt@i915_selftest@m...@requests.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl9/igt@i915_selftest@m...@requests.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +6 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl10/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@flip-vs-suspend@b-edp1: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#198]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl10/igt@kms_flip@flip-vs-susp...@b-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl1/igt@kms_flip@flip-vs-susp...@b-edp1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-tglb7/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-tglb1/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_psr@psr2_suspend: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-iclb2/igt@kms_psr@psr2_suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-iclb7/igt@kms_psr@psr2_suspend.html Possible fixes * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [DMESG-WARN][21] ([i915#118] / [i915#95]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-glk5/igt@gem_exec_whis...@basic-queues-priority.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-glk4/igt@gem_exec_whis...@basic-queues-priority.html * igt@gen9_exec_parse@allowed-all: - shard-kbl: [DMESG-WARN][23] ([i915#1436] / [i915#716]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-kbl1/igt@gen9_exec_pa...@allowed-all.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-kbl7/igt@gen9_exec_pa...@allowed-all.html * igt@i915_module_load@reload: - shard-apl:
Re: [Intel-gfx] [PATCH] drm/i915: Implement display WA #1142:kbl, cfl, cml
On Thu, 2020-09-24 at 22:48 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> Implement display w/a #1142. This supposedly fixes some underruns
> with FBC+VTd. Bspec says we should use the same programming regardless
> of circumstances. Apparently we should flip the magic bits before
> turning on any planes so let's put this into the early w/as.
>
> Cc: Lee Shawn C <
> shawn.c@intel.com
> >
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 9 +
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5a9d933e425a..9d64187cfd56 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -18677,6 +18677,15 @@ static void intel_early_display_was(struct
> drm_i915_private *dev_priv)
> intel_de_write(dev_priv, CHICKEN_PAR1_1,
> intel_de_read(dev_priv, CHICKEN_PAR1_1) |
> FORCE_ARB_IDLE_PLANES);
> }
> +
> + if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> IS_COMETLAKE(dev_priv)) {
WA mentions that it is required only for KBL, but if Lee says that this helps
with his CML issues.
Reviewed-by: José Roberto de Souza
> + /* Display WA #1142:kbl,cfl,cml */
> + intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> + KBL_ARB_FILL_SPARE_22, KBL_ARB_FILL_SPARE_22);
> + intel_de_rmw(dev_priv, CHICKEN_MISC_2,
> + KBL_ARB_FILL_SPARE_13 | KBL_ARB_FILL_SPARE_14,
> + KBL_ARB_FILL_SPARE_14);
> + }
> }
>
> static void ibx_sanitize_pch_hdmi_port(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d805d4da6181..3f97cc0fcbf1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7865,6 +7865,7 @@ enum {
> # define CHICKEN3_DGMG_DONE_FIX_DISABLE (1 << 2)
>
> #define CHICKEN_PAR1_1 _MMIO(0x42080)
> +#define KBL_ARB_FILL_SPARE_22 REG_BIT(22)
> #define DIS_RAM_BYPASS_PSR2_MAN_TRACK (1 << 16)
> #define SKL_DE_COMPRESSED_HASH_MODE (1 << 15)
> #define DPA_MASK_VBLANK_SRD (1 << 15)
> @@ -7877,6 +7878,8 @@ enum {
>
> #define CHICKEN_MISC_2 _MMIO(0x42084)
> #define CNL_COMP_PWR_DOWN (1 << 23)
> +#define KBL_ARB_FILL_SPARE_14 REG_BIT(14)
> +#define KBL_ARB_FILL_SPARE_13 REG_BIT(13)
> #define GLK_CL2_PWR_DOWN(1 << 12)
> #define GLK_CL1_PWR_DOWN(1 << 11)
> #define GLK_CL0_PWR_DOWN(1 << 10)
>
___
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 [v9,01/11] HAX to make DSC work on the icelake test system
== Series Details ==
Series: series starting with [v9,01/11] HAX to make DSC work on the icelake
test system
URL : https://patchwork.freedesktop.org/series/82068/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9050 -> Patchwork_18566
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/index.html
Known issues
Here are the changes found in Patchwork_18566 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_blits@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-tgl-y/igt@gem_tiled_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-tgl-y/igt@gem_tiled_bl...@basic.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-dpms@a-edp1:
- fi-tgl-y: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-tgl-y/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-tgl-y/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][17] ([i915#2203]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-skl-guc/igt@vgem_ba...@unload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +4 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18566/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#1982]:
[Intel-gfx] [PATCH] drm/i915: Implement display WA #1142:kbl, cfl, cml
From: Ville Syrjälä
Implement display w/a #1142. This supposedly fixes some underruns
with FBC+VTd. Bspec says we should use the same programming regardless
of circumstances. Apparently we should flip the magic bits before
turning on any planes so let's put this into the early w/as.
Cc: Lee Shawn C
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..9d64187cfd56 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -18677,6 +18677,15 @@ static void intel_early_display_was(struct
drm_i915_private *dev_priv)
intel_de_write(dev_priv, CHICKEN_PAR1_1,
intel_de_read(dev_priv, CHICKEN_PAR1_1) |
FORCE_ARB_IDLE_PLANES);
}
+
+ if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
IS_COMETLAKE(dev_priv)) {
+ /* Display WA #1142:kbl,cfl,cml */
+ intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
+KBL_ARB_FILL_SPARE_22, KBL_ARB_FILL_SPARE_22);
+ intel_de_rmw(dev_priv, CHICKEN_MISC_2,
+KBL_ARB_FILL_SPARE_13 | KBL_ARB_FILL_SPARE_14,
+KBL_ARB_FILL_SPARE_14);
+ }
}
static void ibx_sanitize_pch_hdmi_port(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d805d4da6181..3f97cc0fcbf1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7865,6 +7865,7 @@ enum {
# define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
#define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define KBL_ARB_FILL_SPARE_22 REG_BIT(22)
#define DIS_RAM_BYPASS_PSR2_MAN_TRACK (1 << 16)
#define SKL_DE_COMPRESSED_HASH_MODE (1 << 15)
#define DPA_MASK_VBLANK_SRD (1 << 15)
@@ -7877,6 +7878,8 @@ enum {
#define CHICKEN_MISC_2 _MMIO(0x42084)
#define CNL_COMP_PWR_DOWN (1 << 23)
+#define KBL_ARB_FILL_SPARE_14 REG_BIT(14)
+#define KBL_ARB_FILL_SPARE_13 REG_BIT(13)
#define GLK_CL2_PWR_DOWN (1 << 12)
#define GLK_CL1_PWR_DOWN (1 << 11)
#define GLK_CL0_PWR_DOWN (1 << 10)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v9,01/11] HAX to make DSC work on the icelake test system
== Series Details == Series: series starting with [v9,01/11] HAX to make DSC work on the icelake test system URL : https://patchwork.freedesktop.org/series/82068/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v9,01/11] HAX to make DSC work on the icelake test system
== Series Details ==
Series: series starting with [v9,01/11] HAX to make DSC work on the icelake
test system
URL : https://patchwork.freedesktop.org/series/82068/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
82d24d08f989 HAX to make DSC work on the icelake test system
88e15167a8c1 drm/i915/display: Rename pipe_timings to transcoder_timings
-:11: WARNING:TYPO_SPELLING: 'halfs' may be misspelled - perhaps 'halves'?
#11:
With Bigjoiner, there are 2 pipes driving 2 halfs of 1
total: 0 errors, 1 warnings, 0 checks, 82 lines checked
272de0c782b9 drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
-:7: WARNING:TYPO_SPELLING: 'halfs' may be misspelled - perhaps 'halves'?
#7:
With bigjoiner, there will be 2 pipes driving 2 halfs of 1 transcoder,
-:134: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#134: FILE: drivers/gpu/drm/i915/display/intel_display.c:13289:
+ crtc_state->hw.pipe_mode = crtc_state->hw.adjusted_mode =
crtc_state->uapi.adjusted_mode;
total: 0 errors, 1 warnings, 1 checks, 364 lines checked
0abe7d3083f0 drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
d44b7997fa69 drm/i915: Try to make bigjoiner work in atomic check
-:145: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#145: FILE: drivers/gpu/drm/i915/display/intel_display.c:13301:
+
crtc_state->bigjoiner_linked_crtc);
-:205: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#205: FILE: drivers/gpu/drm/i915/display/intel_display.c:13372:
+ crtc_state->nv12_planes = crtc_state->c8_planes =
crtc_state->update_planes = 0;
-:300: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#300: FILE: drivers/gpu/drm/i915/display/intel_display.c:14974:
+ slave = new_crtc_state->bigjoiner_linked_crtc =
-:334: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#334: FILE: drivers/gpu/drm/i915/display/intel_display.c:15008:
+ slave_crtc_state->bigjoiner = master_crtc_state->bigjoiner =
false;
-:335: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#335: FILE: drivers/gpu/drm/i915/display/intel_display.c:15009:
+ slave_crtc_state->bigjoiner_slave =
master_crtc_state->bigjoiner_slave = false;
-:336: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#336: FILE: drivers/gpu/drm/i915/display/intel_display.c:15010:
+ slave_crtc_state->bigjoiner_linked_crtc =
master_crtc_state->bigjoiner_linked_crtc = NULL;
-:336: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#336: FILE: drivers/gpu/drm/i915/display/intel_display.c:15010:
+ slave_crtc_state->bigjoiner_linked_crtc =
master_crtc_state->bigjoiner_linked_crtc = NULL;
-:391: WARNING:BRACES: braces {} are not necessary for any arm of this statement
#391: FILE: drivers/gpu/drm/i915/display/intel_display.c:15405:
+ if (new_crtc_state->bigjoiner) {
[...]
+ } else if (INTEL_GEN(dev_priv) >= 9)
[...]
else
[...]
total: 0 errors, 3 warnings, 5 checks, 403 lines checked
0e7a5e2ca045 drm/i915: Enable big joiner support in enable and disable
sequences.
-:178: WARNING:LONG_LINE_COMMENT: line length of 106 exceeds 100 columns
#178: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:4452:
+ /* Our own transcoder needs to be disabled when reading it in
intel_ddi_read_func_ctl() */
-:180: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#180: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:4454:
+ pipe_config->cpu_transcoder = (enum
transcoder)pipe_config->bigjoiner_linked_crtc->pipe;
-:829: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#829: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:826:
+#define PIPE_CONFIG_QUIRK_BIGJOINER_SLAVE (1<<1) /* bigjoiner slave,
partial readout */
^
total: 0 errors, 2 warnings, 1 checks, 1031 lines checked
94713c471ecf drm/i915: Make hardware readout work on i915.
-:33: WARNING:TABSTOP: Statements should start on a tabstop
#33: FILE: drivers/gpu/drm/i915/display/intel_display.c:3611:
+struct intel_crtc_state *crtc_state =
-:76: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#76: FILE: drivers/gpu/drm/i915/display/intel_display.c:10751:
+ (intel_de_read(dev_priv, PLANE_SURF(pipe, plane_id)) &
0xf000) == plane_config->base) {
total: 0 errors, 2 warnings, 0 checks, 118 lines checked
1fe02779c38a drm/i915: Link planes in a bigjoiner configuration, v3.
-:206: ERROR:CODE_INDENT: code indent should use tabs where possible
#206: FILE: drivers/gpu/drm/i915/display/intel_display.c:12692:
+ * Setup and teardown the new bigjoiner plane mappings.$
-:207: ERROR:CODE_INDENT: code indent should use tabs where possible
#207: FILE: drivers/gpu/drm/i915/display/intel_display.c:12693:
+ */$
-:292:
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On 9/24/20 10:27 AM, pet...@infradead.org wrote: > So my current todo list is: > > - Change RT PULL > - Change DL PULL > - Add migrate_disable() tracer; exactly like preempt/irqoff, except >measuring task-runtime instead of cpu-time. > - Add a mode that measures actual interference. > - Add a traceevent to detect preemption in migrate_disable(). > > > And then I suppose I should twist Daniel's arm to update his model to > include these scenarios and numbers. Challenge accepted :-) -- Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Add support for mipi dsi cmd mode (rev14)
== Series Details == Series: Add support for mipi dsi cmd mode (rev14) URL : https://patchwork.freedesktop.org/series/69290/ State : success == Summary == CI Bug Log - changes from CI_DRM_9048_full -> Patchwork_18562_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18562_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][1] -> [TIMEOUT][2] ([i915#1958]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-skl1/igt@gem_userptr_bl...@unsync-unmap-cycles.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-skl5/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-skl10/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-skl7/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-kbl4/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-kbl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#2122]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-skl9/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-skl2/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-wc: - shard-iclb: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-wc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#1188]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-skl3/igt@kms_...@bpc-switch-dpms.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-skl6/igt@kms_...@bpc-switch-dpms.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#198]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-skl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-skl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html * igt@kms_psr@psr2_suspend: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-iclb2/igt@kms_psr@psr2_suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-iclb6/igt@kms_psr@psr2_suspend.html * igt@perf@polling-small-buf: - shard-iclb: [PASS][19] -> [FAIL][20] ([i915#1722]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-iclb7/igt@p...@polling-small-buf.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-iclb3/igt@p...@polling-small-buf.html * igt@perf_pmu@module-unload: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / [i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-apl2/igt@perf_...@module-unload.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/shard-apl4/igt@perf_...@module-unload.html Possible fixes * igt@gem_ctx_param@vm: - shard-skl: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24] +7 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/shard-skl2/igt@gem_ctx_pa...@vm.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Nuke lspcon_downsampling
== Series Details ==
Series: series starting with [1/3] drm/i915: Nuke lspcon_downsampling
URL : https://patchwork.freedesktop.org/series/82067/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9050 -> Patchwork_18565
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/index.html
Known issues
Here are the changes found in Patchwork_18565 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-dpms@a-edp1:
- fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-tgl-y/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/fi-tgl-y/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Warnings
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][15] ([fdo#109271]) -> [INCOMPLETE][16]
([i915#151] / [i915#2377])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18565/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2377]: https://gitlab.freedesktop.org/drm/intel/issues/2377
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (46 -> 39)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-kbl-x1275 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9050 -> Patchwork_18565
CI-20190529: 20190529
CI_DRM_9050: 9a9b636c74cacd2a9fe8c693792998d8d5983e24 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18565: 5ef7b809b94c7d3923a98c7d06a01dd852d352f3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5ef7b809b94c drm/i915: Inline intel_dp_ycbcr420_config()
ab04223e393a drm/i915: Nuke
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: Nuke lspcon_downsampling
== Series Details == Series: series starting with [1/3] drm/i915: Nuke lspcon_downsampling URL : https://patchwork.freedesktop.org/series/82067/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Thu, 24 Sep 2020 19:55:10 +0200 Thomas Gleixner wrote: > On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote: > > On Thu, 24 Sep 2020 08:57:52 +0200 > > Thomas Gleixner wrote: > > > >> > Now as for migration disabled nesting, at least now we would have > >> > groupings of this, and perhaps the theorists can handle that. I mean, > >> > how is this much different that having a bunch of tasks blocked on a > >> > mutex with the owner is pinned on a CPU? > >> > > >> > migrate_disable() is a BKL of pinning affinity. > >> > >> No. That's just wrong. preempt disable is a concurrency control, > > > > I think you totally misunderstood what I was saying. The above wasn't about > > comparing preempt_disable to migrate_disable. It was comparing > > migrate_disable to a chain of tasks blocked on mutexes where the top owner > > has preempt_disable set. You still have a bunch of tasks that can't move to > > other CPUs. > > What? The top owner does not prevent any task from moving. The tasks > cannot move because they are blocked on the mutex, which means they are > not runnable and non runnable tasks are not migrated at all. And neither are migrated disabled tasks preempted by a high priority task. > > I really don't understand what you are trying to say. Don't worry about it. I was just making a high level comparison of how migrate disabled tasks blocked on a higher priority task is similar to that of tasks blocked on a mutex held by a pinned task that is preempted by a high priority task. But we can forget this analogy as it's not appropriate for the current conversation. > > >> > If we only have local_lock() available (even on !RT), then it makes > >> > the blocking in groups. At least this way you could grep for all the > >> > different local_locks in the system and plug that into the algorithm > >> > for WCS, just like one would with a bunch of mutexes. > >> > >> You cannot do that on RT at all where migrate disable is substituting > >> preempt disable in spin and rw locks. The result would be the same as > >> with a !RT kernel just with horribly bad performance. > > > > Note, the spin and rwlocks already have a lock associated with them. Why > > would it be any different on RT? I wasn't suggesting adding another lock > > inside a spinlock. Why would I recommend THAT? I wasn't recommending > > blindly replacing migrate_disable() with local_lock(). I just meant expose > > local_lock() but not migrate_disable(). > > We already exposed local_lock() to non RT and it's for places which do > preempt_disable() or local_irq_disable() without having a lock > associated. But both primitives are scope less and therefore behave like > CPU local BKLs. What local_lock() provides in these cases is: > > - Making the protection scope clear by associating a named local > lock which is coverred by lockdep. > > - It still maps to preempt_disable() or local_irq_disable() in !RT > kernels > > - The scope and the named lock allows RT kernels to substitute with > real (recursion aware) locking primitives which keep preemption and > interupts enabled, but provide the fine grained protection for the > scoped critical section. I'm very much aware of the above. > > So how would you substitute migrate_disable() with a local_lock()? You > can't. Again migrate_disable() is NOT a concurrency control and > therefore it cannot be substituted by any concurrency control primitive. When I was first writing my email, I was writing about a way to replace migrate_disable with a construct similar to local locks without actually mentioning local locks, but then rewrote it to state local locks, trying to simplify what I was writing. I shouldn't have done that, because it portrayed that I wanted to use local_lock() unmodified. I was actually thinking of a new construct that was similar but not exactly the same as local lock. But this will just make things more complex and we can forget about it. I'll wait to see what Peter produces. -- Steve ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Factor out a helper to disable the DPCD training pattern
On Thu, Sep 24, 2020 at 09:48:02PM +0300, Imre Deak wrote:
> To prepare for a follow-up LTTPR change factor out a helper to disable
> the training pattern in DPCD. We'll need to do this for each LTTPR
> (without programming the port to output the idle pattern) when training
> in LTTPR non-transparent mode.
>
> While at it also move the disable-link-training logic from
> intel_dp_set_link_train() to intel_dp_stop_link_train(), since the
> latter is the only user of this.
>
> v2:
> - Move the disable-link-training logic to intel_dp_stop_link_train()
> (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_dp_link_training.c | 32 +--
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 78b0f165fadd..38d4553670a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -91,25 +91,17 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> u8 dp_train_pat)
> {
> u8 buf[sizeof(intel_dp->train_set) + 1];
> - int ret, len;
> + int len;
>
> intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
>
> buf[0] = dp_train_pat;
> - if (intel_dp_training_pattern_symbol(dp_train_pat) ==
> - DP_TRAINING_PATTERN_DISABLE) {
> - /* don't write DP_TRAINING_LANEx_SET on disable */
> - len = 1;
> - } else {
> - /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
> - memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
> - len = intel_dp->lane_count + 1;
> - }
> + /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
> + memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
> + len = intel_dp->lane_count + 1;
>
> - ret = drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
> - buf, len);
> -
> - return ret == len;
> + return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
> + buf, len) == len;
Much nicer without the silly if() cluttering things.
Reviewed-by: Ville Syrjälä
> }
>
> static bool
> @@ -392,6 +384,13 @@ intel_dp_link_training_channel_equalization(struct
> intel_dp *intel_dp)
> return channel_eq;
> }
>
> +static bool intel_dp_disable_dpcd_training_pattern(struct intel_dp *intel_dp)
> +{
> + u8 val = DP_TRAINING_PATTERN_DISABLE;
> +
> + return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET, ,
> 1) == 1;
> +}
> +
> /**
> * intel_dp_stop_link_train - stop link training
> * @intel_dp: DP struct
> @@ -411,8 +410,9 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
> {
> intel_dp->link_trained = true;
>
> - intel_dp_set_link_train(intel_dp,
> - DP_TRAINING_PATTERN_DISABLE);
> + intel_dp_program_link_training_pattern(intel_dp,
> +DP_TRAINING_PATTERN_DISABLE);
> + intel_dp_disable_dpcd_training_pattern(intel_dp);
> }
>
> static bool
> --
> 2.25.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add plane .{min, max}_width() and .max_height() vfuncs
From: Ville Syrjälä
Reduce this maintenance nightmare a bit by converting the plane
min/max width/height stuff into vfuncs.
Now, if I could just think of a nice way to also use this for
intel_mode_valid_max_plane_size()...
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 194 +-
.../drm/i915/display/intel_display_types.h| 9 +
drivers/gpu/drm/i915/display/intel_sprite.c | 140 +
3 files changed, 196 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..a823d406f0ee 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3696,127 +3696,6 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
_intel_frontbuffer(fb)->bits);
}
-static int skl_max_plane_width(const struct drm_framebuffer *fb,
- int color_plane,
- unsigned int rotation)
-{
- int cpp = fb->format->cpp[color_plane];
-
- switch (fb->modifier) {
- case DRM_FORMAT_MOD_LINEAR:
- case I915_FORMAT_MOD_X_TILED:
- /*
-* Validated limit is 4k, but has 5k should
-* work apart from the following features:
-* - Ytile (already limited to 4k)
-* - FP16 (already limited to 4k)
-* - render compression (already limited to 4k)
-* - KVMR sprite and cursor (don't care)
-* - horizontal panning (TODO verify this)
-* - pipe and plane scaling (TODO verify this)
-*/
- if (cpp == 8)
- return 4096;
- else
- return 5120;
- case I915_FORMAT_MOD_Y_TILED_CCS:
- case I915_FORMAT_MOD_Yf_TILED_CCS:
- case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
- /* FIXME AUX plane? */
- case I915_FORMAT_MOD_Y_TILED:
- case I915_FORMAT_MOD_Yf_TILED:
- if (cpp == 8)
- return 2048;
- else
- return 4096;
- default:
- MISSING_CASE(fb->modifier);
- return 2048;
- }
-}
-
-static int glk_max_plane_width(const struct drm_framebuffer *fb,
- int color_plane,
- unsigned int rotation)
-{
- int cpp = fb->format->cpp[color_plane];
-
- switch (fb->modifier) {
- case DRM_FORMAT_MOD_LINEAR:
- case I915_FORMAT_MOD_X_TILED:
- if (cpp == 8)
- return 4096;
- else
- return 5120;
- case I915_FORMAT_MOD_Y_TILED_CCS:
- case I915_FORMAT_MOD_Yf_TILED_CCS:
- /* FIXME AUX plane? */
- case I915_FORMAT_MOD_Y_TILED:
- case I915_FORMAT_MOD_Yf_TILED:
- if (cpp == 8)
- return 2048;
- else
- return 5120;
- default:
- MISSING_CASE(fb->modifier);
- return 2048;
- }
-}
-
-static int icl_min_plane_width(const struct drm_framebuffer *fb)
-{
- /* Wa_14011264657, Wa_14011050563: gen11+ */
- switch (fb->format->format) {
- case DRM_FORMAT_C8:
- return 18;
- case DRM_FORMAT_RGB565:
- return 10;
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_XBGR:
- case DRM_FORMAT_ARGB:
- case DRM_FORMAT_ABGR:
- case DRM_FORMAT_XRGB2101010:
- case DRM_FORMAT_XBGR2101010:
- case DRM_FORMAT_ARGB2101010:
- case DRM_FORMAT_ABGR2101010:
- case DRM_FORMAT_XVYU2101010:
- case DRM_FORMAT_Y212:
- case DRM_FORMAT_Y216:
- return 6;
- case DRM_FORMAT_NV12:
- return 20;
- case DRM_FORMAT_P010:
- case DRM_FORMAT_P012:
- case DRM_FORMAT_P016:
- return 12;
- case DRM_FORMAT_XRGB16161616F:
- case DRM_FORMAT_XBGR16161616F:
- case DRM_FORMAT_ARGB16161616F:
- case DRM_FORMAT_ABGR16161616F:
- case DRM_FORMAT_XVYU12_16161616:
- case DRM_FORMAT_XVYU16161616:
- return 4;
- default:
- return 1;
- }
-}
-
-static int icl_max_plane_width(const struct drm_framebuffer *fb,
- int color_plane,
- unsigned int rotation)
-{
- return 5120;
-}
-
-static int skl_max_plane_height(void)
-{
- return 4096;
-}
-
-static int icl_max_plane_height(void)
-{
- return 4320;
-}
static bool
skl_check_main_ccs_coordinates(struct intel_plane_state *plane_state,
@@ -3874,35 +3753,55 @@ intel_plane_fence_y_offset(const struct
intel_plane_state *plane_state)
return y;
}
+static int intel_plane_min_width(struct intel_plane *plane,
+
[Intel-gfx] [PATCH v2 4/6] drm/dp: Add LTTPR helpers
Add the helpers and register definitions needed to read out the common
and per-PHY LTTPR capabilities and perform link training in the LTTPR
non-transparent mode.
v2:
- Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead
of adding these to i915. (Ville)
Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_helper.c | 244 +++-
include/drm/drm_dp_helper.h | 62
2 files changed, 302 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 478dd51f738d..6014c858b06b 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -150,11 +150,8 @@ void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
{
- unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
-DP_TRAINING_AUX_RD_MASK;
-
if (rd_interval > 4)
DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
rd_interval);
@@ -166,8 +163,35 @@ void drm_dp_link_train_channel_eq_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
usleep_range(rd_interval, rd_interval * 2);
}
+
+void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+DP_TRAINING_AUX_RD_MASK);
+}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
+void drm_dp_lttpr_link_train_clock_recovery_delay(void)
+{
+ usleep_range(100, 200);
+}
+EXPORT_SYMBOL(drm_dp_lttpr_link_train_clock_recovery_delay);
+
+static u8 dp_lttpr_phy_cap(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
+{
+ return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
+}
+
+void drm_dp_lttpr_link_train_channel_eq_delay(const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
+{
+ u8 interval = dp_lttpr_phy_cap(phy_cap,
+
DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
+ DP_TRAINING_AUX_RD_MASK;
+
+ __drm_dp_link_train_channel_eq_delay(interval);
+}
+EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
+
u8 drm_dp_link_rate_to_bw_code(int link_rate)
{
/* Spec says link_bw = link_rate / 0.27Gbps */
@@ -363,6 +387,71 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
}
EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
+/**
+ * drm_dp_dpcd_read_phy_link_status - get the link status information for a DP
PHY
+ * @aux: DisplayPort AUX channel
+ * @dp_phy: the DP PHY to get the link status for
+ * @link_status: buffer to return the status in
+ *
+ * Fetch the AUX DPCD registers for the DPRX or an LTTPR PHY link status. The
+ * layout of the returned @link_status matches the DPCD register layout of the
+ * DPRX PHY link status.
+ *
+ * Returns 0 if the information was read successfully or a negative error code
+ * on failure.
+ */
+int drm_dp_dpcd_read_phy_link_status(struct drm_dp_aux *aux,
+enum drm_dp_phy dp_phy,
+u8 link_status[DP_LINK_STATUS_SIZE])
+{
+ u8 lttpr_status[DP_LINK_STATUS_SIZE - 1];
+ int ret;
+
+ if (dp_phy == DP_PHY_DPRX) {
+ ret = drm_dp_dpcd_read(aux,
+ DP_LANE0_1_STATUS,
+ link_status,
+ DP_LINK_STATUS_SIZE);
+
+ if (ret < 0)
+ return ret;
+
+ WARN_ON(ret != DP_LINK_STATUS_SIZE);
+
+ return 0;
+ }
+
+ ret = drm_dp_dpcd_read(aux,
+ DP_LANE0_1_STATUS_PHY_REPEATER(dp_phy),
+ lttpr_status,
+ sizeof(lttpr_status));
+
+ if (ret < 0)
+ return ret;
+
+ WARN_ON(ret != sizeof(lttpr_status));
+
+#define link_reg(reg) link_status[(reg) - DP_LANE0_1_STATUS]
+#define lttpr_reg(reg) lttpr_status[(reg) - DP_LANE0_1_STATUS_PHY_REPEATER1]
+
+ /* Convert the LTTPR to the sink PHY link status layout */
+ link_reg(DP_LANE0_1_STATUS) =
lttpr_reg(DP_LANE0_1_STATUS_PHY_REPEATER1);
+ link_reg(DP_LANE2_3_STATUS) =
lttpr_reg(DP_LANE2_3_STATUS_PHY_REPEATER1);
+ link_reg(DP_LANE_ALIGN_STATUS_UPDATED) =
+ lttpr_reg(DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1);
+ link_reg(DP_SINK_STATUS) = 0;
+ link_reg(DP_ADJUST_REQUEST_LANE0_1) =
+ lttpr_reg(DP_ADJUST_REQUEST_LANE0_1_PHY_REPEATER1);
+ link_reg(DP_ADJUST_REQUEST_LANE2_3) =
+ lttpr_reg(DP_ADJUST_REQUEST_LANE2_3_PHY_REPEATER1);
[Intel-gfx] [PATCH v2 5/6] drm/i915: Switch to LTTPR transparent mode link training
By default LTTPRs should be in transparent link training mode,
nevertheless in this patch we switch to this default mode explicitly.
The DP Standard recommends this, supposedly because an LTTPR may be left
in the non-transparent mode (by BIOS, previous kernel, or after reset
due to a firmware bug). I haven't seen this happening, but let's follow
the DP Standard.
v2:
- Add a code comment about the explicit disabling of non-transparent
mode.
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
.../drm/i915/display/intel_dp_link_training.c | 52 +++
.../drm/i915/display/intel_dp_link_training.h | 2 +
4 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3d4bf9b6a0a2..b04921eba73b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1280,6 +1280,7 @@ struct intel_dp {
u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
+ u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
u8 fec_capable;
/* source rates */
int num_source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b21f42193a11..64bf4aa384d3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4726,6 +4726,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
int ret;
+ if (!intel_dp_is_edp(intel_dp))
+ intel_dp_lttpr_init(intel_dp);
+
if (drm_dp_read_dpcd_caps(_dp->aux, intel_dp->dpcd))
return false;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 38d4553670a1..4f8f42cc25fa 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -34,6 +34,52 @@ intel_dp_dump_link_status(const u8
link_status[DP_LINK_STATUS_SIZE])
link_status[3], link_status[4], link_status[5]);
}
+static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp)
+{
+ if (drm_dp_read_lttpr_common_caps(_dp->aux,
+ intel_dp->lttpr_common_caps) < 0) {
+ memset(intel_dp->lttpr_common_caps, 0,
+ sizeof(intel_dp->lttpr_common_caps));
+ return false;
+ }
+
+ drm_dbg_kms(_to_i915(intel_dp)->drm,
+ "LTTPR common capabilities: %*ph\n",
+ (int)sizeof(intel_dp->lttpr_common_caps),
+ intel_dp->lttpr_common_caps);
+
+ return true;
+}
+
+static bool
+intel_dp_set_lttpr_transparent_mode(struct intel_dp *intel_dp, bool enable)
+{
+ u8 val = enable ? DP_PHY_REPEATER_MODE_TRANSPARENT :
+ DP_PHY_REPEATER_MODE_NON_TRANSPARENT;
+
+ return drm_dp_dpcd_write(_dp->aux, DP_PHY_REPEATER_MODE, , 1)
== 1;
+}
+
+/**
+ * intel_dp_lttpr_init - detect LTTPRs and init the LTTPR link training mode
+ * @intel_dp: Intel DP struct
+ *
+ * Read the LTTPR common capabilities and switch to transparent link training
+ * mode.
+ */
+int intel_dp_lttpr_init(struct intel_dp *intel_dp)
+{
+ intel_dp_read_lttpr_common_caps(intel_dp);
+
+ /*
+* See DP Standard v2.0 3.6.6.1. about the explicit disabling of
+* non-transparent mode.
+*/
+ intel_dp_set_lttpr_transparent_mode(intel_dp, true);
+
+ return 0;
+}
+
static u8 dp_voltage_max(u8 preemph)
{
switch (preemph & DP_TRAIN_PRE_EMPHASIS_MASK) {
@@ -471,6 +517,12 @@ static void
intel_dp_schedule_fallback_link_training(struct intel_dp *intel_dp)
*/
void intel_dp_start_link_train(struct intel_dp *intel_dp)
{
+ /*
+* TODO: Reiniting LTTPRs here won't be needed once proper connector
+* HW state readout is added.
+*/
+ intel_dp_lttpr_init(intel_dp);
+
if (!intel_dp_link_train(intel_dp))
intel_dp_schedule_fallback_link_training(intel_dp);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 518d834dbc98..3536ce73a123 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -10,6 +10,8 @@
struct intel_dp;
+int intel_dp_lttpr_init(struct intel_dp *intel_dp);
+
void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const u8 link_status[DP_LINK_STATUS_SIZE]);
void intel_dp_start_link_train(struct intel_dp *intel_dp);
--
2.25.1
___
Intel-gfx mailing list
[Intel-gfx] [PATCH v2 6/6] drm/i915: Switch to LTTPR non-transparent mode link training
The DP Standard's recommendation is to use the LTTPR non-transparent
mode link training if LTTPRs are detected, so let's do this.
Besides power-saving, the advantages of this are that the maximum number
of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in
transparent mode), and it provides a way to narrow down the reason for a
link training failure to a given link segment. Non-transparent mode is
probably also the mode that was tested the most by the industry.
The changes in this patchset:
- Pass the DP PHY that is currently link trained to all LT helpers, so
that these can access the correct LTTPR/DPRX DPCD registers.
- During LT take into account the LTTPR common lane rate/count and the
per LTTPR-PHY vswing/pre-emph limits.
- Switch to LTTPR non-transparent LT mode and train each link segment
according to the sequence in DP Standard v2.0 (complete CR/EQ for
each segment before continuing with the next segment).
v2:
- Switch to non-transparent mode during connector detection, which is
required before reading the per-PHY LTTPR capabilities.
- Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville)
- Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the
same logic to intel_dp_get_link_status(). (Ville)
- Make intel_dp_lttpr_phy_caps() return a pointer to the whole array
instead of a pointer to its first element. (Ville)
- Add the intel_dp_phy_is_downstream_of_source() helper. (Ville)
- Add a code comment about the disable->enable quirk of
non-transparent mode.
- Add the intel_dp_training_pattern_set_reg() helper.
- Fix checkpatch/sparse warns.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 27 +-
drivers/gpu/drm/i915/display/intel_dp.h | 2 -
.../drm/i915/display/intel_dp_link_training.c | 358 +++---
.../drm/i915/display/intel_dp_link_training.h | 5 +-
5 files changed, 315 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b04921eba73b..2fb4e9a6a316 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1281,6 +1281,7 @@ struct intel_dp {
u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
+ u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
u8 fec_capable;
/* source rates */
int num_source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 64bf4aa384d3..bbf5a02ef0c1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -161,6 +161,7 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
162000, 27, 54, 81
};
int i, max_rate;
+ int max_lttpr_rate;
if (drm_dp_has_quirk(_dp->desc, 0,
DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
@@ -174,6 +175,9 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
}
max_rate =
drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
+ max_lttpr_rate =
drm_dp_lttpr_max_link_rate(intel_dp->lttpr_common_caps);
+ if (max_lttpr_rate)
+ max_rate = min(max_rate, max_lttpr_rate);
for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
if (dp_rates[i] > max_rate)
@@ -219,6 +223,10 @@ static int intel_dp_max_common_lane_count(struct intel_dp
*intel_dp)
int source_max = dig_port->max_lanes;
int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
+ int lttpr_max =
drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
+
+ if (lttpr_max)
+ sink_max = min(sink_max, lttpr_max);
return min3(source_max, sink_max, fia_max);
}
@@ -4126,17 +4134,6 @@ static void chv_dp_post_pll_disable(struct
intel_atomic_state *state,
chv_phy_post_pll_disable(encoder, old_crtc_state);
}
-/*
- * Fetch AUX CH registers 0x202 - 0x207 which contain
- * link status information
- */
-bool
-intel_dp_get_link_status(struct intel_dp *intel_dp, u8
link_status[DP_LINK_STATUS_SIZE])
-{
- return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
- DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
-}
-
static u8 intel_dp_voltage_max_2(struct intel_dp *intel_dp)
{
return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
@@ -5545,13 +5542,14 @@ void intel_dp_process_phy_request(struct intel_dp
*intel_dp)
_dp->compliance.test_data.phytest;
u8 link_status[DP_LINK_STATUS_SIZE];
- if (!intel_dp_get_link_status(intel_dp,
[Intel-gfx] [PATCH v2 0/6] drm/i915: Add support for LTTPR non-transparent link training mode
This patchset is v2 of [1], addressing the comments from Ville and an issue in the last patch with the per-PHY capability readout (needs to be done after switching to non-transparent mode). [1] https://patchwork.freedesktop.org/series/81968/ Cc: dri-de...@lists.freedesktop.org Cc: Ville Syrjälä Imre Deak (6): drm/i915: Fix DP link training pattern mask drm/i915: Simplify the link training functions drm/i915: Factor out a helper to disable the DPCD training pattern drm/dp: Add LTTPR helpers drm/i915: Switch to LTTPR transparent mode link training drm/i915: Switch to LTTPR non-transparent mode link training drivers/gpu/drm/drm_dp_helper.c | 244 - drivers/gpu/drm/i915/display/intel_ddi.c | 3 +- .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp.c | 46 +- drivers/gpu/drm/i915/display/intel_dp.h | 3 - .../drm/i915/display/intel_dp_link_training.c | 486 +++--- .../drm/i915/display/intel_dp_link_training.h | 13 +- include/drm/drm_dp_helper.h | 62 +++ 8 files changed, 750 insertions(+), 109 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/6] drm/i915: Factor out a helper to disable the DPCD training pattern
To prepare for a follow-up LTTPR change factor out a helper to disable
the training pattern in DPCD. We'll need to do this for each LTTPR
(without programming the port to output the idle pattern) when training
in LTTPR non-transparent mode.
While at it also move the disable-link-training logic from
intel_dp_set_link_train() to intel_dp_stop_link_train(), since the
latter is the only user of this.
v2:
- Move the disable-link-training logic to intel_dp_stop_link_train()
(Ville)
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_dp_link_training.c | 32 +--
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 78b0f165fadd..38d4553670a1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -91,25 +91,17 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
u8 dp_train_pat)
{
u8 buf[sizeof(intel_dp->train_set) + 1];
- int ret, len;
+ int len;
intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
buf[0] = dp_train_pat;
- if (intel_dp_training_pattern_symbol(dp_train_pat) ==
- DP_TRAINING_PATTERN_DISABLE) {
- /* don't write DP_TRAINING_LANEx_SET on disable */
- len = 1;
- } else {
- /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
- memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
- len = intel_dp->lane_count + 1;
- }
+ /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
+ memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
+ len = intel_dp->lane_count + 1;
- ret = drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
- buf, len);
-
- return ret == len;
+ return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
+buf, len) == len;
}
static bool
@@ -392,6 +384,13 @@ intel_dp_link_training_channel_equalization(struct
intel_dp *intel_dp)
return channel_eq;
}
+static bool intel_dp_disable_dpcd_training_pattern(struct intel_dp *intel_dp)
+{
+ u8 val = DP_TRAINING_PATTERN_DISABLE;
+
+ return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET, ,
1) == 1;
+}
+
/**
* intel_dp_stop_link_train - stop link training
* @intel_dp: DP struct
@@ -411,8 +410,9 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
{
intel_dp->link_trained = true;
- intel_dp_set_link_train(intel_dp,
- DP_TRAINING_PATTERN_DISABLE);
+ intel_dp_program_link_training_pattern(intel_dp,
+ DP_TRAINING_PATTERN_DISABLE);
+ intel_dp_disable_dpcd_training_pattern(intel_dp);
}
static bool
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/6] drm/i915: Fix DP link training pattern mask
An LTTPR can be trained with training pattern 4 even if the DPCD
revision is < 1.4, but drm_dp_training_pattern_mask() would change
pattern 4 to pattern 3 on those DPCD revisions.
Since intel_dp_training_pattern() makes already sure that the proper
training pattern is used, all that needs to be masked out is the
scrambling disable flag, which is or'd to the mask later based on the
training pattern.
v2:
- Use a helper instead of open-coding the masking. (Ville)
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +--
drivers/gpu/drm/i915/display/intel_dp.c | 10 +-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp_link_training.h | 6 ++
4 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4d06178cd76c..edeee1d8471c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4158,13 +4158,12 @@ static void intel_ddi_set_link_train(struct intel_dp
*intel_dp,
u8 dp_train_pat)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
u32 temp;
temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
temp &= ~DP_TP_CTL_LINK_TRAIN_MASK;
- switch (dp_train_pat & train_pat_mask) {
+ switch (intel_dp_training_pattern_symbol(dp_train_pat)) {
case DP_TRAINING_PATTERN_DISABLE:
temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
break;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf1e9cf1c0f3..bba9669e0e57 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3778,7 +3778,7 @@ cpt_set_link_train(struct intel_dp *intel_dp,
*DP &= ~DP_LINK_TRAIN_MASK_CPT;
- switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
+ switch (intel_dp_training_pattern_symbol(dp_train_pat)) {
case DP_TRAINING_PATTERN_DISABLE:
*DP |= DP_LINK_TRAIN_OFF_CPT;
break;
@@ -3808,7 +3808,7 @@ g4x_set_link_train(struct intel_dp *intel_dp,
*DP &= ~DP_LINK_TRAIN_MASK;
- switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
+ switch (intel_dp_training_pattern_symbol(dp_train_pat)) {
case DP_TRAINING_PATTERN_DISABLE:
*DP |= DP_LINK_TRAIN_OFF;
break;
@@ -4498,12 +4498,12 @@ intel_dp_program_link_training_pattern(struct intel_dp
*intel_dp,
u8 dp_train_pat)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
- if (dp_train_pat & train_pat_mask)
+ if ((intel_dp_training_pattern_symbol(dp_train_pat)) !=
+ DP_TRAINING_PATTERN_DISABLE)
drm_dbg_kms(_priv->drm,
"Using DP training pattern TPS%d\n",
- dp_train_pat & train_pat_mask);
+ intel_dp_training_pattern_symbol(dp_train_pat));
intel_dp->set_link_train(intel_dp, dp_train_pat);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index f2c8b56be9ea..0e1472b1f868 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -96,7 +96,7 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
buf[0] = dp_train_pat;
- if ((dp_train_pat & DP_TRAINING_PATTERN_MASK) ==
+ if (intel_dp_training_pattern_symbol(dp_train_pat) ==
DP_TRAINING_PATTERN_DISABLE) {
/* don't write DP_TRAINING_LANEx_SET on disable */
len = 1;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 01f1dabbb060..518d834dbc98 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -15,4 +15,10 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
void intel_dp_start_link_train(struct intel_dp *intel_dp);
void intel_dp_stop_link_train(struct intel_dp *intel_dp);
+/* Get the TPSx symbol type of the value programmed to DP_TRAINING_PATTERN_SET
*/
+static inline u8 intel_dp_training_pattern_symbol(u8 pattern)
+{
+ return pattern & ~DP_LINK_SCRAMBLING_DISABLE;
+}
+
#endif /* __INTEL_DP_LINK_TRAINING_H__ */
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH v2 2/6] drm/i915: Simplify the link training functions
Split the prepare, link training, fallback-handling steps into their own
functions for clarity and as a preparation for the upcoming LTTPR
changes.
While at it also:
- Unexport and inline intel_dp_set_idle_link_train(), which is used at a
single place.
- Add some documentation to functions that are exported or that can use
a better description about which part of the LT sequence they
implement.
v2: (Ville)
- Unexport/inline intel_dp_set_idle_link_train()
- Make the documentation of
intel_dp_prepare_link_train()/intel_dp_stop_link_train() more accurate
wrt. HW specific details.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 --
drivers/gpu/drm/i915/display/intel_dp.h | 1 -
.../drm/i915/display/intel_dp_link_training.c | 90 ++-
3 files changed, 70 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index bba9669e0e57..b21f42193a11 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4508,12 +4508,6 @@ intel_dp_program_link_training_pattern(struct intel_dp
*intel_dp,
intel_dp->set_link_train(intel_dp, dp_train_pat);
}
-void intel_dp_set_idle_link_train(struct intel_dp *intel_dp)
-{
- if (intel_dp->set_idle_link_train)
- intel_dp->set_idle_link_train(intel_dp);
-}
-
static void
intel_dp_link_down(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 08a1c0aa8b94..ca8319d6c63c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -95,7 +95,6 @@ intel_dp_program_link_training_pattern(struct intel_dp
*intel_dp,
u8 dp_train_pat);
void
intel_dp_set_signal_levels(struct intel_dp *intel_dp);
-void intel_dp_set_idle_link_train(struct intel_dp *intel_dp);
void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
u8 *link_bw, u8 *rate_select);
bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 0e1472b1f868..78b0f165fadd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -146,14 +146,13 @@ static bool intel_dp_link_max_vswing_reached(struct
intel_dp *intel_dp)
return true;
}
-/* Enable corresponding port and start training pattern 1 */
-static bool
-intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
+/*
+ * Prepare link training by configuring the link parameters. On DDI platforms
+ * also enable the port here.
+ */
+static void intel_dp_prepare_link_train(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- u8 voltage;
- int voltage_tries, cr_tries, max_cr_tries;
- bool max_vswing_reached = false;
u8 link_config[2];
u8 link_bw, rate_select;
@@ -187,6 +186,16 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
drm_dp_dpcd_write(_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
intel_dp->DP |= DP_PORT_EN;
+}
+
+/* Perform the link training clock recovery phase using training pattern 1. */
+static bool
+intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 voltage;
+ int voltage_tries, cr_tries, max_cr_tries;
+ bool max_vswing_reached = false;
/* clock recovery */
if (!intel_dp_reset_link_train(intel_dp,
@@ -309,6 +318,10 @@ static u32 intel_dp_training_pattern(struct intel_dp
*intel_dp)
return DP_TRAINING_PATTERN_2;
}
+/*
+ * Perform the link training channel equalization phase using one of training
+ * pattern 2, 3 or 4 depending on the source and sink capabilities.
+ */
static bool
intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
{
@@ -373,12 +386,27 @@ intel_dp_link_training_channel_equalization(struct
intel_dp *intel_dp)
"Channel equalization failed 5 times\n");
}
- intel_dp_set_idle_link_train(intel_dp);
+ if (intel_dp->set_idle_link_train)
+ intel_dp->set_idle_link_train(intel_dp);
return channel_eq;
-
}
+/**
+ * intel_dp_stop_link_train - stop link training
+ * @intel_dp: DP struct
+ *
+ * Stop the link training of the @intel_dp port, disabling the test pattern
+ * symbol generation on the port and disabling the training pattern in
+ * the sink's DPCD.
+ *
+ * What symbols are output on the port after this point is
+ * platform specific: On DDI/VLV/CHV platforms it will be the idle pattern
+
[Intel-gfx] [PATCH v9 11/11] drm/i915: Add debugfs dumping for bigjoiner, v3.
From: Maarten Lankhorst
Dump debugfs and planar links as well, this will make it easier to debug
when things go wrong.
v4:
* Rebase
Changes since v1:
- Report planar slaves as such, now that we have the plane_state switch.
Changes since v2:
- Rebase on top of the new plane format dumping
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
.../drm/i915/display/intel_display_debugfs.c | 29 ++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 0bf31f9a8af5..2760e132582d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -750,6 +750,17 @@ static void plane_rotation(char *buf, size_t bufsize,
unsigned int rotation)
rotation);
}
+static const char *plane_visibility(const struct intel_plane_state
*plane_state)
+{
+ if (plane_state->uapi.visible)
+ return "visible";
+
+ if (plane_state->planar_slave)
+ return "planar-slave";
+
+ return "hidden";
+}
+
static void intel_plane_uapi_info(struct seq_file *m, struct intel_plane
*plane)
{
const struct intel_plane_state *plane_state =
@@ -768,12 +779,22 @@ static void intel_plane_uapi_info(struct seq_file *m,
struct intel_plane *plane)
plane_rotation(rot_str, sizeof(rot_str),
plane_state->uapi.rotation);
- seq_printf(m, "\t\tuapi: fb=%d,%s,%dx%d, src=" DRM_RECT_FP_FMT ", dst="
DRM_RECT_FMT ", rotation=%s\n",
+ seq_printf(m, "\t\tuapi: fb=%d,%s,%dx%d, visible=%s, src="
DRM_RECT_FP_FMT ", dst=" DRM_RECT_FMT ", rotation=%s\n",
fb ? fb->base.id : 0, fb ? format_name.str : "n/a",
fb ? fb->width : 0, fb ? fb->height : 0,
+ plane_visibility(plane_state),
DRM_RECT_FP_ARG(),
DRM_RECT_ARG(),
rot_str);
+
+ if (plane_state->planar_linked_plane)
+ seq_printf(m, "\t\tplanar: Linked to [PLANE:%d:%s] as a %s\n",
+ plane_state->planar_linked_plane->base.base.id,
plane_state->planar_linked_plane->base.name,
+ plane_state->planar_slave ? "slave" : "master");
+ if (plane_state->bigjoiner_plane)
+ seq_printf(m, "\t\tbigjoiner: Linked to [PLANE:%d:%s] as a
%s\n",
+ plane_state->bigjoiner_plane->base.base.id,
plane_state->bigjoiner_plane->base.name,
+ plane_state->bigjoiner_slave ? "slave" : "master");
}
static void intel_plane_hw_info(struct seq_file *m, struct intel_plane *plane)
@@ -869,6 +890,12 @@ static void intel_crtc_info(struct seq_file *m, struct
intel_crtc *crtc)
intel_scaler_info(m, crtc);
}
+ if (crtc_state->bigjoiner)
+ seq_printf(m, "\tLinked to [CRTC:%d:%s] as a %s\n",
+ crtc_state->bigjoiner_linked_crtc->base.base.id,
+ crtc_state->bigjoiner_linked_crtc->base.name,
+ crtc_state->bigjoiner_slave ? "slave" : "master");
+
for_each_intel_encoder_mask(_priv->drm, encoder,
crtc_state->uapi.encoder_mask)
intel_encoder_info(m, crtc, encoder);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 03/11] drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
From: Maarten Lankhorst
With bigjoiner, there will be 2 pipes driving 2 halfs of 1 transcoder,
because of this, we need a pipe_mode for various calculations, including
for example watermarks, plane clipping, etc.
v6:
* renaming in separate function, only pipe_mode here (Ville)
* Add description (Maarten)
v5:
* Rebase (Manasi)
v4:
* Manual rebase (Manasi)
v3:
* Change state to crtc_state, fix rebase err (Manasi)
v2:
* Manual Rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
Reviewed-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_display.c | 40 +-
.../drm/i915/display/intel_display_types.h| 11 ++-
drivers/gpu/drm/i915/intel_pm.c | 76 +--
3 files changed, 69 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 4850644ab43f..a218ff7d32ec 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6152,18 +6152,16 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
static int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state)
{
- const struct drm_display_mode *adjusted_mode =
- _state->hw.adjusted_mode;
+ const struct drm_display_mode *pipe_mode = _state->hw.pipe_mode;
int width, height;
if (crtc_state->pch_pfit.enabled) {
width = drm_rect_width(_state->pch_pfit.dst);
height = drm_rect_height(_state->pch_pfit.dst);
} else {
- width = adjusted_mode->crtc_hdisplay;
- height = adjusted_mode->crtc_vdisplay;
+ width = pipe_mode->crtc_hdisplay;
+ height = pipe_mode->crtc_vdisplay;
}
-
return skl_update_scaler(crtc_state, !crtc_state->hw.active,
SKL_CRTC_INDEX,
_state->scaler_state.scaler_id,
@@ -8025,7 +8023,7 @@ static bool intel_crtc_supports_double_wide(const struct
intel_crtc *crtc)
static u32 ilk_pipe_pixel_rate(const struct intel_crtc_state *crtc_state)
{
- u32 pixel_rate = crtc_state->hw.adjusted_mode.crtc_clock;
+ u32 pixel_rate = crtc_state->hw.pipe_mode.crtc_clock;
unsigned int pipe_w, pipe_h, pfit_w, pfit_h;
/*
@@ -8062,7 +8060,7 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
if (HAS_GMCH(dev_priv))
/* FIXME calculate proper pipe pixel rate for GMCH pfit */
crtc_state->pixel_rate =
- crtc_state->hw.adjusted_mode.crtc_clock;
+ crtc_state->hw.pipe_mode.crtc_clock;
else
crtc_state->pixel_rate =
ilk_pipe_pixel_rate(crtc_state);
@@ -8072,7 +8070,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- const struct drm_display_mode *adjusted_mode =
_config->hw.adjusted_mode;
+ const struct drm_display_mode *pipe_mode = _config->hw.pipe_mode;
int clock_limit = dev_priv->max_dotclk_freq;
if (INTEL_GEN(dev_priv) < 4) {
@@ -8083,16 +8081,16 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* is > 90% of the (display) core speed.
*/
if (intel_crtc_supports_double_wide(crtc) &&
- adjusted_mode->crtc_clock > clock_limit) {
+ pipe_mode->crtc_clock > clock_limit) {
clock_limit = dev_priv->max_dotclk_freq;
pipe_config->double_wide = true;
}
}
- if (adjusted_mode->crtc_clock > clock_limit) {
+ if (pipe_mode->crtc_clock > clock_limit) {
drm_dbg_kms(_priv->drm,
"requested pixel clock (%d kHz) too high (max: %d
kHz, double wide: %s)\n",
- adjusted_mode->crtc_clock, clock_limit,
+ pipe_mode->crtc_clock, clock_limit,
yesno(pipe_config->double_wide));
return -EINVAL;
}
@@ -8135,7 +8133,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw.
*/
if ((INTEL_GEN(dev_priv) > 4 || IS_G4X(dev_priv)) &&
- adjusted_mode->crtc_hsync_start == adjusted_mode->crtc_hdisplay)
+ pipe_mode->crtc_hsync_start == pipe_mode->crtc_hdisplay)
return -EINVAL;
intel_crtc_compute_pixel_rate(pipe_config);
@@ -12659,15 +12657,15 @@ static bool c8_planes_changed(const struct
intel_crtc_state *new_crtc_state)
static u16 hsw_linetime_wm(const struct intel_crtc_state *crtc_state)
{
-
[Intel-gfx] [PATCH v9 07/11] drm/i915: Make hardware readout work on i915.
From: Maarten Lankhorst
Unfortunately I have no way to test this, but it should be correct
if the bios sets up bigjoiner in a sane way.
Skip iterating over bigjoiner slaves, only the master has the state we
care about.
Add the width of the bigjoiner slave to the reconstructed fb.
Hide the bigjoiner slave to userspace, and double the mode on bigjoiner
master.
And last, disable bigjoiner slave from primary if reconstruction fails.
v2:
* Manual Rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 64 +++-
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7dfaeb8a759a..98c70f057344 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3608,6 +3608,8 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
struct intel_plane *intel_plane = to_intel_plane(primary);
struct intel_plane_state *intel_state =
to_intel_plane_state(plane_state);
+struct intel_crtc_state *crtc_state =
+to_intel_crtc_state(intel_crtc->base.state);
struct drm_framebuffer *fb;
struct i915_vma *vma;
@@ -3630,7 +3632,7 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
if (c == _crtc->base)
continue;
- if (!to_intel_crtc(c)->active)
+ if (!to_intel_crtc_state(c->state)->uapi.active)
continue;
state = to_intel_plane_state(c->primary->state);
@@ -3652,6 +3654,11 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
* pretend the BIOS never had it enabled.
*/
intel_plane_disable_noatomic(intel_crtc, intel_plane);
+ if (crtc_state->bigjoiner) {
+ struct intel_crtc *slave =
+ crtc_state->bigjoiner_linked_crtc;
+ intel_plane_disable_noatomic(slave,
to_intel_plane(slave->base.primary));
+ }
return;
@@ -10627,6 +10634,7 @@ static void
skl_get_initial_plane_config(struct intel_crtc *crtc,
struct intel_initial_plane_config *plane_config)
{
+ struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_plane *plane = to_intel_plane(crtc->base.primary);
@@ -10735,6 +10743,18 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
fb->height = ((val >> 16) & 0x) + 1;
fb->width = ((val >> 0) & 0x) + 1;
+ /* add bigjoiner slave as well, if the fb stretches both */
+ if (crtc_state->bigjoiner) {
+ enum pipe bigjoiner_pipe =
crtc_state->bigjoiner_linked_crtc->pipe;
+
+ if (fb->width == crtc_state->pipe_src_w &&
+ (intel_de_read(dev_priv, PLANE_SURF(pipe, plane_id)) &
0xf000) == plane_config->base) {
+ val = intel_de_read(dev_priv,
PLANE_SIZE(bigjoiner_pipe, plane_id));
+ fb->height += ((val >> 16) & 0xfff) + 1;
+ fb->width += ((val >> 0) & 0x1fff) + 1;
+ }
+ }
+
val = intel_de_read(dev_priv, PLANE_STRIDE(pipe, plane_id));
stride_mult = skl_plane_stride_mult(fb, 0, DRM_MODE_ROTATE_0);
fb->pitches[0] = (val & 0x3ff) * stride_mult;
@@ -18577,7 +18597,8 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc,
/* Adjust the state of the output pipe according to whether we
* have active connectors/encoders. */
- if (crtc_state->hw.active && !intel_crtc_has_encoders(crtc))
+ if (crtc_state->hw.active && !intel_crtc_has_encoders(crtc) &&
+ !crtc_state->bigjoiner_slave)
intel_crtc_disable_noatomic(crtc, ctx);
if (crtc_state->hw.active || HAS_GMCH(dev_priv)) {
@@ -18854,6 +18875,9 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
struct intel_plane *plane;
int min_cdclk = 0;
+ if (crtc_state->bigjoiner_slave)
+ continue;
+
if (crtc_state->hw.active) {
struct drm_display_mode mode;
@@ -18878,6 +18902,9 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
mode.hdisplay = crtc_state->pipe_src_w;
mode.vdisplay = crtc_state->pipe_src_h;
+ if (crtc_state->bigjoiner)
+ mode.hdisplay *= 2;
+
intel_crtc_compute_pixel_rate(crtc_state);
intel_crtc_update_active_timings(crtc_state);
@@ -18928,6 +18955,39 @@ static void intel_modeset_readout_hw_state(struct
[Intel-gfx] [PATCH v9 06/11] drm/i915: Enable big joiner support in enable and disable sequences.
From: Maarten Lankhorst
Make vdsc work when no output is enabled. The big joiner needs VDSC
on the slave, so enable it and set the appropriate bits.
Also update timestamping constants, because slave crtc's are not
updated in drm_atomic_helper_update_legacy_modeset_state().
This should be enough to bring up CRTC's in a big joiner configuration,
without any plane configuration on the second pipe yet.
HOWEVER, we still bring up the crtc's in the wrong order. We need to
make sure that the master crtc is brought up after the slave crtc.
This is done correctly later in this series.
The next steps are to enable planes correctly, and make sure we enable
and update both master and slave in the correct order.
v2:
* Manual rebase (Manasi)
v3:
* Rebase (Manasi)
v4:
* Rebase (Manasi)
v5:
* Get dsc power domain in ddi_init (Manasi)
v6:
* Remove dsc power put from dsc_disable (Maarten)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
drivers/gpu/drm/i915/display/intel_ddi.c | 68 ++-
drivers/gpu/drm/i915/display/intel_display.c | 392 --
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
drivers/gpu/drm/i915/display/intel_vdsc.c | 201 -
drivers/gpu/drm/i915/display/intel_vdsc.h | 7 +-
7 files changed, 421 insertions(+), 256 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 520715b7d5b5..752956af132a 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1454,8 +1454,6 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
- intel_dsc_get_config(encoder, pipe_config);
-
/* FIXME: adapt icl_ddi_clock_get() for DSI and use that? */
pipe_config->port_clock = intel_dpll_get_freq(i915,
pipe_config->shared_dpll);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4d06178cd76c..286ffdafb330 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -28,6 +28,7 @@
#include
#include "i915_drv.h"
+#include "i915_trace.h"
#include "intel_audio.h"
#include "intel_combo_phy.h"
#include "intel_connector.h"
@@ -2118,12 +2119,6 @@ static void intel_ddi_get_power_domains(struct
intel_encoder *encoder,
intel_display_power_get(dev_priv,
intel_ddi_main_link_aux_domain(dig_port));
- /*
-* VDSC power is needed when DSC is enabled
-*/
- if (crtc_state->dsc.compression_enable)
- intel_display_power_get(dev_priv,
- intel_dsc_power_domain(crtc_state));
}
void intel_ddi_enable_pipe_clock(struct intel_encoder *encoder,
@@ -3412,7 +3407,8 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
/* 7.l Configure and enable FEC if needed */
intel_ddi_enable_fec(encoder, crtc_state);
- intel_dsc_enable(encoder, crtc_state);
+ if (!crtc_state->bigjoiner)
+ intel_dsc_enable(encoder, crtc_state);
}
static void hsw_ddi_pre_enable_dp(struct intel_atomic_state *state,
@@ -3484,7 +3480,8 @@ static void hsw_ddi_pre_enable_dp(struct
intel_atomic_state *state,
if (!is_mst)
intel_ddi_enable_pipe_clock(encoder, crtc_state);
- intel_dsc_enable(encoder, crtc_state);
+ if (!crtc_state->bigjoiner)
+ intel_dsc_enable(encoder, crtc_state);
}
static void intel_ddi_pre_enable_dp(struct intel_atomic_state *state,
@@ -3737,6 +3734,21 @@ static void intel_ddi_post_disable(struct
intel_atomic_state *state,
ilk_pfit_disable(old_crtc_state);
}
+ if (old_crtc_state->bigjoiner_linked_crtc) {
+ struct intel_atomic_state *state =
+ to_intel_atomic_state(old_crtc_state->uapi.state);
+ struct intel_crtc *slave =
+ old_crtc_state->bigjoiner_linked_crtc;
+ const struct intel_crtc_state *old_slave_crtc_state =
+ intel_atomic_get_old_crtc_state(state, slave);
+
+ intel_crtc_vblank_off(old_slave_crtc_state);
+ trace_intel_pipe_disable(slave);
+
+ intel_dsc_disable(old_slave_crtc_state);
+ skl_scaler_disable(old_slave_crtc_state);
+ }
+
/*
* When called from DP MST code:
* - old_conn_state will be NULL
@@ -3951,7 +3963,8 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
{
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
-
[Intel-gfx] [PATCH v9 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
From: Maarten Lankhorst
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
eDP does not support bigjoiner, so do not expose bigjoiner only
modes on the eDP port.
v7:
* Add can_bigjoiner() helper (Ville)
* Pass bigjoiner to plane_size validation (Ville)
v6:
* Rebase after dp_downstream mode valid changes (Manasi)
v5:
* Increase max plane width to support 8K with bigjoiner (Maarten)
v4:
* Rebase (Manasi)
Changes since v1:
- Disallow bigjoiner on eDP.
Changes since v2:
- Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
and split off the downstream and source checking to its own function.
(Ville)
v3:
* Rebase (Manasi)
Signed-off-by: Manasi Navare
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +-
drivers/gpu/drm/i915/display/intel_display.h | 3 +-
drivers/gpu/drm/i915/display/intel_dp.c | 126 +++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/display/intel_dsi.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
6 files changed, 111 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a218ff7d32ec..ebe29f7f7791 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17424,7 +17424,8 @@ intel_mode_valid(struct drm_device *dev,
enum drm_mode_status
intel_mode_valid_max_plane_size(struct drm_i915_private *dev_priv,
- const struct drm_display_mode *mode)
+ const struct drm_display_mode *mode,
+ bool bigjoiner)
{
int plane_width_max, plane_height_max;
@@ -17441,7 +17442,7 @@ intel_mode_valid_max_plane_size(struct drm_i915_private
*dev_priv,
* too big for that.
*/
if (INTEL_GEN(dev_priv) >= 11) {
- plane_width_max = 5120;
+ plane_width_max = 5120 << bigjoiner;
plane_height_max = 4320;
} else {
plane_width_max = 5120;
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index d10b7c8cde3f..3d860a9da8fe 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -496,7 +496,8 @@ u32 intel_plane_fb_max_stride(struct drm_i915_private
*dev_priv,
bool intel_plane_can_remap(const struct intel_plane_state *plane_state);
enum drm_mode_status
intel_mode_valid_max_plane_size(struct drm_i915_private *dev_priv,
- const struct drm_display_mode *mode);
+ const struct drm_display_mode *mode,
+ bool bigjoiner);
enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port);
bool is_trans_port_sync_mode(const struct intel_crtc_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf1e9cf1c0f3..05accd49993b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -247,6 +247,29 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
return max_link_clock * max_lanes;
}
+static int source_max_dotclock(struct intel_dp *intel_dp, bool allow_bigjoiner)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct intel_encoder *encoder = _dig_port->base;
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (allow_bigjoiner && INTEL_GEN(dev_priv) >= 11 &&
!intel_dp_is_edp(intel_dp))
+ return 2 * dev_priv->max_dotclk_freq;
+
+ return dev_priv->max_dotclk_freq;
+}
+
+static int
+intel_dp_max_dotclock(struct intel_dp *intel_dp, bool allow_bigjoiner)
+{
+ int max_dotclk = source_max_dotclock(intel_dp, allow_bigjoiner);
+
+ if (intel_dp->dfp.max_dotclock)
+ return min(max_dotclk, intel_dp->dfp.max_dotclock);
+
+ return max_dotclk;
+}
+
static int cnl_max_source_rate(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -503,7 +526,8 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
u32 link_clock, u32 lane_count,
- u32 mode_clock, u32 mode_hdisplay)
+ u32 mode_clock, u32 mode_hdisplay,
+ bool bigjoiner)
{
u32 bits_per_pixel, max_bpp_small_joiner_ram;
int i;
@@ -521,6 +545,10 @@ static u16 intel_dp_dsc_get_output_bpp(struct
drm_i915_private *i915,
/* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz.
[Intel-gfx] [PATCH v9 05/11] drm/i915: Try to make bigjoiner work in atomic check
From: Maarten Lankhorst
When the clock is higher than the dotclock, try with 2 pipes enabled.
If we can enable 2, then we will go into big joiner mode, and steal
the adjacent crtc.
This only links the crtc's in software, no hardware or plane
programming is done yet. Blobs are also copied from the master's
crtc_state, so it doesn't depend at commit time on the other
crtc_state.
v4:
* Fixes in intel_crtc_compute_config (Ville)
v3:
* Manual Rebase (Manasi)
Changes since v1:
- Rename pipe timings to transcoder timings, as they are now different.
Changes since v2:
- Rework bigjoiner checks; always disable slave when recalculating
master. No need to have a separate bigjoiner pass any more.
- Use pipe_mode instead of transcoder_mode, to clean up the code.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_atomic.c | 9 +-
drivers/gpu/drm/i915/display/intel_atomic.h | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 202 --
.../drm/i915/display/intel_display_types.h| 9 +
drivers/gpu/drm/i915/display/intel_dp.c | 22 +-
5 files changed, 211 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 86be032bcf96..e243ce97b534 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -270,14 +270,15 @@ void intel_crtc_free_hw_state(struct intel_crtc_state
*crtc_state)
intel_crtc_put_color_blobs(crtc_state);
}
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state)
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
+const struct intel_crtc_state *from_crtc_state)
{
drm_property_replace_blob(_state->hw.degamma_lut,
- crtc_state->uapi.degamma_lut);
+ from_crtc_state->uapi.degamma_lut);
drm_property_replace_blob(_state->hw.gamma_lut,
- crtc_state->uapi.gamma_lut);
+ from_crtc_state->uapi.gamma_lut);
drm_property_replace_blob(_state->hw.ctm,
- crtc_state->uapi.ctm);
+ from_crtc_state->uapi.ctm);
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 285de07011dc..62a3365ed5e6 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -43,7 +43,8 @@ struct drm_crtc_state *intel_crtc_duplicate_state(struct
drm_crtc *crtc);
void intel_crtc_destroy_state(struct drm_crtc *crtc,
struct drm_crtc_state *state);
void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state);
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
+const struct intel_crtc_state
*from_crtc_state);
struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
void intel_atomic_state_free(struct drm_atomic_state *state);
void intel_atomic_state_clear(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ebe29f7f7791..02567deb6ec4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8070,9 +8070,24 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- const struct drm_display_mode *pipe_mode = _config->hw.pipe_mode;
+ struct drm_display_mode *pipe_mode = _config->hw.pipe_mode;
int clock_limit = dev_priv->max_dotclk_freq;
+ *pipe_mode = pipe_config->hw.adjusted_mode;
+
+ /* Adjust pipe_mode for bigjoiner, with half the horizontal mode */
+ if (pipe_config->bigjoiner) {
+ pipe_mode->crtc_clock /= 2;
+ pipe_mode->crtc_hdisplay /= 2;
+ pipe_mode->crtc_hblank_start /= 2;
+ pipe_mode->crtc_hblank_end /= 2;
+ pipe_mode->crtc_hsync_start /= 2;
+ pipe_mode->crtc_hsync_end /= 2;
+ pipe_mode->crtc_htotal /= 2;
+ pipe_mode->crtc_hskew /= 2;
+ pipe_config->pipe_src_w /= 2;
+ }
+
if (INTEL_GEN(dev_priv) < 4) {
clock_limit = dev_priv->max_cdclk_freq * 9 / 10;
@@ -8133,7 +8148,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw.
*/
if ((INTEL_GEN(dev_priv) > 4 || IS_G4X(dev_priv)) &&
- pipe_mode->crtc_hsync_start ==
[Intel-gfx] [PATCH v9 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.
From: Maarten Lankhorst
Make sure that when a plane is set in a bigjoiner mode, we will add
their counterpart to the atomic state as well. This will allow us to
make sure all state is available when planes are checked.
Because of the funny interactions with bigjoiner and planar YUV
formats, we may end up adding a lot of planes, so we have to keep
iterating until we no longer add any planes.
Also fix the atomic intel plane iterator, so things watermarks start
working automagically.
v6:
* Fix from_plane_state assignments (Manasi)
v5:
* Rebase after adding sagv support (Manasi)
v4:
* Manual rebase (Manasi)
Changes since v1:
- Rebase on top of plane_state split, cleaning up the code a lot.
- Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner capable.
- Add iter macro to intel_atomic_crtc_state_for_each_plane_state() to
keep iteration working.
Changes since v2:
- Add icl_(un)set_bigjoiner_plane_links, to make it more clear where
links are made and broken.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 53 -
.../gpu/drm/i915/display/intel_atomic_plane.h | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 207 --
drivers/gpu/drm/i915/display/intel_display.h | 20 +-
.../drm/i915/display/intel_display_types.h| 11 +
drivers/gpu/drm/i915/intel_pm.c | 20 +-
6 files changed, 274 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 79032701873a..0610a254a5f9 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -246,12 +246,17 @@ static void intel_plane_clear_hw_state(struct
intel_plane_state *plane_state)
memset(_state->hw, 0, sizeof(plane_state->hw));
}
-void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state *plane_state,
+void intel_plane_copy_uapi_to_hw_state(const struct intel_crtc_state
*crtc_state,
+ struct intel_plane_state *plane_state,
const struct intel_plane_state
*from_plane_state)
{
intel_plane_clear_hw_state(plane_state);
- plane_state->hw.crtc = from_plane_state->uapi.crtc;
+ if (from_plane_state->uapi.crtc)
+ plane_state->hw.crtc = crtc_state->uapi.crtc;
+ else
+ plane_state->hw.crtc = NULL;
+
plane_state->hw.fb = from_plane_state->uapi.fb;
if (plane_state->hw.fb)
drm_framebuffer_get(plane_state->hw.fb);
@@ -319,15 +324,36 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
}
static struct intel_crtc *
-get_crtc_from_states(const struct intel_plane_state *old_plane_state,
+get_crtc_from_states(struct intel_atomic_state *state,
+const struct intel_plane_state *old_plane_state,
const struct intel_plane_state *new_plane_state)
{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_plane *plane = to_intel_plane(new_plane_state->uapi.plane);
+
if (new_plane_state->uapi.crtc)
return to_intel_crtc(new_plane_state->uapi.crtc);
if (old_plane_state->uapi.crtc)
return to_intel_crtc(old_plane_state->uapi.crtc);
+ if (new_plane_state->bigjoiner_slave) {
+ const struct intel_plane_state *new_master_plane_state =
+ intel_atomic_get_new_plane_state(state,
new_plane_state->bigjoiner_plane);
+
+ /* need to use uapi here, new_master_plane_state might not be
copied to hw yet */
+ if (new_master_plane_state->uapi.crtc)
+ return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
+ }
+
+ if (old_plane_state->bigjoiner_slave) {
+ const struct intel_plane_state *old_master_plane_state =
+ intel_atomic_get_old_plane_state(state,
old_plane_state->bigjoiner_plane);
+
+ if (old_master_plane_state->uapi.crtc)
+ return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
+ }
+
return NULL;
}
@@ -338,18 +364,33 @@ int intel_plane_atomic_check(struct intel_atomic_state
*state,
intel_atomic_get_new_plane_state(state, plane);
const struct intel_plane_state *old_plane_state =
intel_atomic_get_old_plane_state(state, plane);
+ const struct intel_plane_state *new_master_plane_state;
struct intel_crtc *crtc =
- get_crtc_from_states(old_plane_state, new_plane_state);
+ get_crtc_from_states(state, old_plane_state,
+new_plane_state);
const struct intel_crtc_state *old_crtc_state;
struct intel_crtc_state *new_crtc_state;
-
[Intel-gfx] [PATCH v9 09/11] drm/i915: Add bigjoiner aware plane clipping checks
From: Maarten Lankhorst
We need to look at hw.fb for the framebuffer, and add the translation
for the slave_plane_state. With these changes we set the correct
rectangle on the bigjoiner slave, and don't set incorrect
src/dst/visibility on the slave plane.
v2:
* Manual rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 60 +++
.../gpu/drm/i915/display/intel_atomic_plane.h | 4 ++
drivers/gpu/drm/i915/display/intel_display.c | 19 +++---
drivers/gpu/drm/i915/display/intel_sprite.c | 21 +++
4 files changed, 80 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 0610a254a5f9..7372b28d7879 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -267,6 +267,9 @@ void intel_plane_copy_uapi_to_hw_state(const struct
intel_crtc_state *crtc_state
plane_state->hw.rotation = from_plane_state->uapi.rotation;
plane_state->hw.color_encoding = from_plane_state->uapi.color_encoding;
plane_state->hw.color_range = from_plane_state->uapi.color_range;
+
+ plane_state->uapi.src = drm_plane_state_src(_plane_state->uapi);
+ plane_state->uapi.dst = drm_plane_state_dest(_plane_state->uapi);
}
void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
@@ -515,6 +518,63 @@ void i9xx_update_planes_on_crtc(struct intel_atomic_state
*state,
}
}
+int intel_atomic_plane_check_clipping(struct intel_plane_state *plane_state,
+ struct intel_crtc_state *crtc_state,
+ int min_scale, int max_scale,
+ bool can_position)
+{
+ struct drm_framebuffer *fb = plane_state->hw.fb;
+ struct drm_rect *src = _state->uapi.src;
+ struct drm_rect *dst = _state->uapi.dst;
+ unsigned int rotation = plane_state->uapi.rotation;
+ struct drm_rect clip = {};
+ int hscale, vscale;
+
+ if (!fb) {
+ plane_state->uapi.visible = false;
+ return 0;
+ }
+
+ drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
+
+ /* Check scaling */
+ hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
+ vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
+ if (hscale < 0 || vscale < 0) {
+ DRM_DEBUG_KMS("Invalid scaling of plane\n");
+ drm_rect_debug_print("src: ", src, true);
+ drm_rect_debug_print("dst: ", dst, false);
+ return -ERANGE;
+ }
+
+ if (crtc_state->hw.enable) {
+ clip.x2 = crtc_state->pipe_src_w;
+ clip.y2 = crtc_state->pipe_src_h;
+ }
+
+ /* right side of the image is on the slave crtc, adjust dst to match */
+ if (crtc_state->bigjoiner_slave)
+ drm_rect_translate(dst, -crtc_state->pipe_src_w, 0);
+
+ /*
+* FIXME: This might need further adjustment for seamless scaling
+* with phase information, for the 2p2 and 2p1 scenarios.
+*/
+ plane_state->uapi.visible = drm_rect_clip_scaled(src, dst, );
+
+ drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
+
+ if (!can_position && plane_state->uapi.visible &&
+ !drm_rect_equals(dst, )) {
+ DRM_DEBUG_KMS("Plane must cover entire CRTC\n");
+ drm_rect_debug_print("dst: ", dst, false);
+ drm_rect_debug_print("clip: ", , false);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index c2a1e7c86e6c..d0a599d00ecd 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -53,6 +53,10 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
struct intel_plane *plane,
bool *need_cdclk_calc);
+int intel_atomic_plane_check_clipping(struct intel_plane_state *plane_state,
+ struct intel_crtc_state *crtc_state,
+ int min_scale, int max_scale,
+ bool can_position);
void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index
[Intel-gfx] [PATCH v9 10/11] drm/i915: Add intel_update_bigjoiner handling.
From: Maarten Lankhorst
Enabling is done in a special sequence and so should plane updates
be. Ideally the end user never notices the second pipe is used,
so use the vblank evasion to cover both pipes.
This way ideally everything will be tear free, and updates are
really atomic as userspace expects it.
This still has special handling for bigjoiner which will be
removed eventually and made to fit in the generic
modeset_enables code like trans_port_sync.
This optimization will be done as a second step once we have the
end to end functionality working.
v3:
* Fixes in enable and disable sequence from testing (Manasi)
v2:
* Manual Rebase (Manasi)
* Refactoring on intel_update_crtc and enable_crtc and removing
special trans_port_sync_update (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 133 ---
drivers/gpu/drm/i915/display/intel_sprite.c | 25 +++-
drivers/gpu/drm/i915/display/intel_sprite.h | 3 +-
3 files changed, 138 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index de2b13b14b3a..6168f35deb61 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15711,7 +15711,7 @@ static void intel_update_crtc(struct intel_atomic_state
*state,
else
i9xx_update_planes_on_crtc(state, crtc);
- intel_pipe_update_end(new_crtc_state);
+ intel_pipe_update_end(new_crtc_state, NULL);
/*
* We usually enable FIFO underrun interrupts as part of the
@@ -15735,9 +15735,11 @@ static void intel_old_crtc_state_disables(struct
intel_atomic_state *state,
drm_WARN_ON(_priv->drm, old_crtc_state->bigjoiner_slave);
intel_crtc_disable_planes(state, crtc);
- if (old_crtc_state->bigjoiner)
+ if (old_crtc_state->bigjoiner) {
intel_crtc_disable_planes(state,
old_crtc_state->bigjoiner_linked_crtc);
+ old_crtc_state->bigjoiner_linked_crtc->active = false;
+ }
/*
* We need to disable pipe CRC before disabling the pipe,
@@ -15767,7 +15769,7 @@ static void intel_commit_modeset_disables(struct
intel_atomic_state *state)
/* Only disable port sync and MST slaves */
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
- if (!needs_modeset(new_crtc_state) ||
old_crtc_state->bigjoiner_slave)
+ if (!needs_modeset(new_crtc_state) || old_crtc_state->bigjoiner)
continue;
if (!old_crtc_state->hw.active)
@@ -15809,6 +15811,52 @@ static void intel_commit_modeset_disables(struct
intel_atomic_state *state)
}
}
+static void intel_update_bigjoiner(struct intel_crtc *crtc,
+ struct intel_atomic_state *state,
+ struct intel_crtc_state *old_crtc_state,
+ struct intel_crtc_state *new_crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ bool modeset = needs_modeset(new_crtc_state);
+ struct intel_crtc *slave = new_crtc_state->bigjoiner_linked_crtc;
+ struct intel_crtc_state *new_slave_crtc_state =
+ intel_atomic_get_new_crtc_state(state, slave);
+
+ if (modeset) {
+ /* Enable slave first */
+ intel_crtc_update_active_timings(new_slave_crtc_state);
+ dev_priv->display.crtc_enable(state, slave);
+
+ /* Then master */
+ intel_crtc_update_active_timings(new_crtc_state);
+ dev_priv->display.crtc_enable(state, crtc);
+
+ /* vblanks work again, re-enable pipe CRC. */
+ intel_crtc_enable_pipe_crc(crtc);
+
+ } else {
+ intel_pre_plane_update(state, crtc);
+ intel_pre_plane_update(state, slave);
+
+ if (new_crtc_state->update_pipe)
+ intel_encoders_update_pipe(state, crtc);
+ }
+
+ /*
+* Perform vblank evasion around commit operation, and make sure to
+* commit both planes simultaneously for best results.
+*/
+ intel_pipe_update_start(new_crtc_state);
+
+ commit_pipe_config(state, crtc);
+ commit_pipe_config(state, slave);
+
+ skl_update_planes_on_crtc(state, crtc);
+ skl_update_planes_on_crtc(state, slave);
+
+ intel_pipe_update_end(new_crtc_state, new_slave_crtc_state);
+}
+
static void intel_commit_modeset_enables(struct intel_atomic_state *state)
{
struct intel_crtc_state *new_crtc_state;
@@ -15827,15 +15875,22 @@ static void intel_commit_modeset_enables(struct
intel_atomic_state *state)
static void skl_commit_modeset_enables(struct
[Intel-gfx] [PATCH v9 01/11] HAX to make DSC work on the icelake test system
From: Maarten Lankhorst
DSC is available on the display emulator, but not set in DPCD.
Override the entries to allow bigjoiner testing.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_dp_helper.c | 4 ++--
include/drm/drm_dp_helper.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 478dd51f738d..7f355c1c49c0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1987,7 +1987,7 @@ u8 drm_dp_dsc_sink_max_slice_count(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
return 4;
if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
- return 2;
+ return 4;
if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
return 1;
} else {
@@ -2011,7 +2011,7 @@ u8 drm_dp_dsc_sink_max_slice_count(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
return 4;
if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
- return 2;
+ return 4;
if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
return 1;
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c9f2851904d0..42b91764bbad 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1449,6 +1449,7 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpc[DP_DSC_RECEIVER_CAP_SI
static inline bool
drm_dp_sink_supports_dsc(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
{
+ return dsc_dpcd[DP_DSC_REV - DP_DSC_SUPPORT];
return dsc_dpcd[DP_DSC_SUPPORT - DP_DSC_SUPPORT] &
DP_DSC_DECOMPRESSION_IS_SUPPORTED;
}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 02/11] drm/i915/display: Rename pipe_timings to transcoder_timings
No functional changes in this patch.
With Bigjoiner, there are 2 pipes driving 2 halfs of 1
transcoder. The transcoder_mode has the full timings, and is used
for configuring the transcoder with the intended mode after
joining the 2 halves.
To clear the confusion, we rename intel_set_pipe_timings to
intel_set_transcoder_timings
v2:
* Split the renaming into separate patch (Ville)
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Animesh Manna
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 22 ++--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..4850644ab43f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -154,7 +154,7 @@ static void ilk_pch_clock_get(struct intel_crtc *crtc,
static int intel_framebuffer_init(struct intel_framebuffer *ifb,
struct drm_i915_gem_object *obj,
struct drm_mode_fb_cmd2 *mode_cmd);
-static void intel_set_pipe_timings(const struct intel_crtc_state *crtc_state);
+static void intel_set_transcoder_timings(const struct intel_crtc_state
*crtc_state);
static void intel_set_pipe_src_size(const struct intel_crtc_state *crtc_state);
static void intel_cpu_transcoder_set_m_n(const struct intel_crtc_state
*crtc_state,
const struct intel_link_m_n *m_n,
@@ -6943,7 +6943,7 @@ static void ilk_crtc_enable(struct intel_atomic_state
*state,
if (intel_crtc_has_dp_encoder(new_crtc_state))
intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
if (new_crtc_state->has_pch_encoder)
@@ -7088,7 +7088,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
intel_encoders_pre_enable(state, crtc);
if (!transcoder_is_dsi(cpu_transcoder))
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
@@ -7483,7 +7483,7 @@ static void valleyview_crtc_enable(struct
intel_atomic_state *state,
if (intel_crtc_has_dp_encoder(new_crtc_state))
intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
@@ -7551,7 +7551,7 @@ static void i9xx_crtc_enable(struct intel_atomic_state
*state,
if (intel_crtc_has_dp_encoder(new_crtc_state))
intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
i9xx_set_pipeconf(new_crtc_state);
@@ -8805,7 +8805,7 @@ static void i8xx_compute_dpll(struct intel_crtc *crtc,
crtc_state->dpll_hw_state.dpll = dpll;
}
-static void intel_set_pipe_timings(const struct intel_crtc_state *crtc_state)
+static void intel_set_transcoder_timings(const struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -8891,8 +8891,8 @@ static bool intel_pipe_is_interlaced(const struct
intel_crtc_state *crtc_state)
return intel_de_read(dev_priv, PIPECONF(cpu_transcoder)) &
PIPECONF_INTERLACE_MASK;
}
-static void intel_get_pipe_timings(struct intel_crtc *crtc,
- struct intel_crtc_state *pipe_config)
+static void intel_get_transcoder_timings(struct intel_crtc *crtc,
+struct intel_crtc_state *pipe_config)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -9515,7 +9515,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
if (INTEL_GEN(dev_priv) < 4)
pipe_config->double_wide = tmp & PIPECONF_DOUBLE_WIDE;
- intel_get_pipe_timings(crtc, pipe_config);
+ intel_get_transcoder_timings(crtc, pipe_config);
intel_get_pipe_src_size(crtc, pipe_config);
i9xx_get_pfit_config(pipe_config);
@@ -10796,7 +10796,7 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc,
pipe_config->pixel_multiplier = 1;
}
- intel_get_pipe_timings(crtc, pipe_config);
+ intel_get_transcoder_timings(crtc, pipe_config);
intel_get_pipe_src_size(crtc, pipe_config);
ilk_get_pfit_config(pipe_config);
@@ -11213,7 +11213,7 @@ static bool hsw_get_pipe_config(struct intel_crtc
[Intel-gfx] [PATCH 3/3] drm/i915: Inline intel_dp_ycbcr420_config()
From: Ville Syrjälä
intel_dp_ycbcr420_config() is rather pointless. Just inline it
directly into intel_dp_compute_config(). This gets rid of the
ugly double assignment of output_format.
Not really sure what the best policy would be when the user
supplies a mode classiefied by the display as "YCbCr 4:2:0
only", but we know that we can't do YCbCr 4:2:0 output. For
now keep the current behaviour of just silently upgrade
it to RGB 4:4:4.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 33 +++--
1 file changed, 9 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f58df4994d92..a50e502dedf8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -599,7 +599,8 @@ intel_dp_output_format(struct drm_connector *connector,
struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
const struct drm_display_info *info = >display_info;
- if (!drm_mode_is_420_only(info, mode))
+ if (!connector->ycbcr_420_allowed ||
+ !drm_mode_is_420_only(info, mode))
return INTEL_OUTPUT_FORMAT_RGB;
if (intel_dp->dfp.ycbcr_444_to_420)
@@ -2456,25 +2457,6 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
return 0;
}
-static int
-intel_dp_ycbcr420_config(struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
-{
- struct drm_connector *connector = conn_state->connector;
- const struct drm_display_mode *adjusted_mode =
- _state->hw.adjusted_mode;
-
- if (!connector->ycbcr_420_allowed)
- return 0;
-
- crtc_state->output_format = intel_dp_output_format(connector,
adjusted_mode);
-
- if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
- return 0;
-
- return intel_pch_panel_fitting(crtc_state, conn_state);
-}
-
bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
@@ -2724,11 +2706,14 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
pipe_config->has_pch_encoder = true;
- pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+ pipe_config->output_format =
intel_dp_output_format(_connector->base,
+ adjusted_mode);
- ret = intel_dp_ycbcr420_config(pipe_config, conn_state);
- if (ret)
- return ret;
+ if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
+ ret = intel_pch_panel_fitting(pipe_config, conn_state);
+ if (ret)
+ return ret;
+ }
if (!intel_dp_port_has_audio(dev_priv, port))
pipe_config->has_audio = false;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Nuke lspcon_downsampling
From: Ville Syrjälä
crtc_state->lspcon_downsampling isn't particularly useful at
the moment since we can't even do proper readout for it.
Let's get rid of it. Will help with unifying the LSPCON with
the regular DFP YCbCr output support.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 12 ---
.../drm/i915/display/intel_display_types.h| 3 ---
drivers/gpu/drm/i915/display/intel_lspcon.c | 20 +++
3 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..a51cf048ecd3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11229,18 +11229,6 @@ static bool hsw_get_pipe_config(struct intel_crtc
*crtc,
} else {
pipe_config->output_format =
bdw_get_pipemisc_output_format(crtc);
-
- /*
-* Currently there is no interface defined to
-* check user preference between RGB/YCBCR444
-* or YCBCR420. So the only possible case for
-* YCBCR444 usage is driving YCBCR420 output
-* with LSPCON, when pipe is configured for
-* YCBCR444 output and LSPCON takes care of
-* downsampling it.
-*/
- pipe_config->lspcon_downsampling =
- pipe_config->output_format ==
INTEL_OUTPUT_FORMAT_YCBCR444;
}
pipe_config->gamma_mode = intel_de_read(dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3d4bf9b6a0a2..4e7d52d821cd 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1035,9 +1035,6 @@ struct intel_crtc_state {
/* Output format RGB/YCBCR etc */
enum intel_output_format output_format;
- /* Output down scaling is done in LSPCON device */
- bool lspcon_downsampling;
-
/* enable pipe gamma? */
bool gamma_enable;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index dc1b35559afd..59f13aef58b5 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -195,7 +195,6 @@ void lspcon_ycbcr420_config(struct drm_connector *connector,
connector->ycbcr_420_allowed) {
crtc_state->port_clock /= 2;
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
- crtc_state->lspcon_downsampling = true;
}
}
@@ -492,14 +491,19 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
return;
}
- if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
- if (crtc_state->lspcon_downsampling)
- frame.avi.colorspace = HDMI_COLORSPACE_YUV420;
- else
- frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
- } else {
+ /*
+* Currently there is no interface defined to
+* check user preference between RGB/YCBCR444
+* or YCBCR420. So the only possible case for
+* YCBCR444 usage is driving YCBCR420 output
+* with LSPCON, when pipe is configured for
+* YCBCR444 output and LSPCON takes care of
+* downsampling it.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
+ frame.avi.colorspace = HDMI_COLORSPACE_YUV420;
+ else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
- }
drm_hdmi_avi_infoframe_quant_range(,
conn_state->connector,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Nuke lspcon_ycbcr420_config()
From: Ville Syrjälä
Remove the lspcon special case from intel_dp_compute_config() and
just treat it like any other DFP than can do 4:4:4->4:2:0 conversion.
The only difference between the two codepaths was that the lspcon
code tried to already halve port_clock. That was just total nonsense
as we hadn't even computed the base port_clock at that time.
All that stuff happens intel_dp_compute_link_config*() and it
already takes care of the 4:2:0 clock reduction.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 8 +++-
drivers/gpu/drm/i915/display/intel_lspcon.c | 14 --
drivers/gpu/drm/i915/display/intel_lspcon.h | 2 --
3 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 54a4b81ea3ff..f58df4994d92 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2713,7 +2713,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
enum port port = encoder->port;
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct intel_digital_connector_state *intel_conn_state =
@@ -2727,10 +2726,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
- if (lspcon->active)
- lspcon_ycbcr420_config(_connector->base, pipe_config);
- else
- ret = intel_dp_ycbcr420_config(pipe_config, conn_state);
+ ret = intel_dp_ycbcr420_config(pipe_config, conn_state);
if (ret)
return ret;
@@ -6240,7 +6236,9 @@ intel_dp_update_420(struct intel_dp *intel_dp)
ycbcr_420_passthrough =
drm_dp_downstream_420_passthrough(intel_dp->dpcd,
intel_dp->downstream_ports);
+ /* on-board LSPCON always assumed to support 4:4:4->4:2:0 conversion */
ycbcr_444_to_420 =
+ dp_to_dig_port(intel_dp)->lspcon.active ||
drm_dp_downstream_444_to_420_conversion(intel_dp->dpcd,
intel_dp->downstream_ports);
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 59f13aef58b5..bbe011c5f7a5 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -184,20 +184,6 @@ static bool lspcon_wake_native_aux_ch(struct intel_lspcon
*lspcon)
return true;
}
-void lspcon_ycbcr420_config(struct drm_connector *connector,
- struct intel_crtc_state *crtc_state)
-{
- const struct drm_display_info *info = >display_info;
- const struct drm_display_mode *adjusted_mode =
- _state->hw.adjusted_mode;
-
- if (drm_mode_is_420_only(info, adjusted_mode) &&
- connector->ycbcr_420_allowed) {
- crtc_state->port_clock /= 2;
- crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
- }
-}
-
static bool lspcon_probe(struct intel_lspcon *lspcon)
{
int retry;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 1cffe8a42a08..31eebab9ed57 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -32,7 +32,5 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
const struct drm_connector_state *conn_state);
u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config);
-void lspcon_ycbcr420_config(struct drm_connector *connector,
- struct intel_crtc_state *crtc_state);
#endif /* __INTEL_LSPCON_H__ */
--
2.26.2
___
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 [v4,1/3] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
== Series Details ==
Series: series starting with [v4,1/3] drm/i915/display: Ignore
IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
URL : https://patchwork.freedesktop.org/series/82066/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9050 -> Patchwork_18564
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/index.html
Known issues
Here are the changes found in Patchwork_18564 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] /
[i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [PASS][3] -> [DMESG-WARN][4] ([i915#2203])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@vgem_basic@dmabuf-export:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html
Possible fixes
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-dpms@a-edp1:
- fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-tgl-y/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-tgl-y/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
* igt@prime_vgem@basic-read:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-tgl-y/igt@prime_v...@basic-read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-tgl-y/igt@prime_v...@basic-read.html
Warnings
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +5 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9050/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18564/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]:
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote: > On Thu, 24 Sep 2020 08:57:52 +0200 > Thomas Gleixner wrote: > >> > Now as for migration disabled nesting, at least now we would have >> > groupings of this, and perhaps the theorists can handle that. I mean, >> > how is this much different that having a bunch of tasks blocked on a >> > mutex with the owner is pinned on a CPU? >> > >> > migrate_disable() is a BKL of pinning affinity. >> >> No. That's just wrong. preempt disable is a concurrency control, > > I think you totally misunderstood what I was saying. The above wasn't about > comparing preempt_disable to migrate_disable. It was comparing > migrate_disable to a chain of tasks blocked on mutexes where the top owner > has preempt_disable set. You still have a bunch of tasks that can't move to > other CPUs. What? The top owner does not prevent any task from moving. The tasks cannot move because they are blocked on the mutex, which means they are not runnable and non runnable tasks are not migrated at all. I really don't understand what you are trying to say. >> > If we only have local_lock() available (even on !RT), then it makes >> > the blocking in groups. At least this way you could grep for all the >> > different local_locks in the system and plug that into the algorithm >> > for WCS, just like one would with a bunch of mutexes. >> >> You cannot do that on RT at all where migrate disable is substituting >> preempt disable in spin and rw locks. The result would be the same as >> with a !RT kernel just with horribly bad performance. > > Note, the spin and rwlocks already have a lock associated with them. Why > would it be any different on RT? I wasn't suggesting adding another lock > inside a spinlock. Why would I recommend THAT? I wasn't recommending > blindly replacing migrate_disable() with local_lock(). I just meant expose > local_lock() but not migrate_disable(). We already exposed local_lock() to non RT and it's for places which do preempt_disable() or local_irq_disable() without having a lock associated. But both primitives are scope less and therefore behave like CPU local BKLs. What local_lock() provides in these cases is: - Making the protection scope clear by associating a named local lock which is coverred by lockdep. - It still maps to preempt_disable() or local_irq_disable() in !RT kernels - The scope and the named lock allows RT kernels to substitute with real (recursion aware) locking primitives which keep preemption and interupts enabled, but provide the fine grained protection for the scoped critical section. So how would you substitute migrate_disable() with a local_lock()? You can't. Again migrate_disable() is NOT a concurrency control and therefore it cannot be substituted by any concurrency control primitive. >> That means the stacking problem has to be solved anyway. >> >> So why on earth do you want to create yet another special duct tape case >> for kamp_local() which proliferates inconsistency instead of aiming for >> consistency accross all preemption models? > > The idea was to help with the scheduling issue. I don't see how mixing concepts and trying to duct tape a problem which is clearly in the realm of the scheduler, i.e. load balancing and placing algorithms, is helpful. Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/14] drm/i915: Add SKL GT1.5 PCI IDs
> -Original Message- > From: Ville Syrjälä > Sent: Thursday, September 24, 2020 3:46 AM > To: Srivatsa, Anusha > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 04/14] drm/i915: Add SKL GT1.5 PCI IDs > > On Thu, Sep 24, 2020 at 12:37:47AM +, Srivatsa, Anusha wrote: > > > > > > > -Original Message- > > > From: Intel-gfx On Behalf > > > Of Ville Syrjala > > > Sent: Thursday, July 16, 2020 10:21 AM > > > To: intel-gfx@lists.freedesktop.org > > > Subject: [Intel-gfx] [PATCH 04/14] drm/i915: Add SKL GT1.5 PCI IDs > > > > > > From: Alexei Podtelezhnikov > > > > > > Add three new devices 0x1913, 0x1915, and 0x1917 also known as > > > iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. > > > > > > Signed-off-by: Alexei Podtelezhnikov > > > [vsyrjala: Split separate changes into separate patchs, > > >Sort the IDs] > > The above comment appears in every patch. If this is v2 of the patches > then it goes right after the commit message as: > > > > V2: Split separate changes into separate patches, sort the IDs > > (Ville) > > No. I use the [vsyrjala: blah] notation to indicate I modified the original > patch which was authored by someone else. > > > > > > Signed-off-by: Ville Syrjälä > > The code changes itself look good. Ah. Ok. Makes sense Anusha > > Reviewed-by: Anusha Srivatsa > > > > > --- > > > include/drm/i915_pciids.h | 9 ++--- > > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > > > index 9df3697f074d..c906088ccffe 100644 > > > --- a/include/drm/i915_pciids.h > > > +++ b/include/drm/i915_pciids.h > > > @@ -329,17 +329,20 @@ > > > INTEL_VGA_DEVICE(0x22b3, info) > > > > > > #define INTEL_SKL_ULT_GT1_IDS(info) \ > > > - INTEL_VGA_DEVICE(0x1906, info) /* ULT GT1 */ > > > + INTEL_VGA_DEVICE(0x1906, info), /* ULT GT1 */ \ > > > + INTEL_VGA_DEVICE(0x1913, info) /* ULT GT1.5 */ > > > > > > #define INTEL_SKL_ULX_GT1_IDS(info) \ > > > - INTEL_VGA_DEVICE(0x190E, info) /* ULX GT1 */ > > > + INTEL_VGA_DEVICE(0x190E, info), /* ULX GT1 */ \ > > > + INTEL_VGA_DEVICE(0x1915, info) /* ULX GT1.5 */ > > > > > > #define INTEL_SKL_GT1_IDS(info) \ > > > INTEL_SKL_ULT_GT1_IDS(info), \ > > > INTEL_SKL_ULX_GT1_IDS(info), \ > > > INTEL_VGA_DEVICE(0x1902, info), /* DT GT1 */ \ > > > INTEL_VGA_DEVICE(0x190B, info), /* Halo GT1 */ \ > > > - INTEL_VGA_DEVICE(0x190A, info) /* SRV GT1 */ > > > + INTEL_VGA_DEVICE(0x190A, info), /* SRV GT1 */ \ > > > + INTEL_VGA_DEVICE(0x1917, info) /* DT GT1.5 */ > > > > > > #define INTEL_SKL_ULT_GT2_IDS(info) \ > > > INTEL_VGA_DEVICE(0x1916, info), /* ULT GT2 */ \ > > > -- > > > 2.26.2 > > > > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/3] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
For platforms without selective fetch this register is reserved so do not write 0 to it. Cc: Gwan-gyeong Mun Cc: Ville Syrjälä Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_psr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 8a9d0bdde1bf..4e09ae61d4aa 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -942,7 +942,7 @@ static void intel_psr_enable_source(struct intel_dp *intel_dp, intel_de_write(dev_priv, EXITLINE(cpu_transcoder), val); } - if (HAS_PSR_HW_TRACKING(dev_priv)) + if (HAS_PSR_HW_TRACKING(dev_priv) && HAS_PSR2_SEL_FETCH(dev_priv)) intel_de_rmw(dev_priv, CHICKEN_PAR1_1, IGNORE_PSR2_HW_TRACKING, dev_priv->psr.psr2_sel_fetch_enabled ? IGNORE_PSR2_HW_TRACKING : 0); -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/3] drm/i915/display: Check PSR parameter and flag only in state compute phase
Due to the debugfs flag, has_psr2 in CRTC state could have a different
value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO
and selective fetch) to be set to not a expected state.
So here only taking in consideration the parameter and debugfs flag
when computing PSR state, this way the CRTC state will also have
the correct state.
intel_psr_fastset_force() was already broken as
intel_psr_compute_config() was already only enabling PSR when
psr_global_enabled() and all other PSR requirements are met.
So some changes was required in this function, now it iterates over
all connectors, if it is a eDP connector and is active force a modeset
in the CRTC driving this connector, what will cause the new PSR state
to be set based on the debugfs flag.
v2:
- end connector iterator in error cases
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 73 +---
1 file changed, 41 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 4e09ae61d4aa..02f74b0ddec1 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -91,19 +91,14 @@ static bool psr_global_enabled(struct drm_i915_private
*i915)
}
}
-static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
- const struct intel_crtc_state *crtc_state)
+static bool psr2_global_enabled(struct drm_i915_private *dev_priv)
{
- /* Cannot enable DSC and PSR2 simultaneously */
- drm_WARN_ON(_priv->drm, crtc_state->dsc.compression_enable &&
- crtc_state->has_psr2);
-
switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
case I915_PSR_DEBUG_DISABLE:
case I915_PSR_DEBUG_FORCE_PSR1:
return false;
default:
- return crtc_state->has_psr2;
+ return true;
}
}
@@ -729,6 +724,11 @@ static bool intel_psr2_config_valid(struct intel_dp
*intel_dp,
return false;
}
+ if (!psr2_global_enabled(dev_priv)) {
+ drm_dbg_kms(_priv->drm, "PSR2 disabled by flag\n");
+ return false;
+ }
+
/*
* DSC and PSR2 cannot be enabled simultaneously. If a requested
* resolution requires DSC to be enabled, priority is given to DSC
@@ -817,8 +817,11 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
if (intel_dp != dev_priv->psr.dp)
return;
- if (!psr_global_enabled(dev_priv))
+ if (!psr_global_enabled(dev_priv)) {
+ drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
return;
+ }
+
/*
* HSW spec explicitly says PSR is tied to port A.
* BDW+ platforms have a instance of PSR registers per transcoder but
@@ -959,7 +962,7 @@ static void intel_psr_enable_locked(struct drm_i915_private
*dev_priv,
drm_WARN_ON(_priv->drm, dev_priv->psr.enabled);
- dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
+ dev_priv->psr.psr2_enabled = crtc_state->has_psr2;
dev_priv->psr.busy_frontbuffer_bits = 0;
dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
@@ -1029,15 +1032,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
drm_WARN_ON(_priv->drm, dev_priv->drrs.dp);
mutex_lock(_priv->psr.lock);
-
- if (!psr_global_enabled(dev_priv)) {
- drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
- goto unlock;
- }
-
intel_psr_enable_locked(dev_priv, crtc_state, conn_state);
-
-unlock:
mutex_unlock(_priv->psr.lock);
}
@@ -1222,8 +1217,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
mutex_lock(_priv->psr.lock);
- enable = crtc_state->has_psr && psr_global_enabled(dev_priv);
- psr2_enable = intel_psr2_enabled(dev_priv, crtc_state);
+ enable = crtc_state->has_psr;
+ psr2_enable = crtc_state->has_psr2;
if (enable == psr->enabled && psr2_enable == psr->psr2_enabled) {
/* Force a PSR exit when enabling CRC to avoid CRC timeouts */
@@ -1320,11 +1315,12 @@ static bool __psr_wait_for_idle_locked(struct
drm_i915_private *dev_priv)
static int intel_psr_fastset_force(struct drm_i915_private *dev_priv)
{
+ struct drm_connector_list_iter conn_iter;
struct drm_device *dev = _priv->drm;
struct drm_modeset_acquire_ctx ctx;
struct drm_atomic_state *state;
- struct intel_crtc *crtc;
- int err;
+ struct drm_connector *conn;
+ int err = 0;
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -1334,25 +1330,38 @@ static int intel_psr_fastset_force(struct
drm_i915_private *dev_priv)
[Intel-gfx] [PATCH v4 3/3] drm/i915/display: Program PSR2 selective fetch registers
Another step towards PSR2 selective fetch, here programming plane
selective fetch registers and MAN_TRK_CTL enabling selective fetch but
for now it is fetching the whole area of the planes.
The damaged area calculation will come as next and final step.
v2:
- removed warn on when no plane is visible in state
- removed calculations using plane damaged area in
intel_psr2_program_plane_sel_fetch()
v3:
- do not shift 16 positions the plane dst coordinates, only src is
shifted
v4:
- only setting PLANE_SEL_FETCH_CTL_ENABLE and MCURSOR_MODE in
PLANE_SEL_FETCH_CTL
BSpec: 55229
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/display/intel_psr.c | 118 ++-
drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
4 files changed, 132 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..96bc515497c1 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11812,6 +11812,9 @@ static void i9xx_update_cursor(struct intel_plane
*plane,
if (INTEL_GEN(dev_priv) >= 9)
skl_write_cursor_wm(plane, crtc_state);
+ if (!needs_modeset(crtc_state))
+ intel_psr2_program_plane_sel_fetch(plane, crtc_state,
plane_state, 0);
+
if (plane->cursor.base != base ||
plane->cursor.size != fbc_ctl ||
plane->cursor.cntl != cntl) {
@@ -12823,8 +12826,11 @@ static int intel_crtc_atomic_check(struct
intel_atomic_state *state,
}
- if (!mode_changed)
- intel_psr2_sel_fetch_update(state, crtc);
+ if (!mode_changed) {
+ ret = intel_psr2_sel_fetch_update(state, crtc);
+ if (ret)
+ return ret;
+ }
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 02f74b0ddec1..f6e0a192d5e5 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1166,6 +1166,39 @@ static void psr_force_hw_tracking_exit(struct
drm_i915_private *dev_priv)
intel_psr_exit(dev_priv);
}
+void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
+ const struct intel_crtc_state
*crtc_state,
+ const struct intel_plane_state
*plane_state,
+ int color_plane)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ enum pipe pipe = plane->pipe;
+ u32 val;
+
+ if (!crtc_state->enable_psr2_sel_fetch)
+ return;
+
+ val = plane_state ? plane_state->ctl : 0;
+ val = plane->id == PLANE_CURSOR ? val & MCURSOR_MODE :
+ val & PLANE_SEL_FETCH_CTL_ENABLE;
+ intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id), val);
+ if (!val || plane->id == PLANE_CURSOR)
+ return;
+
+ val = plane_state->uapi.dst.y1 << 16 | plane_state->uapi.dst.x1;
+ intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_POS(pipe, plane->id), val);
+
+ val = plane_state->color_plane[color_plane].y << 16;
+ val |= plane_state->color_plane[color_plane].x;
+ intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_OFFSET(pipe, plane->id),
+ val);
+
+ /* Sizes are 0 based */
+ val = ((drm_rect_height(_state->uapi.src) >> 16) - 1) << 16;
+ val |= (drm_rect_width(_state->uapi.src) >> 16) - 1;
+ intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_SIZE(pipe, plane->id), val);
+}
+
void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -1180,16 +1213,91 @@ void intel_psr2_program_trans_man_trk_ctl(const struct
intel_crtc_state *crtc_st
crtc_state->psr2_man_track_ctl);
}
-void intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
-struct intel_crtc *crtc)
+static void psr2_man_trk_ctl_calc(struct intel_crtc_state *crtc_state,
+ struct drm_rect *clip, bool full_update)
+{
+ u32 val = PSR2_MAN_TRK_CTL_ENABLE;
+
+ if (full_update) {
+ val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
+ goto exit;
+ }
+
+ if (clip->y1 == -1)
+ goto exit;
+
+ val |= PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
+ val |= PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1 / 4 + 1);
+ val |= PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(DIV_ROUND_UP(clip->y2, 4) +
1);
+exit:
+ crtc_state->psr2_man_track_ctl = val;
+}
+
+static void
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display: Program PSR2 selective fetch registers
On Thu, 2020-09-24 at 14:27 +0100, Mun, Gwan-gyeong wrote:
> On Wed, 2020-09-23 at 10:09 -0700, Souza, Jose wrote:
> > On Wed, 2020-09-23 at 10:10 -0700, José Roberto de Souza wrote:
> > > On Wed, 2020-09-23 at 14:02 +0100, Mun, Gwan-gyeong wrote:
> > > > On Thu, 2020-09-17 at 18:02 -0700, José Roberto de Souza wrote:
> > > > > Another step towards PSR2 selective fetch, here programming
> > > > > plane
> > > > > selective fetch registers and MAN_TRK_CTL enabling selective
> > > > > fetch
> > > > > but
> > > > > for now it is fetching the whole area of the planes.
> > > > > The damaged area calculation will come as next and final step.
> > > > >
> > > > > v2:
> > > > > - removed warn on when no plane is visible in state
> > > > > - removed calculations using plane damaged area in
> > > > > intel_psr2_program_plane_sel_fetch()
> > > > >
> > > > > v3:
> > > > > - do not shift 16 positions the plane dst coordinates, only src
> > > > > is
> > > > > shifted
> > > > >
> > > > > BSpec: 55229
> > > > > Cc: Gwan-gyeong Mun <
> > > > > gwan-gyeong@intel.com
> > > > >
> > > > >
> > > > >
> > > > > Cc: Ville Syrjälä <
> > > > > ville.syrj...@linux.intel.com
> > > > >
> > > > >
> > > > >
> > > > > Signed-off-by: José Roberto de Souza <
> > > > > jose.so...@intel.com
> > > > >
> > > > >
> > > > >
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 10 +-
> > > > > drivers/gpu/drm/i915/display/intel_psr.c | 120
> > > > > ++-
> > > > > drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
> > > > > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
> > > > > 4 files changed, 134 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index 5a9d933e425a..96bc515497c1 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -11812,6 +11812,9 @@ static void i9xx_update_cursor(struct
> > > > > intel_plane *plane,
> > > > > if (INTEL_GEN(dev_priv) >= 9)
> > > > > skl_write_cursor_wm(plane, crtc_state);
> > > > >
> > > > > + if (!needs_modeset(crtc_state))
> > > > > + intel_psr2_program_plane_sel_fetch(plane,
> > > > > crtc_state,
> > > > > plane_state, 0);
> > > > > +
> > > > > if (plane->cursor.base != base ||
> > > > > plane->cursor.size != fbc_ctl ||
> > > > > plane->cursor.cntl != cntl) {
> > > > > @@ -12823,8 +12826,11 @@ static int
> > > > > intel_crtc_atomic_check(struct
> > > > > intel_atomic_state *state,
> > > > >
> > > > > }
> > > > >
> > > > > - if (!mode_changed)
> > > > > - intel_psr2_sel_fetch_update(state, crtc);
> > > > > + if (!mode_changed) {
> > > > > + ret = intel_psr2_sel_fetch_update(state, crtc);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > + }
> > > > >
> > > > > return 0;
> > > > > }
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > index 02f74b0ddec1..deb0523f9f29 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > @@ -1166,6 +1166,41 @@ static void
> > > > > psr_force_hw_tracking_exit(struct
> > > > > drm_i915_private *dev_priv)
> > > > > intel_psr_exit(dev_priv);
> > > > > }
> > > > >
> > > > > +void intel_psr2_program_plane_sel_fetch(struct intel_plane
> > > > > *plane,
> > > > > + const struct
> > > > > intel_crtc_state
> > > > > *crtc_state,
> > > > > + const struct
> > > > > intel_plane_state
> > > > > *plane_state,
> > > > > + int color_plane)
> > > > > +{
> > > > > + struct drm_i915_private *dev_priv = to_i915(plane-
> > > > > > base.dev);
> > > > >
> > > > > + enum pipe pipe = plane->pipe;
> > > > > + u32 val;
> > > > > +
> > > > > + if (!crtc_state->enable_psr2_sel_fetch)
> > > > > + return;
> > > > > +
> > > > > + /*
> > > > > + * skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0
> > > > > for
> > > > > gen11+, so
> > > > > + * plane_state->ctl is the right value
> > > > > + */
> > > > > + val = plane_state ? plane_state->ctl : 0;
> > > >
> > > > IMHO, skl_plane_ctl() might set other ctl bits, it would be
> > > > better to
> > > > have separated ctl bit value for "selective fetch ctl".
> > >
> > > Like said all other bits are spares so can be set without issues
> > > but okay will a "plane_state->ctl & PLANE_SEL_FETCH_CTL_ENABLE".
> >
> > Please take a look to the answer of your other comment bellow, with
> > the change above can I have your rv-b?
>
> The purpose and composition of bits of Register_SEL_FETCH_PLANE_CTL is
> different
Re: [Intel-gfx] [PATCH 0/4] Allow privileged user to map the OA buffer
Hi Chris, Okay to push this series? Thanks, Umesh On Thu, Aug 20, 2020 at 11:01:56AM -0700, Umesh Nerlige Ramappa wrote: Allow user to map the OA buffer and also trigger reports into it. CI fixes: v1: Fixes a memory corruption due to addition of OA whitelist on demand. v2: Spinlock when applying whitelist v3: Use uncore->lock. Do not check for wal->count when applying whitelist. v4: Refresh and rerun with newly added test (forked access). Tests: https://patchwork.freedesktop.org/series/80761/ Signed-off-by: Umesh Nerlige Ramappa Test-with: 20200818203547.24461-1-umesh.nerlige.rama...@intel.com Piotr Maciejewski (1): drm/i915/perf: Ensure observation logic is not clock gated Umesh Nerlige Ramappa (3): drm/i915/perf: Whitelist OA report trigger registers drm/i915/perf: Whitelist OA counter and buffer registers drm/i915/perf: Map OA buffer to user space for gen12 performance query drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 153 +--- drivers/gpu/drm/i915/gt/intel_workarounds.h | 7 + .../gpu/drm/i915/gt/intel_workarounds_types.h | 5 + drivers/gpu/drm/i915/i915_perf.c | 225 +- drivers/gpu/drm/i915/i915_perf_types.h| 5 + drivers/gpu/drm/i915/i915_reg.h | 10 + include/uapi/drm/i915_drm.h | 33 +++ 9 files changed, 402 insertions(+), 40 deletions(-) -- 2.20.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
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] mm: update the documentation for vfree
== Series Details ==
Series: series starting with [01/11] mm: update the documentation for vfree
URL : https://patchwork.freedesktop.org/series/82063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9049 -> Patchwork_18563
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/index.html
Known issues
Here are the changes found in Patchwork_18563 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_blits@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-y/igt@gem_tiled_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-y/igt@gem_tiled_bl...@basic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Possible fixes
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [DMESG-FAIL][7] ([i915#1748]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@kms_busy@basic@modeset:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
- fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-y/igt@kms_busy@ba...@modeset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-y/igt@kms_busy@ba...@modeset.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-skl-guc/igt@vgem_ba...@unload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-tgl-y: [DMESG-WARN][15] ([i915#1982] / [i915#2411]) ->
[DMESG-WARN][16] ([i915#2411])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-y/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-y/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1748]: https://gitlab.freedesktop.org/drm/intel/issues/1748
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] mm: update the documentation for vfree
== Series Details ==
Series: series starting with [01/11] mm: update the documentation for vfree
URL : https://patchwork.freedesktop.org/series/82063/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5e88ddacdd34 mm: update the documentation for vfree
90f3c1ba13d1 mm: add a VM_MAP_PUT_PAGES flag for vmap
d41a24c9aa63 mm: add a vmap_pfn function
-:78: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#78: FILE: mm/vmalloc.c:2448:
+ area = get_vm_area_caller(count * PAGE_SIZE, VM_IOREMAP,
+ __builtin_return_address(0));
-:82: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#82: FILE: mm/vmalloc.c:2452:
+ if (apply_to_page_range(_mm, (unsigned long)area->addr,
+ count * PAGE_SIZE, vmap_pfn_apply, )) {
total: 0 errors, 0 warnings, 2 checks, 67 lines checked
5a2e6e88ce76 mm: allow a NULL fn callback in apply_to_page_range
140abd5e7d29 zsmalloc: switch from alloc_vm_area to get_vm_area
-:8: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do not
match
#8:
Co-developed-by: Minchan Kim
Signed-off-by: Christoph Hellwig
total: 0 errors, 1 warnings, 0 checks, 18 lines checked
56b3f4b2f183 drm/i915: use vmap in shmem_pin_map
a037e6a84cf4 drm/i915: stop using kmap in i915_gem_object_map
1b6df0a418db drm/i915: use vmap in i915_gem_object_map
-:48: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#48: FILE: drivers/gpu/drm/i915/gem/i915_gem_pages.c:237:
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+ enum i915_map_type type)
-:146: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#146: FILE: drivers/gpu/drm/i915/gem/i915_gem_pages.c:293:
+static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
+ enum i915_map_type type)
total: 0 errors, 0 warnings, 2 checks, 166 lines checked
cad740b44a07 xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
15518d083ba6 x86/xen: open code alloc_vm_area in arch_gnttab_valloc
-:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#52: FILE: arch/x86/xen/grant-table.c:111:
+ if (apply_to_page_range(_mm, (unsigned long)area->area->addr,
+ PAGE_SIZE * nr_frames, gnttab_apply, area))
total: 0 errors, 0 warnings, 1 checks, 45 lines checked
18c3303e9cc0 mm: remove alloc_vm_area
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for mipi dsi cmd mode (rev14)
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev14)
URL : https://patchwork.freedesktop.org/series/69290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9048 -> Patchwork_18562
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/index.html
Known issues
Here are the changes found in Patchwork_18562 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-tgl-y/igt@gem_flink_ba...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] /
[i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-apl-guc/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-tgl-y/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Possible fixes
* igt@gem_mmap@basic:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-tgl-y/igt@gem_m...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-tgl-y/igt@gem_m...@basic.html
* igt@i915_module_load@reload:
- fi-tgl-y: [DMESG-WARN][15] ([i915#1982] / [k.org#205379]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-tgl-y/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- {fi-tgl-dsi}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-tgl-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-tgl-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][21] ([i915#2203]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-skl-guc/igt@vgem_ba...@unload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18562/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-rte:
- fi-tgl-y: [DMESG-WARN][25] ([i915#2411]) -> [DMESG-WARN][26]
([i915#1982] / [i915#2411])
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9048/fi-tgl-y/igt@i915_pm_...@basic-rte.html
[26]:
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Always test execution status on closing the context
On 16/09/2020 10:42, Chris Wilson wrote:
Verify that if a context is active at the time it is closed, that it is
either persistent and preemptible (with hangcheck running) or it shall
be removed from execution.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
Testcase: igt/gem_ctx_persistence/heartbeat-close
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: # v5.7+
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 48 +
1 file changed, 10 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a548626fa8bc..4fd38101bb56 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -390,24 +390,6 @@ __context_engines_static(const struct i915_gem_context
*ctx)
return rcu_dereference_protected(ctx->engines, true);
}
-static bool __reset_engine(struct intel_engine_cs *engine)
-{
- struct intel_gt *gt = engine->gt;
- bool success = false;
-
- if (!intel_has_reset_engine(gt))
- return false;
-
- if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
- >reset.flags)) {
- success = intel_engine_reset(engine, NULL) == 0;
- clear_and_wake_up_bit(I915_RESET_ENGINE + engine->id,
- >reset.flags);
- }
-
- return success;
-}
-
static void __reset_context(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
@@ -431,12 +413,7 @@ static bool __cancel_engine(struct intel_engine_cs *engine)
* kill the banned context, we fallback to doing a local reset
* instead.
*/
- if (IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT) &&
- !intel_engine_pulse(engine))
- return true;
-
- /* If we are unable to send a pulse, try resetting this engine. */
- return __reset_engine(engine);
+ return intel_engine_pulse(engine) == 0;
Where is the path now which actually resets the currently running
workload (engine) of a non-persistent context? Pulse will be sent and
then rely on hangcheck but otherwise let it run?
Regards,
Tvrtko
}
static bool
@@ -506,7 +483,7 @@ static struct intel_engine_cs *active_engine(struct
intel_context *ce)
return engine;
}
-static void kill_engines(struct i915_gem_engines *engines)
+static void kill_engines(struct i915_gem_engines *engines, bool ban)
{
struct i915_gem_engines_iter it;
struct intel_context *ce;
@@ -521,7 +498,7 @@ static void kill_engines(struct i915_gem_engines *engines)
for_each_gem_engine(ce, engines, it) {
struct intel_engine_cs *engine;
- if (intel_context_set_banned(ce))
+ if (ban && intel_context_set_banned(ce))
continue;
/*
@@ -534,7 +511,7 @@ static void kill_engines(struct i915_gem_engines *engines)
engine = active_engine(ce);
/* First attempt to gracefully cancel the context */
- if (engine && !__cancel_engine(engine))
+ if (engine && !__cancel_engine(engine) && ban)
/*
* If we are unable to send a preemptive pulse to bump
* the context from the GPU, we have to resort to a full
@@ -544,8 +521,10 @@ static void kill_engines(struct i915_gem_engines *engines)
}
}
-static void kill_stale_engines(struct i915_gem_context *ctx)
+static void kill_context(struct i915_gem_context *ctx)
{
+ bool ban = (!i915_gem_context_is_persistent(ctx) ||
+ !ctx->i915->params.enable_hangcheck);
struct i915_gem_engines *pos, *next;
spin_lock_irq(>stale.lock);
@@ -558,7 +537,7 @@ static void kill_stale_engines(struct i915_gem_context *ctx)
spin_unlock_irq(>stale.lock);
- kill_engines(pos);
+ kill_engines(pos, ban);
spin_lock_irq(>stale.lock);
GEM_BUG_ON(i915_sw_fence_signaled(>fence));
@@ -570,11 +549,6 @@ static void kill_stale_engines(struct i915_gem_context
*ctx)
spin_unlock_irq(>stale.lock);
}
-static void kill_context(struct i915_gem_context *ctx)
-{
- kill_stale_engines(ctx);
-}
-
static void engines_idle_release(struct i915_gem_context *ctx,
struct i915_gem_engines *engines)
{
@@ -609,7 +583,7 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
kill:
if (list_empty(>link)) /* raced, already closed */
- kill_engines(engines);
+ kill_engines(engines, true);
i915_sw_fence_commit(>fence);
}
@@ -667,9 +641,7 @@ static void context_close(struct i915_gem_context *ctx)
* case we opt to forcibly kill off all remaining requests on
* context close.
*/
- if
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Uninitialized variable in i915_gem_object_map_page()
== Series Details == Series: drm/i915: Uninitialized variable in i915_gem_object_map_page() URL : https://patchwork.freedesktop.org/series/82060/ State : failure == Summary == Applying: drm/i915: Uninitialized variable in i915_gem_object_map_page() Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gem/i915_gem_pages.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gem/i915_gem_pages.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_pages.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Uninitialized variable in i915_gem_object_map_page() When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] remove alloc_vm_area v2
Hi Andrew, this series removes alloc_vm_area, which was left over from the big vmalloc interface rework. It is a rather arkane interface, basicaly the equivalent of get_vm_area + actually faulting in all PTEs in the allocated area. It was originally addeds for Xen (which isn't modular to start with), and then grew users in zsmalloc and i915 which seems to mostly qualify as abuses of the interface, especially for i915 as a random driver should not set up PTE bits directly. Note that the i915 patches apply to the drm-tip branch of the drm-tip tree, as that tree has recent conflicting commits in the same area. A git tree is also available here: git://git.infradead.org/users/hch/misc.git alloc_vm_area Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/alloc_vm_area Changes since v1: - fix a bug in the zsmalloc changes - fix a bug and rebase to include the recent changes in i915 - add a new vmap flag that allows to free the page array and pages using vfree - add a vfree documentation updated from Matthew Diffstat: arch/x86/xen/grant-table.c| 27 -- drivers/gpu/drm/i915/Kconfig |1 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 131 +- drivers/gpu/drm/i915/gt/shmem_utils.c | 76 - drivers/xen/xenbus/xenbus_client.c| 30 +++--- include/linux/vmalloc.h |7 - mm/Kconfig|3 mm/memory.c | 16 ++- mm/nommu.c|7 - mm/vmalloc.c | 123 ++-- mm/zsmalloc.c | 10 +- 11 files changed, 200 insertions(+), 231 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] mm: add a VM_MAP_PUT_PAGES flag for vmap
Add a flag so that vmap takes ownership of the passed in page array. When vfree is called on such an allocation it will put one reference on each page, and free the page array itself. Signed-off-by: Christoph Hellwig --- include/linux/vmalloc.h | 1 + mm/vmalloc.c| 9 +++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 0221f852a7e1a3..b899681e3ff9f0 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -24,6 +24,7 @@ struct notifier_block;/* in notifier.h */ #define VM_UNINITIALIZED 0x0020 /* vm_struct is not fully initialized */ #define VM_NO_GUARD0x0040 /* don't add guard page */ #define VM_KASAN 0x0080 /* has allocated kasan shadow memory */ +#define VM_MAP_PUT_PAGES 0x0100 /* put pages and free array in vfree */ /* * VM_KASAN is used slighly differently depending on CONFIG_KASAN_VMALLOC. diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 8770260419af06..ffad65f052c3f9 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2377,8 +2377,11 @@ EXPORT_SYMBOL(vunmap); * @flags: vm_area->flags * @prot: page protection for the mapping * - * Maps @count pages from @pages into contiguous kernel virtual - * space. + * Maps @count pages from @pages into contiguous kernel virtual space. + * If @flags contains %VM_MAP_PUT_PAGES the ownership of the pages array itself + * (which must be kmalloc or vmalloc memory) and one reference per pages in it + * are transferred from the caller to vmap(), and will be freed / dropped when + * vfree() is called on the return value. * * Return: the address of the area or %NULL on failure */ @@ -2404,6 +2407,8 @@ void *vmap(struct page **pages, unsigned int count, return NULL; } + if (flags & VM_MAP_PUT_PAGES) + area->pages = pages; return area->addr; } EXPORT_SYMBOL(vmap); -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++
2 files changed, 59 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
select CRC32
select SND_HDA_I915 if SND_HDA_CORE
select CEC_CORE if CEC_NOTIFIER
+ select VMAP_PFN
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..b519417667eb4b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj)
return err;
}
-static inline pte_t iomap_pte(resource_size_t base,
- dma_addr_t offset,
- pgprot_t prot)
-{
- return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
/* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+ enum i915_map_type type)
{
- unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
- struct sg_table *sgt = obj->mm.pages;
- pte_t *stack[32], **mem;
- struct vm_struct *area;
+ unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+ struct page *stack[32], **pages = stack, *page;
+ struct sgt_iter iter;
pgprot_t pgprot;
+ void *vaddr;
- if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
- return NULL;
-
- if (GEM_WARN_ON(type == I915_MAP_WC &&
- !static_cpu_has(X86_FEATURE_PAT)))
- return NULL;
-
- /* A single page can always be kmapped */
- if (n_pte == 1 && type == I915_MAP_WB) {
- struct page *page = sg_page(sgt->sgl);
-
+ switch (type) {
+ default:
+ MISSING_CASE(type);
+ fallthrough;/* to use PAGE_KERNEL anyway */
+ case I915_MAP_WB:
/*
* On 32b, highmem using a finite set of indirect PTE (i.e.
* vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
* So if the page is beyond the 32b boundary, make an explicit
* vmap.
*/
- if (!PageHighMem(page))
- return page_address(page);
- }
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- /* Too big for stack -- allocate temporary array instead */
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
-
- area = alloc_vm_area(obj->base.size, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
- return NULL;
- }
-
- switch (type) {
- default:
- MISSING_CASE(type);
- fallthrough;/* to use PAGE_KERNEL anyway */
- case I915_MAP_WB:
+ if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+ return page_address(sg_page(obj->mm.pages->sgl));
pgprot = PAGE_KERNEL;
break;
case I915_MAP_WC:
@@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
break;
}
- if (i915_gem_object_has_struct_page(obj)) {
- struct sgt_iter iter;
- struct page *page;
- pte_t **ptes = mem;
+ if (n_pages > ARRAY_SIZE(stack)) {
+ /* Too big for stack -- allocate temporary array instead */
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
+ return NULL;
+ }
- for_each_sgt_page(page, iter, sgt)
- **ptes++ = mk_pte(page, pgprot);
- } else
[Intel-gfx] [PATCH 01/11] mm: update the documentation for vfree
From: "Matthew Wilcox (Oracle)"
* Document that you can call vfree() on an address returned from vmap()
* Remove the note about the minimum size -- the minimum size of a vmalloc
allocation is one page
* Add a Context: section
* Fix capitalisation
* Reword the prohibition on calling from NMI context to avoid a double
negative
Signed-off-by: Matthew Wilcox (Oracle)
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index be4724b916b3e7..8770260419af06 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2321,20 +2321,21 @@ static void __vfree(const void *addr)
}
/**
- * vfree - release memory allocated by vmalloc()
- * @addr: memory base address
+ * vfree - Release memory allocated by vmalloc()
+ * @addr: Memory base address
*
- * Free the virtually continuous memory area starting at @addr, as
- * obtained from vmalloc(), vmalloc_32() or __vmalloc(). If @addr is
- * NULL, no operation is performed.
+ * Free the virtually continuous memory area starting at @addr, as obtained
+ * from one of the vmalloc() family of APIs. This will usually also free the
+ * physical memory underlying the virtual allocation, but that memory is
+ * reference counted, so it will not be freed until the last user goes away.
*
- * Must not be called in NMI context (strictly speaking, only if we don't
- * have CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG, but making the calling
- * conventions for vfree() arch-depenedent would be a really bad idea)
+ * If @addr is NULL, no operation is performed.
*
+ * Context:
* May sleep if called *not* from interrupt context.
- *
- * NOTE: assumes that the object at @addr has a size >= sizeof(llist_node)
+ * Must not be called in NMI context (strictly speaking, it could be
+ * if we have CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG, but making the calling
+ * conventions for vfree() arch-depenedent would be a really bad idea).
*/
void vfree(const void *addr)
{
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
allows to fill put the phys_addr values directly instead of doing
another loop over all addresses.
Signed-off-by: Christoph Hellwig
---
drivers/xen/xenbus/xenbus_client.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index 2690318ad50f48..fd80e318b99cc7 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -73,16 +73,13 @@ struct map_ring_valloc {
struct xenbus_map_node *node;
/* Why do we need two arrays? See comment of __xenbus_map_ring */
- union {
- unsigned long addrs[XENBUS_MAX_RING_GRANTS];
- pte_t *ptes[XENBUS_MAX_RING_GRANTS];
- };
+ unsigned long addrs[XENBUS_MAX_RING_GRANTS];
phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
struct gnttab_map_grant_ref map[XENBUS_MAX_RING_GRANTS];
struct gnttab_unmap_grant_ref unmap[XENBUS_MAX_RING_GRANTS];
- unsigned int idx; /* HVM only. */
+ unsigned int idx;
};
static DEFINE_SPINLOCK(xenbus_valloc_lock);
@@ -686,6 +683,14 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev,
void *vaddr)
EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
#ifdef CONFIG_XEN_PV
+static int map_ring_apply(pte_t *pte, unsigned long addr, void *data)
+{
+ struct map_ring_valloc *info = data;
+
+ info->phys_addrs[info->idx++] = arbitrary_virt_to_machine(pte).maddr;
+ return 0;
+}
+
static int xenbus_map_ring_pv(struct xenbus_device *dev,
struct map_ring_valloc *info,
grant_ref_t *gnt_refs,
@@ -694,18 +699,15 @@ static int xenbus_map_ring_pv(struct xenbus_device *dev,
{
struct xenbus_map_node *node = info->node;
struct vm_struct *area;
- int err = GNTST_okay;
- int i;
- bool leaked;
+ bool leaked = false;
+ int err = -ENOMEM;
- area = alloc_vm_area(XEN_PAGE_SIZE * nr_grefs, info->ptes);
+ area = get_vm_area(XEN_PAGE_SIZE * nr_grefs, VM_IOREMAP);
if (!area)
return -ENOMEM;
-
- for (i = 0; i < nr_grefs; i++)
- info->phys_addrs[i] =
- arbitrary_virt_to_machine(info->ptes[i]).maddr;
-
+ if (apply_to_page_range(_mm, (unsigned long)area->addr,
+ XEN_PAGE_SIZE * nr_grefs, map_ring_apply, info))
+ goto failed;
err = __xenbus_map_ring(dev, gnt_refs, nr_grefs, node->handles,
info, GNTMAP_host_map | GNTMAP_contains_pte,
);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/11] mm: add a vmap_pfn function
Add a proper helper to remap PFNs into kernel virtual space so that
drivers don't have to abuse alloc_vm_area and open coded PTE
manipulation for it.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 1 +
mm/Kconfig | 3 +++
mm/vmalloc.c| 45 +
3 files changed, 49 insertions(+)
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index b899681e3ff9f0..c77efeac242514 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -122,6 +122,7 @@ extern void vfree_atomic(const void *addr);
extern void *vmap(struct page **pages, unsigned int count,
unsigned long flags, pgprot_t prot);
+void *vmap_pfn(unsigned long *pfns, unsigned int count, pgprot_t prot);
extern void vunmap(const void *addr);
extern int remap_vmalloc_range_partial(struct vm_area_struct *vma,
diff --git a/mm/Kconfig b/mm/Kconfig
index 6c974888f86f97..6fa7ba1199eb1e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -815,6 +815,9 @@ config DEVICE_PRIVATE
memory; i.e., memory that is only accessible from the device (or
group of devices). You likely also want to select HMM_MIRROR.
+config VMAP_PFN
+ bool
+
config FRAME_VECTOR
bool
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ffad65f052c3f9..e2a2ded8d93478 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2413,6 +2413,51 @@ void *vmap(struct page **pages, unsigned int count,
}
EXPORT_SYMBOL(vmap);
+#ifdef CONFIG_VMAP_PFN
+struct vmap_pfn_data {
+ unsigned long *pfns;
+ pgprot_tprot;
+ unsigned intidx;
+};
+
+static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
+{
+ struct vmap_pfn_data *data = private;
+
+ if (WARN_ON_ONCE(pfn_valid(data->pfns[data->idx])))
+ return -EINVAL;
+ *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot));
+ return 0;
+}
+
+/**
+ * vmap_pfn - map an array of PFNs into virtually contiguous space
+ * @pfns: array of PFNs
+ * @count: number of pages to map
+ * @prot: page protection for the mapping
+ *
+ * Maps @count PFNs from @pfns into contiguous kernel virtual space and returns
+ * the start address of the mapping.
+ */
+void *vmap_pfn(unsigned long *pfns, unsigned int count, pgprot_t prot)
+{
+ struct vmap_pfn_data data = { .pfns = pfns, .prot = pgprot_nx(prot) };
+ struct vm_struct *area;
+
+ area = get_vm_area_caller(count * PAGE_SIZE, VM_IOREMAP,
+ __builtin_return_address(0));
+ if (!area)
+ return NULL;
+ if (apply_to_page_range(_mm, (unsigned long)area->addr,
+ count * PAGE_SIZE, vmap_pfn_apply, )) {
+ free_vm_area(area);
+ return NULL;
+ }
+ return area->addr;
+}
+EXPORT_SYMBOL_GPL(vmap_pfn);
+#endif /* CONFIG_VMAP_PFN */
+
static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
pgprot_t prot, int node)
{
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/11] drm/i915: use vmap in shmem_pin_map
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag if
actually required). Switch to use vmap, and use vfree to free both the
vmalloc mapping and the page array, as well as dropping the references
to each page.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++
1 file changed, 18 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79dea..f011ea42487e11 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -49,80 +49,40 @@ struct file *shmem_create_from_object(struct
drm_i915_gem_object *obj)
return file;
}
-static size_t shmem_npte(struct file *file)
-{
- return file->f_mapping->host->i_size >> PAGE_SHIFT;
-}
-
-static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
-{
- unsigned long pfn;
-
- vunmap(ptr);
-
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
-
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (!WARN_ON(IS_ERR(page))) {
- put_page(page);
- put_page(page);
- }
- }
-}
-
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
- struct vm_struct *area;
- unsigned long pfn;
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
+ struct page **pages;
+ size_t n_pages, i;
+ void *vaddr;
- area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
+ n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
return NULL;
- }
- ptes = mem;
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
-
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (IS_ERR(page))
+ for (i = 0; i < n_pages; i++) {
+ pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
+ GFP_KERNEL);
+ if (IS_ERR(pages[i]))
goto err_page;
-
- **ptes++ = mk_pte(page, PAGE_KERNEL);
}
- if (mem != stack)
- kvfree(mem);
-
+ vaddr = vmap(pages, n_pages, VM_MAP_PUT_PAGES, PAGE_KERNEL);
+ if (!vaddr)
+ goto err_page;
mapping_set_unevictable(file->f_mapping);
- return area->addr;
-
+ return vaddr;
err_page:
- if (mem != stack)
- kvfree(mem);
-
- __shmem_unpin_map(file, area->addr, pfn);
+ while (--i >= 0)
+ put_page(pages[i]);
+ kvfree(pages);
return NULL;
}
void shmem_unpin_map(struct file *file, void *ptr)
{
mapping_clear_unevictable(file->f_mapping);
- __shmem_unpin_map(file, ptr, shmem_npte(file));
+ vfree(ptr);
}
static int __shmem_rw(struct file *file, loff_t off,
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
Replace the last call to alloc_vm_area with an open coded version using
an iterator in struct gnttab_vm_area instead of the triple indirection
magic in alloc_vm_area.
Signed-off-by: Christoph Hellwig
---
arch/x86/xen/grant-table.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 4988e19598c8a5..1e681bf62561a0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -25,6 +25,7 @@
static struct gnttab_vm_area {
struct vm_struct *area;
pte_t **ptes;
+ int idx;
} gnttab_shared_vm_area, gnttab_status_vm_area;
int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
@@ -90,19 +91,31 @@ void arch_gnttab_unmap(void *shared, unsigned long
nr_gframes)
}
}
+static int gnttab_apply(pte_t *pte, unsigned long addr, void *data)
+{
+ struct gnttab_vm_area *area = data;
+
+ area->ptes[area->idx++] = pte;
+ return 0;
+}
+
static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned nr_frames)
{
area->ptes = kmalloc_array(nr_frames, sizeof(*area->ptes), GFP_KERNEL);
if (area->ptes == NULL)
return -ENOMEM;
-
- area->area = alloc_vm_area(PAGE_SIZE * nr_frames, area->ptes);
- if (area->area == NULL) {
- kfree(area->ptes);
- return -ENOMEM;
- }
-
+ area->area = get_vm_area(PAGE_SIZE * nr_frames, VM_IOREMAP);
+ if (!area->area)
+ goto out_free_ptes;
+ if (apply_to_page_range(_mm, (unsigned long)area->area->addr,
+ PAGE_SIZE * nr_frames, gnttab_apply, area))
+ goto out_free_vm_area;
return 0;
+out_free_vm_area:
+ free_vm_area(area->area);
+out_free_ptes:
+ kfree(area->ptes);
+ return -ENOMEM;
}
static void arch_gnttab_vfree(struct gnttab_vm_area *area)
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Thu, Sep 24, 2020 at 09:51:38AM -0400, Steven Rostedt wrote: > > It turns out, that getting selected for pull-balance is exactly that > > condition, and clearly a migrate_disable() task cannot be pulled, but we > > can use that signal to try and pull away the running task that's in the > > way. > > Unless of course that running task is in a migrate disable section > itself ;-) See my ramblings here: https://lkml.kernel.org/r/20200924082717.ga1362...@hirez.programming.kicks-ass.net My plan was to have the migrate_enable() of the running task trigger the migration in that case. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/11] zsmalloc: switch from alloc_vm_area to get_vm_area
Just manually pre-fault the PTEs using apply_to_page_range. Co-developed-by: Minchan Kim Signed-off-by: Christoph Hellwig --- mm/zsmalloc.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index c36fdff9a37131..918c7b019b3d78 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1122,10 +1122,16 @@ static inline int __zs_cpu_up(struct mapping_area *area) */ if (area->vm) return 0; - area->vm = alloc_vm_area(PAGE_SIZE * 2, NULL); + area->vm = get_vm_area(PAGE_SIZE * 2, 0); if (!area->vm) return -ENOMEM; - return 0; + + /* +* Populate ptes in advance to avoid pte allocation with GFP_KERNEL +* in non-preemtible context of zs_map_object. +*/ + return apply_to_page_range(_mm, (unsigned long)area->vm->addr, + PAGE_SIZE * 2, NULL, NULL); } static inline void __zs_cpu_down(struct mapping_area *area) -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] mm: remove alloc_vm_area
All users are gone now.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 5 +
mm/nommu.c | 7 --
mm/vmalloc.c| 48 -
3 files changed, 1 insertion(+), 59 deletions(-)
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index c77efeac242514..938eaf9517e266 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -169,6 +169,7 @@ extern struct vm_struct *__get_vm_area_caller(unsigned long
size,
unsigned long flags,
unsigned long start, unsigned long end,
const void *caller);
+void free_vm_area(struct vm_struct *area);
extern struct vm_struct *remove_vm_area(const void *addr);
extern struct vm_struct *find_vm_area(const void *addr);
@@ -204,10 +205,6 @@ static inline void set_vm_flush_reset_perms(void *addr)
}
#endif
-/* Allocate/destroy a 'vmalloc' VM area. */
-extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes);
-extern void free_vm_area(struct vm_struct *area);
-
/* for /dev/kmem */
extern long vread(char *buf, char *addr, unsigned long count);
extern long vwrite(char *buf, char *addr, unsigned long count);
diff --git a/mm/nommu.c b/mm/nommu.c
index 75a327149af127..9272f30e4c4726 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -354,13 +354,6 @@ void vm_unmap_aliases(void)
}
EXPORT_SYMBOL_GPL(vm_unmap_aliases);
-struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes)
-{
- BUG();
- return NULL;
-}
-EXPORT_SYMBOL_GPL(alloc_vm_area);
-
void free_vm_area(struct vm_struct *area)
{
BUG();
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index e2a2ded8d93478..3bc5b832451ef2 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3083,54 +3083,6 @@ int remap_vmalloc_range(struct vm_area_struct *vma, void
*addr,
}
EXPORT_SYMBOL(remap_vmalloc_range);
-static int f(pte_t *pte, unsigned long addr, void *data)
-{
- pte_t ***p = data;
-
- if (p) {
- *(*p) = pte;
- (*p)++;
- }
- return 0;
-}
-
-/**
- * alloc_vm_area - allocate a range of kernel address space
- * @size: size of the area
- * @ptes: returns the PTEs for the address space
- *
- * Returns:NULL on failure, vm_struct on success
- *
- * This function reserves a range of kernel address space, and
- * allocates pagetables to map that range. No actual mappings
- * are created.
- *
- * If @ptes is non-NULL, pointers to the PTEs (in init_mm)
- * allocated for the VM area are returned.
- */
-struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes)
-{
- struct vm_struct *area;
-
- area = get_vm_area_caller(size, VM_IOREMAP,
- __builtin_return_address(0));
- if (area == NULL)
- return NULL;
-
- /*
-* This ensures that page tables are constructed for this region
-* of kernel virtual address space and mapped into init_mm.
-*/
- if (apply_to_page_range(_mm, (unsigned long)area->addr,
- size, f, ptes ? : NULL)) {
- free_vm_area(area);
- return NULL;
- }
-
- return area;
-}
-EXPORT_SYMBOL_GPL(alloc_vm_area);
-
void free_vm_area(struct vm_struct *area)
{
struct vm_struct *ret;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/11] mm: allow a NULL fn callback in apply_to_page_range
Besides calling the callback on each page, apply_to_page_range also has
the effect of pre-faulting all PTEs for the range. To support callers
that only need the pre-faulting, make the callback optional.
Based on a patch from Minchan Kim .
Signed-off-by: Christoph Hellwig
---
mm/memory.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 469af373ae76e1..a60136046d7fcc 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2231,13 +2231,15 @@ static int apply_to_pte_range(struct mm_struct *mm,
pmd_t *pmd,
arch_enter_lazy_mmu_mode();
- do {
- if (create || !pte_none(*pte)) {
- err = fn(pte++, addr, data);
- if (err)
- break;
- }
- } while (addr += PAGE_SIZE, addr != end);
+ if (fn) {
+ do {
+ if (create || !pte_none(*pte)) {
+ err = fn(pte++, addr, data);
+ if (err)
+ break;
+ }
+ } while (addr += PAGE_SIZE, addr != end);
+ }
*mask |= PGTBL_PTE_MODIFIED;
arch_leave_lazy_mmu_mode();
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map
kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index d6eeefab3d018b..6550c0bc824ea2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -162,8 +162,6 @@ static void unmap_object(struct drm_i915_gem_object *obj,
void *ptr)
{
if (is_vmalloc_addr(ptr))
vunmap(ptr);
- else
- kunmap(kmap_to_page(ptr));
}
struct sg_table *
@@ -277,11 +275,10 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
* forever.
*
* So if the page is beyond the 32b boundary, make an explicit
-* vmap. On 64b, this check will be optimised away as we can
-* directly kmap any page on the system.
+* vmap.
*/
if (!PageHighMem(page))
- return kmap(page);
+ return page_address(page);
}
mem = stack;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Thu, 24 Sep 2020 14:42:41 +0200 Peter Zijlstra wrote: > On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote: > > Anyway, instead of blocking. What about having a counter of number of > > migrate disabled tasks per cpu, and when taking a migrate_disable(), and > > there's > > already another task with migrate_disabled() set, and the current task has > > an affinity greater than 1, it tries to migrate to another CPU? > > That doesn't solve the problem. On wakeup we should already prefer an > idle CPU over one running a (RT) task, but you can always wake more > tasks than there's CPUs around and you'll _have_ to stack at some point. Yes, understood. > > The trick is how to unstack them correctly. We need to detect when a > migrate_disable() task _should_ start running again, and migrate away > whoever is in the way at that point. > > It turns out, that getting selected for pull-balance is exactly that > condition, and clearly a migrate_disable() task cannot be pulled, but we > can use that signal to try and pull away the running task that's in the > way. Unless of course that running task is in a migrate disable section itself ;-) But I guess we will always have that SHC, and there will always be a scenario that you can't balance properly. But hopefully in practice we wont see that. How to handle kmap_local(), will migrate_disable() be used only for 32bit or, for consistency, will it also apply to 64bit? -- Steve ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Always send a pulse down the engine after disabling heartbeat
On 16/09/2020 10:42, Chris Wilson wrote:
Currently, we check we can send a pulse prior to disabling the
heartbeat to verify that we can change the heartbeat, but since we may
re-evaluate execution upon changing the heartbeat interval we need another
pulse afterwards to refresh execution.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: # v5.7+
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 8ffdf676c0a0..d09df370f7cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -192,10 +192,12 @@ int intel_engine_set_heartbeat(struct intel_engine_cs
*engine,
WRITE_ONCE(engine->props.heartbeat_interval_ms, delay);
if (intel_engine_pm_get_if_awake(engine)) {
- if (delay)
+ if (delay) {
intel_engine_unpark_heartbeat(engine);
- else
+ } else {
intel_engine_park_heartbeat(engine);
+ intel_engine_pulse(engine); /* recheck execution */
+ }
intel_engine_pm_put(engine);
}
I did not immediately get this one. Do we really need two pulses or
maybe we could re-order the code a bit and just undo the heartbeat park
if pulse after parking did not work?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Cancel outstanding work after disabling heartbeats on an engine
On 16/09/2020 10:42, Chris Wilson wrote:
We only allow persistent requests to remain on the GPU past the closure
of their containing context (and process) so long as they are continuously
checked for hangs or allow other requests to preempt them, as we need to
ensure forward progress of the system. If we allow persistent contexts
to remain on the system after the the hangcheck mechanism is disabled,
the system may grind to a halt. On disabling the mechanism, we sent a
pulse along the engine to remove all executing contexts from the engine
which would check for hung contexts -- but we did not prevent those
contexts from being resubmitted if they survived the final hangcheck.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
Testcase: igt/gem_ctx_persistence/heartbeat-stop
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: # v5.7+
---
drivers/gpu/drm/i915/gt/intel_engine.h | 9 +
drivers/gpu/drm/i915/i915_request.c| 5 +
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 08e2c000dcc3..7c3a1012e702 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -337,4 +337,13 @@ intel_engine_has_preempt_reset(const struct
intel_engine_cs *engine)
return intel_engine_has_preemption(engine);
}
+static inline bool
+intel_engine_has_heartbeat(const struct intel_engine_cs *engine)
+{
+ if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
+ return false;
+
+ return READ_ONCE(engine->props.heartbeat_interval_ms);
+}
+
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 436ce368ddaa..0e813819b041 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -542,8 +542,13 @@ bool __i915_request_submit(struct i915_request *request)
if (i915_request_completed(request))
goto xfer;
+ if (unlikely(intel_context_is_closed(request->context) &&
+!intel_engine_has_heartbeat(engine)))
+ intel_context_set_banned(request->context);
+
if (unlikely(intel_context_is_banned(request->context)))
i915_request_set_error_once(request, -EIO);
+
if (unlikely(fatal_error(request->fence.error)))
__i915_request_skip(request);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/gem: Hold request reference for canceling an active context
On 16/09/2020 10:42, Chris Wilson wrote:
We have to be very careful while walking the timeline->requests list
under the RCU guard, as the requests (and so rq->link) use
SLAB_TYPESAFE_BY_RCU and so the requests may be reallocated within an
rcu grace period. As the requests are reallocated, they are removed from
one list and placed on another, and if we are iterating over that
request at that moment, the list iteration jumps from one list to the
next and promptly gets confused. Verify we hold the request reference
to ensure that the request is not added to a new list behind our backs.
<4> [582.745252] general protection fault, probably for non-canonical address
0xcd5c: [#1] PREEMPT SMP PTI
<4> [582.745297] CPU: 0 PID: 1475 Comm: gem_ctx_persist Not tainted
5.9.0-rc1-CI-CI_DRM_8908+ #1
<4> [582.745304] Hardware name: Intel Corporation NUC7CJYH/NUC7JYB, BIOS
JYGLKCPX.86A.0027.2018.0125.1347 01/25/2018
<4> [582.745317] RIP: 0010:__lock_acquire+0x2c3/0x1f40
<4> [582.745323] Code: 00 65 8b 05 c7 8a ef 7e 85 c0 0f 85 b4 07 00 00 44 8b 9d c4 08
00 00 45 85 db 0f 84 0f 01 00 00 ba 05 00 00 00 e9 c8 06 00 00 <48> 81 3f c0 89 c7 82
b8 00 00 00 00 41 0f 45 c0 83 fe 01 41 89 c3
<4> [582.745334] RSP: 0018:c9000461bc40 EFLAGS: 00010002
<4> [582.745340] RAX: RBX: 0001 RCX:
<4> [582.745345] RDX: RSI: RDI:
cd5c
<4> [582.745350] RBP: 8881ec4a2880 R08: 0001 R09:
0001
<4> [582.745356] R10: 0001 R11: 0001 R12:
<4> [582.745361] R13: R14: R15:
cd5c
<4> [582.745367] FS: 7fb44da78e40() GS:88827800()
knlGS:
<4> [582.745373] CS: 0010 DS: ES: CR0: 80050033
<4> [582.745378] CR2: 7fb44daad040 CR3: 000268428000 CR4:
00350ef0
<4> [582.745383] Call Trace:
<4> [582.745390] ? __lock_acquire+0x913/0x1f40
<4> [582.745397] lock_acquire+0xb5/0x3c0
<4> [582.745526] ? kill_engines+0x19a/0x4b0 [i915]
<4> [582.745533] ? find_held_lock+0x2d/0x90
<4> [582.745541] _raw_spin_lock_irq+0x30/0x40
<4> [582.745635] ? kill_engines+0x19a/0x4b0 [i915]
<4> [582.745727] kill_engines+0x19a/0x4b0 [i915]
<4> [582.745820] context_close+0x195/0x410 [i915]
<4> [582.745912] i915_gem_context_close+0x5b/0x160 [i915]
<4> [582.745994] i915_driver_postclose+0x14/0x40 [i915]
<4> [582.746003] drm_file_free.part.13+0x240/0x290
<4> [582.746009] drm_release_noglobal+0x16/0x50
<4> [582.746016] __fput+0xa5/0x250
<4> [582.746021] task_work_run+0x6e/0xb0
<4> [582.746028] exit_to_user_mode_prepare+0x178/0x180
<4> [582.746034] syscall_exit_to_user_mode+0x36/0x220
<4> [582.746040] entry_SYSCALL_64_after_hwframe+0x44/0xa9
<4> [582.746045] RIP: 0033:0x7fb44d1dc421
<4> [582.746050] Code: f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00
00 00 66 90 8b 05 ea cf 20 00 85 c0 75 16 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77
3f f3 c3 0f 1f 44 00 00 53 89 fb 48 83 ec 10
<4> [582.746062] RSP: 002b:7ffed2e83818 EFLAGS: 0246 ORIG_RAX:
0003
<4> [582.746069] RAX: RBX: 556410bfe840 RCX:
7fb44d1dc421
<4> [582.746075] RDX: 000a RSI: c0406469 RDI:
0008
<4> [582.746080] RBP: 0008 R08: 7fb44d1c51cc R09:
7fb44d1c5240
<4> [582.746086] R10: 0001 R11: 0246 R12:
fffb
<4> [582.746091] R13: 0006 R14: R15:
000a
<4> [582.746099] Modules linked in: vgem mei_hdcp snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio btusb btrtl btbcm btintel
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul bluetooth
ghash_clmulni_intel ecdh_generic ecc i915 r8169 realtek mei_me mei snd_hda_intel
i2c_hid snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm
pinctrl_geminilake pinctrl_intel prime_numbers [last unloaded: test_drm_mm]
Fixes: 09a3054f38db ("drm/i915/gem: Reduce context termination list iteration guard
to RCU")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 -
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index cf5ecbde9e06..a548626fa8bc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -460,8 +460,8 @@ __active_engine(struct i915_request *rq, struct
intel_engine_cs **active)
spin_lock(>active.lock);
}
- if (!i915_request_completed(rq)) {
- if (i915_request_is_active(rq) && rq->fence.error != -EIO)
+ if (i915_request_is_active(rq)) {
+ if (!i915_request_completed(rq))
*active = locked;
ret = true;
}
@@ -479,13 +479,26 @@
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display: Program PSR2 selective fetch registers
On Wed, 2020-09-23 at 10:09 -0700, Souza, Jose wrote:
> On Wed, 2020-09-23 at 10:10 -0700, José Roberto de Souza wrote:
> > On Wed, 2020-09-23 at 14:02 +0100, Mun, Gwan-gyeong wrote:
> > > On Thu, 2020-09-17 at 18:02 -0700, José Roberto de Souza wrote:
> > > > Another step towards PSR2 selective fetch, here programming
> > > > plane
> > > > selective fetch registers and MAN_TRK_CTL enabling selective
> > > > fetch
> > > > but
> > > > for now it is fetching the whole area of the planes.
> > > > The damaged area calculation will come as next and final step.
> > > >
> > > > v2:
> > > > - removed warn on when no plane is visible in state
> > > > - removed calculations using plane damaged area in
> > > > intel_psr2_program_plane_sel_fetch()
> > > >
> > > > v3:
> > > > - do not shift 16 positions the plane dst coordinates, only src
> > > > is
> > > > shifted
> > > >
> > > > BSpec: 55229
> > > > Cc: Gwan-gyeong Mun <
> > > > gwan-gyeong@intel.com
> > > >
> > > >
> > > > Cc: Ville Syrjälä <
> > > > ville.syrj...@linux.intel.com
> > > >
> > > >
> > > > Signed-off-by: José Roberto de Souza <
> > > > jose.so...@intel.com
> > > >
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 10 +-
> > > > drivers/gpu/drm/i915/display/intel_psr.c | 120
> > > > ++-
> > > > drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
> > > > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
> > > > 4 files changed, 134 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index 5a9d933e425a..96bc515497c1 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -11812,6 +11812,9 @@ static void i9xx_update_cursor(struct
> > > > intel_plane *plane,
> > > > if (INTEL_GEN(dev_priv) >= 9)
> > > > skl_write_cursor_wm(plane, crtc_state);
> > > >
> > > > + if (!needs_modeset(crtc_state))
> > > > + intel_psr2_program_plane_sel_fetch(plane,
> > > > crtc_state,
> > > > plane_state, 0);
> > > > +
> > > > if (plane->cursor.base != base ||
> > > > plane->cursor.size != fbc_ctl ||
> > > > plane->cursor.cntl != cntl) {
> > > > @@ -12823,8 +12826,11 @@ static int
> > > > intel_crtc_atomic_check(struct
> > > > intel_atomic_state *state,
> > > >
> > > > }
> > > >
> > > > - if (!mode_changed)
> > > > - intel_psr2_sel_fetch_update(state, crtc);
> > > > + if (!mode_changed) {
> > > > + ret = intel_psr2_sel_fetch_update(state, crtc);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > >
> > > > return 0;
> > > > }
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > index 02f74b0ddec1..deb0523f9f29 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > @@ -1166,6 +1166,41 @@ static void
> > > > psr_force_hw_tracking_exit(struct
> > > > drm_i915_private *dev_priv)
> > > > intel_psr_exit(dev_priv);
> > > > }
> > > >
> > > > +void intel_psr2_program_plane_sel_fetch(struct intel_plane
> > > > *plane,
> > > > + const struct
> > > > intel_crtc_state
> > > > *crtc_state,
> > > > + const struct
> > > > intel_plane_state
> > > > *plane_state,
> > > > + int color_plane)
> > > > +{
> > > > + struct drm_i915_private *dev_priv = to_i915(plane-
> > > > >base.dev);
> > > > + enum pipe pipe = plane->pipe;
> > > > + u32 val;
> > > > +
> > > > + if (!crtc_state->enable_psr2_sel_fetch)
> > > > + return;
> > > > +
> > > > + /*
> > > > +* skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0
> > > > for
> > > > gen11+, so
> > > > +* plane_state->ctl is the right value
> > > > +*/
> > > > + val = plane_state ? plane_state->ctl : 0;
> > >
> > > IMHO, skl_plane_ctl() might set other ctl bits, it would be
> > > better to
> > > have separated ctl bit value for "selective fetch ctl".
> >
> > Like said all other bits are spares so can be set without issues
> > but okay will a "plane_state->ctl & PLANE_SEL_FETCH_CTL_ENABLE".
>
> Please take a look to the answer of your other comment bellow, with
> the change above can I have your rv-b?
The purpose and composition of bits of Register_SEL_FETCH_PLANE_CTL is
different from Register_PLANE_CTL.
And the Spares bits of Register_SEL_FETCH_PLANE_CTL might be used for
other purpose.
(And we current don't know the side effect of setting of Spares bit of
Register_SEL_FETCH_PLANE_CTL )
therefor I recommend "Read and Modify" to SEL_FETCH_PLANE_CTL.
>
> > > > +
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On Thu, Sep 24, 2020 at 01:22:35PM +0100, Tvrtko Ursulin wrote: > CI says series looks good from the i915 perspective (*). > > I don't know how will you handle it logistically, but when you have final > version I am happy to re-read and r-b the i915 patches. I'll resend the series later today, and will make sure you are on the Cc list. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Redo "Remove i915_request.lock requirement for execution callbacks"
On 15/09/2020 10:30, Chris Wilson wrote:
The reordering and rebasing of commit 2e4c6c1a9db5 ("drm/i915: Remove
i915_request.lock requirement for execution callbacks") caused it to
revert an earlier correction. Let us restore commit 99f0a640d464
("drm/i915: Remove requirement for holding i915_request.lock for
breadcrumbs")
Fixes: 2e4c6c1a9db5 ("drm/i915: Remove i915_request.lock requirement for execution
callbacks")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Rodrigo Vivi
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_request.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 11e272422fb7..436ce368ddaa 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -593,16 +593,8 @@ bool __i915_request_submit(struct i915_request *request)
__notify_execute_cb_irq(request);
/* We may be recursing from the signal callback of another i915 fence */
- if (!i915_request_signaled(request)) {
- spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
-
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
->fence.flags) &&
- !i915_request_enable_breadcrumb(request))
- intel_engine_signal_breadcrumbs(engine);
-
- spin_unlock(>lock);
- }
+ if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
+ i915_request_enable_breadcrumb(request);
return result;
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V14 2/5] i915/dsi: Configure TE interrupt for cmd mode
Configure TE interrupt as part of the vblank
enable call flow.
v2: Hide the private flags check inside configure_te (Jani)
v3: Fix the position of masking de_port_masked for DSI_TE.
v4: Simplify the caller of configure_te (Jani)
v5: Clear IIR, remove the usage of private_flags
v6: including icl_dsi header is not needed
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 50 +++--
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 759f523c6a6b..913548addfba 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2631,12 +2631,47 @@ int ilk_enable_vblank(struct drm_crtc *crtc)
return 0;
}
+static bool gen11_dsi_configure_te(struct intel_crtc *intel_crtc,
+ bool enable)
+{
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+ enum port port;
+ u32 tmp;
+
+ if (!(intel_crtc->mode_flags &
+ (I915_MODE_FLAG_DSI_USE_TE1 | I915_MODE_FLAG_DSI_USE_TE0)))
+ return false;
+
+ /* for dual link cases we consider TE from slave */
+ if (intel_crtc->mode_flags & I915_MODE_FLAG_DSI_USE_TE1)
+ port = PORT_B;
+ else
+ port = PORT_A;
+
+ tmp = I915_READ(DSI_INTR_MASK_REG(port));
+ if (enable)
+ tmp &= ~DSI_TE_EVENT;
+ else
+ tmp |= DSI_TE_EVENT;
+
+ I915_WRITE(DSI_INTR_MASK_REG(port), tmp);
+
+ tmp = I915_READ(DSI_INTR_IDENT_REG(port));
+ I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
+
+ return true;
+}
+
int bdw_enable_vblank(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
unsigned long irqflags;
+ if (gen11_dsi_configure_te(intel_crtc, true))
+ return 0;
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
@@ -2702,9 +2737,13 @@ void ilk_disable_vblank(struct drm_crtc *crtc)
void bdw_disable_vblank(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
unsigned long irqflags;
+ if (gen11_dsi_configure_te(intel_crtc, false))
+ return;
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
@@ -3400,6 +3439,13 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
if (IS_GEN9_LP(dev_priv))
de_port_masked |= BXT_DE_PORT_GMBUS;
+ if (INTEL_GEN(dev_priv) >= 11) {
+ enum port port;
+
+ if (intel_bios_is_dsi_present(dev_priv, ))
+ de_port_masked |= DSI0_TE | DSI1_TE;
+ }
+
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
GEN8_PIPE_FIFO_UNDERRUN;
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V14 4/5] drm/i915/dsi: Initiate frame request in cmd mode
In TE Gate mode or TE NO_GATE mode on every flip
we need to set the frame update request bit.
After this bit is set transcoder hardware will
automatically send the frame data to the panel
in case of TE NO_GATE mode, where it sends after
it receives the TE event in case of TE_GATE mode.
Once the frame data is sent to the panel, we see
the frame counter updating.
v2: Use intel_de_read/write
v3: remove the usage of private_flags
v4: Use icl_dsi in func names if non static,
fix code formatting issues. (Jani)
v5: Send frame update request at the beginning of
pipe_update_end, use crtc_state mode_flags (Ville)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 26 +
drivers/gpu/drm/i915/display/intel_dsi.h| 1 +
drivers/gpu/drm/i915/display/intel_sprite.c | 7 ++
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 2789020e20db..fe946a2e2082 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host *host,
return 0;
}
+void icl_dsi_frame_update(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 tmp, mode_flags;
+ enum port port;
+
+ mode_flags = crtc_state->mode_flags;
+
+ /*
+* case 1 also covers dual link
+* In case of dual link, frame update should be set on
+* DSI_0
+*/
+ if (mode_flags & I915_MODE_FLAG_DSI_USE_TE0)
+ port = PORT_A;
+ else if (mode_flags & I915_MODE_FLAG_DSI_USE_TE1)
+ port = PORT_B;
+ else
+ return;
+
+ tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
+ tmp |= DSI_FRAME_UPDATE_REQUEST;
+ intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp);
+}
+
static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h
b/drivers/gpu/drm/i915/display/intel_dsi.h
index 19f78a4022d3..625f2f1ae061 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi.h
+++ b/drivers/gpu/drm/i915/display/intel_dsi.h
@@ -167,6 +167,7 @@ static inline u16 intel_dsi_encoder_ports(struct
intel_encoder *encoder)
/* icl_dsi.c */
void icl_dsi_init(struct drm_i915_private *dev_priv);
+void icl_dsi_frame_update(struct intel_crtc_state *crtc_state);
/* intel_dsi.c */
int intel_dsi_bitrate(const struct intel_dsi *intel_dsi);
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 63040cb0d4e1..eaee29e0f535 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -47,6 +47,7 @@
#include "intel_frontbuffer.h"
#include "intel_pm.h"
#include "intel_psr.h"
+#include "intel_dsi.h"
#include "intel_sprite.h"
int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
@@ -202,6 +203,12 @@ void intel_pipe_update_end(struct intel_crtc_state
*new_crtc_state)
trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
+ /*
+* Incase of mipi dsi command mode, we need to set frame update
+* request for every commit.
+*/
+ icl_dsi_frame_update(new_crtc_state);
+
/* We're still in the vblank-evade critical section, this can't race.
* Would be slightly nice to just grab the vblank count and arm the
* event outside of the critical section - the spinlock might spin for a
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V14 1/5] drm/i915/dsi: Add details about TE in get_config
We need details about enabling TE on which port
before we enable TE through vblank enable path.
This is based on the configuration that we receive
from the VBT wrt ports, dual_link.
Signed-off-by: Vandita Kulkarni
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 30 +++---
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 520715b7d5b5..2789020e20db 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1447,6 +1447,18 @@ static bool gen11_dsi_is_periodic_cmd_mode(struct
intel_dsi *intel_dsi)
return (val & DSI_PERIODIC_FRAME_UPDATE_ENABLE);
}
+static void gen11_dsi_get_cmd_mode_config(struct intel_dsi *intel_dsi,
+ struct intel_crtc_state *pipe_config)
+{
+ if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
+ pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE1 |
+ I915_MODE_FLAG_DSI_USE_TE0;
+ else if (intel_dsi->ports == BIT(PORT_B))
+ pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE1;
+ else
+ pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE0;
+}
+
static void gen11_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
@@ -1468,6 +1480,10 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
pipe_config->pipe_bpp = bdw_get_pipemisc_bpp(crtc);
+ /* Get the details on which TE should be enabled */
+ if (is_cmd_mode(intel_dsi))
+ gen11_dsi_get_cmd_mode_config(intel_dsi, pipe_config);
+
if (gen11_dsi_is_periodic_cmd_mode(intel_dsi))
pipe_config->mode_flags |= I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
}
@@ -1562,18 +1578,8 @@ static int gen11_dsi_compute_config(struct intel_encoder
*encoder,
* receive TE from the slave if
* dual link is enabled
*/
- if (is_cmd_mode(intel_dsi)) {
- if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
- pipe_config->mode_flags |=
- I915_MODE_FLAG_DSI_USE_TE1 |
- I915_MODE_FLAG_DSI_USE_TE0;
- else if (intel_dsi->ports == BIT(PORT_B))
- pipe_config->mode_flags |=
- I915_MODE_FLAG_DSI_USE_TE1;
- else
- pipe_config->mode_flags |=
- I915_MODE_FLAG_DSI_USE_TE0;
- }
+ if (is_cmd_mode(intel_dsi))
+ gen11_dsi_get_cmd_mode_config(intel_dsi, pipe_config);
return 0;
}
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V14 0/5] Add support for mipi dsi cmd mode
This series contain interrupt handling part of cmd mode. Configuration patches were merged already. Vandita Kulkarni (5): drm/i915/dsi: Add details about TE in get_config i915/dsi: Configure TE interrupt for cmd mode drm/i915/dsi: Add TE handler for dsi cmd mode. drm/i915/dsi: Initiate frame request in cmd mode drm/i915/dsi: Enable software vblank counter drivers/gpu/drm/i915/display/icl_dsi.c | 56 +++-- drivers/gpu/drm/i915/display/intel_display.c | 11 ++ drivers/gpu/drm/i915/display/intel_dsi.h | 1 + drivers/gpu/drm/i915/display/intel_sprite.c | 7 ++ drivers/gpu/drm/i915/i915_irq.c | 119 ++- 5 files changed, 180 insertions(+), 14 deletions(-) -- 2.21.0.5.gaeb582a ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V14 3/5] drm/i915/dsi: Add TE handler for dsi cmd mode.
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.
If we are operating in TE_GATE mode, after we do
a frame update, the transcoder will send the frame data
to the panel, after it receives a TE. Whereas if we
are operating in NO_GATE mode then the transcoder will
immediately send the frame data to the panel.
We are not dealing with the periodic command mode here.
v2: Pass only relevant masked bits to the handler (Jani)
v3: Fix the check for cmd mode in TE handler function.
v4: Use intel_handle_vblank instead of drm_handle_vblank (Jani)
v3: Use static on handler func (Jani)
Signed-off-by: Vandita Kulkarni
Reported-by: kernel test robot
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_irq.c | 65 +
1 file changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 913548addfba..c2e4b227bdf3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2237,6 +2237,63 @@ gen8_de_misc_irq_handler(struct drm_i915_private
*dev_priv, u32 iir)
drm_err(_priv->drm, "Unexpected DE Misc interrupt\n");
}
+static void gen11_dsi_te_interrupt_handler(struct drm_i915_private *dev_priv,
+ u32 te_trigger)
+{
+ enum pipe pipe = INVALID_PIPE;
+ enum transcoder dsi_trans;
+ enum port port;
+ u32 val, tmp;
+
+ /*
+* Incase of dual link, TE comes from DSI_1
+* this is to check if dual link is enabled
+*/
+ val = I915_READ(TRANS_DDI_FUNC_CTL2(TRANSCODER_DSI_0));
+ val &= PORT_SYNC_MODE_ENABLE;
+
+ /*
+* if dual link is enabled, then read DSI_0
+* transcoder registers
+*/
+ port = ((te_trigger & DSI1_TE && val) || (te_trigger & DSI0_TE)) ?
+ PORT_A : PORT_B;
+ dsi_trans = (port == PORT_A) ? TRANSCODER_DSI_0 : TRANSCODER_DSI_1;
+
+ /* Check if DSI configured in command mode */
+ val = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
+ val = val & OP_MODE_MASK;
+
+ if (val != CMD_MODE_NO_GATE && val != CMD_MODE_TE_GATE) {
+ drm_err(_priv->drm, "DSI trancoder not configured in
command mode\n");
+ return;
+ }
+
+ /* Get PIPE for handling VBLANK event */
+ val = I915_READ(TRANS_DDI_FUNC_CTL(dsi_trans));
+ switch (val & TRANS_DDI_EDP_INPUT_MASK) {
+ case TRANS_DDI_EDP_INPUT_A_ON:
+ pipe = PIPE_A;
+ break;
+ case TRANS_DDI_EDP_INPUT_B_ONOFF:
+ pipe = PIPE_B;
+ break;
+ case TRANS_DDI_EDP_INPUT_C_ONOFF:
+ pipe = PIPE_C;
+ break;
+ default:
+ drm_err(_priv->drm, "Invalid PIPE\n");
+ return;
+ }
+
+ intel_handle_vblank(dev_priv, pipe);
+
+ /* clear TE in dsi IIR */
+ port = (te_trigger & DSI1_TE) ? PORT_B : PORT_A;
+ tmp = I915_READ(DSI_INTR_IDENT_REG(port));
+ I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
+}
+
static irqreturn_t
gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
{
@@ -2301,6 +2358,14 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
found = true;
}
+ if (INTEL_GEN(dev_priv) >= 11) {
+ tmp_mask = iir & (DSI0_TE | DSI1_TE);
+ if (tmp_mask) {
+
gen11_dsi_te_interrupt_handler(dev_priv, tmp_mask);
+ found = true;
+ }
+ }
+
if (!found)
drm_err(_priv->drm,
"Unexpected DE Port interrupt\n");
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V14 5/5] drm/i915/dsi: Enable software vblank counter
In case of DSI cmd mode, we get hw vblank counter
updated after the TE comes in, if we try to read
the hw vblank counter in te handler we wouldnt have
the udpated vblank counter yet.
This will lead to a state where we would send the
vblank event to the user space in the next te,
though the frame update would have completed in
the first TE duration itself.
Hence switch to using software timestamp based
vblank counter.
v2: Use mode_flags from crtc_state (Ville)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_display.c | 11 +++
drivers/gpu/drm/i915/i915_irq.c | 4
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..bb495947ccd5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1808,6 +1808,17 @@ enum pipe intel_crtc_pch_transcoder(struct intel_crtc
*crtc)
static u32 intel_crtc_max_vblank_count(const struct intel_crtc_state
*crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ u32 mode_flags = crtc->mode_flags;
+
+ /*
+* From Gen 11, In case of dsi cmd mode, frame counter wouldnt
+* have updated at the beginning of TE, if we want to use
+* the hw counter, then we would find it updated in only
+* the next TE, hence switching to sw counter.
+*/
+ if (mode_flags & (I915_MODE_FLAG_DSI_USE_TE0 |
I915_MODE_FLAG_DSI_USE_TE1))
+ return 0;
/*
* On i965gm the hardware frame counter reads
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c2e4b227bdf3..634c60befe7e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -682,8 +682,12 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+ struct drm_vblank_crtc *vblank =
_priv->drm.vblank[drm_crtc_index(crtc)];
enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ if (!vblank->max_vblank_count)
+ return 0;
+
return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
}
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote: > Anyway, instead of blocking. What about having a counter of number of > migrate disabled tasks per cpu, and when taking a migrate_disable(), and > there's > already another task with migrate_disabled() set, and the current task has > an affinity greater than 1, it tries to migrate to another CPU? That doesn't solve the problem. On wakeup we should already prefer an idle CPU over one running a (RT) task, but you can always wake more tasks than there's CPUs around and you'll _have_ to stack at some point. The trick is how to unstack them correctly. We need to detect when a migrate_disable() task _should_ start running again, and migrate away whoever is in the way at that point. It turns out, that getting selected for pull-balance is exactly that condition, and clearly a migrate_disable() task cannot be pulled, but we can use that signal to try and pull away the running task that's in the way. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Thu, 24 Sep 2020 08:57:52 +0200 Thomas Gleixner wrote: > > Now as for migration disabled nesting, at least now we would have > > groupings of this, and perhaps the theorists can handle that. I mean, > > how is this much different that having a bunch of tasks blocked on a > > mutex with the owner is pinned on a CPU? > > > > migrate_disable() is a BKL of pinning affinity. > > No. That's just wrong. preempt disable is a concurrency control, I think you totally misunderstood what I was saying. The above wasn't about comparing preempt_disable to migrate_disable. It was comparing migrate_disable to a chain of tasks blocked on mutexes where the top owner has preempt_disable set. You still have a bunch of tasks that can't move to other CPUs. > > If we only have local_lock() available (even on !RT), then it makes > > the blocking in groups. At least this way you could grep for all the > > different local_locks in the system and plug that into the algorithm > > for WCS, just like one would with a bunch of mutexes. > > You cannot do that on RT at all where migrate disable is substituting > preempt disable in spin and rw locks. The result would be the same as > with a !RT kernel just with horribly bad performance. Note, the spin and rwlocks already have a lock associated with them. Why would it be any different on RT? I wasn't suggesting adding another lock inside a spinlock. Why would I recommend THAT? I wasn't recommending blindly replacing migrate_disable() with local_lock(). I just meant expose local_lock() but not migrate_disable(). > > That means the stacking problem has to be solved anyway. > > So why on earth do you want to create yet another special duct tape case > for kamp_local() which proliferates inconsistency instead of aiming for > consistency accross all preemption models? The idea was to help with the scheduling issue. Anyway, instead of blocking. What about having a counter of number of migrate disabled tasks per cpu, and when taking a migrate_disable(), and there's already another task with migrate_disabled() set, and the current task has an affinity greater than 1, it tries to migrate to another CPU? This way migrate_disable() is less likely to have a bunch of tasks blocked on one CPU serialized by each task exiting the migrate_disable() section. Yes, there's more overhead, but it only happens if multiple tasks are in a migrate disable section on the same CPU. -- Steve ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Uninitialized variable in i915_gem_object_map_page()
The "i" iterator is never set to zero. This probably doesn't affect
testing because GCC sometimes initializes variables and also we have a
new pluggin to initialize stack variables to zero.
Fixes: 7edd32a9e614 ("drm/i915: use vmap in i915_gem_object_map")
Signed-off-by: Dan Carpenter
---
Hi Andrew, this should probably go through the -mm tree and get folded
into the original patch.
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 90029ea83aed..12bedabc1daa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -266,6 +266,7 @@ static void *i915_gem_object_map_page(struct
drm_i915_gem_object *obj,
return NULL;
}
+ i = 0;
for_each_sgt_page(page, iter, obj->mm.pages)
pages[i++] = page;
vaddr = vmap(pages, n_pages, 0, pgprot);
@@ -291,6 +292,7 @@ static void *i915_gem_object_map_pfn(struct
drm_i915_gem_object *obj)
return NULL;
}
+ i = 0;
for_each_sgt_daddr(addr, iter, obj->mm.pages)
pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On 23/09/2020 15:44, Christoph Hellwig wrote: On Wed, Sep 23, 2020 at 02:58:43PM +0100, Tvrtko Ursulin wrote: Series did not get a CI run from our side because of a different base so I don't know if you would like to have a run there? If so you would need to rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could even send a series to intel-gfx-try...@lists.freedesktop.org, suppressing cc, to check it out without sending a copy to the real mailing list. It doesn't seem like I can post to any freedesktop list, as I always get rejection messages. But I'll happily prepare a branch if one of you an feed it into your CI. That's fine, just ping me and I will forward it for testing, thanks! git://git.infradead.org/users/hch/misc.git i915-vmap-wip Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-vmap-wip note that this includes a new commit to clean up one of the recent commits in the code. CI says series looks good from the i915 perspective (*). I don't know how will you handle it logistically, but when you have final version I am happy to re-read and r-b the i915 patches. Regards, Tvrtko *) https://patchwork.freedesktop.org/series/82051/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [V13 4/5] drm/i915/dsi: Initiate fame request in cmd mode
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, September 23, 2020 4:03 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [V13 4/5] drm/i915/dsi: Initiate fame request in cmd mode
>
> On Wed, Sep 23, 2020 at 10:02:49AM +, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: Wednesday, September 23, 2020 3:30 PM
> > > To: Kulkarni, Vandita
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > >
> > > Subject: Re: [V13 4/5] drm/i915/dsi: Initiate fame request in cmd
> > > mode
> > >
> > > On Tue, Sep 22, 2020 at 07:14:25PM +0530, Vandita Kulkarni wrote:
> > > > In TE Gate mode or TE NO_GATE mode on every flip we need to set
> > > > the frame update request bit.
> > > > After this bit is set transcoder hardware will automatically send
> > > > the frame data to the panel in case of TE NO_GATE mode, where it
> > > > sends after it receives the TE event in case of TE_GATE mode.
> > > > Once the frame data is sent to the panel, we see the frame counter
> > > > updating.
> > > >
> > > > v2: Use intel_de_read/write
> > > >
> > > > v3: remove the usage of private_flags
> > > >
> > > > v4: Use icl_dsi in func names if non static,
> > > > fix code formatting issues. (Jani)
> > > >
> > > > Signed-off-by: Vandita Kulkarni
> > > > ---
> > > > drivers/gpu/drm/i915/display/icl_dsi.c | 26
>
> > > > drivers/gpu/drm/i915/display/intel_display.c | 10
> > > > drivers/gpu/drm/i915/display/intel_dsi.h | 1 +
> > > > 3 files changed, 37 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > index 2789020e20db..7d2abc7f6ba3 100644
> > > > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct
> > > > intel_dsi_host
> > > *host,
> > > > return 0;
> > > > }
> > > >
> > > > +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state) {
> > > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > + u32 tmp, flags;
> > > > + enum port port;
> > > > +
> > > > + flags = crtc->mode_flags;
> > > > +
> > > > + /*
> > > > +* case 1 also covers dual link
> > > > +* In case of dual link, frame update should be set on
> > > > +* DSI_0
> > > > +*/
> > > > + if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > > > + port = PORT_A;
> > > > + else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > > > + port = PORT_B;
> > > > + else
> > > > + return;
> > > > +
> > > > + tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > > > + tmp |= DSI_FRAME_UPDATE_REQUEST;
> > > > + intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > > > +
> > > > static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > > > *encoder) {
> > > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > diff
> > > > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index 5a9d933e425a..c4f331f2af45 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -15616,6 +15616,16 @@ static void
> > > > intel_atomic_commit_tail(struct
> > > intel_atomic_state *state)
> > > > intel_set_cdclk_post_plane_update(state);
> > > > }
> > > >
> > > > + /*
> > > > +* Incase of mipi dsi command mode, we need to set frame update
> > > > +* for every commit
> > > > +*/
> > > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> > > > + if (INTEL_GEN(dev_priv) >= 11 &&
> > > > + intel_crtc_has_type(new_crtc_state,
> > > > INTEL_OUTPUT_DSI))
> > > > + if (new_crtc_state->hw.active)
> > > > + icl_dsi_frame_update(new_crtc_state);
> > > > +
> > >
> > > Still the wrong place.
> > Should I be adding it at the end of pipe update? As we need TE to be
> enabled when we send frame update.
>
> If it needs te then it should probably enable te.
Thanks for pointing this out.
Just to make sure on my assumption of keeping TE enabled before sending frame
update,
I cross checked with the hw team and there seems to be no such rule.
Frame update request will be valid until the transcoder starts the frame.
Like you pointed out will add this to the beginning of pipe_update_end,
And send the next version.
Thanks,
Vandita
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Thu, Sep 24, 2020 at 01:13:17PM +0200, Daniel Vetter wrote:
> On Thu, Sep 24, 2020 at 1:01 PM Ville Syrjälä
> wrote:
> >
> > On Thu, Sep 24, 2020 at 01:10:56PM +0300, Pekka Paalanen wrote:
> > > On Thu, 24 Sep 2020 10:04:12 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen
> > > > wrote:
> > > > >
> > > > > On Wed, 23 Sep 2020 22:01:25 +0200
> > > > > Daniel Vetter wrote:
> > > > >
> > > > > > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > > > > > > > When doing an atomic modeset with ALLOW_MODESET drivers are
> > > > > > > > allowed to
> > > > > > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > > > > > reconfiguring global resources).
> > > > >
> > > > > ...
> > > > >
> > > > > > > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct
> > > > > > > > drm_atomic_state *state)
> > > > > > > > }
> > > > > > > > }
> > > > > > > >
> > > > > > > > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > > > > > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > > > > > +
> > > > > > > > + /*
> > > > > > > > + * For commits that allow modesets drivers can add other
> > > > > > > > CRTCs to the
> > > > > > > > + * atomic commit, e.g. when they need to reallocate
> > > > > > > > global resources.
> > > > > > > > + * This can cause spurious EBUSY, which robs compositors
> > > > > > > > of a very
> > > > > > > > + * effective sanity check for their drawing loop.
> > > > > > > > Therefor only allow
> > > > > > > > + * drivers to add unrelated CRTC states for modeset
> > > > > > > > commits.
> > > > > > > > + *
> > > > > > > > + * FIXME: Should add affected_crtc mask to the ATOMIC
> > > > > > > > IOCTL as an output
> > > > > > > > + * so compositors know what's going on.
> > > > > > > > + */
> > > > > > > > + if (affected_crtc != requested_crtc) {
> > > > > > > > + DRM_DEBUG_ATOMIC("driver added CRTC to commit:
> > > > > > > > requested 0x%x, affected 0x%0x\n",
> > > > > > > > + requested_crtc, affected_crtc);
> > > > > > > > + WARN(!state->allow_modeset, "adding CRTC not
> > > > > > > > allowed without modesets: requested 0x%x, affected 0x%0x\n",
> > > > > > > > + requested_crtc, affected_crtc);
> > > > > > > Previous patch had the warn on state->allow_modeset now is
> > > > > > > !state->allow_modeset. Is that correct?
> > > > > >
> > > > > > We need to fire a warning when allow_modeset is _not_ set. An
> > > > > > earlier
> > > > > > version got that wrong, and yes that would have caused a _ton_ of
> > > > > > warnings on any fairly new intel platform.
> > > > > >
> > > > > > > I haven't followed the entire thread on this matter, but I guess
> > > > > > > the idea
> > > > > > > is that somehow the kernel would pass to userspace a CRTC mask of
> > > > > > > affected_crtc (somehow, we don't know how atm) and with it,
> > > > > > > userspace
> > > > > > > can then issue a new commit (this commit blocking) with those?
> > > > > >
> > > > > > Either that, or just use that to track all the in-flight drm events.
> > > > > > Userspace will get events for all the crtc, not just the one it
> > > > > > asked
> > > > > > to update.
> > > > >
> > > > > Wait, does that happen already? Getting CRTC events for CRTCs
> > > > > userspace
> > > > > didn't include in the atomic commit?
> > > >
> > > > Yeah I'm pretty sure. With the affected_crtc mask you could update
> > > > your internal book-keeping to catch these, which should also prevent
> > > > all the spurious EBUSY. But I'm not entirely sure, I just read the
> > > > code, haven't tested.
> > >
> > > If that actually happens, how does userspace know whether the
> > > userdata argument with the event is valid or not?
> >
> > At some point I was worried about the kernel potentially sending spurious
> > events, but IIRC I managed to convince myself that it shouldn't happen.
> > I think I came to the conclusion the events were populated before the
> > core calls into the driver. But maybe I misanalyzed it, or something
> > has since broken?
>
> Hm right this shouldn't happen, I misread the code. So if userspace
> wants events for all affected crtc, it needs to add them explicitly to
> the atomic ioctl (just set an arbitrary property on each crtc to its
> current value or something like that).
Hmm. I thought we wouldn't even need the dummy prop. But looking at
the code we do in fact need it. The ioctl structure itself should
allow adding an object without any properties, but the code then
skips the get_crtc_state() and thus no event for that crtc. I guess
it's been like that forever so not much point in trying to change
that anymore.
--
Ville Syrjälä
Intel
___
Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Thu, Sep 24, 2020 at 1:01 PM Ville Syrjälä
wrote:
>
> On Thu, Sep 24, 2020 at 01:10:56PM +0300, Pekka Paalanen wrote:
> > On Thu, 24 Sep 2020 10:04:12 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > On Wed, 23 Sep 2020 22:01:25 +0200
> > > > Daniel Vetter wrote:
> > > >
> > > > > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > > > > > > When doing an atomic modeset with ALLOW_MODESET drivers are
> > > > > > > allowed to
> > > > > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > > > > reconfiguring global resources).
> > > >
> > > > ...
> > > >
> > > > > > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct
> > > > > > > drm_atomic_state *state)
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > > > > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > > > > +
> > > > > > > + /*
> > > > > > > + * For commits that allow modesets drivers can add other
> > > > > > > CRTCs to the
> > > > > > > + * atomic commit, e.g. when they need to reallocate global
> > > > > > > resources.
> > > > > > > + * This can cause spurious EBUSY, which robs compositors of
> > > > > > > a very
> > > > > > > + * effective sanity check for their drawing loop. Therefor
> > > > > > > only allow
> > > > > > > + * drivers to add unrelated CRTC states for modeset commits.
> > > > > > > + *
> > > > > > > + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL
> > > > > > > as an output
> > > > > > > + * so compositors know what's going on.
> > > > > > > + */
> > > > > > > + if (affected_crtc != requested_crtc) {
> > > > > > > + DRM_DEBUG_ATOMIC("driver added CRTC to commit:
> > > > > > > requested 0x%x, affected 0x%0x\n",
> > > > > > > + requested_crtc, affected_crtc);
> > > > > > > + WARN(!state->allow_modeset, "adding CRTC not
> > > > > > > allowed without modesets: requested 0x%x, affected 0x%0x\n",
> > > > > > > + requested_crtc, affected_crtc);
> > > > > > Previous patch had the warn on state->allow_modeset now is
> > > > > > !state->allow_modeset. Is that correct?
> > > > >
> > > > > We need to fire a warning when allow_modeset is _not_ set. An earlier
> > > > > version got that wrong, and yes that would have caused a _ton_ of
> > > > > warnings on any fairly new intel platform.
> > > > >
> > > > > > I haven't followed the entire thread on this matter, but I guess
> > > > > > the idea
> > > > > > is that somehow the kernel would pass to userspace a CRTC mask of
> > > > > > affected_crtc (somehow, we don't know how atm) and with it,
> > > > > > userspace
> > > > > > can then issue a new commit (this commit blocking) with those?
> > > > >
> > > > > Either that, or just use that to track all the in-flight drm events.
> > > > > Userspace will get events for all the crtc, not just the one it asked
> > > > > to update.
> > > >
> > > > Wait, does that happen already? Getting CRTC events for CRTCs userspace
> > > > didn't include in the atomic commit?
> > >
> > > Yeah I'm pretty sure. With the affected_crtc mask you could update
> > > your internal book-keeping to catch these, which should also prevent
> > > all the spurious EBUSY. But I'm not entirely sure, I just read the
> > > code, haven't tested.
> >
> > If that actually happens, how does userspace know whether the
> > userdata argument with the event is valid or not?
>
> At some point I was worried about the kernel potentially sending spurious
> events, but IIRC I managed to convince myself that it shouldn't happen.
> I think I came to the conclusion the events were populated before the
> core calls into the driver. But maybe I misanalyzed it, or something
> has since broken?
Hm right this shouldn't happen, I misread the code. So if userspace
wants events for all affected crtc, it needs to add them explicitly to
the atomic ioctl (just set an arbitrary property on each crtc to its
current value or something like that). That also means that the bug
Pekka posted shouldn't have been caused by this stuff here.
Note for code readers: There's a retry loop for ww-mutex backoff, but
we do completely clear all states, so crtc states shouldn't be able to
persist and then get events when userspace didn't ask for them.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Thu, Sep 24, 2020 at 01:10:56PM +0300, Pekka Paalanen wrote:
> On Thu, 24 Sep 2020 10:04:12 +0200
> Daniel Vetter wrote:
>
> > On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen wrote:
> > >
> > > On Wed, 23 Sep 2020 22:01:25 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad
> > > > wrote:
> > > > >
> > > > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed
> > > > > > to
> > > > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > > > reconfiguring global resources).
> > >
> > > ...
> > >
> > > > > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct
> > > > > > drm_atomic_state *state)
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > > > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > > > +
> > > > > > + /*
> > > > > > + * For commits that allow modesets drivers can add other
> > > > > > CRTCs to the
> > > > > > + * atomic commit, e.g. when they need to reallocate global
> > > > > > resources.
> > > > > > + * This can cause spurious EBUSY, which robs compositors of a
> > > > > > very
> > > > > > + * effective sanity check for their drawing loop. Therefor
> > > > > > only allow
> > > > > > + * drivers to add unrelated CRTC states for modeset commits.
> > > > > > + *
> > > > > > + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL
> > > > > > as an output
> > > > > > + * so compositors know what's going on.
> > > > > > + */
> > > > > > + if (affected_crtc != requested_crtc) {
> > > > > > + DRM_DEBUG_ATOMIC("driver added CRTC to commit:
> > > > > > requested 0x%x, affected 0x%0x\n",
> > > > > > + requested_crtc, affected_crtc);
> > > > > > + WARN(!state->allow_modeset, "adding CRTC not allowed
> > > > > > without modesets: requested 0x%x, affected 0x%0x\n",
> > > > > > + requested_crtc, affected_crtc);
> > > > > Previous patch had the warn on state->allow_modeset now is
> > > > > !state->allow_modeset. Is that correct?
> > > >
> > > > We need to fire a warning when allow_modeset is _not_ set. An earlier
> > > > version got that wrong, and yes that would have caused a _ton_ of
> > > > warnings on any fairly new intel platform.
> > > >
> > > > > I haven't followed the entire thread on this matter, but I guess the
> > > > > idea
> > > > > is that somehow the kernel would pass to userspace a CRTC mask of
> > > > > affected_crtc (somehow, we don't know how atm) and with it, userspace
> > > > > can then issue a new commit (this commit blocking) with those?
> > > >
> > > > Either that, or just use that to track all the in-flight drm events.
> > > > Userspace will get events for all the crtc, not just the one it asked
> > > > to update.
> > >
> > > Wait, does that happen already? Getting CRTC events for CRTCs userspace
> > > didn't include in the atomic commit?
> >
> > Yeah I'm pretty sure. With the affected_crtc mask you could update
> > your internal book-keeping to catch these, which should also prevent
> > all the spurious EBUSY. But I'm not entirely sure, I just read the
> > code, haven't tested.
>
> If that actually happens, how does userspace know whether the
> userdata argument with the event is valid or not?
At some point I was worried about the kernel potentially sending spurious
events, but IIRC I managed to convince myself that it shouldn't happen.
I think I came to the conclusion the events were populated before the
core calls into the driver. But maybe I misanalyzed it, or something
has since broken?
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/14] drm/i915: Sort SKL PCI IDs
On Thu, Sep 24, 2020 at 12:49:13AM +, Srivatsa, Anusha wrote: > > > > -Original Message- > > From: Intel-gfx On Behalf Of Ville > > Syrjala > > Sent: Thursday, July 16, 2020 10:21 AM > > To: intel-gfx@lists.freedesktop.org > > Subject: [Intel-gfx] [PATCH 08/14] drm/i915: Sort SKL PCI IDs > > > > From: Ville Syrjälä > > > > Sort the SKL PCI IDs numerically. Some order seems better than > > randomness. > > There are 2 patches - patch 2 and 3 in the series that are reclassifying some > PCI IDs and there is patch 4 that adds a missing ID. All of those with this > patch can be combined to a single patch OR patch 2, 3 and 4 can be squashed > as one solitary patch. The original patch from Alexei was a single patch. I split it up for a reason; easier to revert things if/when necessary, and it's also easier to review. If your commit message is of the form "do A and B" it's generally a good indication that it should be split into two patches. > > Anusha > > Cc: Alexei Podtelezhnikov > > Signed-off-by: Ville Syrjälä > > --- > > include/drm/i915_pciids.h | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > > 4870c3c9f9b2..5185ac789038 100644 > > --- a/include/drm/i915_pciids.h > > +++ b/include/drm/i915_pciids.h > > @@ -340,8 +340,8 @@ > > INTEL_SKL_ULT_GT1_IDS(info), \ > > INTEL_SKL_ULX_GT1_IDS(info), \ > > INTEL_VGA_DEVICE(0x1902, info), /* DT GT1 */ \ > > - INTEL_VGA_DEVICE(0x190B, info), /* Halo GT1 */ \ > > INTEL_VGA_DEVICE(0x190A, info), /* SRV GT1 */ \ > > + INTEL_VGA_DEVICE(0x190B, info), /* Halo GT1 */ \ > > INTEL_VGA_DEVICE(0x1917, info) /* DT GT1.5 */ > > > > #define INTEL_SKL_ULT_GT2_IDS(info) \ > > @@ -355,8 +355,8 @@ > > INTEL_SKL_ULT_GT2_IDS(info), \ > > INTEL_SKL_ULX_GT2_IDS(info), \ > > INTEL_VGA_DEVICE(0x1912, info), /* DT GT2 */ \ > > - INTEL_VGA_DEVICE(0x191B, info), /* Halo GT2 */ \ > > INTEL_VGA_DEVICE(0x191A, info), /* SRV GT2 */ \ > > + INTEL_VGA_DEVICE(0x191B, info), /* Halo GT2 */ \ > > INTEL_VGA_DEVICE(0x191D, info) /* WKS GT2 */ > > > > #define INTEL_SKL_ULT_GT3_IDS(info) \ > > @@ -372,9 +372,9 @@ > > > > #define INTEL_SKL_GT4_IDS(info) \ > > INTEL_VGA_DEVICE(0x1932, info), /* DT GT4 */ \ > > + INTEL_VGA_DEVICE(0x193A, info), /* SRV GT4e */ \ > > INTEL_VGA_DEVICE(0x193B, info), /* Halo GT4e */ \ > > - INTEL_VGA_DEVICE(0x193D, info), /* WKS GT4e */ \ > > - INTEL_VGA_DEVICE(0x193A, info) /* SRV GT4e */ > > + INTEL_VGA_DEVICE(0x193D, info) /* WKS GT4e */ > > > > #define INTEL_SKL_IDS(info) \ > > INTEL_SKL_GT1_IDS(info), \ > > -- > > 2.26.2 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
drm-misc-fixes-2020-09-24: drm-misc-fixes for v5.9: - Single null pointer deref fix for dma-buf. The following changes since commit 74ea06164cda81dc80e97790164ca533fd7e3087: drm/sun4i: mixer: Extend regmap max_register (2020-09-10 13:08:48 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-09-24 for you to fetch changes up to 19a508bd1ad8e444de86873bf2f2b2ab8edd6552: dmabuf: fix NULL pointer dereference in dma_buf_release() (2020-09-21 11:17:06 +0200) drm-misc-fixes for v5.9: - Single null pointer deref fix for dma-buf. Charan Teja Reddy (1): dmabuf: fix NULL pointer dereference in dma_buf_release() drivers/dma-buf/dma-buf.c | 2 ++ 1 file changed, 2 insertions(+) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/14] drm/i915: Add SKL GT1.5 PCI IDs
On Thu, Sep 24, 2020 at 12:37:47AM +, Srivatsa, Anusha wrote: > > > > -Original Message- > > From: Intel-gfx On Behalf Of Ville > > Syrjala > > Sent: Thursday, July 16, 2020 10:21 AM > > To: intel-gfx@lists.freedesktop.org > > Subject: [Intel-gfx] [PATCH 04/14] drm/i915: Add SKL GT1.5 PCI IDs > > > > From: Alexei Podtelezhnikov > > > > Add three new devices 0x1913, 0x1915, and 0x1917 also known as > > iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. > > > > Signed-off-by: Alexei Podtelezhnikov > > [vsyrjala: Split separate changes into separate patchs, > >Sort the IDs] > The above comment appears in every patch. If this is v2 of the patches then > it goes right after the commit message as: > > V2: Split separate changes into separate patches, sort the IDs (Ville) No. I use the [vsyrjala: blah] notation to indicate I modified the original patch which was authored by someone else. > > > Signed-off-by: Ville Syrjälä > The code changes itself look good. > > Reviewed-by: Anusha Srivatsa > > > --- > > include/drm/i915_pciids.h | 9 ++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > > 9df3697f074d..c906088ccffe 100644 > > --- a/include/drm/i915_pciids.h > > +++ b/include/drm/i915_pciids.h > > @@ -329,17 +329,20 @@ > > INTEL_VGA_DEVICE(0x22b3, info) > > > > #define INTEL_SKL_ULT_GT1_IDS(info) \ > > - INTEL_VGA_DEVICE(0x1906, info) /* ULT GT1 */ > > + INTEL_VGA_DEVICE(0x1906, info), /* ULT GT1 */ \ > > + INTEL_VGA_DEVICE(0x1913, info) /* ULT GT1.5 */ > > > > #define INTEL_SKL_ULX_GT1_IDS(info) \ > > - INTEL_VGA_DEVICE(0x190E, info) /* ULX GT1 */ > > + INTEL_VGA_DEVICE(0x190E, info), /* ULX GT1 */ \ > > + INTEL_VGA_DEVICE(0x1915, info) /* ULX GT1.5 */ > > > > #define INTEL_SKL_GT1_IDS(info)\ > > INTEL_SKL_ULT_GT1_IDS(info), \ > > INTEL_SKL_ULX_GT1_IDS(info), \ > > INTEL_VGA_DEVICE(0x1902, info), /* DT GT1 */ \ > > INTEL_VGA_DEVICE(0x190B, info), /* Halo GT1 */ \ > > - INTEL_VGA_DEVICE(0x190A, info) /* SRV GT1 */ > > + INTEL_VGA_DEVICE(0x190A, info), /* SRV GT1 */ \ > > + INTEL_VGA_DEVICE(0x1917, info) /* DT GT1.5 */ > > > > #define INTEL_SKL_ULT_GT2_IDS(info) \ > > INTEL_VGA_DEVICE(0x1916, info), /* ULT GT2 */ \ > > -- > > 2.26.2 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 0/2] HDCP misc
On 2020-09-23 at 18:54:33 +0530, Anshuman Gupta wrote: > Rebased of a older series which has been pending to merge. > original series : https://patchwork.freedesktop.org/series/73345/ Thanks for the review and rebasing. Pushed into dinq. Ram. > > Ramalingam C (2): > drm/i915: terminate reauth at stream management failure > drm/i915: dont retry stream management at seq_num_m roll over > > drivers/gpu/drm/i915/display/intel_hdcp.c | 89 ++- > 1 file changed, 56 insertions(+), 33 deletions(-) > > -- > 2.26.2 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Thu, 24 Sep 2020 10:04:12 +0200
Daniel Vetter wrote:
> On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen wrote:
> >
> > On Wed, 23 Sep 2020 22:01:25 +0200
> > Daniel Vetter wrote:
> >
> > > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad
> > > wrote:
> > > >
> > > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > > reconfiguring global resources).
> >
> > ...
> >
> > > > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct
> > > > > drm_atomic_state *state)
> > > > > }
> > > > > }
> > > > >
> > > > > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > > +
> > > > > + /*
> > > > > + * For commits that allow modesets drivers can add other CRTCs
> > > > > to the
> > > > > + * atomic commit, e.g. when they need to reallocate global
> > > > > resources.
> > > > > + * This can cause spurious EBUSY, which robs compositors of a
> > > > > very
> > > > > + * effective sanity check for their drawing loop. Therefor only
> > > > > allow
> > > > > + * drivers to add unrelated CRTC states for modeset commits.
> > > > > + *
> > > > > + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as
> > > > > an output
> > > > > + * so compositors know what's going on.
> > > > > + */
> > > > > + if (affected_crtc != requested_crtc) {
> > > > > + DRM_DEBUG_ATOMIC("driver added CRTC to commit:
> > > > > requested 0x%x, affected 0x%0x\n",
> > > > > + requested_crtc, affected_crtc);
> > > > > + WARN(!state->allow_modeset, "adding CRTC not allowed
> > > > > without modesets: requested 0x%x, affected 0x%0x\n",
> > > > > + requested_crtc, affected_crtc);
> > > > Previous patch had the warn on state->allow_modeset now is
> > > > !state->allow_modeset. Is that correct?
> > >
> > > We need to fire a warning when allow_modeset is _not_ set. An earlier
> > > version got that wrong, and yes that would have caused a _ton_ of
> > > warnings on any fairly new intel platform.
> > >
> > > > I haven't followed the entire thread on this matter, but I guess the
> > > > idea
> > > > is that somehow the kernel would pass to userspace a CRTC mask of
> > > > affected_crtc (somehow, we don't know how atm) and with it, userspace
> > > > can then issue a new commit (this commit blocking) with those?
> > >
> > > Either that, or just use that to track all the in-flight drm events.
> > > Userspace will get events for all the crtc, not just the one it asked
> > > to update.
> >
> > Wait, does that happen already? Getting CRTC events for CRTCs userspace
> > didn't include in the atomic commit?
>
> Yeah I'm pretty sure. With the affected_crtc mask you could update
> your internal book-keeping to catch these, which should also prevent
> all the spurious EBUSY. But I'm not entirely sure, I just read the
> code, haven't tested.
If that actually happens, how does userspace know whether the
userdata argument with the event is valid or not?
The kernel should expect the userdata argument to be one-shot, because
it may be a pointer to a malloc()'d struct that gets freed the moment
the originally expected event is handled, so re-using userdata is going
to break userspace (ISTR Mutter uses this style with legacy, Weston
passes somewhat more persistent pointers with both legacy and atomic).
Does the kernel reset it to zero? What if userspace doesn't use a
pointer but e.g. an index where 0 may be a legal value but also wrong?
Thanks,
pq
> > That could explain why Weston freaks out in
> > https://gitlab.freedesktop.org/wayland/weston/-/issues/435
>
> Hm it's strange that you first get an EBUSY, and only on the next
> modeset get the spurious event. You should get one already on the
> first modeset.
> -Daniel
>
> >
> >
> > Thanks,
> > pq
> >
> >
> > > If that's easier to do by re-issuing the commit with the
> > > full set of crtc, then I guess that's an option. But not required (I
> > > think at least, would need to test that to make sure).
> > > -Daniel
> > >
> > > > > + }
> > > > > +
> > > > > return 0;
> > > > > }
> > > > > EXPORT_SYMBOL(drm_atomic_check_only);
>
>
>
pgpqxbQmMBSiO.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel - Just a couple of simple fixes. With Daniel's irc ack I backmerged Linus' tree at an arbitrary commit due to a build failure in v5.9-rc6 that blocked CI. drm-intel-fixes-2020-09-24: drm/i915 fixes for v5.9-rc7: - Fix selftest reference to stack data out of scope - Fix GVT null pointer dereference - Backmerge from Linus' master to fix build BR, Jani. The following changes since commit 98477740630f270aecf648f1d6a9dbc6027d4ff1: Merge branch 'rcu/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu (2020-09-21 12:42:31 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-09-24 for you to fetch changes up to 16cce04cdb200ba905d1241b425ac48da5a9ace5: drm/i915/selftests: Push the fake iommu device from the stack to data (2020-09-23 10:15:46 +0300) drm/i915 fixes for v5.9-rc7: - Fix selftest reference to stack data out of scope - Fix GVT null pointer dereference - Backmerge from Linus' master to fix build Chris Wilson (1): drm/i915/selftests: Push the fake iommu device from the stack to data Jani Nikula (2): Merge remote-tracking branch 'origin/master' into drm-intel-fixes Merge tag 'gvt-fixes-2020-09-17' of https://github.com/intel/gvt-linux into drm-intel-fixes Zhenyu Wang (1): drm/i915/gvt: Fix port number for BDW on EDID region setup drivers/gpu/drm/i915/gvt/vgpu.c | 6 +- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 12 +--- 2 files changed, 10 insertions(+), 8 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Switch 4k kmalloc to use get_free_page for alignment
On Wed, 23 Sep 2020 at 12:42, Chris Wilson wrote: > > In generating the reference LRC, we want a page-aligned address for > simplicity in computing the offsets within. This then shares the > computation for the HW LRC which is mapped and so page aligned, making > the comparison straightforward. It seems that kmalloc(4k) is not always > returning from a 4k-aligned slab cache (which would give us a page aligned > address) so force alignment by explicitly allocating a page. > > Reported-by: "Gote, Nitin R" > Signed-off-by: Chris Wilson > Cc: "Gote, Nitin R" Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
