[Intel-gfx] [PATCH] drm/i915/dp: No need to poll FEC Enable Live bit
The Bspec does not mention polling the FEC Enable Live status bit. That is only there for debug purposes. So remove the polling from driver. Cc: Ankit Nautiyal Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/display/intel_ddi.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 92940a0c5ef8..6b3edd7e4423 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3507,12 +3507,6 @@ static void intel_ddi_enable_fec(struct intel_encoder *encoder, val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state)); val |= DP_TP_CTL_FEC_ENABLE; intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), val); - - if (intel_de_wait_for_set(dev_priv, - dp_tp_status_reg(encoder, crtc_state), - DP_TP_STATUS_FEC_ENABLE_LIVE, 1)) - drm_err(_priv->drm, - "Timed out waiting for FEC Enable Status\n"); } static void intel_ddi_disable_fec_state(struct intel_encoder *encoder, -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix error return code in check_partial_mapping()
== Series Details ==
Series: drm/i915: fix error return code in check_partial_mapping()
URL : https://patchwork.freedesktop.org/series/84242/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9387 -> Patchwork_18973
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18973 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18973, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18973:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@mman:
- fi-cml-u2: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-cml-u2/igt@i915_selftest@l...@mman.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-cml-u2/igt@i915_selftest@l...@mman.html
- fi-cml-s: [PASS][3] -> [DMESG-FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-cml-s/igt@i915_selftest@l...@mman.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-cml-s/igt@i915_selftest@l...@mman.html
- fi-skl-6700k2: [PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-skl-6700k2/igt@i915_selftest@l...@mman.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-skl-6700k2/igt@i915_selftest@l...@mman.html
- fi-ivb-3770:[PASS][7] -> [DMESG-FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-ivb-3770/igt@i915_selftest@l...@mman.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-ivb-3770/igt@i915_selftest@l...@mman.html
- fi-kbl-guc: [PASS][9] -> [DMESG-FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-kbl-guc/igt@i915_selftest@l...@mman.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-kbl-guc/igt@i915_selftest@l...@mman.html
New tests
-
New tests have been introduced between CI_DRM_9387 and Patchwork_18973:
### New CI tests (1) ###
* boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18973 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-byt-j1900/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#1982] /
[k.org#205379])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-tgl-u2/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@kms_addfb_basic@addfb25-bad-modifier:
- fi-tgl-y: [PASS][15] -> [DMESG-WARN][16] ([i915#402])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
Possible fixes
* igt@gem_flink_basic@bad-open:
- fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
* igt@kms_busy@basic@flip:
- {fi-kbl-7560u}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-kbl-7560u/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-kbl-7560u/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][21] ([i915#1161] / [i915#262]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18973/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9387/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote: > On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote: > > Really, no ... something which produces no improvement has no value > > at all ... we really shouldn't be wasting maintainer time with it > > because it has a cost to merge. I'm not sure we understand where > > the balance lies in value vs cost to merge but I am confident in > > the zero value case. > > What? We can't measure how many future bugs aren't introduced because > the kernel requires explicit case flow-control statements for all new > code. No but we can measure how vulnerable our current coding habits are to the mistake this warning would potentially prevent. I don't think it's wrong to extrapolate that if we had no instances at all of prior coding problems we likely wouldn't have any in future either making adopting the changes needed to enable the warning valueless ... that's the zero value case I was referring to above. Now, what we have seems to be about 6 cases (at least what's been shown in this thread) where a missing break would cause potentially user visible issues. That means the value of this isn't zero, but it's not a no-brainer massive win either. That's why I think asking what we've invested vs the return isn't a useless exercise. > We already enable -Wimplicit-fallthrough globally, so that's not the > discussion. The issue is that Clang is (correctly) even more strict > than GCC for this, so these are the remaining ones to fix for full > Clang coverage too. > > People have spent more time debating this already than it would have > taken to apply the patches. :) You mean we've already spent 90% of the effort to come this far so we might as well go the remaining 10% because then at least we get some return? It's certainly a clinching argument in defence procurement ... > This is about robustness and language wrangling. It's a big code- > base, and this is the price of our managing technical debt for > permanent robustness improvements. (The numbers I ran from Gustavo's > earlier patches were that about 10% of the places adjusted were > identified as legitimate bugs being fixed. This final series may be > lower, but there are still bugs being found from it -- we need to > finish this and shut the door on it for good.) I got my six patches by analyzing the lwn.net report of the fixes that was cited which had 21 of which 50% didn't actually change the emitted code, and 25% didn't have a user visible effect. But the broader point I'm making is just because the compiler people come up with a shiny new warning doesn't necessarily mean the problem it's detecting is one that causes us actual problems in the code base. I'd really be happier if we had a theory about what classes of CVE or bug we could eliminate before we embrace the next new warning. James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix error return code in check_partial_mapping()
Fix to return a negative error code from the error handling case
instead of 0 in function check_partial_mapping(), as done elsewhere
in this function.
Fixes: 07e98eb0a174 ("drm/i915/selftests: Tighten the timeout testing for
partial mmaps")
Reported-by: Hulk Robot
Signed-off-by: Luo Meng
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index d27d87a678c8..3f5e7d0a3c53 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -137,8 +137,10 @@ static int check_partial_mapping(struct
drm_i915_gem_object *obj,
i915_vma_unpin_iomap(vma);
offset = tiled_offset(tile, page << PAGE_SHIFT);
- if (offset >= obj->base.size)
+ if (offset >= obj->base.size) {
+ err = -EINVAL;
goto out;
+ }
intel_gt_flush_ggtt_writes(_i915(obj->base.dev)->gt);
--
2.25.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Wed, 25 Nov 2020, Miguel Ojeda wrote: > > The C standard has nothing to do with this. We use compiler extensions > of several kinds, for many years. Even discounting those extensions, the > kernel is not even conforming to C due to e.g. strict aliasing. I am not > sure what you are trying to argue here. > I'm saying that supporting the official language spec makes more sense than attempting to support a multitude of divergent interpretations of the spec (i.e. gcc, clang, coverity etc.) I'm also saying that the reason why we use -std=gnu89 is that existing code was written in that language, not in ad hoc languages comprised of collections of extensions that change with every release. > But, since you insist: yes, the `fallthrough` attribute is in the > current C2x draft. > Thank you for checking. I found a free version that's only 6 weeks old: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf It will be interesting to see whether 6.7.11.5 changes once the various implementations reach agreement. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Tue, 24 Nov 2020, Kees Cook wrote: > On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote: > > Really, no ... something which produces no improvement has no value at > > all ... we really shouldn't be wasting maintainer time with it because > > it has a cost to merge. I'm not sure we understand where the balance > > lies in value vs cost to merge but I am confident in the zero value > > case. > > What? We can't measure how many future bugs aren't introduced because > the kernel requires explicit case flow-control statements for all new > code. > These statements are not "missing" unless you presume that code written before the latest de facto language spec was written should somehow be held to that spec. If the 'fallthrough' statement is not part of the latest draft spec then we should ask why not before we embrace it. Being that the kernel still prefers -std=gnu89 you might want to consider what has prevented -std=gnu99 or -std=gnu2x etc. > We already enable -Wimplicit-fallthrough globally, so that's not the > discussion. The issue is that Clang is (correctly) even more strict than > GCC for this, so these are the remaining ones to fix for full Clang > coverage too. > Seems to me you should be patching the compiler. When you have consensus among the language lawyers you'll have more credibility with those being subjected to enforcement. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Wed, Nov 25, 2020 at 12:53 AM Finn Thain wrote: > > I'm saying that supporting the official language spec makes more sense > than attempting to support a multitude of divergent interpretations of the > spec (i.e. gcc, clang, coverity etc.) Making the kernel strictly conforming is a ship that sailed long ago, for several reasons. Anyway, supporting several compilers and other tools, regardless of extensions, is valuable. > I'm also saying that the reason why we use -std=gnu89 is that existing > code was written in that language, not in ad hoc languages comprised of > collections of extensions that change with every release. No, we aren't particularly tied to `gnu89` or anything like that. We could actually go for `gnu11` already, since the minimum GCC and Clang support it. Even if a bit of code needs fixing, that shouldn't be a problem if someone puts the work. In other words, the kernel code is not frozen, nor are the features it uses from compilers. They do, in fact, change from time to time. > Thank you for checking. I found a free version that's only 6 weeks old: You're welcome! There are quite a few new attributes coming, mostly following C++ ones. > It will be interesting to see whether 6.7.11.5 changes once the various > implementations reach agreement. Not sure what you mean. The standard does not evolve through implementations' agreement (although standardizing existing practice is one of the best arguments to back a change). Cheers, Miguel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 9:38 PM James Bottomley wrote: > > So you think a one line patch should take one minute to produce ... I > really don't think that's grounded in reality. No, I have not said that. Please don't put words in my mouth (again). I have said *authoring* lines of *this* kind takes a minute per line. Specifically: lines fixing the fallthrough warning mechanically and repeatedly where the compiler tells you to, and doing so full-time for a month. For instance, take the following one from Gustavo. Are you really saying it takes 12 minutes (your number) to write that `break;`? diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c index 24cc445169e2..a3e0fb5b8671 100644 --- a/drivers/gpu/drm/via/via_irq.c +++ b/drivers/gpu/drm/via/via_irq.c @@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void *data, struct drm_file *file_priv) irqwait->request.sequence += atomic_read(_irq->irq_received); irqwait->request.type &= ~_DRM_VBLANK_RELATIVE; + break; case VIA_IRQ_ABSOLUTE: break; default: > I suppose a one line > patch only takes a minute to merge with b4 if no-one reviews or tests > it, but that's not really desirable. I have not said that either. I said reviewing and merging those are noise compared to any complex patch. Testing should be done by the author comparing codegen. > Part of what I'm trying to measure is the "and useful" bit because > that's not a given. It is useful since it makes intent clear. It also catches actual bugs, which is even more valuable. > Well, you know, subsystems are very different in terms of the amount of > patches a maintainer has to process per release cycle of the kernel. > If a maintainer is close to capacity, additional patches, however > trivial, become a problem. If a maintainer has spare cycles, trivial > patches may look easy. First of all, voluntary maintainers choose their own workload. Furthermore, we already measure capacity in the `MAINTAINERS` file: maintainers can state they can only handle a few patches. Finally, if someone does not have time for a trivial patch, they are very unlikely to have any time to review big ones. > You seem to be saying that because you find it easy to merge trivial > patches, everyone should. Again, I have not said anything of the sort. Cheers, Miguel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Tue, Nov 24, 2020 at 11:24 PM Finn Thain wrote: > > These statements are not "missing" unless you presume that code written > before the latest de facto language spec was written should somehow be > held to that spec. There is no "language spec" the kernel adheres to. Even if it did, kernel code is not frozen. If an improvement is found, it should be applied. > If the 'fallthrough' statement is not part of the latest draft spec then > we should ask why not before we embrace it. Being that the kernel still > prefers -std=gnu89 you might want to consider what has prevented > -std=gnu99 or -std=gnu2x etc. The C standard has nothing to do with this. We use compiler extensions of several kinds, for many years. Even discounting those extensions, the kernel is not even conforming to C due to e.g. strict aliasing. I am not sure what you are trying to argue here. But, since you insist: yes, the `fallthrough` attribute is in the current C2x draft. Cheers, Miguel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote:
>
> What I meant was that you've used pessimism as if it was fact.
"future mistakes that it might prevent" is neither pessimism nor states a fact.
> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".
It is only knee-jerk if you think you are infallible.
> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools
This warning comes from a development tool -- the compiler.
> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.
The kernel is not a frozen codebase.
Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.
> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.
Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.
> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?
Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.
> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.
If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.
> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.
I was not asking you to prove it. I am stating that proving it is very easy.
Cheers,
Miguel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
== Series Details == Series: drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping URL : https://patchwork.freedesktop.org/series/84238/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9385_full -> Patchwork_18972_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18972_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18972_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_18972_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gem_contexts: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-skl5/igt@i915_selftest@live@gem_contexts.html New tests - New tests have been introduced between CI_DRM_9385_full and Patchwork_18972_full: ### New CI tests (1) ### * boot: - Statuses : 199 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_18972_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]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-glk5/igt@gem_exec_reloc@basic-many-act...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-glk7/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen: - shard-skl: [PASS][4] -> [FAIL][5] ([i915#54]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-64x64-offscreen.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-64x64-offscreen.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled: - shard-apl: [PASS][6] -> [DMESG-WARN][7] ([i915#1635] / [i915#1982]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-apl7/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-apl3/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][8] -> [FAIL][9] ([i915#79]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-skl9/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@plain-flip-fb-recreate@a-edp1: - shard-skl: [PASS][10] -> [DMESG-FAIL][11] ([i915#1982]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl10/igt@kms_flip@plain-flip-fb-recre...@a-edp1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-skl8/igt@kms_flip@plain-flip-fb-recre...@a-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt: - shard-tglb: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +4 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-msflip-blt.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-tglb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite: - shard-iclb: [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite.html * igt@kms_panel_fitting@atomic-fastset: - shard-skl: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) +4 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl10/igt@kms_panel_fitt...@atomic-fastset.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-skl4/igt@kms_panel_fitt...@atomic-fastset.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][18] -> [FAIL][19] ([fdo#108145] / [i915#265]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html *
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
Hi Aditya,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.10-rc5 next-20201124]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Aditya-Swarup/drm-i915-tgl-Fix-REVID-macros-for-TGL-to-fetch-correct-stepping/20201125-083215
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a005-20201125 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/ce4e72969ddaa07dd8426d230d04ed91382e2fd9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Aditya-Swarup/drm-i915-tgl-Fix-REVID-macros-for-TGL-to-fetch-correct-stepping/20201125-083215
git checkout ce4e72969ddaa07dd8426d230d04ed91382e2fd9
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/drm/drm_mm.h:49,
from drivers/gpu/drm/i915/i915_vma.h:31,
from drivers/gpu/drm/i915/gt/uc/intel_guc.h:17,
from drivers/gpu/drm/i915/gt/uc/intel_uc.h:9,
from drivers/gpu/drm/i915/gt/intel_gt_types.h:16,
from drivers/gpu/drm/i915/gt/intel_gt.h:10,
from drivers/gpu/drm/i915/selftests/igt_reset.c:10:
drivers/gpu/drm/i915/selftests/../i915_drv.h: In function 'tgl_revids_get':
>> drivers/gpu/drm/i915/selftests/../i915_drv.h:1594:9: warning: format '%lu'
>> expects argument of type 'long unsigned int', but argument 5 has type
>> 'unsigned int' [-Wformat=]
1594 | "Unsupported SOC stepping found %u, using %lu instead\n",
| ^~~~
include/drm/drm_print.h:450:38: note: in definition of macro 'drm_dbg_kms'
450 | drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
| ^~~
In file included from drivers/gpu/drm/i915/selftests/igt_reset.c:12:
drivers/gpu/drm/i915/selftests/../i915_drv.h:1594:53: note: format string is
defined here
1594 | "Unsupported SOC stepping found %u, using %lu instead\n",
| ~~^
| |
| long unsigned int
| %u
In file included from include/drm/drm_mm.h:49,
from drivers/gpu/drm/i915/i915_vma.h:31,
from drivers/gpu/drm/i915/gt/uc/intel_guc.h:17,
from drivers/gpu/drm/i915/gt/uc/intel_uc.h:9,
from drivers/gpu/drm/i915/gt/intel_gt_types.h:16,
from drivers/gpu/drm/i915/gt/intel_gt.h:10,
from drivers/gpu/drm/i915/selftests/igt_reset.c:10:
drivers/gpu/drm/i915/selftests/../i915_drv.h:1602:8: warning: format '%lu'
expects argument of type 'long unsigned int', but argument 5 has type 'unsigned
int' [-Wformat=]
1602 |"Unsupported SOC stepping found %u, using %lu instead\n",
|^~~~
include/drm/drm_print.h:450:38: note: in definition of macro 'drm_dbg_kms'
450 | drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
| ^~~
In file included from drivers/gpu/drm/i915/selftests/igt_reset.c:12:
drivers/gpu/drm/i915/selftests/../i915_drv.h:1602:52: note: format string is
defined here
1602 |"Unsupported SOC stepping found %u, using %lu instead\n",
| ~~^
||
|long unsigned int
| %u
vim +1594 drivers/gpu/drm/i915/selftests/../i915_drv.h
1577
1578 #define TGL_UY_REVID_RANGE(revid) \
1579 ((revid) < ARRAY_SIZE(tgl_uy_revids))
1580
1581 #define TGL_REVID_RANGE(revid) \
1582 ((revid) < ARRAY_SIZE(tgl_revids))
1583
1584 static inline const struct i915_rev_steppings *
1585 tgl_revids_get(struct drm_i915_private *dev_priv)
1586 {
1587 const u8 revid = INTEL_REVID(dev_priv);
1588
1589 if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
1590
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: Track logically enabled planes for hw state
== Series Details == Series: series starting with [1/4] drm/i915: Track logically enabled planes for hw state URL : https://patchwork.freedesktop.org/series/84230/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9385_full -> Patchwork_18970_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18970_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18970_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_18970_full: ### CI changes ### Possible regressions * boot (NEW): - shard-skl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [FAIL][41], [FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl10/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl10/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl9/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl9/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl8/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl8/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl6/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl5/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl5/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl4/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl4/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl3/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl3/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/shard-skl3/boot.html [41]:
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
Hi Aditya,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.10-rc5 next-20201124]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Aditya-Swarup/drm-i915-tgl-Fix-REVID-macros-for-TGL-to-fetch-correct-stepping/20201125-083215
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a004-20201125 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/ce4e72969ddaa07dd8426d230d04ed91382e2fd9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Aditya-Swarup/drm-i915-tgl-Fix-REVID-macros-for-TGL-to-fetch-correct-stepping/20201125-083215
git checkout ce4e72969ddaa07dd8426d230d04ed91382e2fd9
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/drm/drm_mm.h:49,
from include/drm/drm_vma_manager.h:26,
from include/drm/drm_gem.h:40,
from drivers/gpu/drm/i915/i915_drv.h:55,
from drivers/gpu/drm/i915/gt/intel_workarounds.c:7:
drivers/gpu/drm/i915/i915_drv.h: In function 'tgl_revids_get':
>> drivers/gpu/drm/i915/i915_drv.h:1594:9: warning: format '%lu' expects
>> argument of type 'long unsigned int', but argument 5 has type 'unsigned int'
>> [-Wformat=]
1594 | "Unsupported SOC stepping found %u, using %lu instead\n",
| ^~~~
include/drm/drm_print.h:450:38: note: in definition of macro 'drm_dbg_kms'
450 | drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
| ^~~
In file included from drivers/gpu/drm/i915/gt/intel_workarounds.c:7:
drivers/gpu/drm/i915/i915_drv.h:1594:53: note: format string is defined here
1594 | "Unsupported SOC stepping found %u, using %lu instead\n",
| ~~^
| |
| long unsigned int
| %u
In file included from include/drm/drm_mm.h:49,
from include/drm/drm_vma_manager.h:26,
from include/drm/drm_gem.h:40,
from drivers/gpu/drm/i915/i915_drv.h:55,
from drivers/gpu/drm/i915/gt/intel_workarounds.c:7:
drivers/gpu/drm/i915/i915_drv.h:1602:8: warning: format '%lu' expects
argument of type 'long unsigned int', but argument 5 has type 'unsigned int'
[-Wformat=]
1602 |"Unsupported SOC stepping found %u, using %lu instead\n",
|^~~~
include/drm/drm_print.h:450:38: note: in definition of macro 'drm_dbg_kms'
450 | drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
| ^~~
In file included from drivers/gpu/drm/i915/gt/intel_workarounds.c:7:
drivers/gpu/drm/i915/i915_drv.h:1602:52: note: format string is defined here
1602 |"Unsupported SOC stepping found %u, using %lu instead\n",
| ~~^
||
|long unsigned int
| %u
vim +1594 drivers/gpu/drm/i915/i915_drv.h
1577
1578 #define TGL_UY_REVID_RANGE(revid) \
1579 ((revid) < ARRAY_SIZE(tgl_uy_revids))
1580
1581 #define TGL_REVID_RANGE(revid) \
1582 ((revid) < ARRAY_SIZE(tgl_revids))
1583
1584 static inline const struct i915_rev_steppings *
1585 tgl_revids_get(struct drm_i915_private *dev_priv)
1586 {
1587 const u8 revid = INTEL_REVID(dev_priv);
1588
1589 if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
1590 if (TGL_UY_REVID_RANGE(revid)) {
1591 return tgl_uy_revids + revid;
1592 } else {
1593 drm_dbg_kms(_priv->drm,
> 1594 "Unsupported SOC stepping found %u,
> using %lu instead\n",
1595 revid, ARRAY_SIZE(tgl_uy_revids) -
1);
[Intel-gfx] ✗ Fi.CI.IGT: failure for Move display initialization
== Series Details == Series: Move display initialization URL : https://patchwork.freedesktop.org/series/84225/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9385_full -> Patchwork_18969_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18969_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18969_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_18969_full: ### CI changes ### Possible regressions * boot (NEW): - shard-skl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([FAIL][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [FAIL][48]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl9/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl10/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl10/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl10/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl10/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl10/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl1/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl1/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl9/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl9/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl8/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl8/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl7/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl7/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl6/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl6/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl5/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/shard-skl5/boot.html [42]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Limit frequency drop to RPe on parking
== Series Details == Series: drm/i915/gt: Limit frequency drop to RPe on parking URL : https://patchwork.freedesktop.org/series/84223/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9385_full -> Patchwork_18967_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18967_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18967_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_18967_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gem_contexts: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl2/igt@i915_selftest@live@gem_contexts.html New tests - New tests have been introduced between CI_DRM_9385_full and Patchwork_18967_full: ### New CI tests (1) ### * boot: - Statuses : 198 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_18967_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_wc@fault-concurrent: - shard-iclb: [PASS][2] -> [DMESG-WARN][3] ([i915#1982]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-iclb3/igt@gem_mmap...@fault-concurrent.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-iclb2/igt@gem_mmap...@fault-concurrent.html * igt@kms_cursor_crc@pipe-b-cursor-128x128-random: - shard-skl: [PASS][4] -> [FAIL][5] ([i915#54]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-128x128-random.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl8/igt@kms_cursor_...@pipe-b-cursor-128x128-random.html * igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge: - shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#1982]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-glk7/igt@kms_cursor_edge_w...@pipe-b-128x128-top-edge.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-glk3/igt@kms_cursor_edge_w...@pipe-b-128x128-top-edge.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@bc-hdmi-a1-hdmi-a2: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2122]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-glk4/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@bc-hdmi-a1-hdmi-a2.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-glk3/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@bc-hdmi-a1-hdmi-a2.html * igt@kms_flip@2x-plain-flip-ts-check-interruptible@ab-vga1-hdmi-a1: - shard-hsw: [PASS][10] -> [DMESG-WARN][11] ([i915#1982]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-hsw4/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ab-vga1-hdmi-a1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-hsw6/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ab-vga1-hdmi-a1.html * igt@kms_flip@plain-flip-fb-recreate@a-edp1: - shard-skl: [PASS][12] -> [DMESG-FAIL][13] ([i915#1982]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl10/igt@kms_flip@plain-flip-fb-recre...@a-edp1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl5/igt@kms_flip@plain-flip-fb-recre...@a-edp1.html * igt@kms_flip@plain-flip-ts-check-interruptible@c-edp1: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#2122]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/igt@kms_flip@plain-flip-ts-check-interrupti...@c-edp1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl3/igt@kms_flip@plain-flip-ts-check-interrupti...@c-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt: - shard-tglb: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-msflip-blt.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-tglb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-cpu: - shard-snb: [PASS][18] -> [SKIP][19] ([fdo#109271]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-snb5/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-cpu.html [19]:
[Intel-gfx] linux firmware PR for i915 GuC v49.0.1
Hi Josh, Kyle, Ben, Kindly add the below i915 changes to linux-firmware.git: The following changes since commit b362fd4cb8963ad75517dbcf424974f65a29a60e: Mellanox: Add new mlxsw_spectrum firmware xx.2008.2018 (2020-11-24 09:55:03 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware FDO/guc_v49 for you to fetch changes up to c487f7dadcd21116613441ed355b764003b3f57b: i915: Add GuC firmware v49.0.1 for all platforms (2020-11-24 17:04:17 -0800) John Harrison (2): i915: Remove duplicate KBL DMC entry i915: Add GuC firmware v49.0.1 for all platforms WHENCE | 25 - i915/bxt_guc_49.0.1.bin | Bin 0 -> 196224 bytes i915/cml_guc_49.0.1.bin | Bin 0 -> 197184 bytes i915/ehl_guc_49.0.1.bin | Bin 0 -> 324160 bytes i915/glk_guc_49.0.1.bin | Bin 0 -> 196672 bytes i915/icl_guc_49.0.1.bin | Bin 0 -> 324160 bytes i915/kbl_guc_49.0.1.bin | Bin 0 -> 197184 bytes i915/skl_guc_49.0.1.bin | Bin 0 -> 196288 bytes i915/tgl_guc_49.0.1.bin | Bin 0 -> 321792 bytes 9 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 i915/bxt_guc_49.0.1.bin create mode 100644 i915/cml_guc_49.0.1.bin create mode 100644 i915/ehl_guc_49.0.1.bin create mode 100644 i915/glk_guc_49.0.1.bin create mode 100644 i915/icl_guc_49.0.1.bin create mode 100644 i915/kbl_guc_49.0.1.bin create mode 100644 i915/skl_guc_49.0.1.bin create mode 100644 i915/tgl_guc_49.0.1.bin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
== Series Details == Series: drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping URL : https://patchwork.freedesktop.org/series/84238/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h HDRTEST drivers/gpu/drm/i915/display/intel_display_types.h In file included from ./include/drm/drm_mm.h:49, from ./include/drm/drm_vma_manager.h:26, from ./include/drm/drm_gem.h:40, from ./drivers/gpu/drm/i915/i915_drv.h:55, from ./drivers/gpu/drm/i915/display/intel_display_types.h:46, from : ./drivers/gpu/drm/i915/i915_drv.h: In function ‘tgl_revids_get’: ./drivers/gpu/drm/i915/i915_drv.h:1594:9: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘unsigned int’ [-Werror=format=] "Unsupported SOC stepping found %u, using %lu instead\n", ^~~~ ./include/drm/drm_print.h:450:38: note: in definition of macro ‘drm_dbg_kms’ drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__) ^~~ ./drivers/gpu/drm/i915/i915_drv.h:1602:8: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘unsigned int’ [-Werror=format=] "Unsupported SOC stepping found %u, using %lu instead\n", ^~~~ ./include/drm/drm_print.h:450:38: note: in definition of macro ‘drm_dbg_kms’ drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__) ^~~ cc1: all warnings being treated as errors drivers/gpu/drm/i915/Makefile:304: recipe for target 'drivers/gpu/drm/i915/display/intel_display_types.hdrtest' failed make[4]: *** [drivers/gpu/drm/i915/display/intel_display_types.hdrtest] Error 1 scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1799: recipe for target 'drivers' failed make: *** [drivers] Error 2 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/build_32bit.log ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
== Series Details ==
Series: drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
URL : https://patchwork.freedesktop.org/series/84238/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18972
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/index.html
New tests
-
New tests have been introduced between CI_DRM_9385 and Patchwork_18972:
### New CI tests (1) ###
* boot:
- Statuses : 38 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18972 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +2 similar
issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/fi-tgl-y/igt@debugfs_test@read_all_entries.html
* igt@gem_exec_suspend@basic-s0:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] /
[i915#62]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-byt-j1900/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [PASS][7] -> [DMESG-FAIL][8] ([i915#541])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u: [DMESG-WARN][11] ([i915#262]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@prime_vgem@basic-read:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@prime_v...@basic-read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/fi-tgl-y/igt@prime_v...@basic-read.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y: [DMESG-WARN][17] ([i915#2411]) -> [DMESG-WARN][18]
([i915#1982] / [i915#2411])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18972/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
Participating hosts (43 -> 38)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bdw-samus fi-kbl-r
Build changes
-
* Linux: CI_DRM_9385 -> Patchwork_18972
CI-20190529: 20190529
CI_DRM_9385: 3d37e624f60f40cea80e784617686ae2917e9b01 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5870:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
== Series Details ==
Series: drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
URL : https://patchwork.freedesktop.org/series/84238/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3f30d254dfce drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
-:60: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#60: FILE: drivers/gpu/drm/i915/i915_drv.h:1592:
+ return tgl_uy_revids + revid;
+ } else {
-:68: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#68: FILE: drivers/gpu/drm/i915/i915_drv.h:1600:
+ return tgl_revids + revid;
+ } else {
total: 0 errors, 2 warnings, 0 checks, 57 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/21] drm/i915/tgl: Fix macros for TGL SOC based WA
On 11/24/20 12:11 PM, Lucas De Marchi wrote:
> +Matt Roper, see question in item (3) below
>
> On Tue, Nov 24, 2020 at 04:20:40PM +0200, Jani Nikula wrote:
>> On Tue, 24 Nov 2020, Lucas De Marchi wrote:
>>> On Mon, Nov 23, 2020 at 05:32:22PM -0800, Aditya Swarup wrote:
On 11/18/20 1:18 AM, Jani Nikula wrote:
> On Tue, 17 Nov 2020, Lucas De Marchi wrote:
>> On Tue, Nov 17, 2020 at 10:50:10AM -0800, Aditya Swarup wrote:
>>> @@ -1579,9 +1579,9 @@ static inline const struct i915_rev_steppings *
>>> tgl_revids_get(struct drm_i915_private *dev_priv)
>>> {
>>> if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv))
>>> - return tgl_uy_revids;
>>> + return tgl_uy_revids + INTEL_REVID(dev_priv);
>>
>> oohh, no. You have to at least check you are not accessing out of
>> bounds. New HW running on old kernel should not access create invalid
>> accesses like this.
>
> And this is just one reason why exposing arrays directly as an interface
> to the rest of the driver is a bad idea. Basically I look at *all*
> externs in the driver with suspicion, and they're all exceptions that
> should not be repeated. The revid arrays are a direct invitation to keep
> adding more and more extern arrays. And more ways to go out of bounds.
We definitely need an array table for the SOC -> Display, GT stepping
mapping.
>>>
>>> the mapping could be very well in the define iff you don't have
>>> different mappings per sku as is the case with TGL. Example:
>>>
>>> #define ADLS_REVID_A0 0
>>> #define ADLS_REVID_A1 5
>>>
>>> #define ADLS_DISP_REVID_A0 0
>>> #define ADLS_DISP_REVID_B0 5
>>>
>>> The actual value is actually the *SoC* revid, regardless the name of the
>>> macro. Since we already have to use a different macro -
>>> IS_DISP_REVID() - I don't think this is much worse and would allow us to
>>> get rid of the table *for ADL-S*, at the expense of having to pass as
>>> argument the ADLS_DISP_REVID_*. However this doesn't apply to TGL as TGL
>>> has a different mapping per sku.
>>>
>>>
SOC steppings were usually the same as display steppings/GT steppings
until TGL and therefore
didn't require special mapping cases. But from TGL onwards, we have
different combinations of
Disp and GT steppings per SOC stepping. Alderlake-S makes this direct
mapping even more difficult
without the array requiring more macros to deal with SOC -> DISP/GT
stepping differences.
Will fix the array bound checks but the possibility of SOC revision id
from drm struct going
out of bounds is minimal. Can only happen if we don't have support for
latest SOC -> Disp/GT table
>>>
>>> this is very common. It's just a matter of trying to run a slightly old
>>> kernel in a slightly newer rev of the hardware.
>>
>> Indeed. All kernels released with the arrays are simply bust for any new
>> hardware revisions. They'll need a minimal Cc: stable fix.
>>
>> Here's something I drafted [1] to fix the situation more
>> generally. There are still some issues to overcome, though they exist
>> already in the current code.
>>
>> This could be followed up with converting *all* platforms to the scheme,
>> making it universal, regardless of whether the revids in the hardware
>> are consecutive or not.
>>
>> BR,
>> Jani.
>>
>>
>> [1] https://cgit.freedesktop.org/~jani/drm/log/?h=revid-stepping-scheme
>
> That is looking good. Some feedback I can give before this series being
> sent for review:
I like this approach as well and we were discussing this in the ADLS rev ID
thread. With the tables it
makes it simpler to manage rather than worrying about individual macros. Jani
do you want me to rebase ADLS
changes on top of your patches and resubmit your patches for review or you will
be submitting this series yourself?
>
> 1) You need to call the init function from somewhere
> 2) For the FIXMEs:
>
> + /*
> + * FIXME: We should be able to take into account new revids not
> + * recognized by this kernel version.
> + */
>
> + /*
> + * FIXME: We should be able to handle gaps in revid arrays gracefully,
> + * and in a way that works sensibly for the range checks. This is true
> + * for the existing revid range checks; it's fine if a new id pops up in
> + * the middle.
> + *
> + * It's okay for the display stepping to be zero, though in an array all
> + * or none should be set to non-zero, not a mix.
> + */
>
> Maybe consider that gt_stepping will never be 0 and in the case it is (or
> size > ARRAY_SIZE), just backtrack to use the first one we find with
> gt_stepping != 0? then we probably should add a warning that we are not
> actually using the correct one, but it's the best we can do.
>
> 3) REVID_BXT_B_LAST
I couldn't spot REVID_NONE as well in the patches.
>
> what is that? The only thing that comes to mind is for "matching all B
>
[Intel-gfx] [PATCH] drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
Fix TGL REVID macros to fetch correct display/gt stepping based
on SOC rev id from INTEL_REVID() macro. Previously, we were just
returning the first element of the revid array instead of using
the correct index based on SOC rev id.
Also, add array bound checks for TGL REV ID array. Since, there
might be a possibility of using older kernels on latest platform
revision, resulting in out of bounds access for rev ID array.
In this scenario, print message for unsupported rev ID and apply
settings for latest rev ID available.
Fixes: ("drm/i915/tgl: Fix stepping WA matching")
Cc: José Roberto de Souza
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_drv.h | 35 +++--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 15be8debae54..29d55b7017be 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1572,16 +1572,37 @@ enum {
TGL_REVID_D0,
};
-extern const struct i915_rev_steppings tgl_uy_revids[];
-extern const struct i915_rev_steppings tgl_revids[];
+extern const struct i915_rev_steppings tgl_uy_revids[4];
+extern const struct i915_rev_steppings tgl_revids[2];
+
+#define TGL_UY_REVID_RANGE(revid) \
+ ((revid) < ARRAY_SIZE(tgl_uy_revids))
+
+#define TGL_REVID_RANGE(revid) \
+ ((revid) < ARRAY_SIZE(tgl_revids))
static inline const struct i915_rev_steppings *
tgl_revids_get(struct drm_i915_private *dev_priv)
{
- if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv))
- return tgl_uy_revids;
- else
- return tgl_revids;
+ const u8 revid = INTEL_REVID(dev_priv);
+
+ if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
+ if (TGL_UY_REVID_RANGE(revid)) {
+ return tgl_uy_revids + revid;
+ } else {
+ drm_dbg_kms(_priv->drm,
+ "Unsupported SOC stepping found %u, using
%lu instead\n",
+ revid, ARRAY_SIZE(tgl_uy_revids) - 1);
+ return tgl_uy_revids + (ARRAY_SIZE(tgl_uy_revids) - 1);
+ }
+ } else if (TGL_REVID_RANGE(revid)) {
+ return tgl_revids + revid;
+ } else {
+ drm_dbg_kms(_priv->drm,
+ "Unsupported SOC stepping found %u, using %lu
instead\n",
+ revid, ARRAY_SIZE(tgl_revids) - 1);
+ return tgl_uy_revids + (ARRAY_SIZE(tgl_revids) - 1);
+ }
}
#define IS_TGL_DISP_REVID(p, since, until) \
@@ -1591,12 +1612,14 @@ tgl_revids_get(struct drm_i915_private *dev_priv)
#define IS_TGL_UY_GT_REVID(p, since, until) \
((IS_TGL_U(p) || IS_TGL_Y(p)) && \
+TGL_UY_REVID_RANGE(INTEL_REVID(p)) && \
tgl_uy_revids->gt_stepping >= (since) && \
tgl_uy_revids->gt_stepping <= (until))
#define IS_TGL_GT_REVID(p, since, until) \
(IS_TIGERLAKE(p) && \
!(IS_TGL_U(p) || IS_TGL_Y(p)) && \
+TGL_REVID_RANGE(INTEL_REVID(p)) && \
tgl_revids->gt_stepping >= (since) && \
tgl_revids->gt_stepping <= (until))
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/21] drm/i915/adl_s: MCHBAR memory info registers are moved
On Tue, Nov 17, 2020 at 10:50:24AM -0800, Aditya Swarup wrote:
From: Caz Yokoyama
The crwebview indicates on ADL-S that some of our MCHBAR
registers have moved from their traditional 0x50XX offsets to
new locations. The meaning and bit layout of the registers
remain same.
Cc: Lucas De Marchi
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Imre Deak
Cc: Matt Roper
Signed-off-by: Yokoyama, Caz
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_dram.c | 18 +++---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4c8d0d84af6a..6abba59592f7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10863,6 +10863,8 @@ enum skl_power_gate {
#define SKL_DRAM_DDR_TYPE_LPDDR3 (2 << 0)
#define SKL_DRAM_DDR_TYPE_LPDDR4 (3 << 0)
+#define ADLS_MAD_INTER_CHANNEL_0_0_0_MCHBAR _MMIO(MCHBAR_MIRROR_BASE_SNB +
0x6048)
should be single space after define
Lucas De Marchi
+
#define SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN_MMIO(MCHBAR_MIRROR_BASE_SNB +
0x500C)
#define SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN_MMIO(MCHBAR_MIRROR_BASE_SNB +
0x5010)
#define SKL_DRAM_S_SHIFT 16
@@ -10890,6 +10892,9 @@ enum skl_power_gate {
#define CNL_DRAM_RANK_3(0x2 << 9)
#define CNL_DRAM_RANK_4(0x3 << 9)
+#define ADLS_MAD_DIMM_CH0_0_0_0_MCHBAR _MMIO(MCHBAR_MIRROR_BASE_SNB +
0x6054)
+#define ADLS_MAD_DIMM_CH1_0_0_0_MCHBAR _MMIO(MCHBAR_MIRROR_BASE_SNB +
0x6058)
+
/* Please see hsw_read_dcomp() and hsw_write_dcomp() before using this register,
* since on HSW we can't write to it using I915_WRITE. */
#define D_COMP_HSW _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5F0C)
diff --git a/drivers/gpu/drm/i915/intel_dram.c
b/drivers/gpu/drm/i915/intel_dram.c
index 4754296a250e..e7427e5f4130 100644
--- a/drivers/gpu/drm/i915/intel_dram.c
+++ b/drivers/gpu/drm/i915/intel_dram.c
@@ -184,13 +184,21 @@ skl_dram_get_channels_info(struct drm_i915_private *i915)
u32 val;
int ret;
- val = intel_uncore_read(>uncore,
+ if (IS_ALDERLAKE_S(i915))
+ val = intel_uncore_read(>uncore,
+ ADLS_MAD_DIMM_CH0_0_0_0_MCHBAR);
+ else
+ val = intel_uncore_read(>uncore,
SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
ret = skl_dram_get_channel_info(i915, , 0, val);
if (ret == 0)
dram_info->num_channels++;
- val = intel_uncore_read(>uncore,
+ if (IS_ALDERLAKE_S(i915))
+ val = intel_uncore_read(>uncore,
+ ADLS_MAD_DIMM_CH1_0_0_0_MCHBAR);
+ else
+ val = intel_uncore_read(>uncore,
SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
ret = skl_dram_get_channel_info(i915, , 1, val);
if (ret == 0)
@@ -231,7 +239,11 @@ skl_get_dram_type(struct drm_i915_private *i915)
{
u32 val;
- val = intel_uncore_read(>uncore,
+ if (IS_ALDERLAKE_S(i915))
+ val = intel_uncore_read(>uncore,
+ ADLS_MAD_INTER_CHANNEL_0_0_0_MCHBAR);
+ else
+ val = intel_uncore_read(>uncore,
SKL_MAD_INTER_CHANNEL_0_0_0_MCHBAR_MCMAIN);
switch (val & SKL_DRAM_DDR_TYPE_MASK) {
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.
Though we have never claimed to have a completely fair scheduler, that
is what is expected.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Ramalingam C
---
tests/i915/gem_exec_schedule.c | 847 +
1 file changed, 847 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index f23d63ac3..d888efcd7 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2516,6 +2517,819 @@ static void measure_semaphore_power(int i915)
rapl_close();
}
+static int read_timestamp_frequency(int i915)
+{
+ int value = 0;
+ drm_i915_getparam_t gp = {
+ .value = ,
+ .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+ };
+ ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+ return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+ return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ctx_ticks(int i915, uint64_t ns)
+{
+ int f = read_timestamp_frequency(i915);
+ if (intel_gen(intel_get_drm_devid(i915)) == 11)
+ f = 1250; /* icl!!! are you feeling alright? CTX vs CS */
+ return div64_u64_round_up(ns * f, NSEC_PER_SEC);
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+ return div64_u64_round_up(ticks * NSEC_PER_SEC,
+ read_timestamp_frequency(i915));
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x) MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define MI_MATH_NOOP MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define MI_MATH_ADD MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define MI_MATH_SUB MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define MI_MATH_AND MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define MI_MATH_XOR MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define MI_MATH_STORE(op1, op2) MI_MATH_INSTR(0x180, op1, op2)
+#define MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define MI_MATH_REG(x)(x)
+#define MI_MATH_REG_SRCA 0x20
+#define MI_MATH_REG_SRCB 0x21
+#define MI_MATH_REG_ACCU 0x31
+#define MI_MATH_REG_ZF0x32
+#define MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+ const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+ const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define RUNTIME (base + 0x3a8)
+ enum { START_TS, NOW_TS };
+ uint32_t *map, *cs, *jmp;
+
+ igt_require(base);
+
+ /* Loop until CTX_TIMESTAMP - initial > @ns */
+
+ cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+ *cs++ = MI_LOAD_REGISTER_IMM;
+ *cs++ = CS_GPR(START_TS) + 4;
+ *cs++ = 0;
+ *cs++ = MI_LOAD_REGISTER_REG;
+ *cs++ = RUNTIME;
+ *cs++ = CS_GPR(START_TS);
+
+ while (offset_in_page(cs) & 63)
+ *cs++ = 0;
+ jmp = cs;
+
+ *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+ *cs++ = MI_LOAD_REGISTER_IMM;
+ *cs++ = CS_GPR(NOW_TS) + 4;
+ *cs++ = 0;
+ *cs++ = MI_LOAD_REGISTER_REG;
+ *cs++ = RUNTIME;
+ *cs++ = CS_GPR(NOW_TS);
+
+ /* delta = now - start; inverted to match COND_BBE */
+ *cs++ = MI_MATH(4);
+ *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+ *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+ *cs++ = MI_MATH_SUB;
+ *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+ /* Save delta for reading by COND_BBE */
+ *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+ *cs++ = CS_GPR(NOW_TS);
+
[Intel-gfx] [PATCH i-g-t 1/2] tools/intel_gpu_top: Include total package power
With integrated graphics the TDP is shared between the gpu and the cpu,
knowing the total energy consumed by the package is relevant to
understanding throttling.
v2: Tidy integration by eliminating struct rapl and improve output
formatting.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 218 +-
1 file changed, 130 insertions(+), 88 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 86de09aa9..0a49cfecc 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -50,10 +50,12 @@ struct pmu_pair {
};
struct pmu_counter {
- bool present;
+ uint64_t type;
uint64_t config;
unsigned int idx;
struct pmu_pair val;
+ double scale;
+ bool present;
};
struct engine {
@@ -79,8 +81,8 @@ struct engines {
struct pmu_pair ts;
int rapl_fd;
- double rapl_scale;
- const char *rapl_unit;
+ struct pmu_counter r_gpu, r_pkg;
+ unsigned int num_rapl;
int imc_fd;
double imc_reads_scale;
@@ -92,7 +94,6 @@ struct engines {
struct pmu_counter freq_act;
struct pmu_counter irq;
struct pmu_counter rc6;
- struct pmu_counter rapl;
struct pmu_counter imc_reads;
struct pmu_counter imc_writes;
@@ -108,6 +109,109 @@ struct engines {
};
+__attribute__((format(scanf,3,4)))
+static int igt_sysfs_scanf(int dir, const char *attr, const char *fmt, ...)
+{
+ FILE *file;
+ int fd;
+ int ret = -1;
+
+ fd = openat(dir, attr, O_RDONLY);
+ if (fd < 0)
+ return -1;
+
+ file = fdopen(fd, "r");
+ if (file) {
+ va_list ap;
+
+ va_start(ap, fmt);
+ ret = vfscanf(file, fmt, ap);
+ va_end(ap);
+
+ fclose(file);
+ } else {
+ close(fd);
+ }
+
+ return ret;
+}
+
+static int rapl_parse(struct pmu_counter *pmu, const char *str)
+{
+ locale_t locale, oldlocale;
+ bool result = true;
+ char buf[128] = {};
+ int dir;
+
+ dir = open("/sys/devices/power", O_RDONLY);
+ if (dir < 0)
+ return -errno;
+
+ /* Replace user environment with plain C to match kernel format */
+ locale = newlocale(LC_ALL, "C", 0);
+ oldlocale = uselocale(locale);
+
+ result &= igt_sysfs_scanf(dir, "type", "%"PRIu64, >type) == 1;
+
+ snprintf(buf, sizeof(buf) - 1, "events/energy-%s", str);
+ result &= igt_sysfs_scanf(dir, buf, "event=%"PRIx64, >config) == 1;
+
+ snprintf(buf, sizeof(buf) - 1, "events/energy-%s.scale", str);
+ result &= igt_sysfs_scanf(dir, buf, "%lf", >scale) == 1;
+
+ snprintf(buf, sizeof(buf) - 1, "events/energy-%s.unit", str);
+ if (igt_sysfs_scanf(dir, buf, "%127s", buf) == 1 &&
+ strcmp(buf, "Joules"))
+ fprintf(stderr, "Unexpected units for RAPL %s: found %s\n",
+ str, buf);
+
+ uselocale(oldlocale);
+ freelocale(locale);
+
+ close(dir);
+
+ if (!result)
+ return -EINVAL;
+
+ if (isnan(pmu->scale) || !pmu->scale)
+ return -ERANGE;
+
+ return 0;
+}
+
+static void
+rapl_open(struct pmu_counter *pmu,
+ const char *domain,
+ struct engines *engines)
+{
+ int fd;
+
+ if (rapl_parse(pmu, domain) < 0)
+ return;
+
+ fd = igt_perf_open_group(pmu->type, pmu->config, engines->rapl_fd);
+ if (fd < 0)
+ return;
+
+ if (engines->rapl_fd == -1)
+ engines->rapl_fd = fd;
+
+ pmu->idx = engines->num_rapl++;
+ pmu->present = true;
+}
+
+static void gpu_power_open(struct pmu_counter *pmu,
+ struct engines *engines)
+{
+ rapl_open(pmu, "gpu", engines);
+}
+
+static void pkg_power_open(struct pmu_counter *pmu,
+ struct engines *engines)
+{
+ rapl_open(pmu, "pkg", engines);
+}
+
static uint64_t
get_pmu_config(int dirfd, const char *name, const char *counter)
{
@@ -357,38 +461,6 @@ static double filename_to_double(const char *filename)
return v;
}
-#define RAPL_ROOT "/sys/devices/power/"
-#define RAPL_EVENT "/sys/devices/power/events/"
-
-static uint64_t rapl_type_id(void)
-{
- return filename_to_u64(RAPL_ROOT "type", 10);
-}
-
-static uint64_t rapl_gpu_power(void)
-{
- return filename_to_u64(RAPL_EVENT "energy-gpu", 0);
-}
-
-static double rapl_gpu_power_scale(void)
-{
- return filename_to_double(RAPL_EVENT "energy-gpu.scale");
-}
-
-static const char *rapl_gpu_power_unit(void)
-{
- char buf[32];
-
- if (filename_to_buf(RAPL_EVENT "energy-gpu.unit",
- buf, sizeof(buf)) == 0)
- if (!strcmp(buf, "Joules"))
- return strdup("Watts");
- else
- return strdup(buf);
[Intel-gfx] [PATCH i-g-t 2/2] tools/intel_gpu_top: Consolidate imc to use pmu_counter
Follow the same pattern as rapl for imc, and consolidate everything to
work on struct pmu_counter.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 249 ++
1 file changed, 82 insertions(+), 167 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 0a49cfecc..9af1c29b6 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -55,6 +55,7 @@ struct pmu_counter {
unsigned int idx;
struct pmu_pair val;
double scale;
+ const char *units;
bool present;
};
@@ -85,17 +86,14 @@ struct engines {
unsigned int num_rapl;
int imc_fd;
- double imc_reads_scale;
- const char *imc_reads_unit;
- double imc_writes_scale;
- const char *imc_writes_unit;
+ struct pmu_counter imc_reads;
+ struct pmu_counter imc_writes;
+ unsigned int num_imc;
struct pmu_counter freq_req;
struct pmu_counter freq_act;
struct pmu_counter irq;
struct pmu_counter rc6;
- struct pmu_counter imc_reads;
- struct pmu_counter imc_writes;
bool discrete;
char *device;
@@ -400,146 +398,93 @@ static struct engines *discover_engines(char *device)
return engines;
}
-static int
-filename_to_buf(const char *filename, char *buf, unsigned int bufsize)
-{
- int fd, err;
- ssize_t ret;
-
- fd = open(filename, O_RDONLY);
- if (fd < 0)
- return -1;
-
- ret = read(fd, buf, bufsize - 1);
- err = errno;
- close(fd);
- if (ret < 1) {
- errno = ret < 0 ? err : ENOMSG;
-
- return -1;
- }
+#define _open_pmu(type, cnt, pmu, fd) \
+({ \
+ int fd__; \
+\
+ fd__ = igt_perf_open_group((type), (pmu)->config, (fd)); \
+ if (fd__ >= 0) { \
+ if ((fd) == -1) \
+ (fd) = fd__; \
+ (pmu)->present = true; \
+ (pmu)->idx = (cnt)++; \
+ } \
+\
+ fd__; \
+})
- if (ret > 1 && buf[ret - 1] == '\n')
- buf[ret - 1] = '\0';
- else
- buf[ret] = '\0';
+static int imc_parse(struct pmu_counter *pmu, const char *str)
+{
+ locale_t locale, oldlocale;
+ bool result = true;
+ char buf[128] = {};
+ int dir;
- return 0;
-}
+ dir = open("/sys/devices/uncore_imc", O_RDONLY);
+ if (dir < 0)
+ return -errno;
-static uint64_t filename_to_u64(const char *filename, int base)
-{
- char buf[64], *b;
+ /* Replace user environment with plain C to match kernel format */
+ locale = newlocale(LC_ALL, "C", 0);
+ oldlocale = uselocale(locale);
- if (filename_to_buf(filename, buf, sizeof(buf)))
- return 0;
+ result &= igt_sysfs_scanf(dir, "type", "%"PRIu64, >type) == 1;
- /*
-* Handle both single integer and key=value formats by skipping
-* leading non-digits.
-*/
- b = buf;
- while (*b && !isdigit(*b))
- b++;
+ snprintf(buf, sizeof(buf) - 1, "events/%s", str);
+ result &= igt_sysfs_scanf(dir, buf, "event=%"PRIx64, >config) == 1;
- return strtoull(b, NULL, base);
-}
+ snprintf(buf, sizeof(buf) - 1, "events/%s.scale", str);
+ result &= igt_sysfs_scanf(dir, buf, "%lf", >scale) == 1;
-static double filename_to_double(const char *filename)
-{
- char *oldlocale;
- char buf[80];
- double v;
+ snprintf(buf, sizeof(buf) - 1, "events/%s.unit", str);
+ result &= igt_sysfs_scanf(dir, buf, "%127s", buf) == 1;
+ pmu->units = strdup(buf);
- if (filename_to_buf(filename, buf, sizeof(buf)))
- return 0;
+ uselocale(oldlocale);
+ freelocale(locale);
- oldlocale = setlocale(LC_ALL, "C");
- v = strtod(buf, NULL);
- setlocale(LC_ALL, oldlocale);
+ close(dir);
- return v;
-}
+ if (!result)
+ return -EINVAL;
-#define IMC_ROOT "/sys/devices/uncore_imc/"
-#define IMC_EVENT "/sys/devices/uncore_imc/events/"
+ if (isnan(pmu->scale) || !pmu->scale)
+ return -ERANGE;
-static uint64_t imc_type_id(void)
-{
- return filename_to_u64(IMC_ROOT "type", 10);
+ return 0;
}
-static uint64_t imc_data_reads(void)
+static void
+imc_open(struct pmu_counter *pmu,
+const char *domain,
+struct engines *engines)
{
- return filename_to_u64(IMC_EVENT "data_reads", 0);
-}
+ int fd;
-static double imc_data_reads_scale(void)
-{
- return filename_to_double(IMC_EVENT "data_reads.scale");
-}
+ if (imc_parse(pmu, domain) < 0)
+ return;
-static const char *imc_data_reads_unit(void)
-{
- char buf[32];
+ fd = igt_perf_open_group(pmu->type, pmu->config, engines->imc_fd);
+ if (fd < 0)
+ return;
- if
[Intel-gfx] [PATCH i-g-t 2/2] tools/intel_gpu_top: Consolidate imc to use pmu_counter
Follow the same pattern as rapl for imc, and consolidate everything to
work on struct pmu_counter.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 249 ++
1 file changed, 82 insertions(+), 167 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 0a49cfecc..9af1c29b6 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -55,6 +55,7 @@ struct pmu_counter {
unsigned int idx;
struct pmu_pair val;
double scale;
+ const char *units;
bool present;
};
@@ -85,17 +86,14 @@ struct engines {
unsigned int num_rapl;
int imc_fd;
- double imc_reads_scale;
- const char *imc_reads_unit;
- double imc_writes_scale;
- const char *imc_writes_unit;
+ struct pmu_counter imc_reads;
+ struct pmu_counter imc_writes;
+ unsigned int num_imc;
struct pmu_counter freq_req;
struct pmu_counter freq_act;
struct pmu_counter irq;
struct pmu_counter rc6;
- struct pmu_counter imc_reads;
- struct pmu_counter imc_writes;
bool discrete;
char *device;
@@ -400,146 +398,93 @@ static struct engines *discover_engines(char *device)
return engines;
}
-static int
-filename_to_buf(const char *filename, char *buf, unsigned int bufsize)
-{
- int fd, err;
- ssize_t ret;
-
- fd = open(filename, O_RDONLY);
- if (fd < 0)
- return -1;
-
- ret = read(fd, buf, bufsize - 1);
- err = errno;
- close(fd);
- if (ret < 1) {
- errno = ret < 0 ? err : ENOMSG;
-
- return -1;
- }
+#define _open_pmu(type, cnt, pmu, fd) \
+({ \
+ int fd__; \
+\
+ fd__ = igt_perf_open_group((type), (pmu)->config, (fd)); \
+ if (fd__ >= 0) { \
+ if ((fd) == -1) \
+ (fd) = fd__; \
+ (pmu)->present = true; \
+ (pmu)->idx = (cnt)++; \
+ } \
+\
+ fd__; \
+})
- if (ret > 1 && buf[ret - 1] == '\n')
- buf[ret - 1] = '\0';
- else
- buf[ret] = '\0';
+static int imc_parse(struct pmu_counter *pmu, const char *str)
+{
+ locale_t locale, oldlocale;
+ bool result = true;
+ char buf[128] = {};
+ int dir;
- return 0;
-}
+ dir = open("/sys/devices/uncore_imc", O_RDONLY);
+ if (dir < 0)
+ return -errno;
-static uint64_t filename_to_u64(const char *filename, int base)
-{
- char buf[64], *b;
+ /* Replace user environment with plain C to match kernel format */
+ locale = newlocale(LC_ALL, "C", 0);
+ oldlocale = uselocale(locale);
- if (filename_to_buf(filename, buf, sizeof(buf)))
- return 0;
+ result &= igt_sysfs_scanf(dir, "type", "%"PRIu64, >type) == 1;
- /*
-* Handle both single integer and key=value formats by skipping
-* leading non-digits.
-*/
- b = buf;
- while (*b && !isdigit(*b))
- b++;
+ snprintf(buf, sizeof(buf) - 1, "events/%s", str);
+ result &= igt_sysfs_scanf(dir, buf, "event=%"PRIx64, >config) == 1;
- return strtoull(b, NULL, base);
-}
+ snprintf(buf, sizeof(buf) - 1, "events/%s.scale", str);
+ result &= igt_sysfs_scanf(dir, buf, "%lf", >scale) == 1;
-static double filename_to_double(const char *filename)
-{
- char *oldlocale;
- char buf[80];
- double v;
+ snprintf(buf, sizeof(buf) - 1, "events/%s.unit", str);
+ result &= igt_sysfs_scanf(dir, buf, "%127s", buf) == 1;
+ pmu->units = strdup(buf);
- if (filename_to_buf(filename, buf, sizeof(buf)))
- return 0;
+ uselocale(oldlocale);
+ freelocale(locale);
- oldlocale = setlocale(LC_ALL, "C");
- v = strtod(buf, NULL);
- setlocale(LC_ALL, oldlocale);
+ close(dir);
- return v;
-}
+ if (!result)
+ return -EINVAL;
-#define IMC_ROOT "/sys/devices/uncore_imc/"
-#define IMC_EVENT "/sys/devices/uncore_imc/events/"
+ if (isnan(pmu->scale) || !pmu->scale)
+ return -ERANGE;
-static uint64_t imc_type_id(void)
-{
- return filename_to_u64(IMC_ROOT "type", 10);
+ return 0;
}
-static uint64_t imc_data_reads(void)
+static void
+imc_open(struct pmu_counter *pmu,
+const char *domain,
+struct engines *engines)
{
- return filename_to_u64(IMC_EVENT "data_reads", 0);
-}
+ int fd;
-static double imc_data_reads_scale(void)
-{
- return filename_to_double(IMC_EVENT "data_reads.scale");
-}
+ if (imc_parse(pmu, domain) < 0)
+ return;
-static const char *imc_data_reads_unit(void)
-{
- char buf[32];
+ fd = igt_perf_open_group(pmu->type, pmu->config, engines->imc_fd);
+ if (fd < 0)
+ return;
- if
[Intel-gfx] [PATCH i-g-t 1/2] tools/intel_gpu_top: Include total package power
With integrated graphics the TDP is shared between the gpu and the cpu,
knowing the total energy consumed by the package is relevant to
understanding throttling.
v2: Tidy integration by eliminating struct rapl and improve output
formatting.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 218 +-
1 file changed, 130 insertions(+), 88 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 86de09aa9..0a49cfecc 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -50,10 +50,12 @@ struct pmu_pair {
};
struct pmu_counter {
- bool present;
+ uint64_t type;
uint64_t config;
unsigned int idx;
struct pmu_pair val;
+ double scale;
+ bool present;
};
struct engine {
@@ -79,8 +81,8 @@ struct engines {
struct pmu_pair ts;
int rapl_fd;
- double rapl_scale;
- const char *rapl_unit;
+ struct pmu_counter r_gpu, r_pkg;
+ unsigned int num_rapl;
int imc_fd;
double imc_reads_scale;
@@ -92,7 +94,6 @@ struct engines {
struct pmu_counter freq_act;
struct pmu_counter irq;
struct pmu_counter rc6;
- struct pmu_counter rapl;
struct pmu_counter imc_reads;
struct pmu_counter imc_writes;
@@ -108,6 +109,109 @@ struct engines {
};
+__attribute__((format(scanf,3,4)))
+static int igt_sysfs_scanf(int dir, const char *attr, const char *fmt, ...)
+{
+ FILE *file;
+ int fd;
+ int ret = -1;
+
+ fd = openat(dir, attr, O_RDONLY);
+ if (fd < 0)
+ return -1;
+
+ file = fdopen(fd, "r");
+ if (file) {
+ va_list ap;
+
+ va_start(ap, fmt);
+ ret = vfscanf(file, fmt, ap);
+ va_end(ap);
+
+ fclose(file);
+ } else {
+ close(fd);
+ }
+
+ return ret;
+}
+
+static int rapl_parse(struct pmu_counter *pmu, const char *str)
+{
+ locale_t locale, oldlocale;
+ bool result = true;
+ char buf[128] = {};
+ int dir;
+
+ dir = open("/sys/devices/power", O_RDONLY);
+ if (dir < 0)
+ return -errno;
+
+ /* Replace user environment with plain C to match kernel format */
+ locale = newlocale(LC_ALL, "C", 0);
+ oldlocale = uselocale(locale);
+
+ result &= igt_sysfs_scanf(dir, "type", "%"PRIu64, >type) == 1;
+
+ snprintf(buf, sizeof(buf) - 1, "events/energy-%s", str);
+ result &= igt_sysfs_scanf(dir, buf, "event=%"PRIx64, >config) == 1;
+
+ snprintf(buf, sizeof(buf) - 1, "events/energy-%s.scale", str);
+ result &= igt_sysfs_scanf(dir, buf, "%lf", >scale) == 1;
+
+ snprintf(buf, sizeof(buf) - 1, "events/energy-%s.unit", str);
+ if (igt_sysfs_scanf(dir, buf, "%127s", buf) == 1 &&
+ strcmp(buf, "Joules"))
+ fprintf(stderr, "Unexpected units for RAPL %s: found %s\n",
+ str, buf);
+
+ uselocale(oldlocale);
+ freelocale(locale);
+
+ close(dir);
+
+ if (!result)
+ return -EINVAL;
+
+ if (isnan(pmu->scale) || !pmu->scale)
+ return -ERANGE;
+
+ return 0;
+}
+
+static void
+rapl_open(struct pmu_counter *pmu,
+ const char *domain,
+ struct engines *engines)
+{
+ int fd;
+
+ if (rapl_parse(pmu, domain) < 0)
+ return;
+
+ fd = igt_perf_open_group(pmu->type, pmu->config, engines->rapl_fd);
+ if (fd < 0)
+ return;
+
+ if (engines->rapl_fd == -1)
+ engines->rapl_fd = fd;
+
+ pmu->idx = engines->num_rapl++;
+ pmu->present = true;
+}
+
+static void gpu_power_open(struct pmu_counter *pmu,
+ struct engines *engines)
+{
+ rapl_open(pmu, "gpu", engines);
+}
+
+static void pkg_power_open(struct pmu_counter *pmu,
+ struct engines *engines)
+{
+ rapl_open(pmu, "pkg", engines);
+}
+
static uint64_t
get_pmu_config(int dirfd, const char *name, const char *counter)
{
@@ -357,38 +461,6 @@ static double filename_to_double(const char *filename)
return v;
}
-#define RAPL_ROOT "/sys/devices/power/"
-#define RAPL_EVENT "/sys/devices/power/events/"
-
-static uint64_t rapl_type_id(void)
-{
- return filename_to_u64(RAPL_ROOT "type", 10);
-}
-
-static uint64_t rapl_gpu_power(void)
-{
- return filename_to_u64(RAPL_EVENT "energy-gpu", 0);
-}
-
-static double rapl_gpu_power_scale(void)
-{
- return filename_to_double(RAPL_EVENT "energy-gpu.scale");
-}
-
-static const char *rapl_gpu_power_unit(void)
-{
- char buf[32];
-
- if (filename_to_buf(RAPL_EVENT "energy-gpu.unit",
- buf, sizeof(buf)) == 0)
- if (!strcmp(buf, "Joules"))
- return strdup("Watts");
- else
- return strdup(buf);
Re: [Intel-gfx] [PATCH] drm/i915: Correct location of Wa_1408615072
It seems this was forgotten? We do have it for DG1, but for TGL it's not
being applied.
Lucas De Marchi
On Fri, Jul 24, 2020 at 02:21:03PM -0700, Daniele Ceraolo Spurio wrote:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
On 7/10/2020 2:32 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The above workaround was added as an engine workaround not a GT
workaround. Moved it to the correct location.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 5726cd0a37e0..a6548a77439c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1191,6 +1191,12 @@ tgl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
wa_write_or(wal,
SLICE_UNIT_LEVEL_CLKGATE,
L3_CLKGATE_DIS | L3_CR2X_CLKGATE_DIS);
+
+ /* Wa_1408615072:tgl[a0] */
+ /* Empirical testing shows this register is unaffected by engine reset.
*/
+ if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0))
+ wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
+ VSUNIT_CLKGATE_DIS_TGL);
}
static void
@@ -1648,10 +1654,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_write_or(wal,
GEN7_SARCHKMD,
GEN7_DISABLE_SAMPLER_PREFETCH);
-
- /* Wa_1408615072:tgl */
- wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
- VSUNIT_CLKGATE_DIS_TGL);
}
if (IS_TIGERLAKE(i915)) {
___
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.BUILD: failure for drm/i915/display: Record the plane update times for debugging (rev3)
== Series Details == Series: drm/i915/display: Record the plane update times for debugging (rev3) URL : https://patchwork.freedesktop.org/series/84174/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/display/intel_display_debugfs.o drivers/gpu/drm/i915/display/intel_display_debugfs.c: In function ‘crtc_vblank_info’: drivers/gpu/drm/i915/display/intel_display_debugfs.c:907:6: error: ‘VBLANK_EVASION_TIME_US’ undeclared (first use in this function); did you mean ‘DMAR_OPERATION_TIMEOUT’? VBLANK_EVASION_TIME_US, crtc->debug.over_vbl_time); ^~ DMAR_OPERATION_TIMEOUT drivers/gpu/drm/i915/display/intel_display_debugfs.c:907:6: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:283: recipe for target 'drivers/gpu/drm/i915/display/intel_display_debugfs.o' failed make[4]: *** [drivers/gpu/drm/i915/display/intel_display_debugfs.o] Error 1 scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1799: recipe for target 'drivers' failed make: *** [drivers] Error 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 [1/4] drm/i915: Track logically enabled planes for hw state
== Series Details == Series: series starting with [1/4] drm/i915: Track logically enabled planes for hw state URL : https://patchwork.freedesktop.org/series/84230/ State : success == Summary == CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18970 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/index.html New tests - New tests have been introduced between CI_DRM_9385 and Patchwork_18970: ### New CI tests (1) ### * boot: - Statuses : 39 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_18970 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 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@gem_flink_ba...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/fi-tgl-y/igt@gem_flink_ba...@basic.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-cfl-8109u: [DMESG-WARN][3] ([i915#262]) -> [PASS][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-kefka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@prime_vgem@basic-read: - fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@prime_v...@basic-read.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/fi-tgl-y/igt@prime_v...@basic-read.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 39) -- Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_9385 -> Patchwork_18970 CI-20190529: 20190529 CI_DRM_9385: 3d37e624f60f40cea80e784617686ae2917e9b01 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5870: 08b13995b85df26a77212e4fb21fd772976ef33c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18970: 2475fb19684c58da0b3e62794aba1e349dd5c6a0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2475fb19684c drm/i915: Call kill_bigjoiner_slave() earlier eb9f9aa0b305 drm/i915: Properly flag modesets for all bigjoiner pipes c836548c46a2 drm/i915: Add intel_atomic_add_affected_planes() 8ed43f2396aa drm/i915: Track logically enabled planes for hw state == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18970/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 1/2] drm/i915/display/tgl: Disable FBC with PSR2
On Fri, 2020-11-20 at 01:06 +0530, Uma Shankar wrote: > There are some corner cases wrt underrun when we enable > FBC with PSR2 on TGL. Recommendation from hardware is to > keep this combination disabled. > > Bspec: 50422 HSD: 14010260002 > > v2: Added psr2 enabled check from crtc_state (Anshuman) > Added Bspec link and HSD referneces (Jose) > > v3: Moved the logic to disable fbc to intel_fbc_update_state_cache > and removed the crtc->config usages, as per Ville's recommendation. > > Signed-off-by: Uma Shankar > --- > drivers/gpu/drm/i915/display/intel_fbc.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c > b/drivers/gpu/drm/i915/display/intel_fbc.c > index a5b072816a7b..cb29c6f068f9 100644 > --- a/drivers/gpu/drm/i915/display/intel_fbc.c > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c > @@ -701,6 +701,15 @@ static void intel_fbc_update_state_cache(struct > intel_crtc *crtc, > struct drm_framebuffer *fb = plane_state->hw.fb; > > > > > cache->plane.visible = plane_state->uapi.visible; > + > + /* > + * Tigerlake is not supporting FBC with PSR2. > + * Recommendation is to keep this combination disabled > + * Bspec: 50422 HSD: 14010260002 > + */ > + if (crtc_state->has_psr2 && IS_TIGERLAKE(dev_priv)) > + cache->plane.visible = false; Looks like a hack to me, would be better add a psr2 variable in intel_fbc_state_cache. We also would need have a PSR2 reason set in no_fbc_reason and handle it in IGT. > + > if (!cache->plane.visible) > return; > > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
Hi Chris,
On Tue, Nov 24, 2020 at 06:35:21PM +, Chris Wilson wrote:
> We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> the frequency we intend to restart the GT with. Since the two workloads
> are likely related (e.g. a compositor rendering every 16ms), we want to
> carry the frequency and load information from across the idling.
> However, we do also need to update the frequencies so that workloads
> that run for less than 1ms are autotuned by RPS (otherwise we leave
> compositors running at max clocks, draining excess power). Conversely,
> if we try to run too slowly, the next workload has to run longer. Since
> there is a hysteresis in the power graph, below a certain frequency
> running a short workload for longer consumes more energy than running it
> slightly higher for less time. The exact balance point is unknown
> beforehand, but measurements with 30fps media playback indicate that RPe
> is a better choice.
>
> Reported-by: Edward Baker
> Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> Signed-off-by: Chris Wilson
> Cc: Edward Baker
> Cc: Andi Shyti
> Cc: Lyude Paul
> Cc: # v5.8+
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index b13e7845d483..f74d5e09e176 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
> adj = -2;
> rps->last_adj = adj;
> rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
> + if (rps->cur_freq < rps->efficient_freq) {
> + rps->cur_freq = rps->efficient_freq;
> + rps->last_adj = 0;
> + }
looks OK to me, makes sense:
Reviewed-by: Andi Shyti
Thanks,
Andi
___
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 [1/4] drm/i915: Track logically enabled planes for hw state
== Series Details == Series: series starting with [1/4] drm/i915: Track logically enabled planes for hw state URL : https://patchwork.freedesktop.org/series/84230/ 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:1312:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int [usertype] *s +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1447:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1501:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:864:16: warning: trying to copy expression type 31 +./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
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color
== Series Details ==
Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel
Gen 12 render compression with Clear Color
URL : https://patchwork.freedesktop.org/series/84183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9378_full -> Patchwork_18961_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_18961_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_userptr_blits@vma-merge}:
- shard-snb: [FAIL][1] ([i915#1635]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-snb2/igt@gem_userptr_bl...@vma-merge.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-snb6/igt@gem_userptr_bl...@vma-merge.html
New tests
-
New tests have been introduced between CI_DRM_9378_full and
Patchwork_18961_full:
### New CI tests (1) ###
* boot:
- Statuses : 200 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18961_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-hsw: [PASS][3] -> [FAIL][4] ([i915#2389])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-hsw6/igt@gem_exec_reloc@basic-many-act...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-hsw5/igt@gem_exec_reloc@basic-many-act...@rcs0.html
* igt@i915_module_load@reload-with-fault-injection:
- shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +16
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-skl2/igt@i915_module_l...@reload-with-fault-injection.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-skl2/igt@i915_module_l...@reload-with-fault-injection.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#454])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-iclb7/igt@i915_pm...@dc6-psr.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-iclb2/igt@i915_pm...@dc6-psr.html
* igt@i915_pm_rpm@fences-dpms:
- shard-hsw: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +2
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-hsw1/igt@i915_pm_...@fences-dpms.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-hsw1/igt@i915_pm_...@fences-dpms.html
* igt@kms_cursor_crc@pipe-a-cursor-64x64-onscreen:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#54]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-64x64-onscreen.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-skl2/igt@kms_cursor_...@pipe-a-cursor-64x64-onscreen.html
* igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#2346])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-skl1/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-skl6/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html
* igt@kms_cursor_legacy@short-flip-before-cursor-atomic-transitions:
- shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-tglb8/igt@kms_cursor_leg...@short-flip-before-cursor-atomic-transitions.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-tglb8/igt@kms_cursor_leg...@short-flip-before-cursor-atomic-transitions.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1:
- shard-skl: [PASS][17] -> [FAIL][18] ([i915#2122]) +1 similar
issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-skl10/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-skl1/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-render:
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#49])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/shard-glk5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-render.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/shard-glk3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-render.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-pgflip-blt:
- shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +2
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Track logically enabled planes for hw state
== Series Details == Series: series starting with [1/4] drm/i915: Track logically enabled planes for hw state URL : https://patchwork.freedesktop.org/series/84230/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8ed43f2396aa drm/i915: Track logically enabled planes for hw state c836548c46a2 drm/i915: Add intel_atomic_add_affected_planes() eb9f9aa0b305 drm/i915: Properly flag modesets for all bigjoiner pipes -:68: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #68: FILE: drivers/gpu/drm/i915/display/intel_display.c:15680: + intel_atomic_get_new_crtc_state(state, new_crtc_state->bigjoiner_linked_crtc); total: 0 errors, 1 warnings, 0 checks, 55 lines checked 2475fb19684c drm/i915: Call kill_bigjoiner_slave() earlier ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Move display initialization
== Series Details ==
Series: Move display initialization
URL : https://patchwork.freedesktop.org/series/84225/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18969
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/index.html
New tests
-
New tests have been introduced between CI_DRM_9385 and Patchwork_18969:
### New CI tests (1) ###
* boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18969 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_hotunplug@unbind-rebind:
- fi-icl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html
* igt@gem_flink_basic@bad-open:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-byt-j1900/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982] /
[k.org#205379])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-u2/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-apl-guc: [PASS][9] -> [DMESG-WARN][10] ([i915#1635] /
[i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-7500u: [PASS][11] -> [DMESG-WARN][12] ([i915#203])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-kbl-7500u/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-kbl-7500u/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u: [DMESG-WARN][17] ([i915#262]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
* igt@gem_linear_blits@basic:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@gem_linear_bl...@basic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-tgl-y/igt@gem_linear_bl...@basic.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-y: [DMESG-WARN][21] ([i915#2411]) -> [DMESG-WARN][22]
([i915#2411] / [i915#402])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18969/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Re: [Intel-gfx] [PATCH 00/15] drm: Move struct drm_device.pdev to legacy
Hi Thomas. Nice clean-up series - quite an effort to move one member to deprecated! I have read through most of the patches. I left a few notes in my replies but nothing buggy. Just nitpicks. On Tue, Nov 24, 2020 at 12:38:09PM +0100, Thomas Zimmermann wrote: > The pdev field in struct drm_device points to a PCI device structure and > goes back to UMS-only days when all DRM drivers where for PCI devices. > Meanwhile we also support USB, SPI and platform devices. Each of those > uses the generic device stored in struct drm_device.dev. > > To reduce duplications and remove the special case of PCI, this patchset > converts all modesetting drivers from pdev to dev and makes pdev a field > for legacy UMS drivers. > > For PCI devices, the pointer in struct drm_device.dev can be upcasted to > struct pci_device; or tested for PCI with dev_is_pci(). In several places > the code can use the dev field directly. > > After converting all drivers and the DRM core, the pdev fields becomes > only relevant for legacy drivers. In a later patchset, we may want to > convert these as well and remove pdev entirely. > > The patchset touches many files, but the individual changes are mostly > trivial. I suggest to merge each driver's patch through the respective > tree and later the rest through drm-misc-next. > > Thomas Zimmermann (15): > drm/amdgpu: Remove references to struct drm_device.pdev > drm/ast: Remove references to struct drm_device.pdev > drm/bochs: Remove references to struct drm_device.pdev > drm/cirrus: Remove references to struct drm_device.pdev > drm/gma500: Remove references to struct drm_device.pdev > drm/hibmc: Remove references to struct drm_device.pdev > drm/mgag200: Remove references to struct drm_device.pdev > drm/qxl: Remove references to struct drm_device.pdev > drm/vboxvideo: Remove references to struct drm_device.pdev > drm/virtgpu: Remove references to struct drm_device.pdev > drm/vmwgfx: Remove references to struct drm_device.pdev > drm: Upcast struct drm_device.dev to struct pci_device; replace pdev All above are: Acked-by: Sam Ravnborg > drm/nouveau: Remove references to struct drm_device.pdev I lost my confidence in my reading of this code. > drm/i915: Remove references to struct drm_device.pdev > drm/radeon: Remove references to struct drm_device.pdev I did not look at these at all. I hope someone else find time to do so. Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
Hi Thomas,
On Tue, Nov 24, 2020 at 12:38:24PM +0100, Thomas Zimmermann wrote:
> We have DRM drivers based on USB, SPI and platform devices. All of them
> are fine with storing their device reference in struct drm_device.dev.
> PCI devices should be no exception. Therefore struct drm_device.pdev is
> deprecated.
>
> Instead upcast from struct drm_device.dev with to_pci_dev(). PCI-specific
> code can use dev_is_pci() to test for a PCI device. This patch changes
> the DRM core code and documentation accordingly. Struct drm_device.pdev
> is being moved to legacy status.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_agpsupport.c | 9 ++---
> drivers/gpu/drm/drm_bufs.c | 4 ++--
> drivers/gpu/drm/drm_edid.c | 7 ++-
> drivers/gpu/drm/drm_irq.c| 12 +++-
> drivers/gpu/drm/drm_pci.c| 26 +++---
> drivers/gpu/drm/drm_vm.c | 2 +-
> include/drm/drm_device.h | 12 +---
> 7 files changed, 46 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c
> b/drivers/gpu/drm/drm_agpsupport.c
> index 4c7ad46fdd21..a4040fe4f4ba 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -103,11 +103,13 @@ int drm_agp_info_ioctl(struct drm_device *dev, void
> *data,
> */
> int drm_agp_acquire(struct drm_device *dev)
> {
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> +
> if (!dev->agp)
> return -ENODEV;
> if (dev->agp->acquired)
> return -EBUSY;
> - dev->agp->bridge = agp_backend_acquire(dev->pdev);
> + dev->agp->bridge = agp_backend_acquire(pdev);
> if (!dev->agp->bridge)
> return -ENODEV;
> dev->agp->acquired = 1;
> @@ -402,14 +404,15 @@ int drm_agp_free_ioctl(struct drm_device *dev, void
> *data,
> */
> struct drm_agp_head *drm_agp_init(struct drm_device *dev)
> {
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> struct drm_agp_head *head = NULL;
>
> head = kzalloc(sizeof(*head), GFP_KERNEL);
> if (!head)
> return NULL;
> - head->bridge = agp_find_bridge(dev->pdev);
> + head->bridge = agp_find_bridge(pdev);
> if (!head->bridge) {
> - head->bridge = agp_backend_acquire(dev->pdev);
> + head->bridge = agp_backend_acquire(pdev);
> if (!head->bridge) {
> kfree(head);
> return NULL;
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 7a01d0918861..1da8b360b60a 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -325,7 +325,7 @@ static int drm_addmap_core(struct drm_device *dev,
> resource_size_t offset,
>* As we're limiting the address to 2^32-1 (or less),
>* casting it down to 32 bits is no problem, but we
>* need to point to a 64bit variable first. */
> - map->handle = dma_alloc_coherent(>pdev->dev,
> + map->handle = dma_alloc_coherent(dev->dev,
>map->size,
>>offset,
>GFP_KERNEL);
> @@ -555,7 +555,7 @@ int drm_legacy_rmmap_locked(struct drm_device *dev,
> struct drm_local_map *map)
> case _DRM_SCATTER_GATHER:
> break;
> case _DRM_CONSISTENT:
> - dma_free_coherent(>pdev->dev,
> + dma_free_coherent(dev->dev,
> map->size,
> map->handle,
> map->offset);
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 74f5a3197214..555a04ce2179 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -2075,9 +2076,13 @@ EXPORT_SYMBOL(drm_get_edid);
> struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
>struct i2c_adapter *adapter)
> {
> - struct pci_dev *pdev = connector->dev->pdev;
> + struct drm_device *dev = connector->dev;
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> struct edid *edid;
Maybe add a comment that explain why this can trigger - so people are
helped it they are catched by this.
As it is now it is not even mentioned in the changelog.
> + if (drm_WARN_ON_ONCE(dev, !dev_is_pci(dev->dev)))
> + return NULL;
> +
> vga_switcheroo_lock_ddc(pdev);
> edid = drm_get_edid(connector, adapter);
> vga_switcheroo_unlock_ddc(pdev);
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 09d6e9e2e075..22986a9a593b 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -122,7 +122,7 @@ int drm_irq_install(struct drm_device *dev, int
Re: [Intel-gfx] [PATCH 09/15] drm/nouveau: Remove references to struct drm_device.pdev
Hi Thomas.
On Tue, Nov 24, 2020 at 12:38:18PM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert nouveau to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Ben Skeggs
Suggestion to an alternative implmentation below.
> ---
> drivers/gpu/drm/nouveau/dispnv04/arb.c | 12 +++-
> drivers/gpu/drm/nouveau/dispnv04/disp.h | 14 --
> drivers/gpu/drm/nouveau/dispnv04/hw.c | 10 ++
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 7 ---
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_bios.c | 11 ---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 10 ++
> drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ++---
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 --
> drivers/gpu/drm/nouveau/nouveau_vga.c | 20
> 10 files changed, 58 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
> b/drivers/gpu/drm/nouveau/nouveau_bios.c
> index d204ea8a5618..7cc683b8dc7a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> @@ -110,6 +110,9 @@ static int call_lvds_manufacturer_script(struct
> drm_device *dev, struct dcb_outp
> struct nvbios *bios = >vbios;
> uint8_t sub = bios->data[bios->fp.xlated_entry + script] +
> (bios->fp.link_c_increment && dcbent->or & DCB_OUTPUT_C ? 1 : 0);
> uint16_t scriptofs = ROM16(bios->data[bios->init_script_tbls_ptr + sub
> * 2]);
> +#ifdef __powerpc__
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> +#endif
Or
int device = 0;
>
> if (!bios->fp.xlated_entry || !sub || !scriptofs)
> return -EINVAL;
> @@ -123,8 +126,8 @@ static int call_lvds_manufacturer_script(struct
> drm_device *dev, struct dcb_outp
> #ifdef __powerpc__
> /* Powerbook specific quirks */
device = to_pci_dev(dev->dev)->device;
if (script == LVDS_RESET && (device == 0x0179 || device == 0x0189 ||
device == 0x0329))
> if (script == LVDS_RESET &&
> - (dev->pdev->device == 0x0179 || dev->pdev->device == 0x0189 ||
> - dev->pdev->device == 0x0329))
> + (pdev->device == 0x0179 || pdev->device == 0x0189 ||
> + pdev->device == 0x0329))
> nv_write_tmds(dev, dcbent->or, 0, 0x02, 0x72);
> #endif
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index 24ec5339efb4..4fc0fa696461 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -396,7 +396,9 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
> NV_INFO(drm, "allocated %dx%d fb: 0x%llx, bo %p\n",
> fb->width, fb->height, nvbo->offset, nvbo);
>
> - vga_switcheroo_client_fb_set(dev->pdev, info);
> + if (dev_is_pci(dev->dev))
> + vga_switcheroo_client_fb_set(to_pci_dev(dev->dev), info);
> +
I cannot see why dev_is_pci() is needed here.
So I am obviously missing something :-(
> return 0;
>
> out_unlock:
> @@ -548,7 +550,7 @@ nouveau_fbcon_init(struct drm_device *dev)
> int ret;
>
> if (!dev->mode_config.num_crtc ||
> - (dev->pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> + (to_pci_dev(dev->dev)->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> return 0;
>
> fbcon = kzalloc(sizeof(struct nouveau_fbdev), GFP_KERNEL);
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> index c85dd8afa3c3..7c4b374b3eca 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
> @@ -87,18 +87,20 @@ nouveau_vga_init(struct nouveau_drm *drm)
> {
> struct drm_device *dev = drm->dev;
> bool runtime = nouveau_pmops_runtime();
> + struct pci_dev *pdev;
>
> /* only relevant for PCI devices */
> - if (!dev->pdev)
> + if (!dev_is_pci(dev->dev))
> return;
> + pdev = to_pci_dev(dev->dev);
>
> - vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode);
> + vga_client_register(pdev, dev, NULL, nouveau_vga_set_decode);
>
> /* don't register Thunderbolt eGPU with vga_switcheroo */
> - if (pci_is_thunderbolt_attached(dev->pdev))
> + if (pci_is_thunderbolt_attached(pdev))
> return;
>
> - vga_switcheroo_register_client(dev->pdev, _switcheroo_ops,
> runtime);
> + vga_switcheroo_register_client(pdev, _switcheroo_ops, runtime);
>
> if (runtime && nouveau_is_v1_dsm() && !nouveau_is_optimus())
> vga_switcheroo_init_domain_pm_ops(drm->dev->dev,
> >vga_pm_domain);
> @@ -109,17 +111,19 @@ nouveau_vga_fini(struct nouveau_drm *drm)
> {
> struct drm_device *dev = drm->dev;
> bool runtime = nouveau_pmops_runtime();
> + struct pci_dev *pdev;
>
> /* only
[Intel-gfx] [PATCH] drm/i915/display: Record the plane update times for debugging
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next scanout frame causing a tear. If we overestimate, we
may unnecessarily delay the update to the next frame, causing visible
jitter.
Replace the warning that we exceed some arbitrary threshold for the
vblank update with a histogram for debugfs.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1982
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Cc: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 47 +++
.../drm/i915/display/intel_display_types.h| 7 +++
drivers/gpu/drm/i915/display/intel_sprite.c | 29 +---
3 files changed, 76 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index ca41e8c00ad7..b29136208d56 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -865,6 +865,51 @@ static void intel_scaler_info(struct seq_file *m, struct
intel_crtc *crtc)
}
}
+#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc)
+{
+ char buf[ARRAY_SIZE(crtc->debug.vbl_times) + 1] = {};
+ int h, row, max;
+ u64 count;
+
+ max = 0;
+ count = 0;
+ for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+ if (crtc->debug.vbl_times[h] > max)
+ max = crtc->debug.vbl_times[h];
+ count += crtc->debug.vbl_times[h];
+ }
+ seq_printf(m, "\tUpdates: %llu\n", count);
+ if (!count)
+ return;
+
+ memset(buf, '-', sizeof(buf) - 1);
+ seq_printf(m, "\t |%s|\n", buf);
+
+ for (row = ilog2(max) - 1; row; row--) {
+ memset(buf, ' ', sizeof(buf) - 1);
+ for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+ if (ilog2(crtc->debug.vbl_times[h]) >= row)
+ buf[h] = '*';
+ }
+ seq_printf(m, "\t |%s|\n", buf);
+ }
+
+ memset(buf, '-', sizeof(buf) - 1);
+ seq_printf(m, "\t |%s|\n", buf);
+ seq_printf(m, "\t1us (log) 1ms\n");
+
+ seq_printf(m, "\tMin update: %lluns\n", crtc->debug.min_vbl_time);
+ seq_printf(m, "\tMax update: %lluns\n", crtc->debug.max_vbl_time);
+ seq_printf(m, "\tAverage update: %lluns\n",
+ div64_u64(crtc->debug.sum_vbl_time, count));
+ seq_printf(m, "\tOverruns > %uus: %lu\n",
+ VBLANK_EVASION_TIME_US, crtc->debug.over_vbl_time);
+}
+#else
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc) {}
+#endif
+
static void intel_crtc_info(struct seq_file *m, struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -907,6 +952,8 @@ static void intel_crtc_info(struct seq_file *m, struct
intel_crtc *crtc)
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s\n",
yesno(!crtc->cpu_fifo_underrun_disabled),
yesno(!crtc->pch_fifo_underrun_disabled));
+
+ crtc_vblank_info(m, crtc);
}
static int i915_display_info(struct seq_file *m, void *unused)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ce82d654d0f2..efbb7c61e6fb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1186,6 +1186,13 @@ struct intel_crtc {
ktime_t start_vbl_time;
int min_vbl, max_vbl;
int scanline_start;
+#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
+ u64 min_vbl_time;
+ u64 max_vbl_time;
+ u64 sum_vbl_time;
+ unsigned int vbl_times[21]; /* [1us, 1ms] */
+ unsigned long over_vbl_time;
+#endif
} debug;
/* scalers available on this crtc */
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 019a2d6d807a..661cbaf4cc38 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -250,13 +250,28 @@ void intel_pipe_update_end(struct intel_crtc_state
*new_crtc_state)
crtc->debug.scanline_start, scanline_end);
}
#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
- else if (ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time) >
-VBLANK_EVASION_TIME_US)
- drm_warn(_priv->drm,
-"Atomic update on pipe (%c) took %lld us, max time
under evasion is %u us\n",
-
Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote: > Really, no ... something which produces no improvement has no value at > all ... we really shouldn't be wasting maintainer time with it because > it has a cost to merge. I'm not sure we understand where the balance > lies in value vs cost to merge but I am confident in the zero value > case. What? We can't measure how many future bugs aren't introduced because the kernel requires explicit case flow-control statements for all new code. We already enable -Wimplicit-fallthrough globally, so that's not the discussion. The issue is that Clang is (correctly) even more strict than GCC for this, so these are the remaining ones to fix for full Clang coverage too. People have spent more time debating this already than it would have taken to apply the patches. :) This is about robustness and language wrangling. It's a big code-base, and this is the price of our managing technical debt for permanent robustness improvements. (The numbers I ran from Gustavo's earlier patches were that about 10% of the places adjusted were identified as legitimate bugs being fixed. This final series may be lower, but there are still bugs being found from it -- we need to finish this and shut the door on it for good.) -- Kees Cook ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/15] drm/gma500: Remove references to struct drm_device.pdev
Hi Thomas.
On Tue, Nov 24, 2020 at 12:38:14PM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert gma500 to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Patrik Jakobsson
This patch includes several whitespace changes too.
It would be nice to avoid these as the patch is already large enough.
Browsing the patch it was not so many, it looked like more in the start
of the patch.
Sam
> ---
> drivers/gpu/drm/gma500/cdv_device.c| 30 +++---
> drivers/gpu/drm/gma500/cdv_intel_crt.c | 3 +-
> drivers/gpu/drm/gma500/cdv_intel_lvds.c| 4 +--
> drivers/gpu/drm/gma500/framebuffer.c | 9 +++---
> drivers/gpu/drm/gma500/gma_device.c| 3 +-
> drivers/gpu/drm/gma500/gma_display.c | 4 +--
> drivers/gpu/drm/gma500/gtt.c | 20 ++--
> drivers/gpu/drm/gma500/intel_bios.c| 6 ++--
> drivers/gpu/drm/gma500/intel_gmbus.c | 4 +--
> drivers/gpu/drm/gma500/intel_i2c.c | 2 +-
> drivers/gpu/drm/gma500/mdfld_device.c | 4 ++-
> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 8 ++---
> drivers/gpu/drm/gma500/mid_bios.c | 9 --
> drivers/gpu/drm/gma500/oaktrail_device.c | 5 +--
> drivers/gpu/drm/gma500/oaktrail_lvds.c | 2 +-
> drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c | 2 +-
> drivers/gpu/drm/gma500/opregion.c | 3 +-
> drivers/gpu/drm/gma500/power.c | 13
> drivers/gpu/drm/gma500/psb_drv.c | 16 +-
> drivers/gpu/drm/gma500/psb_drv.h | 8 ++---
> drivers/gpu/drm/gma500/psb_intel_lvds.c| 6 ++--
> drivers/gpu/drm/gma500/psb_intel_sdvo.c| 2 +-
> drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 36 +++---
> 23 files changed, 109 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_device.c
> b/drivers/gpu/drm/gma500/cdv_device.c
> index e75293e4a52f..19e055dbd4c2 100644
> --- a/drivers/gpu/drm/gma500/cdv_device.c
> +++ b/drivers/gpu/drm/gma500/cdv_device.c
> @@ -95,13 +95,14 @@ static u32 cdv_get_max_backlight(struct drm_device *dev)
> static int cdv_get_brightness(struct backlight_device *bd)
> {
> struct drm_device *dev = bl_get_data(bd);
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> u32 val = REG_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
>
> if (cdv_backlight_combination_mode(dev)) {
> u8 lbpc;
>
> val &= ~1;
> - pci_read_config_byte(dev->pdev, 0xF4, );
> + pci_read_config_byte(pdev, 0xF4, );
> val *= lbpc;
> }
> return (val * 100)/cdv_get_max_backlight(dev);
> @@ -111,6 +112,7 @@ static int cdv_get_brightness(struct backlight_device *bd)
> static int cdv_set_brightness(struct backlight_device *bd)
> {
> struct drm_device *dev = bl_get_data(bd);
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> int level = bd->props.brightness;
> u32 blc_pwm_ctl;
>
> @@ -128,7 +130,7 @@ static int cdv_set_brightness(struct backlight_device *bd)
> lbpc = level * 0xfe / max + 1;
> level /= lbpc;
>
> - pci_write_config_byte(dev->pdev, 0xF4, lbpc);
> + pci_write_config_byte(pdev, 0xF4, lbpc);
> }
>
> blc_pwm_ctl = REG_READ(BLC_PWM_CTL) & ~BACKLIGHT_DUTY_CYCLE_MASK;
> @@ -205,8 +207,9 @@ static inline void CDV_MSG_WRITE32(int domain, uint port,
> uint offset,
> static void cdv_init_pm(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = dev->dev_private;
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> u32 pwr_cnt;
> - int domain = pci_domain_nr(dev->pdev->bus);
> + int domain = pci_domain_nr(pdev->bus);
> int i;
>
> dev_priv->apm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
> @@ -234,6 +237,8 @@ static void cdv_init_pm(struct drm_device *dev)
>
> static void cdv_errata(struct drm_device *dev)
> {
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> +
> /* Disable bonus launch.
>* CPU and GPU competes for memory and display misses updates and
>* flickers. Worst with dual core, dual displays.
> @@ -242,7 +247,7 @@ static void cdv_errata(struct drm_device *dev)
>* Bonus Launch to work around the issue, by degrading
>* performance.
>*/
> - CDV_MSG_WRITE32(pci_domain_nr(dev->pdev->bus), 3, 0x30, 0x08027108);
> + CDV_MSG_WRITE32(pci_domain_nr(pdev->bus), 3, 0x30, 0x08027108);
> }
>
> /**
> @@ -255,12 +260,13 @@ static void cdv_errata(struct drm_device *dev)
> static int cdv_save_display_registers(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = dev->dev_private;
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> struct psb_save_area *regs = _priv->regs;
> struct drm_connector *connector;
>
> dev_dbg(dev->dev, "Saving GPU registers.\n");
>
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/
>
> So looks like the bulk of these are:
> switch (x) {
> case 0:
> ++x;
> default:
> break;
> }
>
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895
I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.
--
Kees Cook
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/tgl, rkl, dg1: Apply WA_1406941453 to TGL, RKL and DG1 (rev2)
== Series Details ==
Series: drm/i915/tgl, rkl, dg1: Apply WA_1406941453 to TGL, RKL and DG1 (rev2)
URL : https://patchwork.freedesktop.org/series/83383/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18968
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18968 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18968, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18968:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [PASS][1] -> [DMESG-WARN][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
New tests
-
New tests have been introduced between CI_DRM_9385 and Patchwork_18968:
### New CI tests (1) ###
* boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18968 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][3] -> [SKIP][4] ([fdo#109271])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@modeset:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@kms_busy@ba...@modeset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-tgl-y/igt@kms_busy@ba...@modeset.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u: [DMESG-WARN][13] ([i915#262]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@prime_vgem@basic-read:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@prime_v...@basic-read.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18968/fi-tgl-y/igt@prime_v...@basic-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-buf/dma-resv: Respect num_fences when initializing the shared fence list.
== Series Details == Series: dma-buf/dma-resv: Respect num_fences when initializing the shared fence list. URL : https://patchwork.freedesktop.org/series/84210/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9383_full -> Patchwork_18966_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18966_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18966_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_18966_full: ### IGT changes ### Possible regressions * igt@gem_eio@reset-stress: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-skl4/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-skl2/igt@gem_...@reset-stress.html * igt@i915_selftest@live@gem_contexts: - shard-skl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-skl9/igt@i915_selftest@live@gem_contexts.html New tests - New tests have been introduced between CI_DRM_9383_full and Patchwork_18966_full: ### New CI tests (1) ### * boot: - Statuses : 200 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_18966_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_create@forked: - shard-kbl: [PASS][4] -> [INCOMPLETE][5] ([i915#794]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-kbl1/igt@gem_exec_cre...@forked.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-kbl1/igt@gem_exec_cre...@forked.html * igt@gem_exec_whisper@basic-fds-forked: - shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#118] / [i915#95]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-glk7/igt@gem_exec_whis...@basic-fds-forked.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-glk9/igt@gem_exec_whis...@basic-fds-forked.html * igt@gem_reg_read@timestamp-monotonic: - shard-iclb: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-iclb1/igt@gem_reg_r...@timestamp-monotonic.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-iclb2/igt@gem_reg_r...@timestamp-monotonic.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-onscreen: - shard-skl: [PASS][10] -> [FAIL][11] ([i915#54]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-128x42-onscreen.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-skl5/igt@kms_cursor_...@pipe-a-cursor-128x42-onscreen.html * igt@kms_cursor_legacy@flip-vs-cursor-varying-size: - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2346]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-tglb2/igt@kms_cursor_leg...@flip-vs-cursor-varying-size.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-tglb7/igt@kms_cursor_leg...@flip-vs-cursor-varying-size.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2598]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-tglb8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-tglb3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-hdmi-a1: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#79]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-glk9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-glk9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html * igt@kms_flip@plain-flip-fb-recreate@c-edp1: - shard-skl: [PASS][18] -> [FAIL][19] ([i915#2122]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-skl4/igt@kms_flip@plain-flip-fb-recre...@c-edp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/shard-skl2/igt@kms_flip@plain-flip-fb-recre...@c-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render: - shard-tglb: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/shard-tglb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-render.html [21]:
Re: [Intel-gfx] [drm/i915/gem] 59dd13ad31: phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second -54.0% regression
Quoting Oliver Sang (2020-11-19 07:20:18) > On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote: > > Hi, > > > > Could you add intel-gfx@lists.freedesktop.org into reports going > > forward. > > > > Quoting kernel test robot (2020-11-11 17:58:11) > > > > > > Greeting, > > > > > > FYI, we noticed a -54.0% regression of > > > phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second > > > due to commit: > > > > How many runs are there on the bad version to ensure the bisect is > > repeatable? > > test 4 times. > zxing@inn:/result/phoronix-test-suite/performance-true-Radial_Gradient_Paint-1024x1024-jxrendermark-1.2.4-ucode=0xd6-monitor=da39a3ee/lkp-cfl-d1/debian-x86_64-phoronix/x86_64-rhel-8.3/gcc-9/59dd13ad310793757e34afa489dd6fc8544fc3da$ > grep -r "operations_per_second" */stats.json > 0/stats.json: > "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second": > 4133.487932, > 1/stats.json: > "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second": > 4120.421503, > 2/stats.json: > "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second": > 4188.414835, > 3/stats.json: > "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second": > 4068.549514, a w/o revert (drm-tip) b w/ revert +mB+ | ..b | | ..b.aa | | a.a | | a.a | | b b a | | b b b b. a | | b bb bbb... | |b ab bbab.bb.bba b a aab a| | |__A__| | | |MA_|| +--+ NMin MaxMedian AvgStddev a 120 3621.8761 7356.4442 4606.7895 4607.9132 156.17693 b 120 2664.0563 6359.9686 4519.5036 4534.4463 95.471121 The patch is not expected to have any impact on the machine you are testing on. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Limit frequency drop to RPe on parking
== Series Details ==
Series: drm/i915/gt: Limit frequency drop to RPe on parking
URL : https://patchwork.freedesktop.org/series/84223/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18967
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/index.html
New tests
-
New tests have been introduced between CI_DRM_9385 and Patchwork_18967:
### New CI tests (1) ###
* boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18967 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +2 similar
issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@gem_mmap_...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-soraka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-kbl-soraka/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-kbl-soraka/igt@kms_busy@ba...@flip.html
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u: [DMESG-WARN][11] ([i915#262]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@prime_vgem@basic-read:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@prime_v...@basic-read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-tgl-y/igt@prime_v...@basic-read.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#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (43 -> 39)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_9385 -> Patchwork_18967
CI-20190529: 20190529
CI_DRM_9385: 3d37e624f60f40cea80e784617686ae2917e9b01 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5870: 08b13995b85df26a77212e4fb21fd772976ef33c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18967: 29d842e75c625457dd1cfe74dea57b8e1e300d17 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
29d842e75c62 drm/i915/gt: Limit frequency drop to RPe on parking
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
Quoting Rodrigo Vivi (2020-11-24 19:46:29)
> On Tue, Nov 24, 2020 at 06:35:21PM +, Chris Wilson wrote:
> > We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> > the frequency we intend to restart the GT with. Since the two workloads
> > are likely related (e.g. a compositor rendering every 16ms), we want to
> > carry the frequency and load information from across the idling.
> > However, we do also need to update the frequencies so that workloads
> > that run for less than 1ms are autotuned by RPS (otherwise we leave
> > compositors running at max clocks, draining excess power). Conversely,
> > if we try to run too slowly, the next workload has to run longer. Since
> > there is a hysteresis in the power graph, below a certain frequency
> > running a short workload for longer consumes more energy than running it
> > slightly higher for less time. The exact balance point is unknown
> > beforehand, but measurements with 30fps media playback indicate that RPe
> > is a better choice.
> >
> > Reported-by: Edward Baker
> > Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> > Signed-off-by: Chris Wilson
> > Cc: Edward Baker
> > Cc: Andi Shyti
> > Cc: Lyude Paul
> > Cc: # v5.8+
> > ---
> > drivers/gpu/drm/i915/gt/intel_rps.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> > b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index b13e7845d483..f74d5e09e176 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
> > adj = -2;
> > rps->last_adj = adj;
> > rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
> > + if (rps->cur_freq < rps->efficient_freq) {
> > + rps->cur_freq = rps->efficient_freq;
> > + rps->last_adj = 0;
>
> this is indeed the smallest fix we can propagate:
>
>
> Reviewed-by: Rodrigo Vivi
>
> but I wonder now if we couldn't simply kill the last_adj now and always go
> with the rpe on park/unpark
Since we often have very bursty workloads that are less than 1ms, we do
want to keep the frequency across idling, or else we incur more latency
than is desired by the user (although unpark latency is no joke,
although that is mostly the context switches). The compromise for always
running shorter than an RPS interval is to "gradually" reduce the
frequency (so that compositors do not get stuck at max clocks, yet those
very same compositors also do require very quick autotuning so that
animations are smooth from idle.) Compute is another one where they have
both sustained and bursty workloads, and the shorter-than-RPS bursty
workloads are naturally expected to be to low latency.
So I still think keeping cur_freq is most often the best approach.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Limit frequency drop to RPe on parking
== Series Details == Series: drm/i915/gt: Limit frequency drop to RPe on parking URL : https://patchwork.freedesktop.org/series/84223/ State : warning == Summary == $ dim checkpatch origin/drm-tip 29d842e75c62 drm/i915/gt: Limit frequency drop to RPe on parking -:26: WARNING:BAD_SIGN_OFF: email address ' # v5.8+' might be better as 'sta...@vger.kernel.org# v5.8+' #26: Cc: # v5.8+ total: 0 errors, 1 warnings, 0 checks, 10 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Call kill_bigjoiner_slave() earlier
From: Ville Syrjälä
Let's do the kill_bigjoiner_slave() thing from
intel_bigjoiner_add_affected_crtcs() since it's related to
what we do there. This cleans up the logic in the
compute_config() loop a bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 25
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 04dad3baf8a0..a1eed30b2e0c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15373,21 +15373,16 @@ static int intel_atomic_check_bigjoiner(struct
intel_atomic_state *state,
return -EINVAL;
}
-static int kill_bigjoiner_slave(struct intel_atomic_state *state,
- struct intel_crtc_state *master_crtc_state)
+static void kill_bigjoiner_slave(struct intel_atomic_state *state,
+struct intel_crtc_state *master_crtc_state)
{
struct intel_crtc_state *slave_crtc_state =
- intel_atomic_get_crtc_state(>base,
-
master_crtc_state->bigjoiner_linked_crtc);
-
- if (IS_ERR(slave_crtc_state))
- return PTR_ERR(slave_crtc_state);
+ intel_atomic_get_new_crtc_state(state,
master_crtc_state->bigjoiner_linked_crtc);
slave_crtc_state->bigjoiner = master_crtc_state->bigjoiner = false;
slave_crtc_state->bigjoiner_slave = master_crtc_state->bigjoiner_slave
= false;
slave_crtc_state->bigjoiner_linked_crtc =
master_crtc_state->bigjoiner_linked_crtc = NULL;
intel_crtc_copy_uapi_to_hw_state(state, slave_crtc_state);
- return 0;
}
/**
@@ -15557,6 +15552,13 @@ static int intel_bigjoiner_add_affected_crtcs(struct
intel_atomic_state *state)
return ret;
}
+ for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
+ /* Kill old bigjoiner link, we may re-establish afterwards */
+ if (needs_modeset(crtc_state) &&
+ crtc_state->bigjoiner && !crtc_state->bigjoiner_slave)
+ kill_bigjoiner_slave(state, crtc_state);
+ }
+
return 0;
}
@@ -15598,13 +15600,6 @@ static int intel_atomic_check(struct drm_device *dev,
continue;
}
- /* Kill old bigjoiner link, we may re-establish afterwards */
- if (old_crtc_state->bigjoiner &&
!old_crtc_state->bigjoiner_slave) {
- ret = kill_bigjoiner_slave(state, new_crtc_state);
- if (ret)
- goto fail;
- }
-
if (!new_crtc_state->uapi.enable) {
if (!new_crtc_state->bigjoiner_slave) {
intel_crtc_copy_uapi_to_hw_state(state,
new_crtc_state);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Properly flag modesets for all bigjoiner pipes
From: Ville Syrjälä
If either of the bigjoiner pipes needs a modeset then we need
a modeset on both pipes. Make it so.
v2: Split out the kill_bigjoiner_slave() change (Manasi)
Add affected connectors/planes
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 32 ++--
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index fa6ca6191480..04dad3baf8a0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15525,20 +15525,36 @@ static int intel_atomic_check_async(struct
intel_atomic_state *state)
static int intel_bigjoiner_add_affected_crtcs(struct intel_atomic_state *state)
{
- const struct intel_crtc_state *crtc_state;
+ struct intel_crtc_state *crtc_state;
struct intel_crtc *crtc;
int i;
for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
struct intel_crtc_state *linked_crtc_state;
+ struct intel_crtc *linked_crtc;
+ int ret;
if (!crtc_state->bigjoiner)
continue;
- linked_crtc_state = intel_atomic_get_crtc_state(>base,
-
crtc_state->bigjoiner_linked_crtc);
+ linked_crtc = crtc_state->bigjoiner_linked_crtc;
+ linked_crtc_state = intel_atomic_get_crtc_state(>base,
linked_crtc);
if (IS_ERR(linked_crtc_state))
return PTR_ERR(linked_crtc_state);
+
+ if (!needs_modeset(crtc_state))
+ continue;
+
+ linked_crtc_state->uapi.mode_changed = true;
+
+ ret = drm_atomic_add_affected_connectors(>base,
+_crtc->base);
+ if (ret)
+ return ret;
+
+ ret = intel_atomic_add_affected_planes(state, linked_crtc);
+ if (ret)
+ return ret;
}
return 0;
@@ -15658,6 +15674,16 @@ static int intel_atomic_check(struct drm_device *dev,
new_crtc_state->update_pipe = false;
}
}
+
+ if (new_crtc_state->bigjoiner) {
+ struct intel_crtc_state *linked_crtc_state =
+ intel_atomic_get_new_crtc_state(state,
new_crtc_state->bigjoiner_linked_crtc);
+
+ if (needs_modeset(linked_crtc_state)) {
+ new_crtc_state->uapi.mode_changed = true;
+ new_crtc_state->update_pipe = false;
+ }
+ }
}
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Add intel_atomic_add_affected_planes()
From: Ville Syrjälä
drm_atomic_add_affected_planes() only considers planes which
are logically enabled in the uapi state. For bigjoiner we need
to consider planes logically enabled in the hw state. Add a
helper for that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 3 +--
drivers/gpu/drm/i915/display/intel_display.c | 13 +
drivers/gpu/drm/i915/display/intel_display.h | 2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index c449d28d0560..9034a2093da0 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2415,8 +2415,7 @@ static int intel_modeset_all_pipes(struct
intel_atomic_state *state)
if (ret)
return ret;
- ret = drm_atomic_add_affected_planes(>base,
->base);
+ ret = intel_atomic_add_affected_planes(state, crtc);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 068892e4d2f0..fa6ca6191480 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15107,6 +15107,19 @@ static int intel_crtc_add_planes_to_state(struct
intel_atomic_state *state,
return 0;
}
+int intel_atomic_add_affected_planes(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
+{
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(state, crtc);
+ const struct intel_crtc_state *new_crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+
+ return intel_crtc_add_planes_to_state(state, crtc,
+ old_crtc_state->enabled_planes |
+ new_crtc_state->enabled_planes);
+}
+
static bool active_planes_affects_min_cdclk(struct drm_i915_private *dev_priv)
{
/* See {hsw,vlv,ivb}_plane_ratio() */
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 5e0d42d82c11..a5771bfecba6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -499,6 +499,8 @@ enum phy_fia {
((connector) =
to_intel_connector((__state)->base.connectors[__i].ptr), \
(new_connector_state) =
to_intel_digital_connector_state((__state)->base.connectors[__i].new_state), 1))
+int intel_atomic_add_affected_planes(struct intel_atomic_state *state,
+struct intel_crtc *crtc);
u8 intel_calc_active_pipes(struct intel_atomic_state *state,
u8 active_pipes);
void intel_link_compute_m_n(u16 bpp, int nlanes,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Track logically enabled planes for hw state
From: Ville Syrjälä
Currently crtc_state->uapi.plane_mask only tracks logically
enabled planes on the uapi level. For bigjoiner purposes
we want to do the same for the hw state. Let's follow the
pattern established by active_planes & co. here.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 13 +
drivers/gpu/drm/i915/display/intel_display_types.h | 5 -
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 7e9f84b00859..b5e1ee99535c 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -312,10 +312,13 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
int ret;
intel_plane_set_invisible(new_crtc_state, new_plane_state);
+ new_crtc_state->enabled_planes &= ~BIT(plane->id);
if (!new_plane_state->hw.crtc && !old_plane_state->hw.crtc)
return 0;
+ new_crtc_state->enabled_planes |= BIT(plane->id);
+
ret = plane->check_plane(new_crtc_state, new_plane_state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 595183f7b60f..068892e4d2f0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3551,7 +3551,7 @@ intel_set_plane_visible(struct intel_crtc_state
*crtc_state,
crtc_state->uapi.plane_mask &= ~drm_plane_mask(>base);
}
-static void fixup_active_planes(struct intel_crtc_state *crtc_state)
+static void fixup_plane_bitmasks(struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
struct drm_plane *plane;
@@ -3561,11 +3561,14 @@ static void fixup_active_planes(struct intel_crtc_state
*crtc_state)
* have been used on the same (or wrong) pipe. plane_mask uses
* unique ids, hence we can use that to reconstruct active_planes.
*/
+ crtc_state->enabled_planes = 0;
crtc_state->active_planes = 0;
drm_for_each_plane_mask(plane, _priv->drm,
- crtc_state->uapi.plane_mask)
+ crtc_state->uapi.plane_mask) {
+ crtc_state->enabled_planes |= BIT(to_intel_plane(plane)->id);
crtc_state->active_planes |= BIT(to_intel_plane(plane)->id);
+ }
}
static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
@@ -3583,7 +3586,7 @@ static void intel_plane_disable_noatomic(struct
intel_crtc *crtc,
crtc->base.base.id, crtc->base.name);
intel_set_plane_visible(crtc_state, plane_state, false);
- fixup_active_planes(crtc_state);
+ fixup_plane_bitmasks(crtc_state);
crtc_state->data_rate[plane->id] = 0;
crtc_state->min_cdclk[plane->id] = 0;
@@ -12842,6 +12845,7 @@ static int icl_check_nv12_planes(struct
intel_crtc_state *crtc_state)
plane_state->planar_linked_plane = NULL;
if (plane_state->planar_slave && !plane_state->uapi.visible) {
+ crtc_state->enabled_planes &= ~BIT(plane->id);
crtc_state->active_planes &= ~BIT(plane->id);
crtc_state->update_planes |= BIT(plane->id);
}
@@ -12885,6 +12889,7 @@ static int icl_check_nv12_planes(struct
intel_crtc_state *crtc_state)
linked_state->planar_slave = true;
linked_state->planar_linked_plane = plane;
+ crtc_state->enabled_planes |= BIT(linked->id);
crtc_state->active_planes |= BIT(linked->id);
crtc_state->update_planes |= BIT(linked->id);
drm_dbg_kms(_priv->drm, "Using %s as Y plane for %s\n",
@@ -19165,7 +19170,7 @@ static void readout_plane_state(struct drm_i915_private
*dev_priv)
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
- fixup_active_planes(crtc_state);
+ fixup_plane_bitmasks(crtc_state);
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ce82d654d0f2..c93cf3ddebb6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1047,7 +1047,10 @@ struct intel_crtc_state {
u32 cgm_mode;
};
- /* bitmask of visible planes (enum plane_id) */
+ /* bitmask of logically enabled planes (enum plane_id) */
+ u8 enabled_planes;
+
+ /* bitmask of actually visible planes (enum plane_id) */
u8 active_planes;
u8
Re: [Intel-gfx] [PATCH 02/21] drm/i915/tgl: Fix macros for TGL SOC based WA
+Matt Roper, see question in item (3) below
On Tue, Nov 24, 2020 at 04:20:40PM +0200, Jani Nikula wrote:
On Tue, 24 Nov 2020, Lucas De Marchi wrote:
On Mon, Nov 23, 2020 at 05:32:22PM -0800, Aditya Swarup wrote:
On 11/18/20 1:18 AM, Jani Nikula wrote:
On Tue, 17 Nov 2020, Lucas De Marchi wrote:
On Tue, Nov 17, 2020 at 10:50:10AM -0800, Aditya Swarup wrote:
@@ -1579,9 +1579,9 @@ static inline const struct i915_rev_steppings *
tgl_revids_get(struct drm_i915_private *dev_priv)
{
if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv))
- return tgl_uy_revids;
+ return tgl_uy_revids + INTEL_REVID(dev_priv);
oohh, no. You have to at least check you are not accessing out of
bounds. New HW running on old kernel should not access create invalid
accesses like this.
And this is just one reason why exposing arrays directly as an interface
to the rest of the driver is a bad idea. Basically I look at *all*
externs in the driver with suspicion, and they're all exceptions that
should not be repeated. The revid arrays are a direct invitation to keep
adding more and more extern arrays. And more ways to go out of bounds.
We definitely need an array table for the SOC -> Display, GT stepping mapping.
the mapping could be very well in the define iff you don't have
different mappings per sku as is the case with TGL. Example:
#define ADLS_REVID_A0 0
#define ADLS_REVID_A1 5
#define ADLS_DISP_REVID_A0 0
#define ADLS_DISP_REVID_B0 5
The actual value is actually the *SoC* revid, regardless the name of the
macro. Since we already have to use a different macro -
IS_DISP_REVID() - I don't think this is much worse and would allow us to
get rid of the table *for ADL-S*, at the expense of having to pass as
argument the ADLS_DISP_REVID_*. However this doesn't apply to TGL as TGL
has a different mapping per sku.
SOC steppings were usually the same as display steppings/GT steppings until TGL
and therefore
didn't require special mapping cases. But from TGL onwards, we have different
combinations of
Disp and GT steppings per SOC stepping. Alderlake-S makes this direct mapping
even more difficult
without the array requiring more macros to deal with SOC -> DISP/GT stepping
differences.
Will fix the array bound checks but the possibility of SOC revision id from drm
struct going
out of bounds is minimal. Can only happen if we don't have support for latest SOC
-> Disp/GT table
this is very common. It's just a matter of trying to run a slightly old
kernel in a slightly newer rev of the hardware.
Indeed. All kernels released with the arrays are simply bust for any new
hardware revisions. They'll need a minimal Cc: stable fix.
Here's something I drafted [1] to fix the situation more
generally. There are still some issues to overcome, though they exist
already in the current code.
This could be followed up with converting *all* platforms to the scheme,
making it universal, regardless of whether the revids in the hardware
are consecutive or not.
BR,
Jani.
[1] https://cgit.freedesktop.org/~jani/drm/log/?h=revid-stepping-scheme
That is looking good. Some feedback I can give before this series being
sent for review:
1) You need to call the init function from somewhere
2) For the FIXMEs:
+ /*
+* FIXME: We should be able to take into account new revids not
+* recognized by this kernel version.
+*/
+ /*
+* FIXME: We should be able to handle gaps in revid arrays gracefully,
+* and in a way that works sensibly for the range checks. This is true
+* for the existing revid range checks; it's fine if a new id pops up in
+* the middle.
+*
+* It's okay for the display stepping to be zero, though in an array all
+* or none should be set to non-zero, not a mix.
+*/
Maybe consider that gt_stepping will never be 0 and in the case it is (or
size > ARRAY_SIZE), just backtrack to use the first one we find with
gt_stepping != 0? then we probably should add a warning that we are not
actually using the correct one, but it's the best we can do.
3) REVID_BXT_B_LAST
what is that? The only thing that comes to mind is for "matching all B
steps". Matt Roper had a patch to change the way we interpret the WA
ranges so the bounds are [lower, upper) rather than [lower, upper].
Matt, any problem you faced with that patch? It makes more sense
because we know the stepping in which it's fixed, but we may have
additional revids before that
But I don't see any trace of REVID_BXT_B_LAST in the tree, so not sure
what's this about.
4)
Lastly, I'd still like the simple fix for TGL without all the noise and
without the refactor. It's the simplest fix we can do for the 5.10
timeframe.
Lucas De Marchi
for TGL from Bspec and if we are picking up wrong revision id from drm struct
that means the platform
information obtained itself is wrong which will be a general platform problem
Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
On Tue, Nov 24, 2020 at 06:35:21PM +, Chris Wilson wrote:
> We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> the frequency we intend to restart the GT with. Since the two workloads
> are likely related (e.g. a compositor rendering every 16ms), we want to
> carry the frequency and load information from across the idling.
> However, we do also need to update the frequencies so that workloads
> that run for less than 1ms are autotuned by RPS (otherwise we leave
> compositors running at max clocks, draining excess power). Conversely,
> if we try to run too slowly, the next workload has to run longer. Since
> there is a hysteresis in the power graph, below a certain frequency
> running a short workload for longer consumes more energy than running it
> slightly higher for less time. The exact balance point is unknown
> beforehand, but measurements with 30fps media playback indicate that RPe
> is a better choice.
>
> Reported-by: Edward Baker
> Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> Signed-off-by: Chris Wilson
> Cc: Edward Baker
> Cc: Andi Shyti
> Cc: Lyude Paul
> Cc: # v5.8+
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index b13e7845d483..f74d5e09e176 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
> adj = -2;
> rps->last_adj = adj;
> rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
> + if (rps->cur_freq < rps->efficient_freq) {
> + rps->cur_freq = rps->efficient_freq;
> + rps->last_adj = 0;
this is indeed the smallest fix we can propagate:
Reviewed-by: Rodrigo Vivi
but I wonder now if we couldn't simply kill the last_adj now and always go
with the rpe on park/unpark
> + }
>
> GT_TRACE(rps_to_gt(rps), "park:%x\n", rps->cur_freq);
> }
> --
> 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
Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: move register functions to display/
Quoting Lucas De Marchi (2020-11-24 19:13:16) > Now that all display-related functions are grouped in > i915_driver_register(), move them to display/ so we reduce the amount of > display calls from the rest of the driver. dsm and vgaswitcheroo are candidates as well. They are on the fine line between platform interface and display specific. acpi_video is under display, so dsm seems apt as well. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: group display-related register calls
Quoting Lucas De Marchi (2020-11-24 19:13:15) > intel_gt_driver_register() may be called earlier than > intel_opregion_register() and acpi_video_register(), so move it up. > > intel_display_debugfs_register() may be called later, together with the > other display-related initializations. There is a slight change in > behavior that sysfs files will show up before the display-related > debugfs files, but that shouldn't be a problem - userspace shouldn't be > relying in debugfs. > > This allows us to group all the display-related calls under a single > check for "HAS_DISPLAY()" that can be later moved to a better place. > > Signed-off-by: Lucas De Marchi They do seem to be independent and movable, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: stop registering if drm_dev_register() fails
Quoting Lucas De Marchi (2020-11-24 19:13:14)
> If drm_dev_register() fails there is no reason to continue registering
> the driver and initializing.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_drv.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 320856b665a1..c3fad01ce26f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -669,17 +669,19 @@ static void i915_driver_register(struct
> drm_i915_private *dev_priv)
> intel_vgpu_register(dev_priv);
>
> /* Reveal our presence to userspace */
> - if (drm_dev_register(dev, 0) == 0) {
> - i915_debugfs_register(dev_priv);
> - if (HAS_DISPLAY(dev_priv))
> - intel_display_debugfs_register(dev_priv);
> - i915_setup_sysfs(dev_priv);
> -
> - /* Depends on sysfs having been initialized */
> - i915_perf_register(dev_priv);
> - } else
> + if (drm_dev_register(dev, 0) != 0) {
> drm_err(_priv->drm,
> "Failed to register driver for userspace access!\n");
> + return;
> + }
s/!= 0//
Ok, we keep the driver loaded to do powersaving if not registered, so
there is some advantage in the face of failure. And there is little
point in trying to register some auxiliary interfaces if the primary
inodes are not exposed.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: group display-related register calls
intel_gt_driver_register() may be called earlier than
intel_opregion_register() and acpi_video_register(), so move it up.
intel_display_debugfs_register() may be called later, together with the
other display-related initializations. There is a slight change in
behavior that sysfs files will show up before the display-related
debugfs files, but that shouldn't be a problem - userspace shouldn't be
relying in debugfs.
This allows us to group all the display-related calls under a single
check for "HAS_DISPLAY()" that can be later moved to a better place.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.c | 62 ++---
1 file changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c3fad01ce26f..89af4baa531c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -676,38 +676,39 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
}
i915_debugfs_register(dev_priv);
- if (HAS_DISPLAY(dev_priv))
- intel_display_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
+ intel_gt_driver_register(_priv->gt);
+
if (HAS_DISPLAY(dev_priv)) {
+ intel_display_debugfs_register(dev_priv);
+
/* Must be done after probing outputs */
intel_opregion_register(dev_priv);
acpi_video_register();
- }
- intel_gt_driver_register(_priv->gt);
-
- intel_audio_init(dev_priv);
+ intel_audio_init(dev_priv);
- /*
-* Some ports require correctly set-up hpd registers for detection to
-* work properly (leading to ghost connected connector status), e.g. VGA
-* on gm45. Hence we can only set up the initial fbdev config after hpd
-* irqs are fully enabled. We do it last so that the async config
-* cannot run before the connectors are registered.
-*/
- intel_fbdev_initial_config_async(dev);
+ /*
+* Some ports require correctly set-up hpd registers for
+* detection to work properly (leading to ghost connected
+* connector status), e.g. VGA on gm45. Hence we can only set
+* up the initial fbdev config after hpd irqs are fully
+* enabled. We do it last so that the async config cannot run
+* before the connectors are registered.
+*/
+ intel_fbdev_initial_config_async(dev);
- /*
-* We need to coordinate the hotplugs with the asynchronous fbdev
-* configuration, for which we use the fbdev->async_cookie.
-*/
- if (HAS_DISPLAY(dev_priv))
+ /*
+* We need to coordinate the hotplugs with the asynchronous
+* fbdev configuration, for which we use the
+* fbdev->async_cookie.
+*/
drm_kms_helper_poll_init(dev);
+ }
intel_power_domains_enable(dev_priv);
intel_runtime_pm_enable(_priv->runtime_pm);
@@ -731,19 +732,22 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
intel_runtime_pm_disable(_priv->runtime_pm);
intel_power_domains_disable(dev_priv);
- intel_fbdev_unregister(dev_priv);
- intel_audio_deinit(dev_priv);
+ if (HAS_DISPLAY(dev_priv)) {
+ intel_fbdev_unregister(dev_priv);
+ intel_audio_deinit(dev_priv);
+
+ /*
+* After flushing the fbdev (incl. a late async config which
+* will have delayed queuing of a hotplug event), then flush
+* the hotplug events.
+*/
+ drm_kms_helper_poll_fini(_priv->drm);
- /*
-* After flushing the fbdev (incl. a late async config which will
-* have delayed queuing of a hotplug event), then flush the hotplug
-* events.
-*/
- drm_kms_helper_poll_fini(_priv->drm);
+ acpi_video_unregister();
+ intel_opregion_unregister(dev_priv);
+ }
intel_gt_driver_unregister(_priv->gt);
- acpi_video_unregister();
- intel_opregion_unregister(dev_priv);
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
--
2.29.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: stop registering if drm_dev_register() fails
If drm_dev_register() fails there is no reason to continue registering
the driver and initializing.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 320856b665a1..c3fad01ce26f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -669,17 +669,19 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
intel_vgpu_register(dev_priv);
/* Reveal our presence to userspace */
- if (drm_dev_register(dev, 0) == 0) {
- i915_debugfs_register(dev_priv);
- if (HAS_DISPLAY(dev_priv))
- intel_display_debugfs_register(dev_priv);
- i915_setup_sysfs(dev_priv);
-
- /* Depends on sysfs having been initialized */
- i915_perf_register(dev_priv);
- } else
+ if (drm_dev_register(dev, 0) != 0) {
drm_err(_priv->drm,
"Failed to register driver for userspace access!\n");
+ return;
+ }
+
+ i915_debugfs_register(dev_priv);
+ if (HAS_DISPLAY(dev_priv))
+ intel_display_debugfs_register(dev_priv);
+ i915_setup_sysfs(dev_priv);
+
+ /* Depends on sysfs having been initialized */
+ i915_perf_register(dev_priv);
if (HAS_DISPLAY(dev_priv)) {
/* Must be done after probing outputs */
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/display: move register functions to display/
Now that all display-related functions are grouped in
i915_driver_register(), move them to display/ so we reduce the amount of
display calls from the rest of the driver.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 53
drivers/gpu/drm/i915/display/intel_display.h | 3 ++
drivers/gpu/drm/i915/i915_drv.c | 44 +---
3 files changed, 58 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 595183f7b60f..7bf0fb2a99a5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -24,6 +24,7 @@
* Eric Anholt
*/
+#include
#include
#include
#include
@@ -43,7 +44,9 @@
#include
#include
+#include "display/intel_audio.h"
#include "display/intel_crt.h"
+#include "display/intel_display_debugfs.h"
#include "display/intel_ddi.h"
#include "display/intel_dp.h"
#include "display/intel_dp_mst.h"
@@ -19709,6 +19712,56 @@ void intel_modeset_driver_remove_nogem(struct
drm_i915_private *i915)
intel_bios_driver_remove(i915);
}
+void intel_display_driver_register(struct drm_i915_private *i915)
+{
+ if (!HAS_DISPLAY(i915))
+ return;
+
+ intel_display_debugfs_register(i915);
+
+ /* Must be done after probing outputs */
+ intel_opregion_register(i915);
+ acpi_video_register();
+
+ intel_audio_init(i915);
+
+ /*
+* Some ports require correctly set-up hpd registers for
+* detection to work properly (leading to ghost connected
+* connector status), e.g. VGA on gm45. Hence we can only set
+* up the initial fbdev config after hpd irqs are fully
+* enabled. We do it last so that the async config cannot run
+* before the connectors are registered.
+*/
+ intel_fbdev_initial_config_async(>drm);
+
+ /*
+* We need to coordinate the hotplugs with the asynchronous
+* fbdev configuration, for which we use the
+* fbdev->async_cookie.
+*/
+ drm_kms_helper_poll_init(>drm);
+}
+
+void intel_display_driver_unregister(struct drm_i915_private *i915)
+{
+ if (!HAS_DISPLAY(i915))
+ return;
+
+ intel_fbdev_unregister(i915);
+ intel_audio_deinit(i915);
+
+ /*
+* After flushing the fbdev (incl. a late async config which
+* will have delayed queuing of a hotplug event), then flush
+* the hotplug events.
+*/
+ drm_kms_helper_poll_fini(>drm);
+
+ acpi_video_unregister();
+ intel_opregion_unregister(i915);
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
struct intel_display_error_state {
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 5e0d42d82c11..c1963aa54b77 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -645,6 +645,9 @@ bool
intel_format_info_is_yuv_semiplanar(const struct drm_format_info *info,
uint64_t modifier);
+void intel_display_driver_register(struct drm_i915_private *i915);
+void intel_display_driver_unregister(struct drm_i915_private *i915);
+
/* modesetting */
void intel_modeset_init_hw(struct drm_i915_private *i915);
int intel_modeset_init_noirq(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 89af4baa531c..9dc9248fa168 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
@@ -51,7 +50,6 @@
#include "display/intel_bw.h"
#include "display/intel_cdclk.h"
#include "display/intel_csr.h"
-#include "display/intel_display_debugfs.h"
#include "display/intel_display_types.h"
#include "display/intel_dp.h"
#include "display/intel_fbdev.h"
@@ -683,32 +681,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
intel_gt_driver_register(_priv->gt);
- if (HAS_DISPLAY(dev_priv)) {
- intel_display_debugfs_register(dev_priv);
-
- /* Must be done after probing outputs */
- intel_opregion_register(dev_priv);
- acpi_video_register();
-
- intel_audio_init(dev_priv);
-
- /*
-* Some ports require correctly set-up hpd registers for
-* detection to work properly (leading to ghost connected
-* connector status), e.g. VGA on gm45. Hence we can only set
-* up the initial fbdev config after hpd irqs are fully
-* enabled. We do it last so that the async config cannot run
-* before the connectors are registered.
-*/
- intel_fbdev_initial_config_async(dev);
-
-
[Intel-gfx] [PATCH 0/3] Move display initialization
This reduces the surface from which display/ is called by the
other parts of the driver, starting with the init. For that new
intel_display_driver_{register,unregister} functions are created
that will deal with the HAS_DISPLAY check.
There are more changes needed, but I'm sending this early for feedback
and CI.
Lucas De Marchi (3):
drm/i915: stop registering if drm_dev_register() fails
drm/i915: group display-related register calls
drm/i915/display: move register functions to display/
drivers/gpu/drm/i915/display/intel_display.c | 53
drivers/gpu/drm/i915/display/intel_display.h | 3 ++
drivers/gpu/drm/i915/i915_drv.c | 52 ---
3 files changed, 65 insertions(+), 43 deletions(-)
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/tgl, rkl, dg1: Apply WA_1406941453 to TGL, RKL and DG1
From: Swathi Dhanavanthri
This workaround is applicable only for tgl,rkl and dg1.
Bspec: 52890, 53273, 53508.
Signed-off-by: Swathi Dhanavanthri
Reviewed-by: Clint Taylor
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a82554baa6ac..7c6b21ced56f 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1778,6 +1778,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_masked_en(wal,
GEN9_CS_DEBUG_MODE1,
FF_DOP_CLOCK_GATE_DISABLE);
+
+ /* Wa_1406941453:tgl,rkl,dg1 */
+ wa_masked_en(wal,
+GEN10_SAMPLER_MODE,
+ENABLE_SMALLPL);
}
if (IS_DG1_REVID(i915, DG1_REVID_A0, DG1_REVID_A0) ||
@@ -1808,13 +1813,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
GEN8_RC_SEMA_IDLE_MSG_DISABLE);
}
- if (IS_GEN(i915, 12)) {
- /* Wa_1406941453:gen12 */
- wa_masked_en(wal,
-GEN10_SAMPLER_MODE,
-ENABLE_SMALLPL);
- }
-
if (IS_GEN(i915, 11)) {
/* This is not an Wa. Enable for better image quality */
wa_masked_en(wal,
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/9] relay: require non-NULL callbacks in relay_open()
On Mon, Nov 23, 2020 at 07:59:22PM +0200, Jani Nikula wrote: > There are no clients passing NULL callbacks, which makes sense as it > wouldn't even create a file. Require non-NULL callbacks, and throw away > the handling for NULL callbacks. Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote: > IB/hfi1: Fix fall-through warnings for Clang > IB/mlx4: Fix fall-through warnings for Clang > IB/qedr: Fix fall-through warnings for Clang > RDMA/mlx5: Fix fall-through warnings for Clang I picked these four to the rdma tree, thanks Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/9] ath9k: make relay callbacks const
On Mon, Nov 23, 2020 at 07:59:28PM +0200, Jani Nikula wrote: > Now that relay_open() accepts const callbacks, make relay callbacks > const. Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, 23 Nov 2020, Joe Perches wrote: > On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote: > > it's not for me to prove that such patches don't affect code > > generation. That's for the patch author and (unfortunately) for > > reviewers. > > Ideally, that proof would be provided by the compilation system itself > and not patch authors nor reviewers nor maintainers. > > Unfortunately gcc does not guarantee repeatability or deterministic > output. To my knowledge, neither does clang. > Yes, I've said the same thing myself. But having attempted it, I now think this is a hard problem. YMMV. https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/ https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, 23 Nov 2020, Miguel Ojeda wrote:
> On Mon, 23 Nov 2020, Finn Thain wrote:
>
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> >
> > >
> > > It isn't that much effort, isn't it? Plus we need to take into
> > > account the future mistakes that it might prevent, too.
> >
> > We should also take into account optimisim about future improvements
> > in tooling.
> >
> Not sure what you mean here. There is no reliable way to guess what the
> intention was with a missing fallthrough, even if you parsed whitespace
> and indentation.
>
What I meant was that you've used pessimism as if it was fact.
For example, "There is no way to guess what the effect would be if the
compiler trained programmers to add a knee-jerk 'break' statement to avoid
a warning".
Moreover, what I meant was that preventing programmer mistakes is a
problem to be solved by development tools. The idea that retro-fitting new
language constructs onto mature code is somehow necessary to "prevent
future mistakes" is entirely questionable.
> > > So even if there were zero problems found so far, it is still a
> > > positive change.
> > >
> >
> > It is if you want to spin it that way.
> >
> How is that a "spin"? It is a fact that we won't get *implicit*
> fallthrough mistakes anymore (in particular if we make it a hard error).
>
Perhaps "handwaving" is a better term?
> > > I would agree if these changes were high risk, though; but they are
> > > almost trivial.
> > >
> >
> > This is trivial:
> >
> > case 1:
> > this();
> > + fallthrough;
> > case 2:
> > that();
> >
> > But what we inevitably get is changes like this:
> >
> > case 3:
> > this();
> > + break;
> > case 4:
> > hmmm();
> >
> > Why? Mainly to silence the compiler. Also because the patch author
> > argued successfully that they had found a theoretical bug, often in
> > mature code.
> >
> If someone changes control flow, that is on them. Every kernel developer
> knows what `break` does.
>
Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
leads to well-intentioned patches that cause regressions, it is partly on
you.
Have you ever considered the overall cost of the countless
-Wpresume-incompetence flags?
Perhaps you pay the power bill for a build farm that produces logs that
no-one reads? Perhaps you've run git bisect, knowing that the compiler
messages are not interesting? Or compiled software in using a language
that generates impenetrable messages? If so, here's a tip:
# grep CFLAGS /etc/portage/make.conf
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"
Now allow me some pessimism: the hardware upgrades, gigawatt hours and
wait time attributable to obligatory static analyses are a net loss.
> > But is anyone keeping score of the regressions? If unreported bugs
> > count, what about unreported regressions?
> >
> Introducing `fallthrough` does not change semantics. If you are really
> keen, you can always compare the objects because the generated code
> shouldn't change.
>
No, it's not for me to prove that such patches don't affect code
generation. That's for the patch author and (unfortunately) for reviewers.
> Cheers,
> Miguel
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 08:38:46PM +, Mark Brown wrote: > On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote: > > This series aims to fix almost all remaining fall-through warnings in > > order to enable -Wimplicit-fallthrough for Clang. > > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > > add multiple break/goto/return/fallthrough statements instead of just > > letting the code fall through to the next case. > > > > [...] > > Applied to > >https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > for-next > > Thanks! > > [1/1] regulator: as3722: Fix fall-through warnings for Clang > commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5 Thank you, Mark. -- Gustavo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/9] ath11k: make relay callbacks const
On Mon, Nov 23, 2020 at 07:59:27PM +0200, Jani Nikula wrote: > Now that relay_open() accepts const callbacks, make relay callbacks > const. Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote: > On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote: > > > IB/hfi1: Fix fall-through warnings for Clang > > IB/mlx4: Fix fall-through warnings for Clang > > IB/qedr: Fix fall-through warnings for Clang > > RDMA/mlx5: Fix fall-through warnings for Clang > > I picked these four to the rdma tree, thanks Awesome. :) Thank you, Jason. -- Gustavo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] relay: remove unused buf_mapped and buf_unmapped callbacks
Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] relay: make create_buf_file and remove_buf_file callbacks mandatory
On Mon, Nov 23, 2020 at 07:59:23PM +0200, Jani Nikula wrote: > All clients provide create_buf_file and remove_buf_file callbacks, and > they're required for relay to make sense. There is no point in them > being optional. > > Also document whether each callback is mandatory/optional. Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/
> >
>
> So looks like the bulk of these are:
> switch (x) {
> case 0:
> ++x;
> default:
> break;
> }
>
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915: make relay callbacks const
On Mon, Nov 23, 2020 at 07:59:25PM +0200, Jani Nikula wrote: > Now that relay_open() accepts const callbacks, make relay callbacks > const. > > Cc: intel-gfx@lists.freedesktop.org > Signed-off-by: Jani Nikula Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] relay: allow the use of const callback structs
> +/* subbuf_start callback wrapper */
> +static int cb_subbuf_start(struct rchan_buf *buf, void *subbuf,
> +void *prev_subbuf, size_t prev_padding)
I don't think the comment adds any information over just looking at the
function and the two callers. I'd also name it relay_subbuf_start
instead of the cb_ prefix not used anywhere else in the file.
> {
> + if (buf->chan->cb->subbuf_start)
> + return buf->chan->cb->subbuf_start(buf, subbuf,
> +prev_subbuf, prev_padding);
> +
> if (relay_buf_full(buf))
> return 0;
This could also be simplified a bit more to:
if (!buf->chan->cb->subbuf_start)
return !relay_buf_full(buf);
return buf->chan->cb->subbuf_start(buf, subbuf, prev_subbuf,
prev_padding);
Otherwise this looks good to me:
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] ath10k: make relay callbacks const
On Mon, Nov 23, 2020 at 07:59:26PM +0200, Jani Nikula wrote: > Now that relay_open() accepts const callbacks, make relay callbacks > const. Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 9/9] blktrace: make relay callbacks const
On Mon, Nov 23, 2020 at 07:59:29PM +0200, Jani Nikula wrote: > Now that relay_open() accepts const callbacks, make relay callbacks > const. Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
We treat idling the GT (intel_rps_park) as a downclock event, and reduce
the frequency we intend to restart the GT with. Since the two workloads
are likely related (e.g. a compositor rendering every 16ms), we want to
carry the frequency and load information from across the idling.
However, we do also need to update the frequencies so that workloads
that run for less than 1ms are autotuned by RPS (otherwise we leave
compositors running at max clocks, draining excess power). Conversely,
if we try to run too slowly, the next workload has to run longer. Since
there is a hysteresis in the power graph, below a certain frequency
running a short workload for longer consumes more energy than running it
slightly higher for less time. The exact balance point is unknown
beforehand, but measurements with 30fps media playback indicate that RPe
is a better choice.
Reported-by: Edward Baker
Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
Signed-off-by: Chris Wilson
Cc: Edward Baker
Cc: Andi Shyti
Cc: Lyude Paul
Cc: # v5.8+
---
drivers/gpu/drm/i915/gt/intel_rps.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index b13e7845d483..f74d5e09e176 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
adj = -2;
rps->last_adj = adj;
rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
+ if (rps->cur_freq < rps->efficient_freq) {
+ rps->cur_freq = rps->efficient_freq;
+ rps->last_adj = 0;
+ }
GT_TRACE(rps_to_gt(rps), "park:%x\n", rps->cur_freq);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/16] drm/i915/gem: Drop free_work for GEM contexts
== Series Details == Series: series starting with [01/16] drm/i915/gem: Drop free_work for GEM contexts URL : https://patchwork.freedesktop.org/series/84208/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9382_full -> Patchwork_18964_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18964_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18964_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_18964_full: ### IGT changes ### Possible regressions * igt@gem_eio@in-flight-1us: - shard-skl: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-skl4/igt@gem_...@in-flight-1us.html * igt@gem_eio@in-flight-internal-immediate: - shard-glk: NOTRUN -> [FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-glk2/igt@gem_...@in-flight-internal-immediate.html * igt@gem_exec_capture@capture@vcs1: - shard-iclb: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-iclb4/igt@gem_exec_capture@capt...@vcs1.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-plflip-blt: - shard-glk: [PASS][4] -> [FAIL][5] +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-glk2/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-indfb-plflip-blt.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-glk2/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-indfb-plflip-blt.html * igt@perf_pmu@other-init-4: - shard-tglb: [PASS][6] -> [FAIL][7] +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-tglb7/igt@perf_...@other-init-4.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-tglb5/igt@perf_...@other-init-4.html - shard-skl: [PASS][8] -> [FAIL][9] +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-skl3/igt@perf_...@other-init-4.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-skl8/igt@perf_...@other-init-4.html - shard-kbl: [PASS][10] -> [FAIL][11] +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-kbl6/igt@perf_...@other-init-4.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-kbl6/igt@perf_...@other-init-4.html * igt@perf_pmu@other-read-4: - shard-snb: [PASS][12] -> [FAIL][13] +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-snb6/igt@perf_...@other-read-4.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-snb4/igt@perf_...@other-read-4.html - shard-iclb: [PASS][14] -> [FAIL][15] +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-iclb7/igt@perf_...@other-read-4.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-iclb6/igt@perf_...@other-read-4.html Warnings * igt@i915_pm_rc6_residency@rc6-idle: - shard-iclb: [WARN][16] ([i915#2681]) -> [WARN][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-iclb1/igt@i915_pm_rc6_reside...@rc6-idle.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-iclb5/igt@i915_pm_rc6_reside...@rc6-idle.html New tests - New tests have been introduced between CI_DRM_9382_full and Patchwork_18964_full: ### New CI tests (1) ### * boot: - Statuses : 175 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_18964_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_sync@basic-all: - shard-glk: [PASS][18] -> [DMESG-WARN][19] ([i915#118] / [i915#95]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-glk4/igt@gem_s...@basic-all.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-glk8/igt@gem_s...@basic-all.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-tglb: [PASS][20] -> [WARN][21] ([i915#2681]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-tglb7/igt@i915_pm_rc6_reside...@rc6-fence.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18964/shard-tglb2/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@kms_cursor_crc@pipe-b-cursor-256x256-offscreen: - shard-skl: [PASS][22] -> [FAIL][23] ([i915#54]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-256x256-offscreen.html
Re: [Intel-gfx] [PATCH 07/16] drm/i915/gt: Check for a completed last request once
Quoting Tvrtko Ursulin (2020-11-24 17:19:23)
>
> On 24/11/2020 11:42, Chris Wilson wrote:
> > Pull the repeated check for the last active request being completed to a
> > single spot, when deciding whether or not execlist preemption is
> > required.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
> > 1 file changed, 4 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index cf11cbac241b..43703efb36d1 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -2141,12 +2141,9 @@ static void execlists_dequeue(struct intel_engine_cs
> > *engine)
> >*/
> >
> > if ((last = *active)) {
> > - if (need_preempt(engine, last, rb)) {
> > - if (i915_request_completed(last)) {
> > - tasklet_hi_schedule(>tasklet);
> > - return;
> > - }
> > -
> > + if (i915_request_completed(last)) {
> > + goto check_secondary;
> > + } else if (need_preempt(engine, last, rb)) {
> > ENGINE_TRACE(engine,
> >"preempting last=%llx:%lld, prio=%d,
> > hint=%d\n",
> >last->fence.context,
> > @@ -2174,11 +2171,6 @@ static void execlists_dequeue(struct intel_engine_cs
> > *engine)
> > last = NULL;
> > } else if (need_timeslice(engine, last, rb) &&
> > timeslice_expired(execlists, last)) {
> > - if (i915_request_completed(last)) {
> > - tasklet_hi_schedule(>tasklet);
> > - return;
> > - }
> > -
> > ENGINE_TRACE(engine,
> >"expired last=%llx:%lld, prio=%d,
> > hint=%d, yield?=%s\n",
> >last->fence.context,
> > @@ -2214,6 +2206,7 @@ static void execlists_dequeue(struct intel_engine_cs
> > *engine)
> >* we hopefully coalesce several updates into a single
> >* submission.
> >*/
> > +check_secondary:
> > if (!list_is_last(>sched.link,
> > >active.requests)) {
>
> Is there a tasklet_hi_schedule in here? I see set_timeslice in my checkout.
That tasklet_hi_schedule() was a mistake. It just devolves into a
busy-spinner as we wait for HW to send the next event, which turns out
not to be as instantaneous as hoped.
I recall leaving the imprint of my palm on my face when I figured out
what was causing the spike in the profile.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/16] drm/i915/gt: Decouple completed requests on unwind
Quoting Tvrtko Ursulin (2020-11-24 17:13:02)
>
> On 24/11/2020 11:42, Chris Wilson wrote:
> > Since the introduction of preempt-to-busy, requests can complete in the
> > background, even while they are not on the engine->active.requests list.
> > As such, the engine->active.request list itself is not in strict
> > retirement order, and we have to scan the entire list while unwinding to
> > not miss any. However, if the request is completed we currently leave it
> > on the list [until retirement], but we could just as simply remove it
> > and stop treating it as active. We would only have to then traverse it
> > once while unwinding in quick succession.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 6 --
> > drivers/gpu/drm/i915/i915_request.c | 3 ++-
> > 2 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 30aa59fb7271..cf11cbac241b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1116,8 +1116,10 @@ __unwind_incomplete_requests(struct intel_engine_cs
> > *engine)
> > list_for_each_entry_safe_reverse(rq, rn,
> >>active.requests,
> >sched.link) {
> > - if (i915_request_completed(rq))
> > - continue; /* XXX */
> > + if (i915_request_completed(rq)) {
> > + list_del_init(>sched.link);
> > + continue;
> > + }
> >
> > __i915_request_unsubmit(rq);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 8d7d29c9e375..a9db1376b996 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -321,7 +321,8 @@ bool i915_request_retire(struct i915_request *rq)
> >* after removing the breadcrumb and signaling it, so that we do not
> >* inadvertently attach the breadcrumb to a completed request.
> >*/
> > - remove_from_engine(rq);
> > + if (!list_empty(>sched.link))
> > + remove_from_engine(rq);
>
> The list_empty check is unlocked so is list_del_init in
> remove_from_engine safe on potentially already unlinked request or it
> needs to re-check under the lock?
It's safe. The unwind is under the lock, and remove_from_engine takes
the lock, and both do list_del_init() which is a no-op if already
removed. And the end state of the flag bits is the same on each path. We
can skip the __notify_execute_cb_imm() since we know in unwind it is
executing and there should be no cb.
The test before we take the lock is only allowed to skip the active.lock
if it sees the list is already decoupled, in which case we can leave it
to the unwind to remove it from the engine (and we know that the request
can only have been inflight prior to completion). Since the test is not
locked, we don't serialise with the removal, but the list_del_init is
the last action on the request so there is no window where the unwind is
accessing the request after it may have been retired.
list_move() will not confuse list_empty(), as although it does a
list_del_entry, it is not temporarily re-initialised to an empty list.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/16] drm/i915/gt: Check for a completed last request once
On 24/11/2020 11:42, Chris Wilson wrote:
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index cf11cbac241b..43703efb36d1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2141,12 +2141,9 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
*/
if ((last = *active)) {
- if (need_preempt(engine, last, rb)) {
- if (i915_request_completed(last)) {
- tasklet_hi_schedule(>tasklet);
- return;
- }
-
+ if (i915_request_completed(last)) {
+ goto check_secondary;
+ } else if (need_preempt(engine, last, rb)) {
ENGINE_TRACE(engine,
"preempting last=%llx:%lld, prio=%d,
hint=%d\n",
last->fence.context,
@@ -2174,11 +2171,6 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
last = NULL;
} else if (need_timeslice(engine, last, rb) &&
timeslice_expired(execlists, last)) {
- if (i915_request_completed(last)) {
- tasklet_hi_schedule(>tasklet);
- return;
- }
-
ENGINE_TRACE(engine,
"expired last=%llx:%lld, prio=%d, hint=%d,
yield?=%s\n",
last->fence.context,
@@ -2214,6 +2206,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* we hopefully coalesce several updates into a single
* submission.
*/
+check_secondary:
if (!list_is_last(>sched.link,
>active.requests)) {
Is there a tasklet_hi_schedule in here? I see set_timeslice in my checkout.
Regards,
Tvrtko
/*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color
Re-reported.
-Original Message-
From: Imre Deak
Sent: Tuesday, November 24, 2020 7:13 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.BAT: failure for series starting with [1/2]
drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear
Color
Hi,
On Mon, Nov 23, 2020 at 09:24:31PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel
> Gen 12 render compression with Clear Color
> URL : https://patchwork.freedesktop.org/series/84183/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_9378 -> Patchwork_18961
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_18961 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_18961, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
> External URL:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/index.html
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_18961:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_exec_fence@basic-await@rcs0:
> - fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-skl-lmem/igt@gem_exec_fence@basic-aw...@rcs0.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-skl-lmem/i
> gt@gem_exec_fence@basic-aw...@rcs0.html
>
> * igt@kms_chamelium@common-hpd-after-suspend:
> - fi-kbl-7500u: [PASS][3] -> [FAIL][4]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-kbl-7500u/
> igt@kms_chamel...@common-hpd-after-suspend.html
the patchset adds a new framebuffer modifier used only on TGL, so the above two
failures happen on unaffected platforms.
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_9378 and Patchwork_18961:
>
> ### New CI tests (1) ###
>
> * boot:
> - Statuses : 40 pass(s)
> - Exec time: [0.0] s
>
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_18961 that come from known issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@kms_busy@basic@flip:
> - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1
> similar issue
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@kms_busy@ba...@flip.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-tgl-y/igt@
> kms_busy@ba...@flip.html
>
> * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
> - fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1
> similar issue
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-icl-u2/igt
> @kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
>
> * igt@prime_self_import@basic-with_one_bo_two_files:
> - fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1
> similar issue
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-tgl-y/igt@
> prime_self_import@basic-with_one_bo_two_files.html
>
>
> Possible fixes
>
> * igt@kms_busy@basic@modeset:
> - fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
> similar issue
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@kms_busy@ba...@modeset.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-tgl-y/igt@
> kms_busy@ba...@modeset.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_9378/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_18961/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
> - {fi-kbl-7560u}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-kbl-7560u/
>
Re: [Intel-gfx] [PATCH 06/16] drm/i915/gt: Decouple completed requests on unwind
On 24/11/2020 11:42, Chris Wilson wrote:
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any. However, if the request is completed we currently leave it
on the list [until retirement], but we could just as simply remove it
and stop treating it as active. We would only have to then traverse it
once while unwinding in quick succession.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 --
drivers/gpu/drm/i915/i915_request.c | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 30aa59fb7271..cf11cbac241b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1116,8 +1116,10 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
list_for_each_entry_safe_reverse(rq, rn,
>active.requests,
sched.link) {
- if (i915_request_completed(rq))
- continue; /* XXX */
+ if (i915_request_completed(rq)) {
+ list_del_init(>sched.link);
+ continue;
+ }
__i915_request_unsubmit(rq);
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 8d7d29c9e375..a9db1376b996 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -321,7 +321,8 @@ bool i915_request_retire(struct i915_request *rq)
* after removing the breadcrumb and signaling it, so that we do not
* inadvertently attach the breadcrumb to a completed request.
*/
- remove_from_engine(rq);
+ if (!list_empty(>sched.link))
+ remove_from_engine(rq);
The list_empty check is unlocked so is list_del_init in
remove_from_engine safe on potentially already unlinked request or it
needs to re-check under the lock?
Regards,
Tvrtko
GEM_BUG_ON(!llist_empty(>execute_cb));
__list_del_entry(>link); /* poison neither prev/next (RCU walks) */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color
== Series Details ==
Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel
Gen 12 render compression with Clear Color
URL : https://patchwork.freedesktop.org/series/84183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9378 -> Patchwork_18961
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/index.html
New tests
-
New tests have been introduced between CI_DRM_9378 and Patchwork_18961:
### New CI tests (1) ###
* boot:
- Statuses : 40 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18961 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-await@rcs0:
- fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2] ([i915#2708])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-skl-lmem/igt@gem_exec_fence@basic-aw...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-skl-lmem/igt@gem_exec_fence@basic-aw...@rcs0.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([i915#2128])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
Possible fixes
* igt@kms_busy@basic@modeset:
- fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@kms_busy@ba...@modeset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-tgl-y/igt@kms_busy@ba...@modeset.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_9378/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_18961/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-kbl-7560u}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@prime_vgem@basic-write:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@prime_v...@basic-write.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-tgl-y/igt@prime_v...@basic-write.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#2128]: https://gitlab.freedesktop.org/drm/intel/issues/2128
[i915#2708]: https://gitlab.freedesktop.org/drm/intel/issues/2708
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Re: [Intel-gfx] [PATCH v5 14/17] drm/i915/hdcp: Pass connector to check_2_2_link
On 2020-11-11 at 11:50:48 +0530, Anshuman Gupta wrote:
> This requires for HDCP 2.2 MST check link.
> As for DP/HDMI shims check_2_2_link retrieves the connector
> from dig_port, this is not sufficient or DP MST connector,
> there can be multiple DP MST topology connector associated
> with same dig_port.
Reviewed-by: Ramalingam C
>
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++-
> 4 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b93ecf4f21e3..d2c744b8b461 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -375,7 +375,8 @@ struct intel_hdcp_shim {
> bool is_repeater, u8 type);
>
> /* HDCP2.2 Link Integrity Check */
> - int (*check_2_2_link)(struct intel_digital_port *dig_port);
> + int (*check_2_2_link)(struct intel_digital_port *dig_port,
> + struct intel_connector *connector);
> };
>
> struct intel_hdcp {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index f643d3af59bb..c094839d15d1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -585,7 +585,8 @@ int intel_dp_hdcp2_config_stream_type(struct
> intel_digital_port *dig_port,
> }
>
> static
> -int intel_dp_hdcp2_check_link(struct intel_digital_port *dig_port)
> +int intel_dp_hdcp2_check_link(struct intel_digital_port *dig_port,
> + struct intel_connector *connector)
> {
> u8 rx_status;
> int ret;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 6a48110c7cd7..0c10afc42f01 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -1942,7 +1942,7 @@ static int intel_hdcp2_check_link(struct
> intel_connector *connector)
> goto out;
> }
>
> - ret = hdcp->shim->check_2_2_link(dig_port);
> + ret = hdcp->shim->check_2_2_link(dig_port, connector);
> if (ret == HDCP_LINK_PROTECTED) {
> if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
> intel_hdcp_update_value(connector,
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 0788de04711b..bd0d91101464 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1734,7 +1734,8 @@ int intel_hdmi_hdcp2_read_msg(struct intel_digital_port
> *dig_port,
> }
>
> static
> -int intel_hdmi_hdcp2_check_link(struct intel_digital_port *dig_port)
> +int intel_hdmi_hdcp2_check_link(struct intel_digital_port *dig_port,
> + struct intel_connector *connector)
> {
> u8 rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
> int ret;
> --
> 2.26.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/16] drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancel
On 24/11/2020 16:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-11-24 16:19:15)
On 24/11/2020 11:42, Chris Wilson wrote:
If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index a24cc1ff08a0..f5f6feed0fa6 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -363,6 +363,14 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
kfree(b);
}
+static void irq_signal_request(struct i915_request *rq,
+struct intel_breadcrumbs *b)
+{
+ if (__signal_request(rq) &&
+ llist_add(>signal_node, >signaled_requests))
+ irq_work_queue(>irq_work);
+}
+
static void insert_breadcrumb(struct i915_request *rq)
{
struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
@@ -380,9 +388,7 @@ static void insert_breadcrumb(struct i915_request *rq)
* its signal completion.
*/
if (__request_completed(rq)) {
- if (__signal_request(rq) &&
- llist_add(>signal_node, >signaled_requests))
- irq_work_queue(>irq_work);
+ irq_signal_request(rq, b);
return;
}
@@ -453,6 +459,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
void i915_request_cancel_breadcrumb(struct i915_request *rq)
{
+ struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
bool release;
@@ -461,11 +468,16 @@ void i915_request_cancel_breadcrumb(struct i915_request *rq)
spin_lock(>signal_lock);
list_del_rcu(>signal_link);
- release = remove_signaling_context(rq->engine->breadcrumbs, ce);
+ release = remove_signaling_context(b, ce);
spin_unlock(>signal_lock);
if (release)
intel_context_put(ce);
+ if (__request_completed(rq)) {
+ irq_signal_request(rq, b);
+ return;
This is a bit unintuitive - irq_signal_request does things conditionally
based on the signaled flag, but here the return value is ignored and
reference kept regardless. Which makes me wonder how can the combo of
the two always dtrt. Because __request_completed is seqno based, which
can happen before setting the signaled flag. Like if retire races with
breadcrumbs. Am I missing something?
static void irq_signal_request()
Yes, the completion must happen before the signal bit is set, and there
is race on who sets the signal bit.
So if, and only if, __signal_request() is the first to set the signal
bit do we keep the reference to the request and enqueue it to execute the
callbacks in the irq-worker.
If the request is completed, but someone else has already signaled the
request, the reference is dropped.
static bool __signal_request(struct i915_request *rq)
{
GEM_BUG_ON(test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags));
if (!__dma_fence_signal(>fence)) {
i915_request_put(rq);
return false;
}
return true;
}
I see your point that the reference handling is not obvious. Worth
taking another pass over it to split the different paths into their
different ways so the ownership is not hidden away.
It looks like I confused irq_signal_request and __signal_request. Former
has no return value so what I wrote makes no sense. And then it is
indeed fine what the patch does but I do think at least a good comment
under the if (__request_completed) branch in cancel breadcrumb is needed.
If irq_signal_request could be made return the result from
__dma_fence_signal and if other callers would be able to easily handle
the change even better. (I mean moving the i915_request_put out of
__signal_request.)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/dma-resv: Respect num_fences when initializing the shared fence list.
== Series Details ==
Series: dma-buf/dma-resv: Respect num_fences when initializing the shared fence
list.
URL : https://patchwork.freedesktop.org/series/84210/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9383 -> Patchwork_18966
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/index.html
New tests
-
New tests have been introduced between CI_DRM_9383 and Patchwork_18966:
### New CI tests (1) ###
* boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18966 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-icl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/fi-icl-u2/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/fi-icl-u2/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-soraka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/fi-kbl-soraka/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/fi-kbl-soraka/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- {fi-ehl-1}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/fi-ehl-1/igt@core_hotunp...@unbind-rebind.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/fi-ehl-1/igt@core_hotunp...@unbind-rebind.html
- fi-icl-u2: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/fi-byt-j1900/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- {fi-kbl-7560u}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/fi-kbl-7560u/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/fi-kbl-7560u/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9383/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.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
Participating hosts (43 -> 39)
--
Additional (1): fi-tgl-y
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9383 -> Patchwork_18966
CI-20190529: 20190529
CI_DRM_9383: 2096ebc6896ed1b99fddf7c979ea9209dc3b4f73 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5870: 08b13995b85df26a77212e4fb21fd772976ef33c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18966: a3e8d02ad6beaff42880573f9d4db06775c96516 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a3e8d02ad6be dma-buf/dma-resv: Respect num_fences when initializing the shared
fence list.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18966/index.html
___
Intel-gfx mailing
Re: [Intel-gfx] [PATCH v5 13/17] drm/i915/hdcp: MST streams support in hdcp port_data
On 2020-11-11 at 11:50:47 +0530, Anshuman Gupta wrote:
> Add support for multiple mst stream in hdcp port data
> which will be used by RepeaterAuthStreamManage msg and
> HDCP 2.2 security f/w for m' validation.
>
> Security f/w doesn't have any provision to mark the
> stream_type for each stream separately, it just take
> single input of stream_type while authentiating the
> port. So driver mark each stream_type with common
> highest supported content type for all streams in
> DP MST Topology.
>
> Security f/w supports RepeaterAuthStreamManage msg and m'
> validation only once during port authentication and encryption.
Could we make a note in commit msg that we need to support content type per
stream
when fw supports it?
>
> v2:
> - Init the hdcp port data k for HDMI/DP SST stream.
> v3:
> - Cosmetic changes. [Uma]
> v4:
> - 's/port_auth/hdcp_port_auth'. [Ram]
> - Commit log improvement.
>
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
> Signed-off-by: Anshuman Gupta
> ---
> .../drm/i915/display/intel_display_types.h| 4 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 103 +++---
> 2 files changed, 92 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 6e597f6aafe8..b93ecf4f21e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1445,10 +1445,12 @@ struct intel_digital_port {
> enum phy_fia tc_phy_fia;
> u8 tc_phy_fia_idx;
>
> - /* protects num_hdcp_streams reference count, port_data */
> + /* protects num_hdcp_streams reference count, port_data and port_auth */
Either correct the variable names or refer it as "hdcp related
variables"
> struct mutex hdcp_mutex;
> /* the number of pipes using HDCP signalling out of this port */
> unsigned int num_hdcp_streams;
> + /* port HDCP auth status */
> + bool hdcp_auth_status;
> /* HDCP port data need to pass to security f/w */
> struct hdcp_port_data hdcp_port_data;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 829176df89e7..6a48110c7cd7 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -26,6 +26,64 @@
> #define KEY_LOAD_TRIES 5
> #define HDCP2_LC_RETRY_CNT 3
>
> +static int intel_conn_to_vcpi(struct intel_connector *connector)
> +{
> + /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
> + return connector->port ? connector->port->vcpi.vcpi : 0;
> +}
> +
Lets add a comment about policy on content type selection and why. And
mention that ideally we should be able to support different content type
for different streams.
> +static int
> +intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
> +{
> + struct drm_connector_list_iter conn_iter;
> + struct intel_digital_port *conn_dig_port;
> + struct intel_connector *connector;
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + struct hdcp_port_data *data = _port->hdcp_port_data;
> + bool enforce_type0 = false;
> + int k;
> +
> + if (dig_port->hdcp_auth_status)
> + return 0;
> +
> + drm_connector_list_iter_begin(>drm, _iter);
> + for_each_intel_connector_iter(connector, _iter) {
> + if (!intel_encoder_is_mst(intel_attached_encoder(connector)))
> + continue;
> +
> + conn_dig_port = intel_attached_dig_port(connector);
> + if (conn_dig_port != dig_port)
> + continue;
> +
> + if (connector->base.status == connector_status_disconnected)
> + continue;
> +
> + if (!enforce_type0 && !intel_hdcp2_capable(connector))
> + enforce_type0 = true;
> +
> + data->streams[data->k].stream_id =
> intel_conn_to_vcpi(connector);
> + data->k++;
> +
> + /* if there is only one active stream */
> + if (dig_port->dp.active_mst_links <= 1)
> + break;
> + }
> + drm_connector_list_iter_end(_iter);
> +
> + if (drm_WARN_ON(>drm, data->k > INTEL_NUM_PIPES(i915) || data->k
> == 0))
> + return -EINVAL;
> +
> + /*
> + * Apply common protection level across all streams in DP MST Topology.
> + * Use highest supported content type for all streams in DP MST
> Topology.
> + */
> + for (k = 0; k < data->k; k++)
> + data->streams[k].stream_type =
> + enforce_type0 ? DRM_MODE_HDCP_CONTENT_TYPE0 :
> DRM_MODE_HDCP_CONTENT_TYPE1;
> +
> + return 0;
> +}
> +
> static
> bool intel_hdcp_is_ksv_valid(u8 *ksv)
> {
> @@ -1476,13 +1534,14 @@ static
> int _hdcp2_propagate_stream_management_info(struct intel_connector
>
Re: [Intel-gfx] [RFC] drm/i915/dp: PPS registers doesn't require AUX power
On Tue, Nov 24, 2020 at 03:28:47PM +0530, Anshuman Gupta wrote: > Platforms with South Display Engine on PCH, doesn't > require to get/put the AUX power domain in order to > access PPS register because PPS registers are always on > with South display on PCH. > > Cc: Imre Deak > Cc: > Signed-off-by: Anshuman Gupta Could you describe the issue the patch is fixing? For accessing PPS registers the AUX power well may not be needed, but I'm not sure if this also applies to PPS functionality in general. For instance forcing VDD is required for AUX functionality. In any case we do need a power reference for any register access, so I don't think not getting any power reference for PPS is ok. --Imre > --- > drivers/gpu/drm/i915/display/intel_dp.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 3896d08c4177..84a2c49e154c 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -872,8 +872,9 @@ pps_lock(struct intel_dp *intel_dp) >* See intel_power_sequencer_reset() why we need >* a power domain reference here. >*/ > - wakeref = intel_display_power_get(dev_priv, > - > intel_aux_power_domain(dp_to_dig_port(intel_dp))); > + if (!HAS_PCH_SPLIT(dev_priv)) > + wakeref = intel_display_power_get(dev_priv, > + > intel_aux_power_domain(dp_to_dig_port(intel_dp))); > > mutex_lock(_priv->pps_mutex); > > @@ -886,9 +887,11 @@ pps_unlock(struct intel_dp *intel_dp, intel_wakeref_t > wakeref) > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); > > mutex_unlock(_priv->pps_mutex); > - intel_display_power_put(dev_priv, > - > intel_aux_power_domain(dp_to_dig_port(intel_dp)), > - wakeref); > + > + if (!HAS_PCH_SPLIT(dev_priv)) > + intel_display_power_put(dev_priv, > + > intel_aux_power_domain(dp_to_dig_port(intel_dp)), > + wakeref); > return 0; > } > > -- > 2.26.2 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/16] drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancel
Quoting Tvrtko Ursulin (2020-11-24 16:19:15)
>
> On 24/11/2020 11:42, Chris Wilson wrote:
> > If while we are cancelling the breadcrumb signaling, we find that the
> > request is already completed, move it to the irq signaler and let it be
> > signaled.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 20
> > 1 file changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > index a24cc1ff08a0..f5f6feed0fa6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > @@ -363,6 +363,14 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs
> > *b)
> > kfree(b);
> > }
> >
> > +static void irq_signal_request(struct i915_request *rq,
> > +struct intel_breadcrumbs *b)
> > +{
> > + if (__signal_request(rq) &&
> > + llist_add(>signal_node, >signaled_requests))
> > + irq_work_queue(>irq_work);
> > +}
> > +
> > static void insert_breadcrumb(struct i915_request *rq)
> > {
> > struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
> > @@ -380,9 +388,7 @@ static void insert_breadcrumb(struct i915_request *rq)
> >* its signal completion.
> >*/
> > if (__request_completed(rq)) {
> > - if (__signal_request(rq) &&
> > - llist_add(>signal_node, >signaled_requests))
> > - irq_work_queue(>irq_work);
> > + irq_signal_request(rq, b);
> > return;
> > }
> >
> > @@ -453,6 +459,7 @@ bool i915_request_enable_breadcrumb(struct i915_request
> > *rq)
> >
> > void i915_request_cancel_breadcrumb(struct i915_request *rq)
> > {
> > + struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
> > struct intel_context *ce = rq->context;
> > bool release;
> >
> > @@ -461,11 +468,16 @@ void i915_request_cancel_breadcrumb(struct
> > i915_request *rq)
> >
> > spin_lock(>signal_lock);
> > list_del_rcu(>signal_link);
> > - release = remove_signaling_context(rq->engine->breadcrumbs, ce);
> > + release = remove_signaling_context(b, ce);
> > spin_unlock(>signal_lock);
> > if (release)
> > intel_context_put(ce);
> >
> > + if (__request_completed(rq)) {
> > + irq_signal_request(rq, b);
> > + return;
>
> This is a bit unintuitive - irq_signal_request does things conditionally
> based on the signaled flag, but here the return value is ignored and
> reference kept regardless. Which makes me wonder how can the combo of
> the two always dtrt. Because __request_completed is seqno based, which
> can happen before setting the signaled flag. Like if retire races with
> breadcrumbs. Am I missing something?
static void irq_signal_request()
Yes, the completion must happen before the signal bit is set, and there
is race on who sets the signal bit.
So if, and only if, __signal_request() is the first to set the signal
bit do we keep the reference to the request and enqueue it to execute the
callbacks in the irq-worker.
If the request is completed, but someone else has already signaled the
request, the reference is dropped.
static bool __signal_request(struct i915_request *rq)
{
GEM_BUG_ON(test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags));
if (!__dma_fence_signal(>fence)) {
i915_request_put(rq);
return false;
}
return true;
}
I see your point that the reference handling is not obvious. Worth
taking another pass over it to split the different paths into their
different ways so the ownership is not hidden away.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf/dma-resv: Respect num_fences when initializing the shared fence list.
== Series Details == Series: dma-buf/dma-resv: Respect num_fences when initializing the shared fence list. URL : https://patchwork.freedesktop.org/series/84210/ State : warning == Summary == $ dim checkpatch origin/drm-tip a3e8d02ad6be dma-buf/dma-resv: Respect num_fences when initializing the shared fence list. -:18: WARNING:BAD_SIGN_OFF: email address ' # v3.17+' might be better as 'sta...@vger.kernel.org# v3.17+' #18: Cc: # v3.17+ -:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #19: Reported-by: Niranjana Vishwanathapura total: 0 errors, 2 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 1/2] drm/i915/display/tgl: Disable FBC with PSR2
On Fri, Nov 20, 2020 at 01:06:14AM +0530, Uma Shankar wrote: > There are some corner cases wrt underrun when we enable > FBC with PSR2 on TGL. Recommendation from hardware is to > keep this combination disabled. > > Bspec: 50422 HSD: 14010260002 > > v2: Added psr2 enabled check from crtc_state (Anshuman) > Added Bspec link and HSD referneces (Jose) > > v3: Moved the logic to disable fbc to intel_fbc_update_state_cache > and removed the crtc->config usages, as per Ville's recommendation. > > Signed-off-by: Uma Shankar Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_fbc.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c > b/drivers/gpu/drm/i915/display/intel_fbc.c > index a5b072816a7b..cb29c6f068f9 100644 > --- a/drivers/gpu/drm/i915/display/intel_fbc.c > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c > @@ -701,6 +701,15 @@ static void intel_fbc_update_state_cache(struct > intel_crtc *crtc, > struct drm_framebuffer *fb = plane_state->hw.fb; > > cache->plane.visible = plane_state->uapi.visible; > + > + /* > + * Tigerlake is not supporting FBC with PSR2. > + * Recommendation is to keep this combination disabled > + * Bspec: 50422 HSD: 14010260002 > + */ > + if (crtc_state->has_psr2 && IS_TIGERLAKE(dev_priv)) > + cache->plane.visible = false; > + > if (!cache->plane.visible) > return; > > -- > 2.26.2 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/16] drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancel
On 24/11/2020 11:42, Chris Wilson wrote:
If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index a24cc1ff08a0..f5f6feed0fa6 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -363,6 +363,14 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
kfree(b);
}
+static void irq_signal_request(struct i915_request *rq,
+ struct intel_breadcrumbs *b)
+{
+ if (__signal_request(rq) &&
+ llist_add(>signal_node, >signaled_requests))
+ irq_work_queue(>irq_work);
+}
+
static void insert_breadcrumb(struct i915_request *rq)
{
struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
@@ -380,9 +388,7 @@ static void insert_breadcrumb(struct i915_request *rq)
* its signal completion.
*/
if (__request_completed(rq)) {
- if (__signal_request(rq) &&
- llist_add(>signal_node, >signaled_requests))
- irq_work_queue(>irq_work);
+ irq_signal_request(rq, b);
return;
}
@@ -453,6 +459,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
void i915_request_cancel_breadcrumb(struct i915_request *rq)
{
+ struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
bool release;
@@ -461,11 +468,16 @@ void i915_request_cancel_breadcrumb(struct i915_request *rq)
spin_lock(>signal_lock);
list_del_rcu(>signal_link);
- release = remove_signaling_context(rq->engine->breadcrumbs, ce);
+ release = remove_signaling_context(b, ce);
spin_unlock(>signal_lock);
if (release)
intel_context_put(ce);
+ if (__request_completed(rq)) {
+ irq_signal_request(rq, b);
+ return;
This is a bit unintuitive - irq_signal_request does things conditionally
based on the signaled flag, but here the return value is ignored and
reference kept regardless. Which makes me wonder how can the combo of
the two always dtrt. Because __request_completed is seqno based, which
can happen before setting the signaled flag. Like if retire races with
breadcrumbs. Am I missing something?
Regards,
Tvrtko
+ }
+
i915_request_put(rq);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 08/17] drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
On 2020-11-24 at 21:47:19 +0530, Ramalingam C wrote:
> On 2020-11-24 at 20:32:43 +0530, Anshuman Gupta wrote:
> > On 2020-11-24 at 19:50:17 +0530, Ramalingam C wrote:
> > > On 2020-11-11 at 11:50:42 +0530, Anshuman Gupta wrote:
> > > > Enable HDCP 1.4 over DP MST for Gen12.
> > > >
> > > > Cc: Ramalingam C
> > > > Signed-off-by: Anshuman Gupta
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 +++---
> > > > 1 file changed, 3 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > index 16865b200062..f00e12fc83e8 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > @@ -826,13 +826,9 @@ static struct drm_connector
> > > > *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> > > > intel_attach_force_audio_property(connector);
> > > > intel_attach_broadcast_rgb_property(connector);
> > > >
> > > > -
> > > > - /* TODO: Figure out how to make HDCP work on GEN12+ */
> > > > - if (INTEL_GEN(dev_priv) < 12) {
> > > Just a thought, shouldn't we enable for the platforms that we have
> > > tested HDCP? like <= 12.
> > >
> > > We could keep expanding the list supported.
> > thanks for comment, i will keep this as if (INTEL_GEN(dev_priv) < 12)
> I guess you meant <= 12.
:) yes it was typo
Thanks,
Anshuman.
>
> Ram.
> > Thanks,
> > Anshuman
> > >
> > > Ram.
> > > > - ret = intel_dp_init_hdcp(dig_port, intel_connector);
> > > > - if (ret)
> > > > - DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> > > > - }
> > > > + ret = intel_dp_init_hdcp(dig_port, intel_connector);
> > > > + if (ret)
> > > > + drm_dbg_kms(_priv->drm, "HDCP init failed,
> > > > skipping.\n");
> > > >
> > > > /*
> > > > * Reuse the prop from the SST connector because we're
> > > > --
> > > > 2.26.2
> > > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 08/17] drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
On 2020-11-24 at 20:32:43 +0530, Anshuman Gupta wrote:
> On 2020-11-24 at 19:50:17 +0530, Ramalingam C wrote:
> > On 2020-11-11 at 11:50:42 +0530, Anshuman Gupta wrote:
> > > Enable HDCP 1.4 over DP MST for Gen12.
> > >
> > > Cc: Ramalingam C
> > > Signed-off-by: Anshuman Gupta
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 +++---
> > > 1 file changed, 3 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index 16865b200062..f00e12fc83e8 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -826,13 +826,9 @@ static struct drm_connector
> > > *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> > > intel_attach_force_audio_property(connector);
> > > intel_attach_broadcast_rgb_property(connector);
> > >
> > > -
> > > - /* TODO: Figure out how to make HDCP work on GEN12+ */
> > > - if (INTEL_GEN(dev_priv) < 12) {
> > Just a thought, shouldn't we enable for the platforms that we have
> > tested HDCP? like <= 12.
> >
> > We could keep expanding the list supported.
> thanks for comment, i will keep this as if (INTEL_GEN(dev_priv) < 12)
I guess you meant <= 12.
Ram.
> Thanks,
> Anshuman
> >
> > Ram.
> > > - ret = intel_dp_init_hdcp(dig_port, intel_connector);
> > > - if (ret)
> > > - DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> > > - }
> > > + ret = intel_dp_init_hdcp(dig_port, intel_connector);
> > > + if (ret)
> > > + drm_dbg_kms(_priv->drm, "HDCP init failed, skipping.\n");
> > >
> > > /*
> > >* Reuse the prop from the SST connector because we're
> > > --
> > > 2.26.2
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for relay: allow the use of const callback structs
== Series Details == Series: relay: allow the use of const callback structs URL : https://patchwork.freedesktop.org/series/84209/ State : failure == Summary == Applying: relay: allow the use of const callback structs Using index info to reconstruct a base tree... M include/linux/relay.h M kernel/relay.c Falling back to patching base and 3-way merge... Auto-merging kernel/relay.c CONFLICT (content): Merge conflict in kernel/relay.c Auto-merging include/linux/relay.h error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 relay: allow the use of const callback structs When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Move struct drm_device.pdev to legacy
== Series Details ==
Series: drm: Move struct drm_device.pdev to legacy
URL : https://patchwork.freedesktop.org/series/84205/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9382_full -> Patchwork_18963_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18963_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18963_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_18963_full:
### IGT changes ###
Possible regressions
* igt@gem_eio@in-flight-internal-immediate:
- shard-glk: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-glk5/igt@gem_...@in-flight-internal-immediate.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-plflip-blt:
- shard-glk: [PASS][2] -> [FAIL][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-glk2/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-indfb-plflip-blt.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-glk1/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-indfb-plflip-blt.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_userptr_blits@huge-split}:
- shard-skl: [PASS][4] -> [INCOMPLETE][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-skl2/igt@gem_userptr_bl...@huge-split.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-skl6/igt@gem_userptr_bl...@huge-split.html
New tests
-
New tests have been introduced between CI_DRM_9382_full and
Patchwork_18963_full:
### New CI tests (1) ###
* boot:
- Statuses : 199 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18963_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_whisper@basic-normal-all:
- shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#118] / [i915#95])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-glk8/igt@gem_exec_whis...@basic-normal-all.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-glk6/igt@gem_exec_whis...@basic-normal-all.html
* igt@i915_suspend@sysfs-reader:
- shard-skl: [PASS][8] -> [INCOMPLETE][9] ([i915#198])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-skl6/igt@i915_susp...@sysfs-reader.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-skl2/igt@i915_susp...@sysfs-reader.html
* igt@kms_big_fb@linear-16bpp-rotate-0:
- shard-iclb: [PASS][10] -> [DMESG-WARN][11] ([i915#1226])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-iclb1/igt@kms_big...@linear-16bpp-rotate-0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-iclb2/igt@kms_big...@linear-16bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-c-cursor-64x21-onscreen:
- shard-skl: [PASS][12] -> [FAIL][13] ([i915#54])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-64x21-onscreen.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-skl8/igt@kms_cursor_...@pipe-c-cursor-64x21-onscreen.html
* igt@kms_cursor_edge_walk@pipe-c-256x256-bottom-edge:
- shard-skl: [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) +6
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-skl1/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-skl10/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html
* igt@kms_flip@2x-flip-vs-panning-interruptible@ab-vga1-hdmi-a1:
- shard-hsw: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) +2
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-hsw4/igt@kms_flip@2x-flip-vs-panning-interrupti...@ab-vga1-hdmi-a1.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-hsw6/igt@kms_flip@2x-flip-vs-panning-interrupti...@ab-vga1-hdmi-a1.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@b-dp1:
- shard-kbl: [PASS][18] -> [FAIL][19] ([i915#2122])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9382/shard-kbl6/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-dp1.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18963/shard-kbl2/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-dp1.html
*
