Re: [Intel-gfx] [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap
Am 04.02.21 um 19:38 schrieb Jason Gunthorpe: On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote: On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe wrote: On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote: tldr; DMA buffers aren't normal memory, expecting that you can use them like that (like calling get_user_pages works, or that they're accounting like any other normal memory) cannot be guaranteed. Since some userspace only runs on integrated devices, where all buffers are actually all resident system memory, there's a huge temptation to assume that a struct page is always present and useable like for any more pagecache backed mmap. This has the potential to result in a uapi nightmare. To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which blocks get_user_pages and all the other struct page based infrastructure for everyone. In spirit this is the uapi counterpart to the kernel-internal CONFIG_DMABUF_DEBUG. Fast gup needs the special flag set on the PTE as well.. Feels weird to have a special VMA without also having special PTEs? There's kinda no convenient & cheap way to check for the pte_special flag. This here should at least catch accidental misuse, people building their own ptes we can't stop. Maybe we should exclude VM_MIXEDMAP to catch vm_insert_page in one of these. Hm looking at code I think we need to require VM_PFNMAP here to stop vm_insert_page. And looking at the various functions, that seems to be required (and I guess VM_IO is more for really funky architectures where io-space is somewhere else?). I guess I should check for VM_PFNMAP instead of VM_SPECIAL? Well, you said the goal was to block GUP usage, that won't happen without the PTE special flag, at least on x86 When is that special flag being set? So, really, what you are saying is all dmabuf users should always use vmf_insert_pfn_prot() or something similar - and never insert_page/etc? Exactly, yes. Christian. It might make sense to check the vma flags in all the insert paths, eg vm_insert_page() can't work with VMAs that should not have struct pages in them (eg VM_SPECIAl, VM_PFNMAP, !VM_MIXEMAP if I understand it right) At least as some VM debug option Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc NULL check
> -Original Message-
> From: Imre Deak
> Sent: Thursday, February 4, 2021 11:58 PM
> To: Gupta, Anshuman
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc NULL
> check
>
> On Fri, Jan 29, 2021 at 01:30:43PM +0530, Anshuman Gupta wrote:
> > DP-MST connector encoder initializes at modeset Adding a
> > connector->encoder NULL check in order to avoid any NULL pointer
> > dereference.
> > intel_hdcp_enable() already handle this but debugfs can also invoke
> > the intel_{hdcp,hdcp2_capable}.
> > Handling it gracefully.
> >
> > Signed-off-by: Anshuman Gupta
> > ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 14 --
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index ae1371c36a32..58af323d189a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -135,11 +135,16 @@ int intel_hdcp_read_valid_bksv(struct
> > intel_digital_port *dig_port,
> > /* Is HDCP1.4 capable on Platform and Sink */ bool
> > intel_hdcp_capable(struct intel_connector *connector) {
> > - struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> > + struct intel_digital_port *dig_port;
> > const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> > bool capable = false;
> > u8 bksv[5];
> >
> > + if (!connector->encoder)
> > + return -ENODEV;
>
> I assume this is needed when called from i915_hdcp_sink_capability debugfs
> entry. That one is lacking the locking for the connector, but is that entry
> really
> needed? We print the same info already from the i915_display_info entry which
> has the proper locking and encoder check.
Historically HDCP capability added to i915_display_info later to debug CI
machine as i915_display_info available as CI logs.
Now the plans i915_display_info should only show the monitor capability.
and i915_hdcp_sink_capability will check both sink and platform capability.
Thanks,
Anshuman Gupta.
>
> > +
> > + dig_port = intel_attached_dig_port(connector);
> > +
> > if (!shim)
> > return capable;
> >
> > @@ -156,11 +161,16 @@ bool intel_hdcp_capable(struct intel_connector
> > *connector)
> > /* Is HDCP2.2 capable on Platform and Sink */ bool
> > intel_hdcp2_capable(struct intel_connector *connector) {
> > - struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> > + struct intel_digital_port *dig_port;
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > struct intel_hdcp *hdcp = &connector->hdcp;
> > bool capable = false;
> >
> > + if (!connector->encoder)
> > + return -ENODEV;
> > +
> > + dig_port = intel_attached_dig_port(connector);
> > +
> > /* I915 support for HDCP2.2 */
> > if (!hdcp->hdcp2_supported)
> > return false;
> > --
> > 2.26.2
> >
> > ___
> > 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] RFC: dma-buf: Require VM_SPECIAL vma for mmap
On Thu, Feb 4, 2021 at 9:59 PM Jason Gunthorpe wrote: > > On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote: > > > > > > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote: > > > > > > > So I think just checking for VM_PFNMAP after the vma is set up should > > > > be enough to guarantee we'll only have pte_special ptes in there, > > > > ever. But I'm not sure, this stuff all isn't really documented much > > > > and the code is sometimes a maze (to me at least). > > > > > > Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right > > > check after the VMA is populated > > > > > > But how do you stuff special pfns into a VMA outside the fault > > > handler? > > > > Many drivers we have don't have dynamic buffer management (kinda > > overkill for a few framebuffers on a display-only IP block), so the > > just remap_pfn_range on ->mmap, and don't have a fault handler at all. > > remap_pfn_range() makes sense, do you expect drivers using struct page > backed memory to call that as well? All the ones using CMA through dma_alloc_coherent end up in there with the dma_mmap_wc function. So yeah we have tons already. The drivers with dynamic memory management all use vm_insert_pfn, even when the buffer is in system memory and struct page backed. I think those are the two cases. There's another mmap in drm/i915, but that should never leave intel-specific userspace, and I think we're also phasing it out somewhat. Either way, should never show up in a shared buffer usecase, ever, so I think we can ignore it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915/selftests: Restore previous heartbeat interval
== Series Details == Series: series starting with [CI,1/2] drm/i915/selftests: Restore previous heartbeat interval URL : https://patchwork.freedesktop.org/series/86727/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9733_full -> Patchwork_19596_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19596_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19596_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_19596_full: ### IGT changes ### Possible regressions * igt@kms_flip_tiling@flip-yf-tiled@edp-1-pipe-c: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9733/shard-skl3/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-skl10/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html Known issues Here are the changes found in Patchwork_19596_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-2x: - shard-hsw: [PASS][3] -> [SKIP][4] ([fdo#109271]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9733/shard-hsw1/igt@feature_discov...@display-2x.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-hsw1/igt@feature_discov...@display-2x.html * igt@feature_discovery@psr2: - shard-apl: NOTRUN -> [SKIP][5] ([fdo#109271]) +24 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-apl4/igt@feature_discov...@psr2.html * igt@gem_ctx_persistence@legacy-engines-hang: - shard-hsw: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-hsw8/igt@gem_ctx_persiste...@legacy-engines-hang.html * igt@gem_eio@in-flight-suspend: - shard-apl: NOTRUN -> [DMESG-WARN][7] ([i915#1037] / [i915#180]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-apl1/igt@gem_...@in-flight-suspend.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9733/shard-kbl6/igt@gem_exec_f...@basic-deadline.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-kbl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9733/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_schedule@u-fairslice@vecs0: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1610] / [i915#2803]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9733/shard-skl7/igt@gem_exec_schedule@u-fairsl...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-skl2/igt@gem_exec_schedule@u-fairsl...@vecs0.html * igt@gem_pwrite@basic-exhaustion: - shard-hsw: NOTRUN -> [WARN][15] ([i915#2658]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-hsw8/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@huge-split: - shard-hsw: [PASS][16] -> [FAIL][17] ([i915#2784]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9733/shard-hsw1/igt@gem_userptr_bl...@huge-split.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-hsw1/igt@gem_userptr_bl...@huge-split.html * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb: - shard-kbl: NOTRUN -> [SKIP][18] ([fdo#109271]) +40 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-kbl2/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html * igt@gem_userptr_blits@process-exit-mmap@wb: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#1699]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-skl1/igt@gem_userptr_blits@process-exit-m...@wb.html * igt@gen9_exec_parse@cmd-crossing-page: - shard-iclb: NOTRUN -> [SKIP][20] ([fdo#112306]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19596/shard-iclb6/igt@gen9_exec_pa...@
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: Show connector hdcp capability
== Series Details == Series: drm/i915/hdcp: Show connector hdcp capability URL : https://patchwork.freedesktop.org/series/86740/ State : success == Summary == CI Bug Log - changes from CI_DRM_9736 -> Patchwork_19601 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/index.html Known issues Here are the changes found in Patchwork_19601 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@write: - 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_9736/fi-tgl-y/igt@fb...@write.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/fi-tgl-y/igt@fb...@write.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([i915#1372]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-tgl-y: [PASS][5] -> [FAIL][6] ([i915#2122]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/fi-tgl-y/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/fi-tgl-y/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html Possible fixes * igt@debugfs_test@read_all_entries: - fi-tgl-y: [DMESG-WARN][7] ([i915#1982] / [i915#402]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/fi-tgl-y/igt@debugfs_test@read_all_entries.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 39) -- Missing(4): fi-jsl-1 fi-ilk-m540 fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_9736 -> Patchwork_19601 CI-20190529: 20190529 CI_DRM_9736: 361561fb8050ccab1b4527c781f3e18595e545a0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5992: b781a32b06a0173a71b4e1ac30d18dd7164a67c4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19601: 72498a2f17797e18a44cdc51906a8ee24ac62843 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 72498a2f1779 drm/i915/hdcp: Show connector hdcp capability == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 30/57] drm/i915: Move timeslicing flag to scheduler
On 04/02/2021 16:11, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2021-02-04 15:18:31)
On 01/02/2021 08:56, Chris Wilson wrote:
Whether a scheduler chooses to implement timeslicing is up to it, and
not an underlying property of the HW engine. The scheduler does depend
on the HW supporting preemption.
Therefore, continuing on the comment I made in the previous patch, if we
had a helper with which engine would request scheduling (setting the
tasklet), if it passed in a pointer to itself, scheduler would then be
able to inspect if the engine supports preemption and so set its own
internal flag. Makes sense? It would require something like:
Actually not keen on pushing the inspection into the core scheduler and
would rather have the backend turn it on for itself. Because it's not
just about the engine supporting preemption, it's about whether or not
the backend wants to bother implement timeslicing itself.
If we skip to the end, it looks like this for execlists:
i915_sched_init(&el->sched, i915->drm.dev,
engine->name, engine->mask,
&execlists_ops, engine);
if (IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION) &&
intel_engine_has_preemption(engine))
__set_bit(I915_SCHED_TIMESLICE_BIT, &el->sched.flags);
if (intel_engine_has_preemption(engine)) {
__set_bit(I915_SCHED_BUSYWAIT_BIT, &el->sched.flags);
__set_bit(I915_SCHED_PREEMPT_RESET_BIT, &el->sched.flags);
}
with the virtual scheduler:
ve->base.sched =
i915_sched_create(ve->base.i915->drm.dev,
ve->base.name,
ve->base.mask,
&virtual_ops, ve);
if (!ve->base.sched) {
err = -ENOMEM;
goto err_put;
}
ve->base.sched->flags |= sched; /* override submission method */
I think the virtual scheduler suggests that we can't rely on the
scheduler core to dtrt by itself. And if you are still awake by the time
we get to this point, how to avoid ve->base.sched->flags |= sched are
welcome.
Not at the moment. Since it is details lets finish first and then see is
my thinking.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/module_load: Tidy up gem_exec_store workalike
We emit a store on each GPU after loading the module to confirm the
basic liveness of command submission. Trim away some of the chaff.
Signed-off-by: Chris Wilson
Cc: Ramalingam C
---
tests/i915/i915_module_load.c | 146 ++
1 file changed, 58 insertions(+), 88 deletions(-)
diff --git a/tests/i915/i915_module_load.c b/tests/i915/i915_module_load.c
index 06522ba61..f1fb13914 100644
--- a/tests/i915/i915_module_load.c
+++ b/tests/i915/i915_module_load.c
@@ -37,41 +37,45 @@
#include "igt_sysfs.h"
#include "igt_core.h"
-static void store_all(int fd)
+static void store_all(int i915)
{
- const unsigned int gen = intel_gen(intel_get_drm_devid(fd));
- unsigned int permuted[I915_EXEC_RING_MASK + 1];
- unsigned int engines[I915_EXEC_RING_MASK + 1];
- struct drm_i915_gem_exec_object2 obj[2];
- struct drm_i915_gem_relocation_entry reloc[2 * ARRAY_SIZE(engines)];
- struct drm_i915_gem_execbuffer2 execbuf;
- const struct intel_execution_engine2 *e;
+ const unsigned int gen = intel_gen(intel_get_drm_devid(i915));
+ uint32_t engines[I915_EXEC_RING_MASK + 1];
uint32_t batch[16];
- uint64_t offset;
- unsigned nengine;
- int value;
- int i, j;
-
- memset(&execbuf, 0, sizeof(execbuf));
- execbuf.buffers_ptr = (uintptr_t)obj;
- execbuf.buffer_count = 2;
-
- memset(reloc, 0, sizeof(reloc));
- memset(obj, 0, sizeof(obj));
- obj[0].handle = gem_create(fd, 4096);
- obj[1].handle = gem_create(fd, 4096);
- obj[1].relocation_count = 1;
-
- offset = sizeof(uint32_t);
+ unsigned int sz = ALIGN(sizeof(batch) * ARRAY_SIZE(engines), 4096);
+ struct drm_i915_gem_relocation_entry reloc = {
+ .offset = sizeof(uint32_t),
+ .read_domains = I915_GEM_DOMAIN_RENDER,
+ .write_domain = I915_GEM_DOMAIN_RENDER,
+ };
+ struct drm_i915_gem_exec_object2 obj[2] = {
+ { .handle = gem_create(i915, sizeof(engines)) },
+ {
+ .handle = gem_create(i915, sz),
+ .relocation_count = 1,
+ .relocs_ptr = to_user_pointer(&reloc),
+ },
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(obj),
+ .buffer_count = 2,
+ };
+ const struct intel_execution_engine2 *e;
+ int reloc_sz = sizeof(uint32_t);
+ unsigned int nengine, value;
+ void *cs;
+ int i;
+
i = 0;
batch[i] = MI_STORE_DWORD_IMM | (gen < 6 ? 1 << 22 : 0);
if (gen >= 8) {
batch[++i] = 0;
batch[++i] = 0;
+ reloc_sz = sizeof(uint64_t);
} else if (gen >= 4) {
batch[++i] = 0;
batch[++i] = 0;
- offset += sizeof(uint32_t);
+ reloc.offset += sizeof(uint32_t);
} else {
batch[i]--;
batch[++i] = 0;
@@ -80,74 +84,43 @@ static void store_all(int fd)
batch[++i] = MI_BATCH_BUFFER_END;
nengine = 0;
- intel_detect_and_clear_missed_interrupts(fd);
- __for_each_physical_engine(fd, e) {
- if (!gem_class_can_store_dword(fd, e->class))
+ cs = gem_mmap__device_coherent(i915, obj[1].handle, 0, sz, PROT_WRITE);
+ __for_each_physical_engine(i915, e) {
+ uint64_t addr;
+
+ igt_assert(reloc.presumed_offset != -1);
+ addr = reloc.presumed_offset + reloc.delta;
+
+ if (!gem_class_can_store_dword(i915, e->class))
continue;
- igt_assert(2 * (nengine + 1) * sizeof(batch) <= 4096);
+ engines[nengine] = nengine;
+ batch[value] = engines[nengine];
- engines[nengine] = e->flags;
+ execbuf.flags = e->flags;
if (gen < 6)
- engines[nengine] |= I915_EXEC_SECURE;
- execbuf.flags = engines[nengine];
-
- j = 2*nengine;
- reloc[j].target_handle = obj[0].handle;
- reloc[j].presumed_offset = ~0;
- reloc[j].offset = j*sizeof(batch) + offset;
- reloc[j].delta = nengine*sizeof(uint32_t);
- reloc[j].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
- reloc[j].write_domain = I915_GEM_DOMAIN_INSTRUCTION;
- obj[1].relocs_ptr = (uintptr_t)&reloc[j];
-
- batch[value] = 0xdeadbeef;
- gem_write(fd, obj[1].handle, j*sizeof(batch),
- batch, sizeof(batch));
- execbuf.batch_start_offset = j*sizeof(batch);
- gem_execbuf(fd, &execbuf);
-
- j = 2*nengine + 1;
- reloc[j].target_handle = obj[0].handle;
- reloc[j].presumed_offset = ~0;
- reloc[j].offset = j
[Intel-gfx] [PATCH v2 1/2] drm/i915: cleanup the region class/instance encoding
Get rid of the strange REGION_MAP encoding stuff and just use an
explicit class/instance pair for each region. This better matches our
future uAPI where all queryable regions are identified with a u16 class
and u16 instance.
v2: fix whitespace
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_memory_region.c | 33 ++
drivers/gpu/drm/i915/intel_memory_region.h | 11 ++--
2 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index 49d306b5532f..048b6d6b5af2 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -6,14 +6,22 @@
#include "intel_memory_region.h"
#include "i915_drv.h"
-/* XXX: Hysterical raisins. BIT(inst) needs to just be (inst) at some point. */
-#define REGION_MAP(type, inst) \
- BIT((type) + INTEL_MEMORY_TYPE_SHIFT) | BIT(inst)
-
-static const u32 intel_region_map[] = {
- [INTEL_REGION_SMEM] = REGION_MAP(INTEL_MEMORY_SYSTEM, 0),
- [INTEL_REGION_LMEM] = REGION_MAP(INTEL_MEMORY_LOCAL, 0),
- [INTEL_REGION_STOLEN] = REGION_MAP(INTEL_MEMORY_STOLEN, 0),
+static const struct {
+ u16 class;
+ u16 instance;
+} intel_region_map[] = {
+ [INTEL_REGION_SMEM] = {
+ .class = INTEL_MEMORY_SYSTEM,
+ .instance = 0,
+ },
+ [INTEL_REGION_LMEM] = {
+ .class = INTEL_MEMORY_LOCAL,
+ .instance = 0,
+ },
+ [INTEL_REGION_STOLEN] = {
+ .class = INTEL_MEMORY_STOLEN,
+ .instance = 0,
+ },
};
struct intel_memory_region *
@@ -259,12 +267,13 @@ int intel_memory_regions_hw_probe(struct drm_i915_private
*i915)
for (i = 0; i < ARRAY_SIZE(i915->mm.regions); i++) {
struct intel_memory_region *mem = ERR_PTR(-ENODEV);
- u32 type;
+ u16 type, instance;
if (!HAS_REGION(i915, BIT(i)))
continue;
- type = MEMORY_TYPE_FROM_REGION(intel_region_map[i]);
+ type = intel_region_map[i].class;
+ instance = intel_region_map[i].instance;
switch (type) {
case INTEL_MEMORY_SYSTEM:
mem = i915_gem_shmem_setup(i915);
@@ -284,9 +293,9 @@ int intel_memory_regions_hw_probe(struct drm_i915_private
*i915)
goto out_cleanup;
}
- mem->id = intel_region_map[i];
+ mem->id = i;
mem->type = type;
- mem->instance =
MEMORY_INSTANCE_FROM_REGION(intel_region_map[i]);
+ mem->instance = instance;
i915->mm.regions[i] = mem;
}
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index d17e4fe3123c..8baf2536d7a5 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -39,11 +39,6 @@ enum intel_region_id {
#define REGION_LMEM BIT(INTEL_REGION_LMEM)
#define REGION_STOLEN BIT(INTEL_REGION_STOLEN)
-#define INTEL_MEMORY_TYPE_SHIFT 16
-
-#define MEMORY_TYPE_FROM_REGION(r) (ilog2((r) >> INTEL_MEMORY_TYPE_SHIFT))
-#define MEMORY_INSTANCE_FROM_REGION(r) (ilog2((r) & 0x))
-
#define I915_ALLOC_MIN_PAGE_SIZE BIT(0)
#define I915_ALLOC_CONTIGUOUS BIT(1)
@@ -84,9 +79,9 @@ struct intel_memory_region {
resource_size_t total;
resource_size_t avail;
- unsigned int type;
- unsigned int instance;
- unsigned int id;
+ u16 type;
+ u16 instance;
+ enum intel_region_id id;
char name[8];
struct list_head reserved;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: give stolen system memory its own class
In some future patches we will need to also support a stolen region
carved from device local memory, on platforms like DG1. To handle this
we can simply describe each in terms of its own memory class.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/intel_memory_region.c | 6 +++---
drivers/gpu/drm/i915/intel_memory_region.h | 6 +++---
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index a1e197a6e999..c5f85296a45f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -686,7 +686,7 @@ struct drm_i915_gem_object *
i915_gem_object_create_stolen(struct drm_i915_private *i915,
resource_size_t size)
{
- return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_STOLEN],
+ return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_STOLEN_SMEM],
size, I915_BO_ALLOC_CONTIGUOUS);
}
@@ -726,7 +726,7 @@ i915_gem_object_create_stolen_for_preallocated(struct
drm_i915_private *i915,
resource_size_t stolen_offset,
resource_size_t size)
{
- struct intel_memory_region *mem = i915->mm.regions[INTEL_REGION_STOLEN];
+ struct intel_memory_region *mem =
i915->mm.regions[INTEL_REGION_STOLEN_SMEM];
struct drm_i915_gem_object *obj;
struct drm_mm_node *stolen;
int ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 41eea02a9285..b708517d3972 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -849,7 +849,7 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (INTEL_GEN(i915) >= 9 && i915_selftest.live < 0 &&
i915->params.fake_lmem_start) {
mkwrite_device_info(i915)->memory_regions =
- REGION_SMEM | REGION_LMEM | REGION_STOLEN;
+ REGION_SMEM | REGION_LMEM | REGION_STOLEN_SMEM;
GEM_BUG_ON(!HAS_LMEM(i915));
}
}
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6cff7cf0f17b..d09db36b8287 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -154,7 +154,7 @@
.page_sizes = I915_GTT_PAGE_SIZE_4K
#define GEN_DEFAULT_REGIONS \
- .memory_regions = REGION_SMEM | REGION_STOLEN
+ .memory_regions = REGION_SMEM | REGION_STOLEN_SMEM
#define I830_FEATURES \
GEN(2), \
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index 048b6d6b5af2..bf837b6bb185 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -18,8 +18,8 @@ static const struct {
.class = INTEL_MEMORY_LOCAL,
.instance = 0,
},
- [INTEL_REGION_STOLEN] = {
- .class = INTEL_MEMORY_STOLEN,
+ [INTEL_REGION_STOLEN_SMEM] = {
+ .class = INTEL_MEMORY_STOLEN_SYSTEM,
.instance = 0,
},
};
@@ -278,7 +278,7 @@ int intel_memory_regions_hw_probe(struct drm_i915_private
*i915)
case INTEL_MEMORY_SYSTEM:
mem = i915_gem_shmem_setup(i915);
break;
- case INTEL_MEMORY_STOLEN:
+ case INTEL_MEMORY_STOLEN_SYSTEM:
mem = i915_gem_stolen_setup(i915);
break;
default:
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index 8baf2536d7a5..edd49067c8ca 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -25,19 +25,19 @@ struct sg_table;
enum intel_memory_type {
INTEL_MEMORY_SYSTEM = 0,
INTEL_MEMORY_LOCAL,
- INTEL_MEMORY_STOLEN,
+ INTEL_MEMORY_STOLEN_SYSTEM,
};
enum intel_region_id {
INTEL_REGION_SMEM = 0,
INTEL_REGION_LMEM,
- INTEL_REGION_STOLEN,
+ INTEL_REGION_STOLEN_SMEM,
INTEL_REGION_UNKNOWN, /* Should be last */
};
#define REGION_SMEM BIT(INTEL_REGION_SMEM)
#define REGION_LMEM BIT(INTEL_REGION_LMEM)
-#define REGION_STOLEN BIT(INTEL_REGION_STOLEN)
+#define REGION_STOLEN_SMEM BIT(INTEL_REGION_STOLEN_SMEM)
#define I915_ALLOC_MIN_PAGE_SIZE BIT(0)
#define I915_ALLOC_CONTIGUOUS BIT(1)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedeskt
[Intel-gfx] [PATCH] drm/i915/gt: Ratelimit heartbeat completion probing
The heartbeat runs through a few phases that we expect to complete
within a certain number of heartbeat intervals. First we must submit the
heartbeat to the queue, and if the queue is occupied it may take a
couple of intervals before the heartbeat preempts the workload and is
submitted to HW. Once running on HW, completion is not instantaneous as
it may have to first reset the current workload before it itself runs
through the empty request and signals completion. As such, we know that
the heartbeat must take at least the preempt reset timeout and before we
have had a chance to reset the engine, we do not want to issue a global
reset ourselves (simply so that we only try to do one reset at a time
and not confuse ourselves by resetting twice and hitting an innocent.)
So by taking into consideration that once running the request must take
a finite amount of time, we can delay the final completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Suggested-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 91 +--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
.../drm/i915/gt/selftest_engine_heartbeat.c | 50 +-
3 files changed, 106 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 93741a65924a..5d91d42616c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -20,6 +20,18 @@
* issue a reset -- in the hope that restores progress.
*/
+#define HEARTBEAT_COMPLETION 50u /* milliseconds */
+
+static long completion_timeout(const struct intel_engine_cs *engine)
+{
+ long timeout = HEARTBEAT_COMPLETION;
+
+ if (intel_engine_has_preempt_reset(engine))
+ timeout += READ_ONCE(engine->props.preempt_timeout_ms);
+
+ return msecs_to_jiffies(timeout);
+}
+
static bool next_heartbeat(struct intel_engine_cs *engine)
{
long delay;
@@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs *engine)
return false;
delay = msecs_to_jiffies_timeout(delay);
+
+ /*
+* Once we submit a heartbeat to the HW, we know that it will take
+* at least a certain amount of time to complete. On a hanging system
+* it will first have to wait for the preempt reset timeout, and
+* then it will take some time for the reset to resume with the
+* heartbeat and for it to complete. So once we have submitted the
+* heartbeat to HW, we can wait a while longer before declaring the
+* engine stuck and forcing a reset ourselves. If we do a reset
+* and the engine is also doing a reset, it is possible that we
+* reset the engine twice, harming an innocent.
+*
+* Before we have sumitted the heartbeat, we do not want to change
+* the interval as we to promote the heartbeat and trigger preemption
+* in a deterministic time frame.
+*/
+ if (engine->heartbeat.systole &&
+ i915_request_is_active(engine->heartbeat.systole))
+ delay = max(delay, completion_timeout(engine));
+
if (delay >= HZ)
delay = round_jiffies_up_relative(delay);
mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, delay + 1);
@@ -48,12 +80,51 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
return rq;
}
+static void defibrillator(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+ struct intel_engine_cs *engine =
+ container_of(cb, typeof(*engine), heartbeat.cb);
+
+ if (READ_ONCE(engine->heartbeat.systole))
+ mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, 0);
+}
+
+static void
+untrack_heartbeat(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ rq = fetch_and_zero(&engine->heartbeat.systole);
+ if (!rq)
+ return;
+
+ ENGINE_TRACE(engine, "heartbeat completed: %llx:%lld\n",
+rq->fence.context, rq->fence.seqno);
+
+ dma_fence_remove_callback(&rq->fence, &engine->heartbeat.cb);
+ i915_request_put(rq);
+}
+
+static void
+track_heartbeat(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ ENGINE_TRACE(engine, "heartbeat started: %llx:%lld\n",
+rq->fence.context, rq->fence.seqno);
+
+ dma_fence_add_callback(&rq->fence,
+ &engine->heartbeat.cb,
+ defibrillator);
+ engine->heartbeat.systole = i915_request_get(rq);
+ if (!next_heartbeat(engine))
+ untrack_heartbeat(engine);
+}
+
static void idle_pulse(struct intel_engine_cs
Re: [Intel-gfx] linux-next: manual merge of the drivers-x86 tree with the drm-misc tree
On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko wrote: >> Today's linux-next merge of the drivers-x86 tree got a conflict in: > > Thanks. I already asked Patrik yesterday day if DRM missed to pull an > immutable tag I provided. I think they can pull and resolve conflicts > themselves. Alternatively it would be easy to resolve by Linus by removing > Kconfig lines along with mentioned files, Patrik, I have sent a PR again, so you may consider pulling it, thanks! -- With Best Regards, Andy Shevchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drivers-x86 tree with the drm-misc tree
On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko wrote: > > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko > wrote: > >> Today's linux-next merge of the drivers-x86 tree got a conflict in: > > > > Thanks. I already asked Patrik yesterday day if DRM missed to pull an > > immutable tag I provided. I think they can pull and resolve conflicts > > themselves. Alternatively it would be easy to resolve by Linus by removing > > Kconfig lines along with mentioned files, > > Patrik, I have sent a PR again, so you may consider pulling it, thanks! Daniel, is this something you can pull into drm or ask one of the drm-misc maintainers to do? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915/gt: Ratelimit heartbeat completion probing
The heartbeat runs through a few phases that we expect to complete
within a certain number of heartbeat intervals. First we must submit the
heartbeat to the queue, and if the queue is occupied it may take a
couple of intervals before the heartbeat preempts the workload and is
submitted to HW. Once running on HW, completion is not instantaneous as
it may have to first reset the current workload before it itself runs
through the empty request and signals completion. As such, we know that
the heartbeat must take at least the preempt reset timeout and before we
have had a chance to reset the engine, we do not want to issue a global
reset ourselves (simply so that we only try to do one reset at a time
and not confuse ourselves by resetting twice and hitting an innocent.)
So by taking into consideration that once running the request must take
a finite amount of time, we can delay the final completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Suggested-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 91 +--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
.../drm/i915/gt/selftest_engine_heartbeat.c | 50 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 5 +-
4 files changed, 110 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 93741a65924a..5d91d42616c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -20,6 +20,18 @@
* issue a reset -- in the hope that restores progress.
*/
+#define HEARTBEAT_COMPLETION 50u /* milliseconds */
+
+static long completion_timeout(const struct intel_engine_cs *engine)
+{
+ long timeout = HEARTBEAT_COMPLETION;
+
+ if (intel_engine_has_preempt_reset(engine))
+ timeout += READ_ONCE(engine->props.preempt_timeout_ms);
+
+ return msecs_to_jiffies(timeout);
+}
+
static bool next_heartbeat(struct intel_engine_cs *engine)
{
long delay;
@@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs *engine)
return false;
delay = msecs_to_jiffies_timeout(delay);
+
+ /*
+* Once we submit a heartbeat to the HW, we know that it will take
+* at least a certain amount of time to complete. On a hanging system
+* it will first have to wait for the preempt reset timeout, and
+* then it will take some time for the reset to resume with the
+* heartbeat and for it to complete. So once we have submitted the
+* heartbeat to HW, we can wait a while longer before declaring the
+* engine stuck and forcing a reset ourselves. If we do a reset
+* and the engine is also doing a reset, it is possible that we
+* reset the engine twice, harming an innocent.
+*
+* Before we have sumitted the heartbeat, we do not want to change
+* the interval as we to promote the heartbeat and trigger preemption
+* in a deterministic time frame.
+*/
+ if (engine->heartbeat.systole &&
+ i915_request_is_active(engine->heartbeat.systole))
+ delay = max(delay, completion_timeout(engine));
+
if (delay >= HZ)
delay = round_jiffies_up_relative(delay);
mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, delay + 1);
@@ -48,12 +80,51 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
return rq;
}
+static void defibrillator(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+ struct intel_engine_cs *engine =
+ container_of(cb, typeof(*engine), heartbeat.cb);
+
+ if (READ_ONCE(engine->heartbeat.systole))
+ mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, 0);
+}
+
+static void
+untrack_heartbeat(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ rq = fetch_and_zero(&engine->heartbeat.systole);
+ if (!rq)
+ return;
+
+ ENGINE_TRACE(engine, "heartbeat completed: %llx:%lld\n",
+rq->fence.context, rq->fence.seqno);
+
+ dma_fence_remove_callback(&rq->fence, &engine->heartbeat.cb);
+ i915_request_put(rq);
+}
+
+static void
+track_heartbeat(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ ENGINE_TRACE(engine, "heartbeat started: %llx:%lld\n",
+rq->fence.context, rq->fence.seqno);
+
+ dma_fence_add_callback(&rq->fence,
+ &engine->heartbeat.cb,
+ defibrillator);
+ engine->heartbeat.systole = i915_request_get(rq);
+ if (!next_heartbeat(engine))
+ untrack_heartbeat(engine
[Intel-gfx] [CI] drm/i915/selftest: Synchronise with the GPU timestamp
Wait for the GPU to wake up from the semaphore before measuring the
time, so that we coordinate the sampling on both the CPU and GPU for
more accurate comparisons.
v2: Switch to local_irq_disable() as once suggested by Mika.
Reported-by: Bruce Chang
Signed-off-by: Chris Wilson
Cc: CQ Tang
Reviewed-by: Bruce Chang
---
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
index 41dc1a542cd6..2c898622bdfb 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
@@ -110,13 +110,15 @@ static int __measure_timestamps(struct intel_context *ce,
cpu_relax();
/* Run the request for a 100us, sampling timestamps before/after */
- preempt_disable();
- *dt = local_clock();
+ local_irq_disable();
write_semaphore(&sema[2], 0);
+ while (READ_ONCE(sema[1]) == 0) /* wait for the gpu to catch up */
+ cpu_relax();
+ *dt = local_clock();
udelay(100);
*dt = local_clock() - *dt;
write_semaphore(&sema[2], 1);
- preempt_enable();
+ local_irq_enable();
if (i915_request_wait(rq, 0, HZ / 2) < 0) {
i915_request_put(rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc NULL check
On Fri, Feb 05, 2021 at 10:16:30AM +0200, Gupta, Anshuman wrote:
> > -Original Message-
> > From: Imre Deak
> > Sent: Thursday, February 4, 2021 11:58 PM
> > To: Gupta, Anshuman
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc NULL
> > check
> >
> > On Fri, Jan 29, 2021 at 01:30:43PM +0530, Anshuman Gupta wrote:
> > > DP-MST connector encoder initializes at modeset Adding a
> > > connector->encoder NULL check in order to avoid any NULL pointer
> > > dereference.
> > > intel_hdcp_enable() already handle this but debugfs can also invoke
> > > the intel_{hdcp,hdcp2_capable}.
> > > Handling it gracefully.
> > >
> > > Signed-off-by: Anshuman Gupta
> > > ---
> > > drivers/gpu/drm/i915/display/intel_hdcp.c | 14 --
> > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > index ae1371c36a32..58af323d189a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > @@ -135,11 +135,16 @@ int intel_hdcp_read_valid_bksv(struct
> > > intel_digital_port *dig_port,
> > > /* Is HDCP1.4 capable on Platform and Sink */ bool
> > > intel_hdcp_capable(struct intel_connector *connector) {
> > > - struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > > + struct intel_digital_port *dig_port;
> > > const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> > > bool capable = false;
> > > u8 bksv[5];
> > >
> > > + if (!connector->encoder)
> > > + return -ENODEV;
> >
> > I assume this is needed when called from i915_hdcp_sink_capability
> > debugfs entry. That one is lacking the locking for the connector,
> > but is that entry really needed? We print the same info already from
> > the i915_display_info entry which has the proper locking and encoder
> > check.
>
> Historically HDCP capability added to i915_display_info later to debug
> CI machine as i915_display_info available as CI logs. Now the plans
> i915_display_info should only show the monitor capability. and
> i915_hdcp_sink_capability will check both sink and platform
> capability.
Ok, in any case the encoder NULL check and the required locking should
be done in i915_hdcp_sink_capability_show().
>
> Thanks,
> Anshuman Gupta.
> >
> > > +
> > > + dig_port = intel_attached_dig_port(connector);
> > > +
> > > if (!shim)
> > > return capable;
> > >
> > > @@ -156,11 +161,16 @@ bool intel_hdcp_capable(struct intel_connector
> > > *connector)
> > > /* Is HDCP2.2 capable on Platform and Sink */ bool
> > > intel_hdcp2_capable(struct intel_connector *connector) {
> > > - struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > > + struct intel_digital_port *dig_port;
> > > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > struct intel_hdcp *hdcp = &connector->hdcp;
> > > bool capable = false;
> > >
> > > + if (!connector->encoder)
> > > + return -ENODEV;
> > > +
> > > + dig_port = intel_attached_dig_port(connector);
> > > +
> > > /* I915 support for HDCP2.2 */
> > > if (!hdcp->hdcp2_supported)
> > > return false;
> > > --
> > > 2.26.2
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc NULL check
> -Original Message-
> From: Imre Deak
> Sent: Friday, February 5, 2021 5:35 PM
> To: Gupta, Anshuman
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc NULL
> check
>
> On Fri, Feb 05, 2021 at 10:16:30AM +0200, Gupta, Anshuman wrote:
> > > -Original Message-
> > > From: Imre Deak
> > > Sent: Thursday, February 4, 2021 11:58 PM
> > > To: Gupta, Anshuman
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability
> > > enc NULL check
> > >
> > > On Fri, Jan 29, 2021 at 01:30:43PM +0530, Anshuman Gupta wrote:
> > > > DP-MST connector encoder initializes at modeset Adding a
> > > > connector->encoder NULL check in order to avoid any NULL pointer
> > > > dereference.
> > > > intel_hdcp_enable() already handle this but debugfs can also
> > > > invoke the intel_{hdcp,hdcp2_capable}.
> > > > Handling it gracefully.
> > > >
> > > > Signed-off-by: Anshuman Gupta
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 14 --
> > > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > index ae1371c36a32..58af323d189a 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > @@ -135,11 +135,16 @@ int intel_hdcp_read_valid_bksv(struct
> > > > intel_digital_port *dig_port,
> > > > /* Is HDCP1.4 capable on Platform and Sink */ bool
> > > > intel_hdcp_capable(struct intel_connector *connector) {
> > > > - struct intel_digital_port *dig_port =
> > > intel_attached_dig_port(connector);
> > > > + struct intel_digital_port *dig_port;
> > > > const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> > > > bool capable = false;
> > > > u8 bksv[5];
> > > >
> > > > + if (!connector->encoder)
> > > > + return -ENODEV;
> > >
> > > I assume this is needed when called from i915_hdcp_sink_capability
> > > debugfs entry. That one is lacking the locking for the connector,
> > > but is that entry really needed? We print the same info already from
> > > the i915_display_info entry which has the proper locking and encoder
> > > check.
> >
> > Historically HDCP capability added to i915_display_info later to debug
> > CI machine as i915_display_info available as CI logs. Now the plans
> > i915_display_info should only show the monitor capability. and
> > i915_hdcp_sink_capability will check both sink and platform
> > capability.
>
> Ok, in any case the encoder NULL check and the required locking should be done
> in i915_hdcp_sink_capability_show().
Thanks Imre for review I will send a v2 patch.
Thanks,
Anshuman Gupta.
>
> >
> > Thanks,
> > Anshuman Gupta.
> > >
> > > > +
> > > > + dig_port = intel_attached_dig_port(connector);
> > > > +
> > > > if (!shim)
> > > > return capable;
> > > >
> > > > @@ -156,11 +161,16 @@ bool intel_hdcp_capable(struct
> > > > intel_connector
> > > > *connector)
> > > > /* Is HDCP2.2 capable on Platform and Sink */ bool
> > > > intel_hdcp2_capable(struct intel_connector *connector) {
> > > > - struct intel_digital_port *dig_port =
> > > intel_attached_dig_port(connector);
> > > > + struct intel_digital_port *dig_port;
> > > > struct drm_i915_private *dev_priv =
> > > > to_i915(connector->base.dev);
> > > > struct intel_hdcp *hdcp = &connector->hdcp;
> > > > bool capable = false;
> > > >
> > > > + if (!connector->encoder)
> > > > + return -ENODEV;
> > > > +
> > > > + dig_port = intel_attached_dig_port(connector);
> > > > +
> > > > /* I915 support for HDCP2.2 */
> > > > if (!hdcp->hdcp2_supported)
> > > > return false;
> > > > --
> > > > 2.26.2
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: cleanup the region class/instance encoding
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: cleanup the region
class/instance encoding
URL : https://patchwork.freedesktop.org/series/86753/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9737 -> Patchwork_19602
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_19602:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- {fi-cml-drallion}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/fi-cml-drallion/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Known issues
Here are the changes found in Patchwork_19602 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +2 similar
issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-tgl-y/igt@gem_mmap_...@basic.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@i915_selftest@live@sanitycheck:
- fi-kbl-7500u: [PASS][4] -> [DMESG-WARN][5] ([i915#2605])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][6] ([i915#1888]) -> [PASS][7] +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
- fi-tgl-y: [DMESG-WARN][8] ([i915#2411] / [i915#402]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [DMESG-WARN][10] ([i915#402]) -> [PASS][11] +2
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1208]: https://gitlab.freedesktop.org/drm/intel/issues/1208
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#2546]: https://gitlab.freedesktop.org/drm/intel/issues/2546
[i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (43 -> 39)
--
Additional (1): fi-cml-drallion
Missing(5): fi-jsl-1 fi-ilk-m540 fi-bsw-cyan fi-icl-u2 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9737 -> Patchwork_19602
CI-20190529: 20190529
CI_DRM_9737: 8fef45d7241af38b7d68a8ad3b11ce8ab38b4491 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5992: b781a32b06a0173a71b4e1ac30d18dd7164a67c4 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19602: 7a3060c7aa80ea8ca38046a1b831d4b30934420c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7a3060c7aa80 drm/i915: give stolen system memory its own class
1e8f99e1a917 drm/i915: cleanup the region class/instance encoding
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Autoselect CONFIG_CHECKPOINT_RESTORE for SYS_kcmp
gallium (iris) depends on os_same_file_description() to disambiguate screens and so avoid importing the same screen fd twice as two distinct entities (that share all the kernel resources, so actions on screen affect the other and would cause random faiure). As they depend on it, so must we. os_same_file_description() uses SYS_kcmp to check the file tables for the equivalent struct file, but SYS_kcmp is hidden behind CONFIG_CHECKPOINT_RESTORE. As this is not default, we must select it for ourselves to ensure that our userspace is fully supported. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3046 Signed-off-by: Chris Wilson Cc: Jani Nikula Cc: Daniel Vetter --- drivers/gpu/drm/i915/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca7..470a5214bd33 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -21,6 +21,7 @@ config DRM_I915 select ACPI_VIDEO if ACPI select ACPI_BUTTON if ACPI select SYNC_FILE + select CHECKPOINT_RESTORE # gallium depends on SYS_kcmp select IOSF_MBI select CRC32 select SND_HDA_I915 if SND_HDA_CORE -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drivers-x86 tree with the drm-misc tree
On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson wrote: > > On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko > wrote: > > > > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko > > wrote: > > >> Today's linux-next merge of the drivers-x86 tree got a conflict in: > > > > > > Thanks. I already asked Patrik yesterday day if DRM missed to pull an > > > immutable tag I provided. I think they can pull and resolve conflicts > > > themselves. Alternatively it would be easy to resolve by Linus by > > > removing Kconfig lines along with mentioned files, > > > > Patrik, I have sent a PR again, so you may consider pulling it, thanks! > > Daniel, is this something you can pull into drm or ask one of the > drm-misc maintainers to do? We've already created the conflict, and my understanding is that Linus wants to have visibility into conflict-y stuff and doesn't mind at all resolving conflicts. Hence for 5.12 I think we're fine as-is. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/debugfs : PM_REQ and PM_RES registers
> -Original Message-
> From: Chris Wilson
> Sent: Friday, January 15, 2021 6:51 PM
> To: S, Saichandana ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani ; S, Saichandana
>
> Subject: Re: [Intel-gfx] [PATCH v4] drm/i915/debugfs : PM_REQ and
> PM_RES registers
>
> Quoting Saichandana S (2021-01-15 13:01:10)
> > +static int i915_pm_req_res_info(struct seq_file *m, void *unused) {
> > + struct drm_i915_private *i915 = node_to_i915(m->private);
> > + struct intel_csr *csr = &i915->csr;
> > + u32 DC9_status;
> > +
> > + if (!HAS_CSR(i915))
> > + return -ENODEV;
> > + if (!csr->dmc_payload)
> > + return 0;
> > + DC9_status = intel_de_read(i915, PM_RSP_DBG_1) &
> > + PM_RESP_DC9_READY;
>
> A read without waking the device up? Wait until IGT sees this.
> [wrap with with_intel_runtime_pm(&i915->runtime_pm, wakeref)] -Chris
>
>Using wakeref, doesn't allow i915 to go to suspend state, further blocking
>display DC9 entry. Thus wakeref IGT test will fail.
>[S, Saichandana]
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/56] drm/i915: Move scheduler queue
___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/debugfs : PM_REQ and PM_RES registers
Quoting S, Saichandana (2021-02-05 13:05:20)
>
>
> > -Original Message-
> > From: Chris Wilson
> > Sent: Friday, January 15, 2021 6:51 PM
> > To: S, Saichandana ; intel-
> > g...@lists.freedesktop.org
> > Cc: Nikula, Jani ; S, Saichandana
> >
> > Subject: Re: [Intel-gfx] [PATCH v4] drm/i915/debugfs : PM_REQ and
> > PM_RES registers
> >
> > Quoting Saichandana S (2021-01-15 13:01:10)
> > > +static int i915_pm_req_res_info(struct seq_file *m, void *unused) {
> > > + struct drm_i915_private *i915 = node_to_i915(m->private);
> > > + struct intel_csr *csr = &i915->csr;
> > > + u32 DC9_status;
> > > +
> > > + if (!HAS_CSR(i915))
> > > + return -ENODEV;
> > > + if (!csr->dmc_payload)
> > > + return 0;
> > > + DC9_status = intel_de_read(i915, PM_RSP_DBG_1) &
> > > + PM_RESP_DC9_READY;
> >
> > A read without waking the device up? Wait until IGT sees this.
> > [wrap with with_intel_runtime_pm(&i915->runtime_pm, wakeref)] -Chris
> >
> >Using wakeref, doesn't allow i915 to go to suspend state, further blocking
> >display DC9 entry. Thus wakeref IGT test will fail.
> >[S, Saichandana]
And yet you cannot read this register without waking the device up.
Do we conclude that this is a bad test design?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl, tgl: whitelist COMMON_SLICE_CHICKEN3 register
== Series Details == Series: drm/i915/icl, tgl: whitelist COMMON_SLICE_CHICKEN3 register URL : https://patchwork.freedesktop.org/series/86733/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9735_full -> Patchwork_19598_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19598_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19598_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_19598_full: ### IGT changes ### Possible regressions * igt@kms_flip_tiling@flip-yf-tiled@edp-1-pipe-c: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-skl7/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-skl6/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html Known issues Here are the changes found in Patchwork_19598_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-kbl7/igt@gem_cre...@create-massive.html - shard-tglb: NOTRUN -> [DMESG-WARN][4] ([i915#3002]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-tglb7/igt@gem_cre...@create-massive.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-kbl4/igt@gem_exec_f...@basic-deadline.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-kbl4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html - shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-apl3/igt@gem_exec_fair@basic-n...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-apl1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-tglb1/igt@gem_exec_fair@basic-pace-s...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-tglb1/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_reloc@basic-many-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2389]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-iclb2/igt@gem_exec_reloc@basic-many-act...@vcs1.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-skl: NOTRUN -> [FAIL][14] ([i915#2389]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-skl3/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_schedule@u-fairslice@vecs0: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#2803]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-tglb1/igt@gem_exec_schedule@u-fairsl...@vecs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-tglb1/igt@gem_exec_schedule@u-fairsl...@vecs0.html * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#118] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-glk3/igt@gem_pp...@blt-vs-render-ctxn.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-glk2/igt@gem_pp...@blt-vs-render-ctxn.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-apl4/igt@gem_soft...@noreloc-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-apl6/igt@gem_soft...@noreloc-s3.html * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb: - shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271]) +47 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19598/shard-kbl6/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html * igt@gem_userptr_blits@readonly-mmap-unsync@wb: - shard-tglb: NOTRUN -> [SKIP][22] ([i91
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Ratelimit heartbeat completion probing (rev5)
== Series Details ==
Series: drm/i915/gt: Ratelimit heartbeat completion probing (rev5)
URL : https://patchwork.freedesktop.org/series/86665/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9737 -> Patchwork_19603
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19603/index.html
Known issues
Here are the changes found in Patchwork_19603 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-tgl-y: [PASS][1] -> [DMESG-FAIL][2] ([i915#2601])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19603/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html
- fi-kbl-r: [PASS][3] -> [INCOMPLETE][4] ([i915#2782] /
[i915#2853])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-kbl-r/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19603/fi-kbl-r/igt@i915_selftest@live@gt_heartbeat.html
- fi-cfl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#2853])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19603/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([i915#1372])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19603/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@prime_vgem@basic-fence-flip:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19603/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][11] ([i915#1888]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19603/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19603/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2601]: https://gitlab.freedesktop.org/drm/intel/issues/2601
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2853]: https://gitlab.freedesktop.org/drm/intel/issues/2853
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (43 -> 38)
--
Missing(5): fi-jsl-1 fi-ilk-m540 fi-bsw-cyan fi-icl-u2 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9737 -> Patchwork_19603
CI-20190529: 20190529
CI_DRM_9737: 8fef45d7241af38b7d68a8ad3b11ce8ab38b4491 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5992: b781a32b06a0173a71b4e1ac30d18dd7164a67c4 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19603: 3ba7586ed485d5ebb4f5b9e7158372910630218d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3ba7586ed485 drm/i915/gt: Ratelimit heartbeat completion probing
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19603/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v15 1/2] drm/i915/display: Support PSR Multiple Instances
On Thu, 2021-02-04 at 15:40 +0200, Gwan-gyeong Mun wrote:
> It is a preliminary work for supporting multiple EDP PSR and
> DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
> supportable PSR.
> And this moves and renames the i915_psr structure of drm_i915_private's to
> intel_dp's intel_psr structure.
> It also causes changes in PSR interrupt handling routine for supporting
> multiple transcoders. But it does not change the scenario and timing of
> enabling and disabling PSR. And it not support multiple pipes with
> a single transcoder PSR case yet.
>
> v2: Fix indentation and add comments
> v3: Remove Blank line
> v4: Rebased
> v5: Rebased and Addressed Anshuman's review comment.
> - Move calling of intel_psr_init() to intel_dp_init_connector()
> v6: Address Anshuman's review comments
>- Remove wrong comments and add comments for a limit of supporting of
> a single pipe PSR
> v7: Update intel_psr_compute_config() for supporting multiple transcoder
> PSR on BDW+
> v8: Address Anshuman's review comments
>- Replace DRM_DEBUG_KMS with drm_dbg_kms() / DRM_WARN with drm_warn()
> v9: Fix commit message
> v10: Rebased
> v11: Address Jose's review comment.
> - Reorder calling order of intel_psr2_program_trans_man_trk_ctl().
> - In order to reduce changes keep the old name for drm_i915_private.
> - Change restrictions of multiple instances of PSR.
> v12: Address Jose's review comment.
> - Change the calling of intel_psr2_program_trans_man_trk_ctl() into
> commit_pipe_config().
> - Change a checking order of CAN_PSR() and connector_status to original
> on i915_psr_sink_status_show().
> - Drop unneeded intel_dp_update_pipe() function.
> - In order to wait a specific encoder which belong to crtc_state on
> intel_psr_wait_for_idle(), add checking of encoder.
> - Add an whitespace to comments.
> v13: Rebased and Address Jose's review comment.
> - Add and use for_each_intel_psr_enabled_encoder() macro.
> - In order to use correct frontbuffer_bit for each pipe,
> fix intel_psr_invalidate() and intel_psr_flush().
> - Remove redundant or unneeded codes.
> - Update comments.
> v14: Address Jose's review comment
> - Add and use for_each_intel_encoder_can_psr() macro and
> for_each_intel_encoder_mask_can_psr() macro.
> - Add source_support member variable into intel_psr structure.
> - Update CAN_PSR() macro that checks source_support.
> - Move encoder's PSR availity check to psr_init() from
> psr_compute_config().
> - Remove redundant or unneeded codes.
> v15: Remove wrong mutex lock/unlock of PSR from
> intel_psr2_program_trans_man_trk_ctl()
There is a couple of minor issues yet but we can fix that on top.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Gwan-gyeong Mun
> Cc: José Roberto de Souza
> Cc: Juha-Pekka Heikkila
> Cc: Anshuman Gupta
> Reviewed-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 -
> drivers/gpu/drm/i915/display/intel_display.h | 9 +
> .../drm/i915/display/intel_display_debugfs.c | 95 ++-
> .../drm/i915/display/intel_display_types.h| 51 ++
> drivers/gpu/drm/i915/display/intel_dp.c | 10 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 600 ++
> drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
> drivers/gpu/drm/i915/display/intel_sprite.c | 6 +-
> drivers/gpu/drm/i915/i915_drv.h | 38 --
> drivers/gpu/drm/i915/i915_irq.c | 42 +-
> 10 files changed, 487 insertions(+), 376 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index aca964f7ba72..92c14f3f0abf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14145,8 +14145,6 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> intel_dvo_init(dev_priv);
> }
>
>
> - intel_psr_init(dev_priv);
> -
> for_each_intel_encoder(&dev_priv->drm, encoder) {
> encoder->base.possible_crtcs =
> intel_encoder_possible_crtcs(encoder);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 64ffa34544a7..c72e41b61349 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -417,10 +417,19 @@ enum phy_fia {
> for_each_if((encoder_mask) &\
> drm_encoder_mask(&intel_encoder->base))
>
>
> +#define for_each_intel_encoder_mask_can_psr(dev, intel_encoder,
> encoder_mask) \
> + list_for_each_entry((intel_encoder), &(dev)->mode_config.encoder_list,
> base.head) \
> + for_each_if(((encoder_mask) &
> drm_encoder_mask(&(intel_encoder)->base)) && \
> + intel_encoder_can_psr(intel_encoder))
> +
> #d
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: support ddr5 mem types
On Fri, 2021-02-05 at 07:40 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/display: support ddr5 mem types > URL : https://patchwork.freedesktop.org/series/86726/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_9732_full -> Patchwork_19595_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19595_full absolutely need to > be > verified manually. > > > > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19595_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_19595_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_flip_tiling@flip-yf-tiled@edp-1-pipe-c: > - shard-skl: [PASS][1] -> [FAIL][2] Regression not related, the changes here only affects gen11+. Patch pushed, thanks for the patch Clint. > [1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-skl4/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html > [2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-skl7/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html > > > > > > Known issues > > > Here are the changes found in Patchwork_19595_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_create@create-massive: > - shard-tglb: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) > [3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-tglb2/igt@gem_cre...@create-massive.html > > * igt@gem_ctx_persistence@replace@vecs0: > - shard-iclb: [PASS][4] -> [FAIL][5] ([i915#2410]) > [4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-iclb7/igt@gem_ctx_persistence@repl...@vecs0.html > [5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-iclb7/igt@gem_ctx_persistence@repl...@vecs0.html > > * igt@gem_exec_balancer@hang: > - shard-iclb: [PASS][6] -> [INCOMPLETE][7] ([i915#1895] / > [i915#2295]) > [6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-iclb8/igt@gem_exec_balan...@hang.html > [7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-iclb1/igt@gem_exec_balan...@hang.html > > * igt@gem_exec_fair@basic-none@vcs1: > - shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842]) > [8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html > > * igt@gem_exec_fair@basic-none@vecs0: > - shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842]) > [9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-apl1/igt@gem_exec_fair@basic-n...@vecs0.html > [10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html > > * igt@gem_exec_fair@basic-pace-share@rcs0: > - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) > [11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > [12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > > * igt@gem_exec_fair@basic-pace-solo@rcs0: > - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar > issue > [13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html > [14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html > > * igt@gem_exec_params@secure-non-root: > - shard-tglb: NOTRUN -> [SKIP][15] ([fdo#112283]) > [15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-tglb3/igt@gem_exec_par...@secure-non-root.html > > * igt@gem_exec_reloc@basic-parallel: > - shard-tglb: NOTRUN -> [TIMEOUT][16] ([i915#1729]) > [16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-tglb3/igt@gem_exec_re...@basic-parallel.html > > * igt@gem_exec_schedule@u-fairslice@rcs0: > - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#1610] / > [i915#2803]) > [17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-glk9/igt@gem_exec_schedule@u-fairsl...@rcs0.html > [18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19595/shard-glk4/igt@gem_exec_schedule@u-fairsl...@rcs0.html > - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1610] / > [i915#2803]) > [19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-skl6/igt@gem_exec_schedule@u-fairsl...@rcs0.html > [20]: > https://intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl, tgl: whitelist COMMON_SLICE_CHICKEN3 register
Quoting Sagar Ghuge (2021-02-05 00:33:10) > Adding this register to whitelist will allow UMD to toggle State Cache > Perf fix disable chicken bit. > >"If this bit is enabled, RCC uses BTP+BTI as address tag in its state >cache instead of BTI only" > > which will lead to dropping unnecessary render target flushes and stall > on scoreboard. The rest of the register looks safe to expose, and it passes our sanity checks that the register is local to the context and should not affect others. > Bspec: 11333 > Bspec: 45829 > > Signed-off-by: Sagar Ghuge Acked-by: Chris Wilson The only missing piece of the puzzle that Joonas will require is a Link: to a reviewed userspace patch/MR to confirm the uABI. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v15,1/2] drm/i915/display: Support PSR Multiple Instances
On Fri, 2021-02-05 at 03:08 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v15,1/2] drm/i915/display: Support PSR Multiple
> Instances
> URL : https://patchwork.freedesktop.org/series/86701/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_9732_full -> Patchwork_19590_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
>
Pushed, thanks for the patches.
>
>
>
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_19590_full:
>
> ### Piglit changes ###
>
> Possible regressions
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat4x2_2 (NEW):
> - {pig-icl-1065g7}: NOTRUN -> [CRASH][1]
> [1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19590/pig-icl-1065g7/spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat4x2_2.html
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat4x3 (NEW):
> - {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][2] +7 similar issues
> [2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19590/pig-icl-1065g7/spec@arb_tessellation_shader@execution@tcs-in...@tcs-input-mat4x3.html
>
>
>
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_9732_full and
> Patchwork_19590_full:
>
> ### New Piglit tests (9) ###
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-ivec4:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat2x4:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat3_2:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat4x2_2:
> - Statuses : 1 crash(s)
> - Exec time: [0.53] s
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat4x3:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-uint:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-uvec4:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-uvec4_2:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-vec2:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
>
>
>
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_19590_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_create@create-massive:
> - shard-tglb: NOTRUN -> [DMESG-WARN][3] ([i915#3002])
> [3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19590/shard-tglb1/igt@gem_cre...@create-massive.html
>
> * igt@gem_exec_balancer@hang:
> - shard-iclb: [PASS][4] -> [INCOMPLETE][5] ([i915#1895] /
> [i915#2295] / [i915#3031])
> [4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-iclb8/igt@gem_exec_balan...@hang.html
> [5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19590/shard-iclb2/igt@gem_exec_balan...@hang.html
>
> * igt@gem_exec_fair@basic-none@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][6] ([i915#2842])
> [6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19590/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html
>
> * igt@gem_exec_fair@basic-pace-share@rcs0:
> - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842])
> [7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
> [8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19590/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
>
> * igt@gem_exec_params@secure-non-root:
> - shard-tglb: NOTRUN -> [SKIP][9] ([fdo#112283])
> [9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19590/shard-tglb7/igt@gem_exec_par...@secure-non-root.html
>
> * igt@gem_exec_reloc@basic-parallel:
> - shard-tglb: NOTRUN -> [TIMEOUT][10] ([i915#1729])
> [10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19590/shard-tglb7/igt@gem_exec_re...@basic-parallel.html
>
> * igt@gem_exec_schedule@u-fairslice@rcs0:
> - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#1610] /
> [i915#2803])
> [11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-glk9/igt@gem_exec_schedule@u-fairsl...@rcs0.html
> [12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19590/shard-glk4/igt@gem_exec_schedule@u-fairsl...@rcs0.html
>
> * igt@gem_pipe_control_store_loop@reused-buffer:
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Remove PSR2 on JSL and EHL
On Fri, 2021-02-05 at 04:53 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/display: Remove PSR2 on JSL and EHL > URL : https://patchwork.freedesktop.org/series/86714/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_9732_full -> Patchwork_19592_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19592_full absolutely need to > be > verified manually. > > > > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19592_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_19592_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_flip@2x-flip-vs-suspend@bc-vga1-hdmi-a1: > - shard-hsw: [PASS][1] -> [INCOMPLETE][2] > [1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-hsw7/igt@kms_flip@2x-flip-vs-susp...@bc-vga1-hdmi-a1.html > [2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-hsw2/igt@kms_flip@2x-flip-vs-susp...@bc-vga1-hdmi-a1.html > > * igt@kms_flip_tiling@flip-yf-tiled@edp-1-pipe-c: > - shard-skl: [PASS][3] -> [FAIL][4] > [3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-skl4/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html > [4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-skl4/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html > > > This patch only affects JSL and EHL so this regressions are not related. Pushed, thanks for the patch Edmund. > > > > > Known issues > > > Here are the changes found in Patchwork_19592_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_create@create-massive: > - shard-tglb: NOTRUN -> [DMESG-WARN][5] ([i915#3002]) > [5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-tglb2/igt@gem_cre...@create-massive.html > > * igt@gem_exec_fair@basic-none@rcs0: > - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar > issue > [6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-kbl7/igt@gem_exec_fair@basic-n...@rcs0.html > [7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-kbl6/igt@gem_exec_fair@basic-n...@rcs0.html > > * igt@gem_exec_fair@basic-pace-share@rcs0: > - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) > [8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > [9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > > * igt@gem_exec_params@secure-non-root: > - shard-tglb: NOTRUN -> [SKIP][10] ([fdo#112283]) > [10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-tglb3/igt@gem_exec_par...@secure-non-root.html > > * igt@gem_exec_reloc@basic-parallel: > - shard-tglb: NOTRUN -> [TIMEOUT][11] ([i915#1729]) > [11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-tglb3/igt@gem_exec_re...@basic-parallel.html > > * igt@gem_exec_reloc@basic-wide-active@vcs1: > - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2389]) > [12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html > > * igt@gem_exec_schedule@u-fairslice@rcs0: > - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#1610] / > [i915#2803]) > [13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-kbl1/igt@gem_exec_schedule@u-fairsl...@rcs0.html > [14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-kbl2/igt@gem_exec_schedule@u-fairsl...@rcs0.html > - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#1610] / > [i915#2803]) > [15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-glk9/igt@gem_exec_schedule@u-fairsl...@rcs0.html > [16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-glk3/igt@gem_exec_schedule@u-fairsl...@rcs0.html > - shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#2803]) > [17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-iclb8/igt@gem_exec_schedule@u-fairsl...@rcs0.html > [18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-iclb6/igt@gem_exec_schedule@u-fairsl...@rcs0.html > > * igt@gem_userptr_blits@readonly-mmap-unsync@wb: > - shard-tglb: NOTRUN -> [SKIP][19] ([i915#1704]) +3 similar issues > [19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19592/shard-tglb2/igt@gem_userptr_blits@reado
[Intel-gfx] [PATCH] RFC: dma-buf: Require VM_PFNMAP vma for mmap
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident system memory, there's a huge
temptation to assume that a struct page is always present and useable
like for any more pagecache backed mmap. This has the potential to
result in a uapi nightmare.
To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which
blocks get_user_pages and all the other struct page based
infrastructure for everyone. In spirit this is the uapi counterpart to
the kernel-internal CONFIG_DMABUF_DEBUG.
Motivated by a recent patch which wanted to swich the system dma-buf
heap to vm_insert_page instead of vm_insert_pfn.
v2:
Jason brought up that we also want to guarantee that all ptes have the
pte_special flag set, to catch fast get_user_pages (on architectures
that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would
still allow vm_insert_page, but limiting to VM_PFNMAP will catch that.
From auditing the various functions to insert pfn pte entires
(vm_insert_pfn_prot, remap_pfn_range and all it's callers like
dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so
this should be the correct flag to check for.
References:
https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/
Cc: Jason Gunthorpe
Cc: Suren Baghdasaryan
Cc: Matthew Wilcox
Cc: John Stultz
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..06cb1d2e9fdc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -127,6 +127,7 @@ static struct file_system_type dma_buf_fs_type = {
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
{
struct dma_buf *dmabuf;
+ int ret;
if (!is_dma_buf_file(file))
return -EINVAL;
@@ -142,7 +143,11 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
- return dmabuf->ops->mmap(dmabuf, vma);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+ return ret;
}
static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
@@ -1244,6 +1249,8 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1264,7 +1271,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
- return dmabuf->ops->mmap(dmabuf, vma);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Make psr_safest_params and enable_psr2_sel_fetch parameters read only
On Fri, 2021-02-05 at 04:00 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Make psr_safest_params and enable_psr2_sel_fetch parameters > read only > URL : https://patchwork.freedesktop.org/series/86710/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_9732_full -> Patchwork_19591_full > > > Summary > --- > > **SUCCESS** > > No regressions found. Patch pushed, thanks for the review GG. > > > > > > > Known issues > > > Here are the changes found in Patchwork_19591_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_create@create-massive: > - shard-tglb: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) > [1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-tglb3/igt@gem_cre...@create-massive.html > > * igt@gem_ctx_isolation@preservation-s3@bcs0: > - shard-apl: [PASS][2] -> [DMESG-WARN][3] ([i915#180]) +1 > similar issue > [2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-apl7/igt@gem_ctx_isolation@preservation...@bcs0.html > [3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-apl8/igt@gem_ctx_isolation@preservation...@bcs0.html > > * igt@gem_exec_balancer@hang: > - shard-iclb: [PASS][4] -> [INCOMPLETE][5] ([i915#1895] / > [i915#2295]) > [4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-iclb8/igt@gem_exec_balan...@hang.html > [5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-iclb4/igt@gem_exec_balan...@hang.html > > * igt@gem_exec_fair@basic-none@vcs1: > - shard-iclb: NOTRUN -> [FAIL][6] ([i915#2842]) > [6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html > > * igt@gem_exec_fair@basic-pace-share@rcs0: > - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) > [7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > [8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) > [9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > [10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > > * igt@gem_exec_params@secure-non-root: > - shard-tglb: NOTRUN -> [SKIP][11] ([fdo#112283]) > [11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-tglb5/igt@gem_exec_par...@secure-non-root.html > > * igt@gem_exec_reloc@basic-parallel: > - shard-tglb: NOTRUN -> [TIMEOUT][12] ([i915#1729]) > [12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-tglb5/igt@gem_exec_re...@basic-parallel.html > > * igt@gem_exec_whisper@basic-fds: > - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118] / > [i915#95]) +1 similar issue > [13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-glk6/igt@gem_exec_whis...@basic-fds.html > [14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-glk6/igt@gem_exec_whis...@basic-fds.html > > * igt@gem_userptr_blits@readonly-mmap-unsync@wb: > - shard-tglb: NOTRUN -> [SKIP][15] ([i915#1704]) +3 similar issues > [15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-tglb3/igt@gem_userptr_blits@readonly-mmap-uns...@wb.html > > * igt@gem_userptr_blits@readonly-unsync: > - shard-tglb: NOTRUN -> [SKIP][16] ([fdo#110426] / [i915#1704]) > [16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-tglb5/igt@gem_userptr_bl...@readonly-unsync.html > > * igt@gen3_render_mixed_blits: > - shard-tglb: NOTRUN -> [SKIP][17] ([fdo#109289]) > [17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-tglb5/igt@gen3_render_mixed_blits.html > > * igt@gen9_exec_parse@allowed-all: > - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1436] / > [i915#716]) > [18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-skl7/igt@gen9_exec_pa...@allowed-all.html > [19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-skl6/igt@gen9_exec_pa...@allowed-all.html > > * igt@gen9_exec_parse@bb-chained: > - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#112306]) > [20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19591/shard-tglb5/igt@gen9_exec_pa...@bb-chained.html > > * igt@i915_pm_rc6_residency@rc6-fence: > - shard-hsw: [PASS][21] -> [WARN][22] ([i915#1519]) > [21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9732/shard-hsw7/igt@i915_pm_rc6_reside...@rc6-fence.html > [22]: > https
Re: [Intel-gfx] [PATCH] RFC: dma-buf: Require VM_PFNMAP vma for mmap
Am 05.02.21 um 14:41 schrieb Daniel Vetter:
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident system memory, there's a huge
temptation to assume that a struct page is always present and useable
like for any more pagecache backed mmap. This has the potential to
result in a uapi nightmare.
To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which
blocks get_user_pages and all the other struct page based
infrastructure for everyone. In spirit this is the uapi counterpart to
the kernel-internal CONFIG_DMABUF_DEBUG.
Motivated by a recent patch which wanted to swich the system dma-buf
heap to vm_insert_page instead of vm_insert_pfn.
v2:
Jason brought up that we also want to guarantee that all ptes have the
pte_special flag set, to catch fast get_user_pages (on architectures
that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would
still allow vm_insert_page, but limiting to VM_PFNMAP will catch that.
From auditing the various functions to insert pfn pte entires
(vm_insert_pfn_prot, remap_pfn_range and all it's callers like
dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so
this should be the correct flag to check for.
References:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAKMK7uHi%2BmG0z0HUmNt13QCCvutuRVjpcR0NjRL12k-WbWzkRg%40mail.gmail.com%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7Ca8634bb0be8d4b0de8c108d8c9dbb81c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637481292814972959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8rylgsXhWvQT5zwt1Sc2Nb2IQR%2Fkd16ErIHfZ4PErZI%3D&reserved=0
Cc: Jason Gunthorpe
Cc: Suren Baghdasaryan
Cc: Matthew Wilcox
Cc: John Stultz
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Acked-by: Christian König
---
drivers/dma-buf/dma-buf.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..06cb1d2e9fdc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -127,6 +127,7 @@ static struct file_system_type dma_buf_fs_type = {
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct
*vma)
{
struct dma_buf *dmabuf;
+ int ret;
if (!is_dma_buf_file(file))
return -EINVAL;
@@ -142,7 +143,11 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
- return dmabuf->ops->mmap(dmabuf, vma);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+ return ret;
}
static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
@@ -1244,6 +1249,8 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1264,7 +1271,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
- return dmabuf->ops->mmap(dmabuf, vma);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Index min_{cdclk, voltage_level}[] with pipe
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, February 4, 2021 4:09 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/2] drm/i915: Index min_{cdclk, voltage_level}[]
> with pipe
>
> From: Ville Syrjälä
>
> min_cdclk[] and min_voltage_level[] are supposed to be indexed with the
> pipe. Fix up a few cases where we index via the crtc index (via the atomic
> iterators) instead.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index bf83e9e75227..a9019287f7d5 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2145,10 +2145,10 @@ static int intel_compute_min_cdclk(struct
> intel_cdclk_state *cdclk_state)
> if (IS_ERR(bw_state))
> return PTR_ERR(bw_state);
>
> - if (cdclk_state->min_cdclk[i] == min_cdclk)
> + if (cdclk_state->min_cdclk[crtc->pipe] == min_cdclk)
> continue;
>
> - cdclk_state->min_cdclk[i] = min_cdclk;
> + cdclk_state->min_cdclk[crtc->pipe] = min_cdclk;
>
> ret = intel_atomic_lock_global_state(&cdclk_state->base);
> if (ret)
> @@ -2199,10 +2199,10 @@ static int bxt_compute_min_voltage_level(struct
> intel_cdclk_state *cdclk_state)
> else
> min_voltage_level = 0;
>
> - if (cdclk_state->min_voltage_level[i] == min_voltage_level)
> + if (cdclk_state->min_voltage_level[crtc->pipe] ==
> min_voltage_level)
> continue;
>
> - cdclk_state->min_voltage_level[i] = min_voltage_level;
> + cdclk_state->min_voltage_level[crtc->pipe] =
> min_voltage_level;
>
> ret = intel_atomic_lock_global_state(&cdclk_state->base);
> if (ret)
> --
> 2.26.2
>
> ___
> 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 2/2] drm/i915: Use intel_hdmi_port_clock() more
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, February 4, 2021 4:09 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/2] drm/i915: Use intel_hdmi_port_clock() more
>
> From: Ville Syrjälä
>
> Replace the hand rolled intel_hdmi_port_clock() stuff with the real thing.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 27 ---
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 66e1ac3887c6..457a16c8803a 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2229,6 +2229,16 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
> return MODE_OK;
> }
>
> +static int intel_hdmi_port_clock(int clock, int bpc) {
> + /*
> + * Need to adjust the port link by:
> + * 1.5x for 12bpc
> + * 1.25x for 10bpc
> + */
> + return clock * bpc / 8;
> +}
> +
> static enum drm_mode_status
> intel_hdmi_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> @@ -2260,17 +2270,18 @@ intel_hdmi_mode_valid(struct drm_connector
> *connector,
> clock /= 2;
>
> /* check if we can do 8bpc */
> - status = hdmi_port_clock_valid(hdmi, clock, true, has_hdmi_sink);
> + status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock,
> 8),
> +true, has_hdmi_sink);
>
> if (has_hdmi_sink) {
> /* if we can't do 8bpc we may still be able to do 12bpc */
> if (status != MODE_OK && !HAS_GMCH(dev_priv))
> - status = hdmi_port_clock_valid(hdmi, clock * 3 / 2,
> + status = hdmi_port_clock_valid(hdmi,
> intel_hdmi_port_clock(clock,
> +12),
> true, has_hdmi_sink);
>
> /* if we can't do 8,12bpc we may still be able to do 10bpc */
> if (status != MODE_OK && INTEL_GEN(dev_priv) >= 11)
> - status = hdmi_port_clock_valid(hdmi, clock * 5 / 4,
> + status = hdmi_port_clock_valid(hdmi,
> intel_hdmi_port_clock(clock,
> +10),
> true, has_hdmi_sink);
> }
> if (status != MODE_OK)
> @@ -2378,16 +2389,6 @@ intel_hdmi_ycbcr420_config(struct
> intel_crtc_state *crtc_state,
> return intel_pch_panel_fitting(crtc_state, conn_state); }
>
> -static int intel_hdmi_port_clock(int clock, int bpc) -{
> - /*
> - * Need to adjust the port link by:
> - * 1.5x for 12bpc
> - * 1.25x for 10bpc
> - */
> - return clock * bpc / 8;
> -}
> -
> static int intel_hdmi_compute_bpc(struct intel_encoder *encoder,
> struct intel_crtc_state *crtc_state,
> int clock)
> --
> 2.26.2
>
> ___
> 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 v11 02/10] drm/i915: migrate hsw fdi code to new file.
On Thu, 04 Feb 2021, Jani Nikula wrote:
> From: Dave Airlie
>
> Daniel asked for this, but it's a bit messy and I'm not sure
> how best to clean it up yet.
Thanks, pushed.
BR,
Jani.
>
> Signed-off-by: Dave Airlie
> [Jani: also moved fdi buf trans to intel_fdi.c.]
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 1 +
> drivers/gpu/drm/i915/display/intel_ddi.c | 151 ++-
> drivers/gpu/drm/i915/display/intel_ddi.h | 8 +-
> drivers/gpu/drm/i915/display/intel_fdi.c | 139 +
> drivers/gpu/drm/i915/display/intel_fdi.h | 3 +
> 5 files changed, 156 insertions(+), 146 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index 4934edd51cb0..077ebc7e6396 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -38,6 +38,7 @@
> #include "intel_crt.h"
> #include "intel_ddi.h"
> #include "intel_display_types.h"
> +#include "intel_fdi.h"
> #include "intel_fifo_underrun.h"
> #include "intel_gmbus.h"
> #include "intel_hotplug.h"
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index e2b82e0557e7..28877a31adc0 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -36,10 +36,11 @@
> #include "intel_ddi_buf_trans.h"
> #include "intel_display_types.h"
> #include "intel_dp.h"
> -#include "intel_dp_mst.h"
> #include "intel_dp_link_training.h"
> +#include "intel_dp_mst.h"
> #include "intel_dpio_phy.h"
> #include "intel_dsi.h"
> +#include "intel_fdi.h"
> #include "intel_fifo_underrun.h"
> #include "intel_gmbus.h"
> #include "intel_hdcp.h"
> @@ -91,8 +92,8 @@ static int intel_ddi_hdmi_level(struct intel_encoder
> *encoder,
> * values in advance. This function programs the correct values for
> * DP/eDP/FDI use cases.
> */
> -static void intel_prepare_dp_ddi_buffers(struct intel_encoder *encoder,
> - const struct intel_crtc_state
> *crtc_state)
> +void intel_prepare_dp_ddi_buffers(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> u32 iboost_bit = 0;
> @@ -154,8 +155,8 @@ static void intel_prepare_hdmi_ddi_buffers(struct
> intel_encoder *encoder,
> ddi_translations[level].trans2);
> }
>
> -static void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
> - enum port port)
> +void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
> + enum port port)
> {
> if (IS_BROXTON(dev_priv)) {
> udelay(16);
> @@ -183,7 +184,7 @@ static void intel_wait_ddi_buf_active(struct
> drm_i915_private *dev_priv,
> port_name(port));
> }
>
> -static u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll *pll)
> +u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll *pll)
> {
> switch (pll->info->id) {
> case DPLL_ID_WRPLL1:
> @@ -243,144 +244,6 @@ static u32 icl_pll_to_ddi_clk_sel(struct intel_encoder
> *encoder,
> }
> }
>
> -/* Starting with Haswell, different DDI ports can work in FDI mode for
> - * connection to the PCH-located connectors. For this, it is necessary to
> train
> - * both the DDI port and PCH receiver for the desired DDI buffer settings.
> - *
> - * The recommended port to work in FDI mode is DDI E, which we use here.
> Also,
> - * please note that when FDI mode is active on DDI E, it shares 2 lines with
> - * DDI A (which is used for eDP)
> - */
> -
> -void hsw_fdi_link_train(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state)
> -{
> - struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - u32 temp, i, rx_ctl_val, ddi_pll_sel;
> - int n_entries;
> -
> - intel_ddi_get_buf_trans_fdi(dev_priv, &n_entries);
> -
> - intel_prepare_dp_ddi_buffers(encoder, crtc_state);
> -
> - /* Set the FDI_RX_MISC pwrdn lanes and the 2 workarounds listed at the
> - * mode set "sequence for CRT port" document:
> - * - TP1 to TP2 time with the default value
> - * - FDI delay to 90h
> - *
> - * WaFDIAutoLinkSetTimingOverrride:hsw
> - */
> - intel_de_write(dev_priv, FDI_RX_MISC(PIPE_A),
> -FDI_RX_PWRDN_LANE1_VAL(2) | FDI_RX_PWRDN_LANE0_VAL(2) |
> FDI_RX_TP1_TO_TP2_48 | FDI_RX_FDI_DELAY_90);
> -
> - /* Enable the PCH Receiver FDI PLL */
> - rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE |
> - FDI_RX_PLL_ENABLE |
> - FDI_DP_PORT_WIDTH(crtc_state->fdi_lanes);
> - intel_de_write(dev_priv, F
Re: [Intel-gfx] linux-next: manual merge of the drivers-x86 tree with the drm-misc tree
On Fri, Feb 5, 2021 at 3:05 PM Daniel Vetter wrote: > On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson > wrote: > > > > On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko > > wrote: > > > > > > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko > > > wrote: > > > >> Today's linux-next merge of the drivers-x86 tree got a conflict in: > > > > > > > > Thanks. I already asked Patrik yesterday day if DRM missed to pull an > > > > immutable tag I provided. I think they can pull and resolve conflicts > > > > themselves. Alternatively it would be easy to resolve by Linus by > > > > removing Kconfig lines along with mentioned files, > > > > > > Patrik, I have sent a PR again, so you may consider pulling it, thanks! > > > > Daniel, is this something you can pull into drm or ask one of the > > drm-misc maintainers to do? > > We've already created the conflict, and my understanding is that Linus > wants to have visibility into conflict-y stuff and doesn't mind at all > resolving conflicts. Hence for 5.12 I think we're fine as-is. Fine with me! -- With Best Regards, Andy Shevchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Ratelimit heartbeat completion probing
The heartbeat runs through a few phases that we expect to complete
within a certain number of heartbeat intervals. First we must submit the
heartbeat to the queue, and if the queue is occupied it may take a
couple of intervals before the heartbeat preempts the workload and is
submitted to HW. Once running on HW, completion is not instantaneous as
it may have to first reset the current workload before it itself runs
through the empty request and signals completion. As such, we know that
the heartbeat must take at least the preempt reset timeout and before we
have had a chance to reset the engine, we do not want to issue a global
reset ourselves (simply so that we only try to do one reset at a time
and not confuse ourselves by resetting twice and hitting an innocent.)
So by taking into consideration that once running the request must take
a finite amount of time, we can delay the final completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
Suggested-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 93 +--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
.../drm/i915/gt/selftest_engine_heartbeat.c | 62 ++---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 5 +-
4 files changed, 116 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 93741a65924a..9089689c84eb 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -20,6 +20,18 @@
* issue a reset -- in the hope that restores progress.
*/
+#define HEARTBEAT_COMPLETION 50u /* milliseconds */
+
+static long completion_timeout(const struct intel_engine_cs *engine)
+{
+ long timeout = HEARTBEAT_COMPLETION;
+
+ if (intel_engine_has_preempt_reset(engine))
+ timeout += READ_ONCE(engine->props.preempt_timeout_ms);
+
+ return msecs_to_jiffies(timeout);
+}
+
static bool next_heartbeat(struct intel_engine_cs *engine)
{
long delay;
@@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs *engine)
return false;
delay = msecs_to_jiffies_timeout(delay);
+
+ /*
+* Once we submit a heartbeat to the HW, we know that it will take
+* at least a certain amount of time to complete. On a hanging system
+* it will first have to wait for the preempt reset timeout, and
+* then it will take some time for the reset to resume with the
+* heartbeat and for it to complete. So once we have submitted the
+* heartbeat to HW, we can wait a while longer before declaring the
+* engine stuck and forcing a reset ourselves. If we do a reset
+* and the engine is also doing a reset, it is possible that we
+* reset the engine twice, harming an innocent.
+*
+* Before we have sumitted the heartbeat, we do not want to change
+* the interval as we to promote the heartbeat and trigger preemption
+* in a deterministic time frame.
+*/
+ if (engine->heartbeat.systole &&
+ i915_request_is_active(engine->heartbeat.systole))
+ delay = max(delay, completion_timeout(engine));
+
if (delay >= HZ)
delay = round_jiffies_up_relative(delay);
mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, delay + 1);
@@ -48,12 +80,51 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
return rq;
}
+static void defibrillator(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+ struct intel_engine_cs *engine =
+ container_of(cb, typeof(*engine), heartbeat.cb);
+
+ if (READ_ONCE(engine->heartbeat.systole))
+ mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, 0);
+}
+
+static void
+untrack_heartbeat(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ rq = fetch_and_zero(&engine->heartbeat.systole);
+ if (!rq)
+ return;
+
+ ENGINE_TRACE(engine, "heartbeat completed: %llx:%lld\n",
+rq->fence.context, rq->fence.seqno);
+
+ dma_fence_remove_callback(&rq->fence, &engine->heartbeat.cb);
+ i915_request_put(rq);
+}
+
+static void
+track_heartbeat(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ ENGINE_TRACE(engine, "heartbeat started: %llx:%lld\n",
+rq->fence.context, rq->fence.seqno);
+
+ dma_fence_add_callback(&rq->fence,
+ &engine->heartbeat.cb,
+ defibrillator);
+ engine->heartbeat.systole = i915_request_get(rq);
+ if
[Intel-gfx] [PATCH] drm/i915/gt: Ratelimit heartbeat completion probing
The heartbeat runs through a few phases that we expect to complete
within a certain number of heartbeat intervals. First we must submit the
heartbeat to the queue, and if the queue is occupied it may take a
couple of intervals before the heartbeat preempts the workload and is
submitted to HW. Once running on HW, completion is not instantaneous as
it may have to first reset the current workload before it itself runs
through the empty request and signals completion. As such, we know that
the heartbeat must take at least the preempt reset timeout and before we
have had a chance to reset the engine, we do not want to issue a global
reset ourselves (simply so that we only try to do one reset at a time
and not confuse ourselves by resetting twice and hitting an innocent.)
So by taking into consideration that once running the request must take
a finite amount of time, we can delay the final completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
Suggested-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 93 +--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
.../drm/i915/gt/selftest_engine_heartbeat.c | 65 ++---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 5 +-
4 files changed, 119 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 93741a65924a..01d8a04f77b6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -20,6 +20,18 @@
* issue a reset -- in the hope that restores progress.
*/
+#define HEARTBEAT_COMPLETION 50u /* milliseconds */
+
+static long completion_timeout(const struct intel_engine_cs *engine)
+{
+ long timeout = HEARTBEAT_COMPLETION;
+
+ if (intel_engine_has_preempt_reset(engine))
+ timeout += READ_ONCE(engine->props.preempt_timeout_ms);
+
+ return msecs_to_jiffies(timeout);
+}
+
static bool next_heartbeat(struct intel_engine_cs *engine)
{
long delay;
@@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs *engine)
return false;
delay = msecs_to_jiffies_timeout(delay);
+
+ /*
+* Once we submit a heartbeat to the HW, we know that it will take
+* at least a certain amount of time to complete. On a hanging system
+* it will first have to wait for the preempt reset timeout, and
+* then it will take some time for the reset to resume with the
+* heartbeat and for it to complete. So once we have submitted the
+* heartbeat to HW, we can wait a while longer before declaring the
+* engine stuck and forcing a reset ourselves. If we do a reset
+* and the engine is also doing a reset, it is possible that we
+* reset the engine twice, harming an innocent.
+*
+* Before we have sumitted the heartbeat, we do not want to change
+* the interval as we to promote the heartbeat and trigger preemption
+* in a deterministic time frame.
+*/
+ if (engine->heartbeat.systole &&
+ i915_request_is_active(engine->heartbeat.systole))
+ delay = max(delay, completion_timeout(engine));
+
if (delay >= HZ)
delay = round_jiffies_up_relative(delay);
mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, delay + 1);
@@ -48,12 +80,51 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
return rq;
}
+static void defibrillator(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+ struct intel_engine_cs *engine =
+ container_of(cb, typeof(*engine), heartbeat.cb);
+
+ if (READ_ONCE(engine->heartbeat.systole))
+ mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, 0);
+}
+
+static void
+untrack_heartbeat(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ rq = fetch_and_zero(&engine->heartbeat.systole);
+ if (!rq)
+ return;
+
+ ENGINE_TRACE(engine, "heartbeat completed: %llx:%lld\n",
+rq->fence.context, rq->fence.seqno);
+
+ dma_fence_remove_callback(&rq->fence, &engine->heartbeat.cb);
+ i915_request_put(rq);
+}
+
+static void
+track_heartbeat(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ ENGINE_TRACE(engine, "heartbeat started: %llx:%lld\n",
+rq->fence.context, rq->fence.seqno);
+
+ dma_fence_add_callback(&rq->fence,
+ &engine->heartbeat.cb,
+ defibrillator);
+ engine->heartbeat.systole = i915_request_get(rq);
+ if
[Intel-gfx] [PATCH v12 2/8] drm/i915: move pipe update code into crtc. (v2)
From: Dave Airlie
Daniel suggested this should move here.
v2: move vrr code.
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 241
drivers/gpu/drm/i915/display/intel_sprite.c | 238 ---
2 files changed, 241 insertions(+), 238 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index eb478712c381..8bfa8fc2efdb 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -10,6 +10,9 @@
#include
#include
+#include "i915_trace.h"
+#include "i915_vgpu.h"
+
#include "intel_atomic.h"
#include "intel_atomic_plane.h"
#include "intel_color.h"
@@ -17,8 +20,11 @@
#include "intel_cursor.h"
#include "intel_display_debugfs.h"
#include "intel_display_types.h"
+#include "intel_dsi.h"
#include "intel_pipe_crc.h"
+#include "intel_psr.h"
#include "intel_sprite.h"
+#include "intel_vrr.h"
#include "i9xx_plane.h"
#include "skl_universal_plane.h"
@@ -332,3 +338,238 @@ int intel_crtc_init(struct drm_i915_private *dev_priv,
enum pipe pipe)
return ret;
}
+
+int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
+int usecs)
+{
+ /* paranoia */
+ if (!adjusted_mode->crtc_htotal)
+ return 1;
+
+ return DIV_ROUND_UP(usecs * adjusted_mode->crtc_clock,
+ 1000 * adjusted_mode->crtc_htotal);
+}
+
+static int intel_mode_vblank_start(const struct drm_display_mode *mode)
+{
+ int vblank_start = mode->crtc_vblank_start;
+
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ vblank_start = DIV_ROUND_UP(vblank_start, 2);
+
+ return vblank_start;
+}
+
+/**
+ * intel_pipe_update_start() - start update of a set of display registers
+ * @new_crtc_state: the new crtc state
+ *
+ * Mark the start of an update to pipe registers that should be updated
+ * atomically regarding vblank. If the next vblank will happens within
+ * the next 100 us, this function waits until the vblank passes.
+ *
+ * After a successful call to this function, interrupts will be disabled
+ * until a subsequent call to intel_pipe_update_end(). That is done to
+ * avoid random delays.
+ */
+void intel_pipe_update_start(const struct intel_crtc_state *new_crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_display_mode *adjusted_mode =
&new_crtc_state->hw.adjusted_mode;
+ long timeout = msecs_to_jiffies_timeout(1);
+ int scanline, min, max, vblank_start;
+ wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(&crtc->base);
+ bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) ||
IS_CHERRYVIEW(dev_priv)) &&
+ intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
+ DEFINE_WAIT(wait);
+
+ if (new_crtc_state->uapi.async_flip)
+ return;
+
+ if (new_crtc_state->vrr.enable)
+ vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
+ else
+ vblank_start = intel_mode_vblank_start(adjusted_mode);
+
+ /* FIXME needs to be calibrated sensibly */
+ min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
+ VBLANK_EVASION_TIME_US);
+ max = vblank_start - 1;
+
+ if (min <= 0 || max <= 0)
+ goto irq_disable;
+
+ if (drm_WARN_ON(&dev_priv->drm, drm_crtc_vblank_get(&crtc->base)))
+ goto irq_disable;
+
+ /*
+* Wait for psr to idle out after enabling the VBL interrupts
+* VBL interrupts will start the PSR exit and prevent a PSR
+* re-entry as well.
+*/
+ intel_psr_wait_for_idle(new_crtc_state);
+
+ local_irq_disable();
+
+ crtc->debug.min_vbl = min;
+ crtc->debug.max_vbl = max;
+ trace_intel_pipe_update_start(crtc);
+
+ for (;;) {
+ /*
+* prepare_to_wait() has a memory barrier, which guarantees
+* other CPUs can see the task state update by the time we
+* read the scanline.
+*/
+ prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE);
+
+ scanline = intel_get_crtc_scanline(crtc);
+ if (scanline < min || scanline > max)
+ break;
+
+ if (!timeout) {
+ drm_err(&dev_priv->drm,
+ "Potential atomic update failure on pipe %c\n",
+ pipe_name(crtc->pipe));
+ break;
+ }
+
+ local_irq_enable();
+
+ timeout = schedule_timeout(timeout);
+
+ local_irq_disable();
+ }
+
+ finish_wait(wq, &wait);
+
[Intel-gfx] [PATCH v12 0/8] drm/i915: refactor intel_display.c + a bit more
Rebase of [1], which wen't stale in less than a day, but managed to push the first two. Progress! This also addresses Ville's review comments, I hope. BR, Jani. [1] https://patchwork.freedesktop.org/series/86723/ Dave Airlie (8): drm/i915: migrate skl planes code new file (v5) drm/i915: move pipe update code into crtc. (v2) drm/i915: split fb scalable checks into g4x and skl versions drm/i915: move is_ccs_modifier to an inline drm/i915: migrate pll enable/disable code to intel_dpll.[ch] drm/i915: migrate i9xx plane get config drm/i915: refactor skylake scaler code into new file. drm/i915: move ddi pll state get to dpll mgr drivers/gpu/drm/i915/Makefile |4 +- drivers/gpu/drm/i915/display/i9xx_plane.c | 123 +- drivers/gpu/drm/i915/display/i9xx_plane.h |4 + drivers/gpu/drm/i915/display/icl_dsi.c|2 + drivers/gpu/drm/i915/display/intel_atomic.c |2 +- drivers/gpu/drm/i915/display/intel_crtc.c | 254 +- drivers/gpu/drm/i915/display/intel_ddi.c |2 + drivers/gpu/drm/i915/display/intel_display.c | 2631 ++--- drivers/gpu/drm/i915/display/intel_display.h | 37 +- .../drm/i915/display/intel_display_types.h| 36 + drivers/gpu/drm/i915/display/intel_dp.c |1 + drivers/gpu/drm/i915/display/intel_dp_mst.c |1 + drivers/gpu/drm/i915/display/intel_dpll.c | 509 drivers/gpu/drm/i915/display/intel_dpll.h | 18 + drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 223 ++ drivers/gpu/drm/i915/display/intel_dpll_mgr.h |2 + drivers/gpu/drm/i915/display/intel_pps.c |1 + drivers/gpu/drm/i915/display/intel_psr.c |1 + drivers/gpu/drm/i915/display/intel_sprite.c | 1714 +-- drivers/gpu/drm/i915/display/intel_sprite.h |7 - drivers/gpu/drm/i915/display/skl_scaler.c | 556 drivers/gpu/drm/i915/display/skl_scaler.h | 29 + .../drm/i915/display/skl_universal_plane.c| 2266 ++ .../drm/i915/display/skl_universal_plane.h| 37 + drivers/gpu/drm/i915/display/vlv_dsi.c|1 + drivers/gpu/drm/i915/intel_pm.c |1 + 26 files changed, 4305 insertions(+), 4157 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/skl_scaler.c create mode 100644 drivers/gpu/drm/i915/display/skl_scaler.h create mode 100644 drivers/gpu/drm/i915/display/skl_universal_plane.c create mode 100644 drivers/gpu/drm/i915/display/skl_universal_plane.h -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v12 4/8] drm/i915: move is_ccs_modifier to an inline
From: Dave Airlie
There is no need for this to be out of line.
Reviewed-by: Ville Syrjälä
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 9 -
drivers/gpu/drm/i915/display/intel_display.h | 1 -
drivers/gpu/drm/i915/display/intel_display_types.h | 9 +
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a259ca5433f7..ac652283abfe 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1823,15 +1823,6 @@ intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
}
}
-bool is_ccs_modifier(u64 modifier)
-{
- return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
- modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC ||
- modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS ||
- modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
- modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
-}
-
static int gen12_ccs_aux_stride(struct drm_framebuffer *fb, int ccs_plane)
{
return DIV_ROUND_UP(fb->pitches[skl_ccs_to_main_plane(fb, ccs_plane)],
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 3c153eb78092..2bbd2ee9147e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -517,7 +517,6 @@ void intel_link_compute_m_n(u16 bpp, int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
bool constant_n, bool fec_enable);
-bool is_ccs_modifier(u64 modifier);
void lpt_disable_clkout_dp(struct drm_i915_private *dev_priv);
u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
u32 pixel_format, u64 modifier);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 6183f2f0424b..ebaa9d0ed376 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1946,6 +1946,15 @@ static inline u32 intel_fdi_link_freq(struct
drm_i915_private *dev_priv,
return dev_priv->fdi_pll_freq;
}
+static inline bool is_ccs_modifier(u64 modifier)
+{
+ return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
+ modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC ||
+ modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS ||
+ modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+ modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+}
+
static inline bool is_ccs_plane(const struct drm_framebuffer *fb, int plane)
{
if (!is_ccs_modifier(fb->modifier))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v12 3/8] drm/i915: split fb scalable checks into g4x and skl versions
From: Dave Airlie
This just cleans these up a bit.
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sprite.c| 7 +++
drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 ++--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index b8288330dbc9..46fcb5b9983f 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -1365,19 +1365,18 @@ g4x_plane_get_hw_state(struct intel_plane *plane,
return ret;
}
-static bool intel_fb_scalable(const struct drm_framebuffer *fb)
+static bool g4x_fb_scalable(const struct drm_framebuffer *fb)
{
if (!fb)
return false;
switch (fb->format->format) {
case DRM_FORMAT_C8:
- return false;
case DRM_FORMAT_XRGB16161616F:
case DRM_FORMAT_ARGB16161616F:
case DRM_FORMAT_XBGR16161616F:
case DRM_FORMAT_ABGR16161616F:
- return INTEL_GEN(to_i915(fb->dev)) >= 11;
+ return false;
default:
return true;
}
@@ -1454,7 +1453,7 @@ g4x_sprite_check(struct intel_crtc_state *crtc_state,
int max_scale = DRM_PLANE_HELPER_NO_SCALING;
int ret;
- if (intel_fb_scalable(plane_state->hw.fb)) {
+ if (g4x_fb_scalable(plane_state->hw.fb)) {
if (INTEL_GEN(dev_priv) < 7) {
min_scale = 1;
max_scale = 16 << 16;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 29c2e3693e8b..4ae1a2ef29ec 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1618,7 +1618,7 @@ static int skl_check_plane_surface(struct
intel_plane_state *plane_state)
return 0;
}
-static bool intel_fb_scalable(const struct drm_framebuffer *fb)
+static bool skl_fb_scalable(const struct drm_framebuffer *fb)
{
if (!fb)
return false;
@@ -1651,7 +1651,7 @@ static int skl_plane_check(struct intel_crtc_state
*crtc_state,
return ret;
/* use scaler when colorkey is not required */
- if (!plane_state->ckey.flags && intel_fb_scalable(fb)) {
+ if (!plane_state->ckey.flags && skl_fb_scalable(fb)) {
min_scale = 1;
max_scale = skl_plane_max_scale(dev_priv, fb);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v12 5/8] drm/i915: migrate pll enable/disable code to intel_dpll.[ch]
From: Dave Airlie
This moves the older i9xx/vlv/chv enable/disable to dpll file.
Signed-off-by: Dave Airlie
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 512 ---
drivers/gpu/drm/i915/display/intel_display.h | 3 -
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_dpll.c| 509 ++
drivers/gpu/drm/i915/display/intel_dpll.h| 18 +
drivers/gpu/drm/i915/display/intel_pps.c | 1 +
6 files changed, 529 insertions(+), 515 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ac652283abfe..ac8f89849510 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -113,10 +113,6 @@ static void i9xx_set_pipeconf(const struct
intel_crtc_state *crtc_state);
static void ilk_set_pipeconf(const struct intel_crtc_state *crtc_state);
static void hsw_set_pipeconf(const struct intel_crtc_state *crtc_state);
static void bdw_set_pipemisc(const struct intel_crtc_state *crtc_state);
-static void vlv_prepare_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config);
-static void chv_prepare_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config);
static void ilk_pfit_enable(const struct intel_crtc_state *crtc_state);
static void intel_modeset_setup_hw_state(struct drm_device *dev,
struct drm_modeset_acquire_ctx *ctx);
@@ -569,224 +565,6 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
assert_pch_hdmi_disabled(dev_priv, pipe, PORT_D, PCH_HDMID);
}
-static void _vlv_enable_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum pipe pipe = crtc->pipe;
-
- intel_de_write(dev_priv, DPLL(pipe), pipe_config->dpll_hw_state.dpll);
- intel_de_posting_read(dev_priv, DPLL(pipe));
- udelay(150);
-
- if (intel_de_wait_for_set(dev_priv, DPLL(pipe), DPLL_LOCK_VLV, 1))
- drm_err(&dev_priv->drm, "DPLL %d failed to lock\n", pipe);
-}
-
-static void vlv_enable_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum pipe pipe = crtc->pipe;
-
- assert_pipe_disabled(dev_priv, pipe_config->cpu_transcoder);
-
- /* PLL is protected by panel, make sure we can write it */
- assert_panel_unlocked(dev_priv, pipe);
-
- if (pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE)
- _vlv_enable_pll(crtc, pipe_config);
-
- intel_de_write(dev_priv, DPLL_MD(pipe),
- pipe_config->dpll_hw_state.dpll_md);
- intel_de_posting_read(dev_priv, DPLL_MD(pipe));
-}
-
-
-static void _chv_enable_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum pipe pipe = crtc->pipe;
- enum dpio_channel port = vlv_pipe_to_channel(pipe);
- u32 tmp;
-
- vlv_dpio_get(dev_priv);
-
- /* Enable back the 10bit clock to display controller */
- tmp = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW14(port));
- tmp |= DPIO_DCLKP_EN;
- vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW14(port), tmp);
-
- vlv_dpio_put(dev_priv);
-
- /*
-* Need to wait > 100ns between dclkp clock enable bit and PLL enable.
-*/
- udelay(1);
-
- /* Enable PLL */
- intel_de_write(dev_priv, DPLL(pipe), pipe_config->dpll_hw_state.dpll);
-
- /* Check PLL is locked */
- if (intel_de_wait_for_set(dev_priv, DPLL(pipe), DPLL_LOCK_VLV, 1))
- drm_err(&dev_priv->drm, "PLL %d failed to lock\n", pipe);
-}
-
-static void chv_enable_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum pipe pipe = crtc->pipe;
-
- assert_pipe_disabled(dev_priv, pipe_config->cpu_transcoder);
-
- /* PLL is protected by panel, make sure we can write it */
- assert_panel_unlocked(dev_priv, pipe);
-
- if (pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE)
- _chv_enable_pll(crtc, pipe_config);
-
- if (pipe != PIPE_A) {
- /*
-* WaPixelRepeatModeFixForC0:chv
-*
-* DPLLCMD is AWOL. Use chicken bits to propagate
-* the value from DPLLBMD to either pipe B or C.
-*/
- intel_de_write(dev_priv, CBR4_VLV, CBR_DPLLBMD_PIPE(pipe));
- intel_de_write(dev_priv,
[Intel-gfx] [PATCH v12 6/8] drm/i915: migrate i9xx plane get config
From: Dave Airlie
Migrate this code out like the skylake code.
Signed-off-by: Dave Airlie
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/i9xx_plane.c| 119 +++
drivers/gpu/drm/i915/display/i9xx_plane.h| 4 +
drivers/gpu/drm/i915/display/intel_display.c | 119 ---
3 files changed, 123 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index d116dee201aa..0523e2c79d16 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -893,3 +893,122 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
return ERR_PTR(ret);
}
+static int i9xx_format_to_fourcc(int format)
+{
+ switch (format) {
+ case DISPPLANE_8BPP:
+ return DRM_FORMAT_C8;
+ case DISPPLANE_BGRA555:
+ return DRM_FORMAT_ARGB1555;
+ case DISPPLANE_BGRX555:
+ return DRM_FORMAT_XRGB1555;
+ case DISPPLANE_BGRX565:
+ return DRM_FORMAT_RGB565;
+ default:
+ case DISPPLANE_BGRX888:
+ return DRM_FORMAT_XRGB;
+ case DISPPLANE_RGBX888:
+ return DRM_FORMAT_XBGR;
+ case DISPPLANE_BGRA888:
+ return DRM_FORMAT_ARGB;
+ case DISPPLANE_RGBA888:
+ return DRM_FORMAT_ABGR;
+ case DISPPLANE_BGRX101010:
+ return DRM_FORMAT_XRGB2101010;
+ case DISPPLANE_RGBX101010:
+ return DRM_FORMAT_XBGR2101010;
+ case DISPPLANE_BGRA101010:
+ return DRM_FORMAT_ARGB2101010;
+ case DISPPLANE_RGBA101010:
+ return DRM_FORMAT_ABGR2101010;
+ case DISPPLANE_RGBX161616:
+ return DRM_FORMAT_XBGR16161616F;
+ }
+}
+
+void
+i9xx_get_initial_plane_config(struct intel_crtc *crtc,
+ struct intel_initial_plane_config *plane_config)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_plane *plane = to_intel_plane(crtc->base.primary);
+ enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
+ enum pipe pipe;
+ u32 val, base, offset;
+ int fourcc, pixel_format;
+ unsigned int aligned_height;
+ struct drm_framebuffer *fb;
+ struct intel_framebuffer *intel_fb;
+
+ if (!plane->get_hw_state(plane, &pipe))
+ return;
+
+ drm_WARN_ON(dev, pipe != crtc->pipe);
+
+ intel_fb = kzalloc(sizeof(*intel_fb), GFP_KERNEL);
+ if (!intel_fb) {
+ drm_dbg_kms(&dev_priv->drm, "failed to alloc fb\n");
+ return;
+ }
+
+ fb = &intel_fb->base;
+
+ fb->dev = dev;
+
+ val = intel_de_read(dev_priv, DSPCNTR(i9xx_plane));
+
+ if (INTEL_GEN(dev_priv) >= 4) {
+ if (val & DISPPLANE_TILED) {
+ plane_config->tiling = I915_TILING_X;
+ fb->modifier = I915_FORMAT_MOD_X_TILED;
+ }
+
+ if (val & DISPPLANE_ROTATE_180)
+ plane_config->rotation = DRM_MODE_ROTATE_180;
+ }
+
+ if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B &&
+ val & DISPPLANE_MIRROR)
+ plane_config->rotation |= DRM_MODE_REFLECT_X;
+
+ pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
+ fourcc = i9xx_format_to_fourcc(pixel_format);
+ fb->format = drm_format_info(fourcc);
+
+ if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+ offset = intel_de_read(dev_priv, DSPOFFSET(i9xx_plane));
+ base = intel_de_read(dev_priv, DSPSURF(i9xx_plane)) &
0xf000;
+ } else if (INTEL_GEN(dev_priv) >= 4) {
+ if (plane_config->tiling)
+ offset = intel_de_read(dev_priv,
+ DSPTILEOFF(i9xx_plane));
+ else
+ offset = intel_de_read(dev_priv,
+ DSPLINOFF(i9xx_plane));
+ base = intel_de_read(dev_priv, DSPSURF(i9xx_plane)) &
0xf000;
+ } else {
+ base = intel_de_read(dev_priv, DSPADDR(i9xx_plane));
+ }
+ plane_config->base = base;
+
+ val = intel_de_read(dev_priv, PIPESRC(pipe));
+ fb->width = ((val >> 16) & 0xfff) + 1;
+ fb->height = ((val >> 0) & 0xfff) + 1;
+
+ val = intel_de_read(dev_priv, DSPSTRIDE(i9xx_plane));
+ fb->pitches[0] = val & 0xffc0;
+
+ aligned_height = intel_fb_align_height(fb, 0, fb->height);
+
+ plane_config->size = fb->pitches[0] * aligned_height;
+
+ drm_dbg_kms(&dev_priv->drm,
+ "%s/%s with fb: size=%dx%d@%d, offset=%x, pitch %d, size
0x%x\n",
+ crtc->base.name, plane->base.name, fb->width, fb->height,
+
[Intel-gfx] [PATCH v12 8/8] drm/i915: move ddi pll state get to dpll mgr
From: Dave Airlie
This just migrates the hsw+ code to a better place.
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 219 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 223 ++
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 2 +
3 files changed, 226 insertions(+), 218 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index beed08c00b6c..f7c1f036d38f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6520,212 +6520,6 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc,
return ret;
}
-static void dg1_get_ddi_pll(struct drm_i915_private *dev_priv, enum port port,
- struct intel_crtc_state *pipe_config)
-{
- enum icl_port_dpll_id port_dpll_id = ICL_PORT_DPLL_DEFAULT;
- enum phy phy = intel_port_to_phy(dev_priv, port);
- struct icl_port_dpll *port_dpll;
- struct intel_shared_dpll *pll;
- enum intel_dpll_id id;
- bool pll_active;
- u32 clk_sel;
-
- clk_sel = intel_de_read(dev_priv, DG1_DPCLKA_CFGCR0(phy)) &
DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- id = DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_DPLL_MAP(clk_sel, phy);
-
- if (WARN_ON(id > DPLL_ID_DG1_DPLL3))
- return;
-
- pll = intel_get_shared_dpll_by_id(dev_priv, id);
- port_dpll = &pipe_config->icl_port_dplls[port_dpll_id];
-
- port_dpll->pll = pll;
- pll_active = intel_dpll_get_hw_state(dev_priv, pll,
-&port_dpll->hw_state);
- drm_WARN_ON(&dev_priv->drm, !pll_active);
-
- icl_set_active_port_dpll(pipe_config, port_dpll_id);
-}
-
-static void icl_get_ddi_pll(struct drm_i915_private *dev_priv, enum port port,
- struct intel_crtc_state *pipe_config)
-{
- enum phy phy = intel_port_to_phy(dev_priv, port);
- enum icl_port_dpll_id port_dpll_id;
- struct icl_port_dpll *port_dpll;
- struct intel_shared_dpll *pll;
- enum intel_dpll_id id;
- bool pll_active;
- i915_reg_t reg;
- u32 temp;
-
- if (intel_phy_is_combo(dev_priv, phy)) {
- u32 mask, shift;
-
- if (IS_ALDERLAKE_S(dev_priv)) {
- reg = ADLS_DPCLKA_CFGCR(phy);
- mask = ADLS_DPCLKA_CFGCR_DDI_CLK_SEL_MASK(phy);
- shift = ADLS_DPCLKA_CFGCR_DDI_SHIFT(phy);
- } else if (IS_ROCKETLAKE(dev_priv)) {
- reg = ICL_DPCLKA_CFGCR0;
- mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- shift = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
- } else {
- reg = ICL_DPCLKA_CFGCR0;
- mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- shift = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
- }
-
- temp = intel_de_read(dev_priv, reg) & mask;
- id = temp >> shift;
- port_dpll_id = ICL_PORT_DPLL_DEFAULT;
- } else if (intel_phy_is_tc(dev_priv, phy)) {
- u32 clk_sel = intel_de_read(dev_priv, DDI_CLK_SEL(port)) &
DDI_CLK_SEL_MASK;
-
- if (clk_sel == DDI_CLK_SEL_MG) {
- id = icl_tc_port_to_pll_id(intel_port_to_tc(dev_priv,
- port));
- port_dpll_id = ICL_PORT_DPLL_MG_PHY;
- } else {
- drm_WARN_ON(&dev_priv->drm,
- clk_sel < DDI_CLK_SEL_TBT_162);
- id = DPLL_ID_ICL_TBTPLL;
- port_dpll_id = ICL_PORT_DPLL_DEFAULT;
- }
- } else {
- drm_WARN(&dev_priv->drm, 1, "Invalid port %x\n", port);
- return;
- }
-
- pll = intel_get_shared_dpll_by_id(dev_priv, id);
- port_dpll = &pipe_config->icl_port_dplls[port_dpll_id];
-
- port_dpll->pll = pll;
- pll_active = intel_dpll_get_hw_state(dev_priv, pll,
-&port_dpll->hw_state);
- drm_WARN_ON(&dev_priv->drm, !pll_active);
-
- icl_set_active_port_dpll(pipe_config, port_dpll_id);
-}
-
-static void cnl_get_ddi_pll(struct drm_i915_private *dev_priv, enum port port,
- struct intel_crtc_state *pipe_config)
-{
- struct intel_shared_dpll *pll;
- enum intel_dpll_id id;
- bool pll_active;
- u32 temp;
-
- temp = intel_de_read(dev_priv, DPCLKA_CFGCR0) &
DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
- id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
-
- if (drm_WARN_ON(&dev_priv->drm, id < SKL_DPLL0 || id > SKL_DPLL2))
- return;
-
- pll = intel_get_shared_dpll_by_id(dev_pri
[Intel-gfx] [PATCH v12 7/8] drm/i915: refactor skylake scaler code into new file.
From: Dave Airlie
This moves the code from various places and consolidates it
into one new file.
v2:
- rename skl_program_plane -> skl_program_plane_scaler (Ville)
- also move skl_pfit_enable, and consequently make some skl_scaler_*
functions static to skl_scaler.c (Ville)
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/icl_dsi.c| 1 +
drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 488 +--
drivers/gpu/drm/i915/display/intel_display.h | 6 -
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
drivers/gpu/drm/i915/display/intel_sprite.c | 62 --
drivers/gpu/drm/i915/display/intel_sprite.h | 7 -
drivers/gpu/drm/i915/display/skl_scaler.c | 556 ++
drivers/gpu/drm/i915/display/skl_scaler.h | 29 +
.../drm/i915/display/skl_universal_plane.c| 3 +-
.../drm/i915/display/skl_universal_plane.h| 4 +
drivers/gpu/drm/i915/display/vlv_dsi.c| 1 +
14 files changed, 598 insertions(+), 564 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/skl_scaler.c
create mode 100644 drivers/gpu/drm/i915/display/skl_scaler.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9388e09184fe..235679637d1c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -226,6 +226,7 @@ i915-y += \
display/intel_tc.o \
display/intel_vga.o \
display/i9xx_plane.o \
+ display/skl_scaler.o \
display/skl_universal_plane.o
i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 9eeec6fadec7..7ef6b89c79d9 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -35,6 +35,7 @@
#include "intel_dsi.h"
#include "intel_panel.h"
#include "intel_vdsc.h"
+#include "skl_scaler.h"
#include "skl_universal_plane.h"
static int header_credits_available(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index e00fdc47c0eb..27f7d7109ca3 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -40,7 +40,7 @@
#include "intel_global_state.h"
#include "intel_hdcp.h"
#include "intel_psr.h"
-#include "intel_sprite.h"
+#include "skl_universal_plane.h"
/**
* intel_digital_connector_atomic_get_property - hook for
connector->atomic_get_property.
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index f4746c1edabe..3c4003605f93 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -54,6 +54,7 @@
#include "intel_tc.h"
#include "intel_vdsc.h"
#include "intel_vrr.h"
+#include "skl_scaler.h"
#include "skl_universal_plane.h"
static const u8 index_to_dp_signal_levels[] = {
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1826b4fc6cec..beed08c00b6c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -94,6 +94,7 @@
#include "intel_tc.h"
#include "intel_vga.h"
#include "i9xx_plane.h"
+#include "skl_scaler.h"
#include "skl_universal_plane.h"
static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
@@ -2521,38 +2522,6 @@ intel_plane_fence_y_offset(const struct
intel_plane_state *plane_state)
return y;
}
-static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
-{
- struct drm_device *dev = intel_crtc->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- unsigned long irqflags;
-
- spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
-
- intel_de_write_fw(dev_priv, SKL_PS_CTRL(intel_crtc->pipe, id), 0);
- intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(intel_crtc->pipe, id), 0);
- intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(intel_crtc->pipe, id), 0);
-
- spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
-}
-
-/*
- * This function detaches (aka. unbinds) unused scalers in hardware
- */
-static void skl_detach_scalers(const struct intel_crtc_state *crtc_state)
-{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->uapi.crtc);
- const struct intel_crtc_scaler_state *scaler_state =
- &crtc_state->scaler_state;
- int i;
-
- /* loop through and disable scalers that aren't in use */
- for (i = 0; i < intel_crtc->num_scalers; i++) {
- if (!scaler_state->scalers[i].in_use)
- skl_detach_scaler(intel_crtc, i);
- }
-}
-
static int
__intel_display_resume(struct drm_device *dev,
struc
Re: [Intel-gfx] [PATCH v12 7/8] drm/i915: refactor skylake scaler code into new file.
On Fri, Feb 05, 2021 at 04:48:42PM +0200, Jani Nikula wrote:
> From: Dave Airlie
>
> This moves the code from various places and consolidates it
> into one new file.
>
> v2:
> - rename skl_program_plane -> skl_program_plane_scaler (Ville)
> - also move skl_pfit_enable, and consequently make some skl_scaler_*
> functions static to skl_scaler.c (Ville)
>
> Signed-off-by: Dave Airlie
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/icl_dsi.c| 1 +
> drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> drivers/gpu/drm/i915/display/intel_display.c | 488 +--
> drivers/gpu/drm/i915/display/intel_display.h | 6 -
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
> drivers/gpu/drm/i915/display/intel_sprite.c | 62 --
> drivers/gpu/drm/i915/display/intel_sprite.h | 7 -
> drivers/gpu/drm/i915/display/skl_scaler.c | 556 ++
> drivers/gpu/drm/i915/display/skl_scaler.h | 29 +
> .../drm/i915/display/skl_universal_plane.c| 3 +-
> .../drm/i915/display/skl_universal_plane.h| 4 +
> drivers/gpu/drm/i915/display/vlv_dsi.c| 1 +
> 14 files changed, 598 insertions(+), 564 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/skl_scaler.c
> create mode 100644 drivers/gpu/drm/i915/display/skl_scaler.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 9388e09184fe..235679637d1c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -226,6 +226,7 @@ i915-y += \
> display/intel_tc.o \
> display/intel_vga.o \
> display/i9xx_plane.o \
> + display/skl_scaler.o \
> display/skl_universal_plane.o
> i915-$(CONFIG_ACPI) += \
> display/intel_acpi.o \
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 9eeec6fadec7..7ef6b89c79d9 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -35,6 +35,7 @@
> #include "intel_dsi.h"
> #include "intel_panel.h"
> #include "intel_vdsc.h"
> +#include "skl_scaler.h"
> #include "skl_universal_plane.h"
>
> static int header_credits_available(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index e00fdc47c0eb..27f7d7109ca3 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -40,7 +40,7 @@
> #include "intel_global_state.h"
> #include "intel_hdcp.h"
> #include "intel_psr.h"
> -#include "intel_sprite.h"
> +#include "skl_universal_plane.h"
>
> /**
> * intel_digital_connector_atomic_get_property - hook for
> connector->atomic_get_property.
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index f4746c1edabe..3c4003605f93 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -54,6 +54,7 @@
> #include "intel_tc.h"
> #include "intel_vdsc.h"
> #include "intel_vrr.h"
> +#include "skl_scaler.h"
> #include "skl_universal_plane.h"
>
> static const u8 index_to_dp_signal_levels[] = {
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 1826b4fc6cec..beed08c00b6c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -94,6 +94,7 @@
> #include "intel_tc.h"
> #include "intel_vga.h"
> #include "i9xx_plane.h"
> +#include "skl_scaler.h"
> #include "skl_universal_plane.h"
>
> static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
> @@ -2521,38 +2522,6 @@ intel_plane_fence_y_offset(const struct
> intel_plane_state *plane_state)
> return y;
> }
>
> -static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
> -{
> - struct drm_device *dev = intel_crtc->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - unsigned long irqflags;
> -
> - spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> -
> - intel_de_write_fw(dev_priv, SKL_PS_CTRL(intel_crtc->pipe, id), 0);
> - intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(intel_crtc->pipe, id), 0);
> - intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(intel_crtc->pipe, id), 0);
> -
> - spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
> -}
> -
> -/*
> - * This function detaches (aka. unbinds) unused scalers in hardware
> - */
> -static void skl_detach_scalers(const struct intel_crtc_state *crtc_state)
> -{
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - const struct intel_crtc_scaler_state *scaler_state =
> - &crtc_state->scaler_state;
> - int i;
> -
> - /* loop through and di
Re: [Intel-gfx] [PATCH v12 8/8] drm/i915: move ddi pll state get to dpll mgr
On Fri, Feb 05, 2021 at 04:48:43PM +0200, Jani Nikula wrote:
> From: Dave Airlie
>
> This just migrates the hsw+ code to a better place.
>
> Signed-off-by: Dave Airlie
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 219 +
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 223 ++
> drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 2 +
> 3 files changed, 226 insertions(+), 218 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index beed08c00b6c..f7c1f036d38f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6520,212 +6520,6 @@ static bool ilk_get_pipe_config(struct intel_crtc
> *crtc,
> return ret;
> }
>
> -static void dg1_get_ddi_pll(struct drm_i915_private *dev_priv, enum port
> port,
> - struct intel_crtc_state *pipe_config)
> -{
> - enum icl_port_dpll_id port_dpll_id = ICL_PORT_DPLL_DEFAULT;
> - enum phy phy = intel_port_to_phy(dev_priv, port);
> - struct icl_port_dpll *port_dpll;
> - struct intel_shared_dpll *pll;
> - enum intel_dpll_id id;
> - bool pll_active;
> - u32 clk_sel;
> -
> - clk_sel = intel_de_read(dev_priv, DG1_DPCLKA_CFGCR0(phy)) &
> DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> - id = DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_DPLL_MAP(clk_sel, phy);
Hmm. Since this mostly about DPCLKA_CFGCR/PORT_CLK_SEL/etc.
I think intel_ddi.c would the more approriate place, especially
when considering my recent DDI clock routing refactoring.
I guess we could even consider intel_ddi_clock.c or
somesuch to stuff all of it into. Now I'm also tempted
to turn this stuff into vfuncs as well, to partner up
with the new encoder->{enable,disable}_clock().
> -
> - if (WARN_ON(id > DPLL_ID_DG1_DPLL3))
> - return;
> -
> - pll = intel_get_shared_dpll_by_id(dev_priv, id);
> - port_dpll = &pipe_config->icl_port_dplls[port_dpll_id];
> -
> - port_dpll->pll = pll;
> - pll_active = intel_dpll_get_hw_state(dev_priv, pll,
> - &port_dpll->hw_state);
> - drm_WARN_ON(&dev_priv->drm, !pll_active);
> -
> - icl_set_active_port_dpll(pipe_config, port_dpll_id);
> -}
> -
> -static void icl_get_ddi_pll(struct drm_i915_private *dev_priv, enum port
> port,
> - struct intel_crtc_state *pipe_config)
> -{
> - enum phy phy = intel_port_to_phy(dev_priv, port);
> - enum icl_port_dpll_id port_dpll_id;
> - struct icl_port_dpll *port_dpll;
> - struct intel_shared_dpll *pll;
> - enum intel_dpll_id id;
> - bool pll_active;
> - i915_reg_t reg;
> - u32 temp;
> -
> - if (intel_phy_is_combo(dev_priv, phy)) {
> - u32 mask, shift;
> -
> - if (IS_ALDERLAKE_S(dev_priv)) {
> - reg = ADLS_DPCLKA_CFGCR(phy);
> - mask = ADLS_DPCLKA_CFGCR_DDI_CLK_SEL_MASK(phy);
> - shift = ADLS_DPCLKA_CFGCR_DDI_SHIFT(phy);
> - } else if (IS_ROCKETLAKE(dev_priv)) {
> - reg = ICL_DPCLKA_CFGCR0;
> - mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> - shift = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
> - } else {
> - reg = ICL_DPCLKA_CFGCR0;
> - mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> - shift = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
> - }
> -
> - temp = intel_de_read(dev_priv, reg) & mask;
> - id = temp >> shift;
> - port_dpll_id = ICL_PORT_DPLL_DEFAULT;
> - } else if (intel_phy_is_tc(dev_priv, phy)) {
> - u32 clk_sel = intel_de_read(dev_priv, DDI_CLK_SEL(port)) &
> DDI_CLK_SEL_MASK;
> -
> - if (clk_sel == DDI_CLK_SEL_MG) {
> - id = icl_tc_port_to_pll_id(intel_port_to_tc(dev_priv,
> - port));
> - port_dpll_id = ICL_PORT_DPLL_MG_PHY;
> - } else {
> - drm_WARN_ON(&dev_priv->drm,
> - clk_sel < DDI_CLK_SEL_TBT_162);
> - id = DPLL_ID_ICL_TBTPLL;
> - port_dpll_id = ICL_PORT_DPLL_DEFAULT;
> - }
> - } else {
> - drm_WARN(&dev_priv->drm, 1, "Invalid port %x\n", port);
> - return;
> - }
> -
> - pll = intel_get_shared_dpll_by_id(dev_priv, id);
> - port_dpll = &pipe_config->icl_port_dplls[port_dpll_id];
> -
> - port_dpll->pll = pll;
> - pll_active = intel_dpll_get_hw_state(dev_priv, pll,
> - &port_dpll->hw_state);
> - drm_WARN_ON(&dev_priv->drm, !pll_active);
> -
> - icl_set_active_port_dpll(pipe_config, port_dpll_id);
> -}
> -
> -static void cnl_get_d
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add link rate and lane count to i915_display_info
== Series Details == Series: drm/i915: Add link rate and lane count to i915_display_info URL : https://patchwork.freedesktop.org/series/86738/ State : success == Summary == CI Bug Log - changes from CI_DRM_9735_full -> Patchwork_19600_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19600_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-apl: NOTRUN -> [SKIP][1] ([fdo#109271]) +20 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-apl7/igt@feature_discov...@psr2.html * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-kbl7/igt@gem_cre...@create-massive.html - shard-tglb: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-tglb7/igt@gem_cre...@create-massive.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-kbl: [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-kbl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-kbl6/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-tglb1/igt@gem_exec_fair@basic-pace-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-tglb6/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-skl: NOTRUN -> [FAIL][10] ([i915#2389]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-skl7/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#1610] / [i915#2803]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-kbl2/igt@gem_exec_schedule@u-fairsl...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-kbl6/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb: - shard-kbl: NOTRUN -> [SKIP][13] ([fdo#109271]) +26 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-kbl4/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html * igt@gem_userptr_blits@readonly-mmap-unsync@wb: - shard-tglb: NOTRUN -> [SKIP][14] ([i915#1704]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-tglb7/igt@gem_userptr_blits@readonly-mmap-uns...@wb.html * igt@gen7_exec_parse@basic-offset: - shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109289]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-tglb2/igt@gen7_exec_pa...@basic-offset.html * igt@gen9_exec_parse@cmd-crossing-page: - shard-iclb: NOTRUN -> [SKIP][16] ([fdo#112306]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-iclb8/igt@gen9_exec_pa...@cmd-crossing-page.html * igt@i915_module_load@reload-with-fault-injection: - shard-hsw: [PASS][17] -> [INCOMPLETE][18] ([i915#2880]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9735/shard-hsw5/igt@i915_module_l...@reload-with-fault-injection.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-hsw6/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_query@query-topology-unsupported: - shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109302]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-tglb2/igt@i915_qu...@query-topology-unsupported.html * igt@kms_big_fb@y-tiled-64bpp-rotate-270: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#111614]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-tglb2/igt@kms_big...@y-tiled-64bpp-rotate-270.html * igt@kms_ccs@pipe-c-bad-rotation-90: - shard-skl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111304]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19600/shard-skl7/igt@kms_...@pipe-c-bad-rotation-90.html * igt@kms_chamelium@dp-crc-multiple: - shard-tglb: NOTRUN -> [SKIP][22] ([f
Re: [Intel-gfx] [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice
On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote: > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote: > > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > drm_vblank_restore() exists because certain power saving states > > > can clobber the hardware frame counter. The way it does this is > > > by guesstimating how many frames were missed purely based on > > > the difference between the last stored timestamp vs. a newly > > > sampled timestamp. > > > > > > If we should call this function before a full frame has > > > elapsed since we sampled the last timestamp we would end up > > > with a possibly slightly different timestamp value for the > > > same frame. Currently we will happily overwrite the already > > > stored timestamp for the frame with the new value. This > > > could cause userspace to observe two different timestamps > > > for the same frame (and the timestamp could even go > > > backwards depending on how much error we introduce when > > > correcting the timestamp based on the scanout position). > > > > > > To avoid that let's not update the stored timestamp unless we're > > > also incrementing the sequence counter. We do still want to update > > > vblank->last with the freshly sampled hw frame counter value so > > > that subsequent vblank irqs/queries can actually use the hw frame > > > counter to determine how many frames have elapsed. > > > > Hm I'm not getting the reason for why we store the updated hw vblank > > counter? > > Because next time a vblank irq happens the code will do: > diff = current_hw_counter - vblank->last > > which won't work very well if vblank->last is garbage. > > Updating vblank->last is pretty much why drm_vblank_restore() > exists at all. Oh sure, _restore has to update this, together with the timestamp. But your code adds such an update where we update the hw vblank counter, but not the timestamp, and that feels buggy. Either we're still in the same frame, and then we should story nothing. Or we advanced, and then we probably want a new timestampt for that frame too. Advancing the vblank counter and not advancing the timestamp sounds like a bug in our code. > > There's definitely a race when we grab the hw timestamp at a bad time > > (which can't happen for the irq handler, realistically), so maybe we > > should first adjust that to make sure we never store anything inconsistent > > in the vblank state? > > Not sure what race you mean, or what inconsistent thing we store? For the drm_handle_vblank code we have some fudge so we don't compute something silly when the irq fires (like it often does) before top-of-frame. Ofc that fudge is inheritedly racy, if the irq is extremely delay (almost an entire frame) we'll get it wrong. In practice it doesn't matter. Now _restore can be called anytime, so we might end up in situations where the exact point where we jump to the next frame count, and the exact time where the hw counter jumps, don't lign up. And I think in that case funny things can happen, and I'm not sure your approach of "update hw counter but don't update timestamp" is the right way. I think if we instead ignore any update if our fudge-corrected timestamp is roughly the same, then we handle that race correctly and there's no jumping around. Cheers, Daniel > > And when we have that we should be able to pull the inc == 0 check out > > into _restore(), including comment. Which I think should be cleaner. > > > > Or I'm totally off with why you want to store the hw vblank counter? > > > > > > > > Cc: Dhinakaran Pandiyan > > > Cc: Rodrigo Vivi > > > Cc: Daniel Vetter > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/drm_vblank.c | 11 +++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > index 893165eeddf3..e127a7db2088 100644 > > > --- a/drivers/gpu/drm/drm_vblank.c > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > @@ -176,6 +176,17 @@ static void store_vblank(struct drm_device *dev, > > > unsigned int pipe, > > > > > > vblank->last = last; > > > > > > + /* > > > + * drm_vblank_restore() wants to always update > > > + * vblank->last since we can't trust the frame counter > > > + * across power saving states. But we don't want to alter > > > + * the stored timestamp for the same frame number since > > > + * that would cause userspace to potentially observe two > > > + * different timestamps for the same frame. > > > + */ > > > + if (vblank_count_inc == 0) > > > + return; > > > + > > > write_seqlock(&vblank->seqlock); > > > vblank->time = t_vblank; > > > atomic64_add(vblank_count_inc, &vblank->count); > > > -- > > > 2.26.2 > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > -- > Ville Syrjälä > Intel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _
[Intel-gfx] [PATCH] drm/i915/display: Allow PSR2 selective fetch to be enabled at run-time
Right now CI is blacklisting module reload, so we need to be able to
enable PSR2 selective fetch in run time to test this feature before
enable it by default.
Changes in IGT will also be needed.
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 307ff4b771f4..d78530abfef2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1424,6 +1424,7 @@ struct intel_psr {
#define I915_PSR_DEBUG_DISABLE 0x01
#define I915_PSR_DEBUG_ENABLE 0x02
#define I915_PSR_DEBUG_FORCE_PSR1 0x03
+#define I915_PSR_DEBUG_ENABLE_SEL_FETCH0x4
#define I915_PSR_DEBUG_IRQ 0x10
u32 debug;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 28423356d53b..eabb9a0c2164 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -683,7 +683,8 @@ static bool intel_psr2_sel_fetch_config_valid(struct
intel_dp *intel_dp,
struct intel_plane *plane;
int i;
- if (!dev_priv->params.enable_psr2_sel_fetch) {
+ if (!dev_priv->params.enable_psr2_sel_fetch &&
+ intel_dp->psr.debug != I915_PSR_DEBUG_ENABLE_SEL_FETCH) {
drm_dbg_kms(&dev_priv->drm,
"PSR2 sel fetch not enabled, disabled by
parameter\n");
return false;
@@ -1447,7 +1448,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
enable = crtc_state->has_psr;
psr2_enable = crtc_state->has_psr2;
- if (enable == psr->enabled && psr2_enable == psr->psr2_enabled) {
+ if (enable == psr->enabled && psr2_enable == psr->psr2_enabled &&
+ crtc_state->enable_psr2_sel_fetch == psr->psr2_sel_fetch_enabled) {
/* Force a PSR exit when enabling CRC to avoid CRC timeouts */
if (crtc_state->crc_enabled && psr->enabled)
psr_force_hw_tracking_exit(intel_dp);
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Autoselect CONFIG_CHECKPOINT_RESTORE for SYS_kcmp
On Fri, Feb 05, 2021 at 01:03:07PM +, Chris Wilson wrote: > gallium (iris) depends on os_same_file_description() to disambiguate > screens and so avoid importing the same screen fd twice as two distinct > entities (that share all the kernel resources, so actions on screen > affect the other and would cause random faiure). As they depend on it, > so must we. os_same_file_description() uses SYS_kcmp to check the file > tables for the equivalent struct file, but SYS_kcmp is hidden behind > CONFIG_CHECKPOINT_RESTORE. As this is not default, we must select it for > ourselves to ensure that our userspace is fully supported. > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3046 > Signed-off-by: Chris Wilson > Cc: Jani Nikula > Cc: Daniel Vetter Hm shouldn't we crank this up to CONFIG_DRM? Or embedded folks going to be unhappy about that? If so I guess we'd need to pull out just the SYS_kcmp part ... Asking because I think Bas is also looking at this, and it's not great if we're building on this and then users end up with very subtly broken gl/vk stacks :-/ -Daniel > --- > drivers/gpu/drm/i915/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index 1e1cb245fca7..470a5214bd33 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -21,6 +21,7 @@ config DRM_I915 > select ACPI_VIDEO if ACPI > select ACPI_BUTTON if ACPI > select SYNC_FILE > + select CHECKPOINT_RESTORE # gallium depends on SYS_kcmp > select IOSF_MBI > select CRC32 > select SND_HDA_I915 if SND_HDA_CORE > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Autoselect CONFIG_CHECKPOINT_RESTORE for SYS_kcmp
On Fri, Feb 05, 2021 at 04:58:32PM +0100, Daniel Vetter wrote: > On Fri, Feb 05, 2021 at 01:03:07PM +, Chris Wilson wrote: > > gallium (iris) depends on os_same_file_description() to disambiguate > > screens and so avoid importing the same screen fd twice as two distinct > > entities (that share all the kernel resources, so actions on screen > > affect the other and would cause random faiure). As they depend on it, > > so must we. os_same_file_description() uses SYS_kcmp to check the file > > tables for the equivalent struct file, but SYS_kcmp is hidden behind > > CONFIG_CHECKPOINT_RESTORE. As this is not default, we must select it for > > ourselves to ensure that our userspace is fully supported. > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3046 > > Signed-off-by: Chris Wilson > > Cc: Jani Nikula > > Cc: Daniel Vetter > > Hm shouldn't we crank this up to CONFIG_DRM? > > Or embedded folks going to be unhappy about that? If so I guess we'd need > to pull out just the SYS_kcmp part ... > > Asking because I think Bas is also looking at this, and it's not great if > we're building on this and then users end up with very subtly broken gl/vk > stacks :-/ Forgot to add Airlie. -Daniel > -Daniel > > > --- > > drivers/gpu/drm/i915/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > > index 1e1cb245fca7..470a5214bd33 100644 > > --- a/drivers/gpu/drm/i915/Kconfig > > +++ b/drivers/gpu/drm/i915/Kconfig > > @@ -21,6 +21,7 @@ config DRM_I915 > > select ACPI_VIDEO if ACPI > > select ACPI_BUTTON if ACPI > > select SYNC_FILE > > + select CHECKPOINT_RESTORE # gallium depends on SYS_kcmp > > select IOSF_MBI > > select CRC32 > > select SND_HDA_I915 if SND_HDA_CORE > > -- > > 2.20.1 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Autoselect CONFIG_CHECKPOINT_RESTORE for SYS_kcmp
Am Freitag, dem 05.02.2021 um 16:59 +0100 schrieb Daniel Vetter: > On Fri, Feb 05, 2021 at 04:58:32PM +0100, Daniel Vetter wrote: > > On Fri, Feb 05, 2021 at 01:03:07PM +, Chris Wilson wrote: > > > gallium (iris) depends on os_same_file_description() to disambiguate > > > screens and so avoid importing the same screen fd twice as two distinct > > > entities (that share all the kernel resources, so actions on screen > > > affect the other and would cause random faiure). As they depend on it, > > > so must we. os_same_file_description() uses SYS_kcmp to check the file > > > tables for the equivalent struct file, but SYS_kcmp is hidden behind > > > CONFIG_CHECKPOINT_RESTORE. As this is not default, we must select it for > > > ourselves to ensure that our userspace is fully supported. > > > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3046 > > > Signed-off-by: Chris Wilson > > > Cc: Jani Nikula > > > Cc: Daniel Vetter > > > > Hm shouldn't we crank this up to CONFIG_DRM? > > > > Or embedded folks going to be unhappy about that? If so I guess we'd need > > to pull out just the SYS_kcmp part ... > > > > Asking because I think Bas is also looking at this, and it's not great if > > we're building on this and then users end up with very subtly broken gl/vk > > stacks :-/ amdgpu gallium winsys seems to also require this, so selecting it from higher up in the Kconfig tree makes sense and I don't think embedded would be massively unhappy about this. However kcmp seems to be useful on its own and pulling it out of CHECKPOINT_RESTORE sounds like the right thing to do. Regards, Lucas > > > -Daniel > > > > > --- > > > drivers/gpu/drm/i915/Kconfig | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > > > index 1e1cb245fca7..470a5214bd33 100644 > > > --- a/drivers/gpu/drm/i915/Kconfig > > > +++ b/drivers/gpu/drm/i915/Kconfig > > > @@ -21,6 +21,7 @@ config DRM_I915 > > > select ACPI_VIDEO if ACPI > > > select ACPI_BUTTON if ACPI > > > select SYNC_FILE > > > + select CHECKPOINT_RESTORE # gallium depends on SYS_kcmp > > > select IOSF_MBI > > > select CRC32 > > > select SND_HDA_I915 if SND_HDA_CORE > > > -- > > > 2.20.1 > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice
On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote: > On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote: > > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote: > > > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > > > > > > drm_vblank_restore() exists because certain power saving states > > > > can clobber the hardware frame counter. The way it does this is > > > > by guesstimating how many frames were missed purely based on > > > > the difference between the last stored timestamp vs. a newly > > > > sampled timestamp. > > > > > > > > If we should call this function before a full frame has > > > > elapsed since we sampled the last timestamp we would end up > > > > with a possibly slightly different timestamp value for the > > > > same frame. Currently we will happily overwrite the already > > > > stored timestamp for the frame with the new value. This > > > > could cause userspace to observe two different timestamps > > > > for the same frame (and the timestamp could even go > > > > backwards depending on how much error we introduce when > > > > correcting the timestamp based on the scanout position). > > > > > > > > To avoid that let's not update the stored timestamp unless we're > > > > also incrementing the sequence counter. We do still want to update > > > > vblank->last with the freshly sampled hw frame counter value so > > > > that subsequent vblank irqs/queries can actually use the hw frame > > > > counter to determine how many frames have elapsed. > > > > > > Hm I'm not getting the reason for why we store the updated hw vblank > > > counter? > > > > Because next time a vblank irq happens the code will do: > > diff = current_hw_counter - vblank->last > > > > which won't work very well if vblank->last is garbage. > > > > Updating vblank->last is pretty much why drm_vblank_restore() > > exists at all. > > Oh sure, _restore has to update this, together with the timestamp. > > But your code adds such an update where we update the hw vblank counter, > but not the timestamp, and that feels buggy. Either we're still in the > same frame, and then we should story nothing. Or we advanced, and then we > probably want a new timestampt for that frame too. Even if we're still in the same frame the hw frame counter may already have been reset due to the power well having been turned off. That is what I'm trying to fix here. Now I suppose that's fairly unlikely, at least with PSR which probably does impose some extra delays before the power gets yanked. But at least theoretically possible. > > Advancing the vblank counter and not advancing the timestamp sounds like a > bug in our code. We're not advancing the vblank counter. We're storing a new timestamp for a vblank counter value which already had a timestamp. > > > > There's definitely a race when we grab the hw timestamp at a bad time > > > (which can't happen for the irq handler, realistically), so maybe we > > > should first adjust that to make sure we never store anything inconsistent > > > in the vblank state? > > > > Not sure what race you mean, or what inconsistent thing we store? > > For the drm_handle_vblank code we have some fudge so we don't compute > something silly when the irq fires (like it often does) before > top-of-frame. Ofc that fudge is inheritedly racy, if the irq is extremely > delay (almost an entire frame) we'll get it wrong. Sorry, still no idea what fudge you mean. > > In practice it doesn't matter. > > Now _restore can be called anytime, so we might end up in situations where > the exact point where we jump to the next frame count, and the exact time > where the hw counter jumps, don't lign up. And I think in that case funny > things can happen, and I'm not sure your approach of "update hw counter > but don't update timestamp" is the right way. > > I think if we instead ignore any update if our fudge-corrected timestamp > is roughly the same, then we handle that race correctly and there's no > jumping around. We can't just not update vblank->last, assuming the theory holds that the power well may turn off even if the last vblank timestamp was sampled less than a full frame ago. That will cause the next diff=current_hw_counter-vblank->last to generate total garbage and then the vblank seq number will jump to some random value. Which is exactly the main problem drm_vblank_restore() is trying to prevent. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] kernel: Expose SYS_kcmp by default
Userspace has discovered the functionality offered by SYS_kcmp and has started to depend upon it. In particular, Mesa uses SYS_kcmp for os_same_file_description() in order to identify when two fd (e.g. device or dmabuf) point to the same struct file. Since they depend on it for core functionality, lift SYS_kcmp out of the non-default CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. Signed-off-by: Chris Wilson Cc: Kees Cook Cc: Andy Lutomirski Cc: Will Drewry Cc: Andrew Morton Cc: Dave Airlie Cc: Daniel Vetter Cc: Lucas Stach --- init/Kconfig | 11 +++ kernel/Makefile | 2 +- tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- 3 files changed, 13 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index b77c60f8b963..f62fca13ac5b 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1194,6 +1194,7 @@ endif # NAMESPACES config CHECKPOINT_RESTORE bool "Checkpoint/restore support" select PROC_CHILDREN + select KCMP default n help Enables additional kernel features in a sake of checkpoint/restore. @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS config ARCH_HAS_MEMBARRIER_SYNC_CORE bool +config KCMP + bool "Enable kcmp() system call" if EXPERT + default y + help + Enable the file descriptor comparison system call. It provides + user-space with the ability to compare two fd to see if they + point to the same file, and check other attributes. + + If unsure, say Y. + config RSEQ bool "Enable rseq() system call" if EXPERT default y diff --git a/kernel/Makefile b/kernel/Makefile index aa7368c7eabf..320f1f3941b7 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -51,7 +51,7 @@ obj-y += livepatch/ obj-y += dma/ obj-y += entry/ -obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o +obj-$(CONFIG_KCMP) += kcmp.o obj-$(CONFIG_FREEZER) += freezer.o obj-$(CONFIG_PROFILING) += profile.o obj-$(CONFIG_STACKTRACE) += stacktrace.o diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c index 26c72f2b61b1..1b6c7d33c4ff 100644 --- a/tools/testing/selftests/seccomp/seccomp_bpf.c +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c @@ -315,7 +315,7 @@ TEST(kcmp) ret = __filecmp(getpid(), getpid(), 1, 1); EXPECT_EQ(ret, 0); if (ret != 0 && errno == ENOSYS) - SKIP(return, "Kernel does not support kcmp() (missing CONFIG_CHECKPOINT_RESTORE?)"); + SKIP(return, "Kernel does not support kcmp() (missing CONFIG_KCMP?)"); } TEST(mode_strict_support) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel: Expose SYS_kcmp by default
Am Freitag, dem 05.02.2021 um 16:37 + schrieb Chris Wilson: > Userspace has discovered the functionality offered by SYS_kcmp and has > started to depend upon it. In particular, Mesa uses SYS_kcmp for > os_same_file_description() in order to identify when two fd (e.g. device > or dmabuf) point to the same struct file. Since they depend on it for > core functionality, lift SYS_kcmp out of the non-default > CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. > > Signed-off-by: Chris Wilson > Cc: Kees Cook > Cc: Andy Lutomirski > Cc: Will Drewry > Cc: Andrew Morton > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Lucas Stach > --- > init/Kconfig | 11 +++ > kernel/Makefile | 2 +- > tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- > 3 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/init/Kconfig b/init/Kconfig > index b77c60f8b963..f62fca13ac5b 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1194,6 +1194,7 @@ endif # NAMESPACES > config CHECKPOINT_RESTORE > bool "Checkpoint/restore support" > select PROC_CHILDREN > + select KCMP > default n > help > Enables additional kernel features in a sake of checkpoint/restore. > @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS > config ARCH_HAS_MEMBARRIER_SYNC_CORE > bool > > > > > +config KCMP > + bool "Enable kcmp() system call" if EXPERT > + default y > + help > + Enable the file descriptor comparison system call. It provides > + user-space with the ability to compare two fd to see if they > + point to the same file, and check other attributes. This description undersells the abilities of kcmp, while fd compare is the only thing used by the graphics stack, kcmp can compare a handful of other system resources, see man 2 kcmp. I think the helptext should at least try to cover this fact somewhat. Regards, Lucas > + > + If unsure, say Y. > + > config RSEQ > bool "Enable rseq() system call" if EXPERT > default y > diff --git a/kernel/Makefile b/kernel/Makefile > index aa7368c7eabf..320f1f3941b7 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -51,7 +51,7 @@ obj-y += livepatch/ > obj-y += dma/ > obj-y += entry/ > > > > > -obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o > +obj-$(CONFIG_KCMP) += kcmp.o > obj-$(CONFIG_FREEZER) += freezer.o > obj-$(CONFIG_PROFILING) += profile.o > obj-$(CONFIG_STACKTRACE) += stacktrace.o > diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c > b/tools/testing/selftests/seccomp/seccomp_bpf.c > index 26c72f2b61b1..1b6c7d33c4ff 100644 > --- a/tools/testing/selftests/seccomp/seccomp_bpf.c > +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c > @@ -315,7 +315,7 @@ TEST(kcmp) > ret = __filecmp(getpid(), getpid(), 1, 1); > EXPECT_EQ(ret, 0); > if (ret != 0 && errno == ENOSYS) > - SKIP(return, "Kernel does not support kcmp() (missing > CONFIG_CHECKPOINT_RESTORE?)"); > + SKIP(return, "Kernel does not support kcmp() (missing > CONFIG_KCMP?)"); > } > > > > > TEST(mode_strict_support) ___ 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/selftest: Synchronise with the GPU timestamp (rev2)
== Series Details == Series: drm/i915/selftest: Synchronise with the GPU timestamp (rev2) URL : https://patchwork.freedesktop.org/series/86731/ State : success == Summary == CI Bug Log - changes from CI_DRM_9739 -> Patchwork_19604 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19604/index.html Known issues Here are the changes found in Patchwork_19604 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-byt-j1900: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19604/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html * igt@kms_chamelium@hdmi-crc-fast: - fi-byt-j1900: NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827]) +8 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19604/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9739/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19604/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html Possible fixes * igt@gem_render_tiled_blits@basic: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9739/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19604/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 38) -- Additional (1): fi-byt-j1900 Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9739 -> Patchwork_19604 CI-20190529: 20190529 CI_DRM_9739: ef1034467c46162cfe7d08de4c1f0870b960e7c9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5993: b1225ec25d5671a985c5bb48739111d2e8a723cf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19604: cc7e3b1a8c143809284d96509d4a1930b603b082 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cc7e3b1a8c14 drm/i915/selftest: Synchronise with the GPU timestamp == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19604/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/module_load: Tidy up gem_exec_store workalike
On 2021-02-05 at 10:10:05 +, Chris Wilson wrote:
> We emit a store on each GPU after loading the module to confirm the
> basic liveness of command submission. Trim away some of the chaff.
>
> Signed-off-by: Chris Wilson
> Cc: Ramalingam C
Looks good to me
Reviewed-by: Ramalingam C
> ---
> tests/i915/i915_module_load.c | 146 ++
> 1 file changed, 58 insertions(+), 88 deletions(-)
>
> diff --git a/tests/i915/i915_module_load.c b/tests/i915/i915_module_load.c
> index 06522ba61..f1fb13914 100644
> --- a/tests/i915/i915_module_load.c
> +++ b/tests/i915/i915_module_load.c
> @@ -37,41 +37,45 @@
> #include "igt_sysfs.h"
> #include "igt_core.h"
>
> -static void store_all(int fd)
> +static void store_all(int i915)
> {
> - const unsigned int gen = intel_gen(intel_get_drm_devid(fd));
> - unsigned int permuted[I915_EXEC_RING_MASK + 1];
> - unsigned int engines[I915_EXEC_RING_MASK + 1];
> - struct drm_i915_gem_exec_object2 obj[2];
> - struct drm_i915_gem_relocation_entry reloc[2 * ARRAY_SIZE(engines)];
> - struct drm_i915_gem_execbuffer2 execbuf;
> - const struct intel_execution_engine2 *e;
> + const unsigned int gen = intel_gen(intel_get_drm_devid(i915));
> + uint32_t engines[I915_EXEC_RING_MASK + 1];
> uint32_t batch[16];
> - uint64_t offset;
> - unsigned nengine;
> - int value;
> - int i, j;
> -
> - memset(&execbuf, 0, sizeof(execbuf));
> - execbuf.buffers_ptr = (uintptr_t)obj;
> - execbuf.buffer_count = 2;
> -
> - memset(reloc, 0, sizeof(reloc));
> - memset(obj, 0, sizeof(obj));
> - obj[0].handle = gem_create(fd, 4096);
> - obj[1].handle = gem_create(fd, 4096);
> - obj[1].relocation_count = 1;
> -
> - offset = sizeof(uint32_t);
> + unsigned int sz = ALIGN(sizeof(batch) * ARRAY_SIZE(engines), 4096);
> + struct drm_i915_gem_relocation_entry reloc = {
> + .offset = sizeof(uint32_t),
> + .read_domains = I915_GEM_DOMAIN_RENDER,
> + .write_domain = I915_GEM_DOMAIN_RENDER,
> + };
> + struct drm_i915_gem_exec_object2 obj[2] = {
> + { .handle = gem_create(i915, sizeof(engines)) },
> + {
> + .handle = gem_create(i915, sz),
> + .relocation_count = 1,
> + .relocs_ptr = to_user_pointer(&reloc),
> + },
> + };
> + struct drm_i915_gem_execbuffer2 execbuf = {
> + .buffers_ptr = to_user_pointer(obj),
> + .buffer_count = 2,
> + };
> + const struct intel_execution_engine2 *e;
> + int reloc_sz = sizeof(uint32_t);
> + unsigned int nengine, value;
> + void *cs;
> + int i;
> +
> i = 0;
> batch[i] = MI_STORE_DWORD_IMM | (gen < 6 ? 1 << 22 : 0);
> if (gen >= 8) {
> batch[++i] = 0;
> batch[++i] = 0;
> + reloc_sz = sizeof(uint64_t);
> } else if (gen >= 4) {
> batch[++i] = 0;
> batch[++i] = 0;
> - offset += sizeof(uint32_t);
> + reloc.offset += sizeof(uint32_t);
> } else {
> batch[i]--;
> batch[++i] = 0;
> @@ -80,74 +84,43 @@ static void store_all(int fd)
> batch[++i] = MI_BATCH_BUFFER_END;
>
> nengine = 0;
> - intel_detect_and_clear_missed_interrupts(fd);
> - __for_each_physical_engine(fd, e) {
> - if (!gem_class_can_store_dword(fd, e->class))
> + cs = gem_mmap__device_coherent(i915, obj[1].handle, 0, sz, PROT_WRITE);
> + __for_each_physical_engine(i915, e) {
> + uint64_t addr;
> +
> + igt_assert(reloc.presumed_offset != -1);
> + addr = reloc.presumed_offset + reloc.delta;
> +
> + if (!gem_class_can_store_dword(i915, e->class))
> continue;
>
> - igt_assert(2 * (nengine + 1) * sizeof(batch) <= 4096);
> + engines[nengine] = nengine;
> + batch[value] = engines[nengine];
>
> - engines[nengine] = e->flags;
> + execbuf.flags = e->flags;
> if (gen < 6)
> - engines[nengine] |= I915_EXEC_SECURE;
> - execbuf.flags = engines[nengine];
> -
> - j = 2*nengine;
> - reloc[j].target_handle = obj[0].handle;
> - reloc[j].presumed_offset = ~0;
> - reloc[j].offset = j*sizeof(batch) + offset;
> - reloc[j].delta = nengine*sizeof(uint32_t);
> - reloc[j].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
> - reloc[j].write_domain = I915_GEM_DOMAIN_INSTRUCTION;
> - obj[1].relocs_ptr = (uintptr_t)&reloc[j];
> -
> - batch[value] = 0xdeadbeef;
> - gem_write(fd, obj[1].handle, j*sizeof(batch),
> - batch, sizeof(batch));
> - execbuf.batch_start_offset = j*sizeof(batch);
> - gem_execbuf(fd, &execbuf);
> -
> -
[Intel-gfx] [CI 1/2] drm/i915/gt: Always flush the submission queue on checking for idle
We check for idle during debug prints and other debugging actions.
Simplify the flow by not touching execlists state.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 9cd5cb2b1f1d..daadada6de0b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1247,14 +1247,8 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return true;
/* Waiting to drain ELSP? */
- if (execlists_active(&engine->execlists)) {
- synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
-
- intel_engine_flush_submission(engine);
-
- if (execlists_active(&engine->execlists))
- return false;
- }
+ synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
+ intel_engine_flush_submission(engine);
/* ELSP is empty, but there are ready requests? E.g. after reset */
if (!RB_EMPTY_ROOT(&engine->execlists.queue.rb_root))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/gt: Pull all execlists scheduler initialisation together
Put all the scheduler initialisation code for execlists into a common
routine. This is to reduce code movement later.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 26 ---
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 9d24d91f5ae7..3a01b66939a0 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2917,7 +2917,7 @@ static void rcs_submission_override(struct
intel_engine_cs *engine)
}
}
-int intel_execlists_submission_setup(struct intel_engine_cs *engine)
+static void init_execlists(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
struct drm_i915_private *i915 = engine->i915;
@@ -2925,17 +2925,10 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
u32 base = engine->mmio_base;
tasklet_setup(&engine->execlists.tasklet, execlists_submission_tasklet);
+
timer_setup(&engine->execlists.timer, execlists_timeslice, 0);
timer_setup(&engine->execlists.preempt, execlists_preempt, 0);
- logical_ring_default_vfuncs(engine);
- logical_ring_default_irqs(engine);
-
- if (engine->class == RENDER_CLASS)
- rcs_submission_override(engine);
-
- lrc_init_wa_ctx(engine);
-
if (HAS_LOGICAL_RING_ELSQ(i915)) {
execlists->submit_reg = uncore->regs +
i915_mmio_reg_offset(RING_EXECLIST_SQ_CONTENTS(base));
@@ -2958,10 +2951,23 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
execlists->csb_size = GEN11_CSB_ENTRIES;
engine->context_tag = GENMASK(BITS_PER_LONG - 2, 0);
- if (INTEL_GEN(engine->i915) >= 11) {
+ if (INTEL_GEN(i915) >= 11) {
execlists->ccid |= engine->instance <<
(GEN11_ENGINE_INSTANCE_SHIFT - 32);
execlists->ccid |= engine->class << (GEN11_ENGINE_CLASS_SHIFT -
32);
}
+}
+
+int intel_execlists_submission_setup(struct intel_engine_cs *engine)
+{
+ logical_ring_default_vfuncs(engine);
+ logical_ring_default_irqs(engine);
+
+ if (engine->class == RENDER_CLASS)
+ rcs_submission_override(engine);
+
+ init_execlists(engine);
+
+ lrc_init_wa_ctx(engine);
/* Finally, take ownership and responsibility for cleanup! */
engine->sanitize = execlists_sanitize;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Autoselect CONFIG_CHECKPOINT_RESTORE for SYS_kcmp
== Series Details == Series: drm/i915: Autoselect CONFIG_CHECKPOINT_RESTORE for SYS_kcmp URL : https://patchwork.freedesktop.org/series/86759/ State : success == Summary == CI Bug Log - changes from CI_DRM_9739 -> Patchwork_19605 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19605/index.html Known issues Here are the changes found in Patchwork_19605 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-y: NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19605/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html * igt@gem_huc_copy@huc-copy: - fi-byt-j1900: NOTRUN -> [SKIP][2] ([fdo#109271]) +27 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19605/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@client: - fi-glk-dsi: [PASS][3] -> [DMESG-FAIL][4] ([i915#3047]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9739/fi-glk-dsi/igt@i915_selftest@l...@client.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19605/fi-glk-dsi/igt@i915_selftest@l...@client.html * igt@kms_chamelium@hdmi-crc-fast: - fi-byt-j1900: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19605/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html * igt@prime_vgem@basic-read: - fi-tgl-y: [PASS][6] -> [DMESG-WARN][7] ([i915#402]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9739/fi-tgl-y/igt@prime_v...@basic-read.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19605/fi-tgl-y/igt@prime_v...@basic-read.html Possible fixes * igt@gem_render_tiled_blits@basic: - fi-tgl-y: [DMESG-WARN][8] ([i915#402]) -> [PASS][9] +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9739/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19605/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 38) -- Additional (1): fi-byt-j1900 Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9739 -> Patchwork_19605 CI-20190529: 20190529 CI_DRM_9739: ef1034467c46162cfe7d08de4c1f0870b960e7c9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5993: b1225ec25d5671a985c5bb48739111d2e8a723cf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19605: 00efe8c6bf3f085236fcda00f6978cb2e29b09a1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 00efe8c6bf3f drm/i915: Autoselect CONFIG_CHECKPOINT_RESTORE for SYS_kcmp == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19605/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hdcp: Show connector hdcp capability
== Series Details == Series: drm/i915/hdcp: Show connector hdcp capability URL : https://patchwork.freedesktop.org/series/86740/ State : success == Summary == CI Bug Log - changes from CI_DRM_9736_full -> Patchwork_19601_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19601_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_capture@pi@vecs0: - shard-skl: NOTRUN -> [INCOMPLETE][1] ([i915#198] / [i915#2624]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-skl10/igt@gem_exec_capture@p...@vecs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][2] -> [FAIL][3] ([i915#2842]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-apl: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-apl1/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-skl: [PASS][10] -> [DMESG-WARN][11] ([i915#1610] / [i915#2803]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/shard-skl1/igt@gem_exec_schedule@u-fairsl...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-skl8/igt@gem_exec_schedule@u-fairsl...@vcs0.html * igt@gem_exec_schedule@u-semaphore-codependency: - shard-glk: [PASS][12] -> [DMESG-WARN][13] ([i915#1610]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/shard-glk9/igt@gem_exec_sched...@u-semaphore-codependency.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-glk9/igt@gem_exec_sched...@u-semaphore-codependency.html * igt@gem_exec_whisper@basic-normal-all: - shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#118] / [i915#95]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/shard-glk2/igt@gem_exec_whis...@basic-normal-all.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-glk7/igt@gem_exec_whis...@basic-normal-all.html * igt@gem_userptr_blits@input-checking: - shard-skl: NOTRUN -> [DMESG-WARN][16] ([i915#3002]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-skl5/igt@gem_userptr_bl...@input-checking.html - shard-kbl: NOTRUN -> [DMESG-WARN][17] ([i915#3002]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-kbl2/igt@gem_userptr_bl...@input-checking.html * igt@gen7_exec_parse@basic-allowed: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271]) +18 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-skl5/igt@gen7_exec_pa...@basic-allowed.html * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109506] / [i915#2411]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-tglb3/igt@i915_pm_...@gem-execbuf-stress-pc8.html * igt@kms_big_fb@yf-tiled-32bpp-rotate-0: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#111615]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-tglb3/igt@kms_big...@yf-tiled-32bpp-rotate-0.html * igt@kms_color@pipe-b-ctm-max: - shard-skl: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9736/shard-skl3/igt@kms_co...@pipe-b-ctm-max.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-skl4/igt@kms_co...@pipe-b-ctm-max.html * igt@kms_color_chamelium@pipe-b-ctm-blue-to-red: - shard-tglb: NOTRUN -> [SKIP][23] ([fdo#109284] / [fdo#111827]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19601/shard-tglb3/igt@kms_color_chamel...@pipe-b-ctm-blue-to-red.html * igt@kms_color_chamelium@pipe-c-ctm-
Re: [Intel-gfx] [PATCH] kernel: Expose SYS_kcmp by default
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote: > Userspace has discovered the functionality offered by SYS_kcmp and has > started to depend upon it. In particular, Mesa uses SYS_kcmp for > os_same_file_description() in order to identify when two fd (e.g. device > or dmabuf) point to the same struct file. Since they depend on it for > core functionality, lift SYS_kcmp out of the non-default > CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. > > Signed-off-by: Chris Wilson > Cc: Kees Cook > Cc: Andy Lutomirski > Cc: Will Drewry > Cc: Andrew Morton > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Lucas Stach > --- > init/Kconfig | 11 +++ > kernel/Makefile | 2 +- > tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- > 3 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/init/Kconfig b/init/Kconfig > index b77c60f8b963..f62fca13ac5b 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1194,6 +1194,7 @@ endif # NAMESPACES > config CHECKPOINT_RESTORE > bool "Checkpoint/restore support" > select PROC_CHILDREN > + select KCMP > default n > help > Enables additional kernel features in a sake of checkpoint/restore. > @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS > config ARCH_HAS_MEMBARRIER_SYNC_CORE > bool > > +config KCMP > + bool "Enable kcmp() system call" if EXPERT > + default y I would expect this to be not default-y, especially if CHECKPOINT_RESTORE does a "select" on it. This is a really powerful syscall, but it is bounded by ptrace access controls, and uses pointer address obfuscation, so it may be okay to expose this. As it is, at least Ubuntu already has CONFIG_CHECKPOINT_RESTORE, so really, there's probably not much difference on exposure. So, if you drop the "default y", I'm fine with this. -Kees > + help > + Enable the file descriptor comparison system call. It provides > + user-space with the ability to compare two fd to see if they > + point to the same file, and check other attributes. > + > + If unsure, say Y. > + > config RSEQ > bool "Enable rseq() system call" if EXPERT > default y > diff --git a/kernel/Makefile b/kernel/Makefile > index aa7368c7eabf..320f1f3941b7 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -51,7 +51,7 @@ obj-y += livepatch/ > obj-y += dma/ > obj-y += entry/ > > -obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o > +obj-$(CONFIG_KCMP) += kcmp.o > obj-$(CONFIG_FREEZER) += freezer.o > obj-$(CONFIG_PROFILING) += profile.o > obj-$(CONFIG_STACKTRACE) += stacktrace.o > diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c > b/tools/testing/selftests/seccomp/seccomp_bpf.c > index 26c72f2b61b1..1b6c7d33c4ff 100644 > --- a/tools/testing/selftests/seccomp/seccomp_bpf.c > +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c > @@ -315,7 +315,7 @@ TEST(kcmp) > ret = __filecmp(getpid(), getpid(), 1, 1); > EXPECT_EQ(ret, 0); > if (ret != 0 && errno == ENOSYS) > - SKIP(return, "Kernel does not support kcmp() (missing > CONFIG_CHECKPOINT_RESTORE?)"); > + SKIP(return, "Kernel does not support kcmp() (missing > CONFIG_KCMP?)"); > } > > TEST(mode_strict_support) > -- > 2.20.1 > -- Kees Cook ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl, tgl: whitelist COMMON_SLICE_CHICKEN3 register
On 2/5/21 5:33 AM, Chris Wilson wrote: > Quoting Sagar Ghuge (2021-02-05 00:33:10) >> Adding this register to whitelist will allow UMD to toggle State Cache >> Perf fix disable chicken bit. >> >>"If this bit is enabled, RCC uses BTP+BTI as address tag in its state >>cache instead of BTI only" >> >> which will lead to dropping unnecessary render target flushes and stall >> on scoreboard. > > The rest of the register looks safe to expose, and it passes our sanity > checks that the register is local to the context and should not affect > others. > >> Bspec: 11333 >> Bspec: 45829 >> >> Signed-off-by: Sagar Ghuge > > Acked-by: Chris Wilson > Thank you! > The only missing piece of the puzzle that Joonas will require is a > Link: to a reviewed userspace patch/MR to confirm the uABI. Link to MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8766 > -Chris > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Add link rate and lane count to i915_display_info
Link rate and lane count information are more easier and faster to check in i915_display_info than checking kernel logs for people not familiar with i915 in the following scenarios: * Debugging DP tunnel bandwidth usage in Thunderbolt driver. * In USB4 certification, it is a requirement to know which link rate used by monitor to prove that DP tunnel handle up to HBR3 * In PHY Compliance, when the connector propes are not mounted correctly, some display lanes will not show up in the DP Oscilloscope and will fail CTS. Just give the tester an easy way to identify where the problem is. v2(Ville): Uniform style for '=' and use 'port clock' instead of 'link rate' Cc: Imre Deak Cc: Ville Syrjälä CC: José Roberto de Souza Signed-off-by: Khaled Almahallawy --- drivers/gpu/drm/i915/display/intel_display_debugfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index d62b18d5ecd8..cb088a0a26f3 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -990,9 +990,10 @@ static void intel_crtc_info(struct seq_file *m, struct intel_crtc *crtc) yesno(crtc_state->hw.active), DRM_MODE_ARG(&crtc_state->hw.adjusted_mode)); - seq_printf(m, "\tpipe src size=%dx%d, dither=%s, bpp=%d\n", + seq_printf(m, "\tpipe src size=%dx%d, dither=%s, bpp=%d, port clock=%d, lane count=%d\n", crtc_state->pipe_src_w, crtc_state->pipe_src_h, - yesno(crtc_state->dither), crtc_state->pipe_bpp); + yesno(crtc_state->dither), crtc_state->pipe_bpp, + crtc_state->port_clock, crtc_state->lane_count); intel_scaler_info(m, crtc); } -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFC: dma-buf: Require VM_SPECIAL vma for mmap (rev2)
== Series Details == Series: RFC: dma-buf: Require VM_SPECIAL vma for mmap (rev2) URL : https://patchwork.freedesktop.org/series/86667/ State : warning == Summary == $ dim checkpatch origin/drm-tip a259cff180fc RFC: dma-buf: Require VM_PFNMAP vma for mmap -:34: WARNING:TYPO_SPELLING: 'entires' may be misspelled - perhaps 'entries'? #34: >From auditing the various functions to insert pfn pte entires ^^^ -:39: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #39: References: https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/ -:97: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 3 warnings, 0 checks, 39 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel: Expose SYS_kcmp by default
Hi Chris, Thank you for the patch! Yet something to improve: [auto build test ERROR on linux/master] [also build test ERROR on kees/for-next/seccomp kees/for-next/pstore linus/master v5.11-rc6 next-20210125] [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/Chris-Wilson/kernel-Expose-SYS_kcmp-by-default/20210206-004006 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2ab38c17aac10bf55ab3efde4c4db3893d8691d2 config: powerpc-randconfig-r023-20210205 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project c9439ca36342fb6013187d0a69aef92736951476) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://github.com/0day-ci/linux/commit/f7694e48ae81aac5a226e74421dbda1dcdc3ca92 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Chris-Wilson/kernel-Expose-SYS_kcmp-by-default/20210206-004006 git checkout f7694e48ae81aac5a226e74421dbda1dcdc3ca92 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All error/warnings (new ones prefixed by >>): In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :190:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from kernel/kcmp.c:3: In file included from include/linux/syscalls.h:84: In file included from include/trace/syscall.h:7: In file included from include/linux/trace_events.h:9: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :192:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from kernel/kcmp.c:3: In file included from include/linux/syscalls.h:84: In file included from include/trace/syscall.h:7: In file included from include/linux/trace_events.h:9: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :194:1: note: expanded from her
Re: [Intel-gfx] [PATCH] kernel: Expose SYS_kcmp by default
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on kees/for-next/seccomp kees/for-next/pstore
linus/master v5.11-rc6 next-20210125]
[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/Chris-Wilson/kernel-Expose-SYS_kcmp-by-default/20210206-004006
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
2ab38c17aac10bf55ab3efde4c4db3893d8691d2
config: i386-randconfig-s002-20210205 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-215-g0fb77bb6-dirty
#
https://github.com/0day-ci/linux/commit/f7694e48ae81aac5a226e74421dbda1dcdc3ca92
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Chris-Wilson/kernel-Expose-SYS_kcmp-by-default/20210206-004006
git checkout f7694e48ae81aac5a226e74421dbda1dcdc3ca92
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
kernel/kcmp.c: In function 'kcmp_epoll_target':
>> kernel/kcmp.c:117:13: error: implicit declaration of function
>> 'get_epoll_tfile_raw_ptr'; did you mean 'get_file_raw_ptr'?
>> [-Werror=implicit-function-declaration]
117 | filp_tgt = get_epoll_tfile_raw_ptr(filp_epoll, slot.tfd, slot.toff);
| ^~~
| get_file_raw_ptr
>> kernel/kcmp.c:117:11: warning: assignment to 'struct file *' from 'int'
>> makes pointer from integer without a cast [-Wint-conversion]
117 | filp_tgt = get_epoll_tfile_raw_ptr(filp_epoll, slot.tfd, slot.toff);
| ^
cc1: some warnings being treated as errors
vim +117 kernel/kcmp.c
d97b46a64674a2 Cyrill Gorcunov 2012-05-31 96
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 97 #ifdef CONFIG_EPOLL
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 98 static int
kcmp_epoll_target(struct task_struct *task1,
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 99
struct task_struct *task2,
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 100
unsigned long idx1,
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 101
struct kcmp_epoll_slot __user *uslot)
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 102 {
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 103struct file *filp,
*filp_epoll, *filp_tgt;
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 104struct kcmp_epoll_slot
slot;
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 105
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 106if
(copy_from_user(&slot, uslot, sizeof(slot)))
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 107return -EFAULT;
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 108
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 109filp =
get_file_raw_ptr(task1, idx1);
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 110if (!filp)
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 111return -EBADF;
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 112
f43c283a89a7dc Eric W. Biederman 2020-11-20 113filp_epoll =
fget_task(task2, slot.efd);
f43c283a89a7dc Eric W. Biederman 2020-11-20 114if (!filp_epoll)
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 115return -EBADF;
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 116
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 @117filp_tgt =
get_epoll_tfile_raw_ptr(filp_epoll, slot.tfd, slot.toff);
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 118fput(filp_epoll);
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 119
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 120if (IS_ERR(filp_tgt))
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 121return
PTR_ERR(filp_tgt);
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 122
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 123return kcmp_ptr(filp,
filp_tgt, KCMP_FILE);
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 124 }
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 125 #else
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 126 static int
kcmp_epoll_target(struct task_struct *task1,
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 127
struct task_struct *task2,
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 128
unsigned long idx1,
0791e3644e5ef2 Cyrill Gorcunov 2017-07-12 129
struct kcmp_epoll
[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC: dma-buf: Require VM_SPECIAL vma for mmap (rev2)
== Series Details == Series: RFC: dma-buf: Require VM_SPECIAL vma for mmap (rev2) URL : https://patchwork.freedesktop.org/series/86667/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9740 -> Patchwork_19606 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19606 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19606, 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_19606/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19606: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-ilk-650: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-ilk-650/igt@run...@aborted.html - fi-bsw-kefka: NOTRUN -> [FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-bsw-kefka/igt@run...@aborted.html - fi-tgl-y: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-tgl-y/igt@run...@aborted.html - fi-bsw-nick:NOTRUN -> [FAIL][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-bsw-nick/igt@run...@aborted.html - fi-snb-2520m: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-snb-2520m/igt@run...@aborted.html - fi-ivb-3770:NOTRUN -> [FAIL][6] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-ivb-3770/igt@run...@aborted.html - fi-elk-e7500: NOTRUN -> [FAIL][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-elk-e7500/igt@run...@aborted.html - fi-bsw-n3050: NOTRUN -> [FAIL][8] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-bsw-n3050/igt@run...@aborted.html - fi-tgl-u2: NOTRUN -> [FAIL][9] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-tgl-u2/igt@run...@aborted.html * igt@vgem_basic@dmabuf-mmap: - fi-ivb-3770:[PASS][10] -> [DMESG-WARN][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-ivb-3770/igt@vgem_ba...@dmabuf-mmap.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-ivb-3770/igt@vgem_ba...@dmabuf-mmap.html - fi-glk-dsi: [PASS][12] -> [DMESG-WARN][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-glk-dsi/igt@vgem_ba...@dmabuf-mmap.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-glk-dsi/igt@vgem_ba...@dmabuf-mmap.html - fi-kbl-soraka: [PASS][14] -> [DMESG-WARN][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-kbl-soraka/igt@vgem_ba...@dmabuf-mmap.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-kbl-soraka/igt@vgem_ba...@dmabuf-mmap.html - fi-elk-e7500: [PASS][16] -> [DMESG-WARN][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-elk-e7500/igt@vgem_ba...@dmabuf-mmap.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-elk-e7500/igt@vgem_ba...@dmabuf-mmap.html - fi-skl-6700k2: [PASS][18] -> [DMESG-WARN][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-skl-6700k2/igt@vgem_ba...@dmabuf-mmap.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-skl-6700k2/igt@vgem_ba...@dmabuf-mmap.html - fi-cml-s: [PASS][20] -> [DMESG-WARN][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-cml-s/igt@vgem_ba...@dmabuf-mmap.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-cml-s/igt@vgem_ba...@dmabuf-mmap.html - fi-cfl-guc: [PASS][22] -> [DMESG-WARN][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-cfl-guc/igt@vgem_ba...@dmabuf-mmap.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-cfl-guc/igt@vgem_ba...@dmabuf-mmap.html - fi-hsw-4770:[PASS][24] -> [DMESG-WARN][25] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-hsw-4770/igt@vgem_ba...@dmabuf-mmap.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-hsw-4770/igt@vgem_ba...@dmabuf-mmap.html - fi-bsw-n3050: [PASS][26] -> [DMESG-WARN][27] [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-bsw-n3050/igt@vgem_ba...@dmabuf-mmap.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-bsw-n3050/igt@vgem_ba...@dmabuf-mmap.html - fi-ilk-650: [PASS][28] -> [DMESG-WARN][29] [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-ilk-650/igt@vgem_ba...@dmabuf-mmap.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19606/fi-
Re: [Intel-gfx] [PATCH 1/3] i915/display/intel_dp: Read PCON DSC ENC caps only for DPCD rev >= 1.4
On Thu, Feb 04, 2021 at 12:18:40PM +0530, Ankit Nautiyal wrote: > DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E. > Do not read the registers if DPCD rev < 1.4. > > Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/2868 > Signed-off-by: Ankit Nautiyal > --- > drivers/gpu/drm/i915/display/intel_dp.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 8c12d5375607..2b83f0f433a2 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -2489,9 +2489,11 @@ static void intel_dp_get_pcon_dsc_cap(struct intel_dp > *intel_dp) > struct drm_i915_private *i915 = dp_to_i915(intel_dp); > > /* Clear the cached register set to avoid using stale values */ > - > memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd)); > > + if (intel_dp->dpcd[DP_DPCD_REV] < 0x14) > + return; > + Can't check the spec, but makes sense that this stuff is only valid for recent DCPD revisions. Acked-by: Ville Syrjälä > if (drm_dp_dpcd_read(&intel_dp->aux, DP_PCON_DSC_ENCODER, >intel_dp->pcon_dsc_dpcd, >sizeof(intel_dp->pcon_dsc_dpcd)) < 0) > -- > 2.29.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 2/3] drm/dp_helper: Define options for FRL training for HDMI2.1 PCON
On Thu, Feb 04, 2021 at 12:18:41PM +0530, Ankit Nautiyal wrote:
> Currently the FRL training mode (Concurrent, Sequential) and
> training type (Normal, Extended) are not defined properly and
> are passed as bool values in drm_helpers for pcon
> configuration for FRL training.
>
> This patch:
> -Defines FRL training type and link bring up sequence mode as enum.
> -Fixes the drm_helpers for FRL Training configuration to use these enums.
> -Modifies the calls to the above drm_helpers in i915/intel_dp as per the
> above change.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_dp_helper.c | 18 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
> include/drm/drm_dp_helper.h | 46 +++--
> 3 files changed, 56 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index eedbb48815b7..2ca4ab5af470 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2635,14 +2635,13 @@ EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
> * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
> * @aux: DisplayPort AUX channel
> * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
> - * @concurrent_mode: true if concurrent mode or operation is required,
> - * false otherwise.
> + * @frl_mode: FRL Training mode, it can be either Concurrent or Sequential.
> *
> * Returns 0 if success, else returns negative error code.
> */
>
> int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
> - bool concurrent_mode)
> + enum dp_pcon_frl_train_mode frl_mode)
> {
> int ret;
> u8 buf;
> @@ -2651,7 +2650,7 @@ int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux,
> int max_frl_gbps,
> if (ret < 0)
> return ret;
>
> - if (concurrent_mode)
> + if (frl_mode == DP_PCON_FRL_MODE_CONCURRENT)
> buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
> else
> buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
> @@ -2694,21 +2693,20 @@ EXPORT_SYMBOL(drm_dp_pcon_frl_configure_1);
> * drm_dp_pcon_frl_configure_2() - Set HDMI Link configuration Step-2
> * @aux: DisplayPort AUX channel
> * @max_frl_mask : Max FRL BW to be tried by the PCON with HDMI Sink
> - * @extended_train_mode : true for Extended Mode, false for Normal Mode.
> - * In Normal mode, the PCON tries each frl bw from the max_frl_mask starting
> - * from min, and stops when link training is successful. In Extended mode,
> all
> - * frl bw selected in the mask are trained by the PCON.
> + * @frl_type : FRL training type, can be Extended, or Normal.
> *
> * Returns 0 if success, else returns negative error code.
> */
> int drm_dp_pcon_frl_configure_2(struct drm_dp_aux *aux, int max_frl_mask,
> - bool extended_train_mode)
> + enum dp_pcon_frl_train_type frl_type)
> {
> int ret;
> u8 buf = max_frl_mask;
>
> - if (extended_train_mode)
> + if (frl_type == DP_PCON_FRL_TRAIN_EXTENDED)
> buf |= DP_PCON_FRL_LINK_TRAIN_EXTENDED;
> + else
> + buf &= ~DP_PCON_FRL_LINK_TRAIN_EXTENDED;
These names are annoyingly close to each other. Prettu much
guaranteed to mix them up at some point. We should try to come
up something a bit more distinctive for the enum, or just forget
the enum and use the register values directly.
>
> ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_2, buf);
> if (ret < 0)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2b83f0f433a2..1962d6dd8641 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2560,10 +2560,6 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp
> *intel_dp)
>
> static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
> {
> -#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
> -#define PCON_CONCURRENT_MODE (1 > 0)
> -#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
> -#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
> #define TIMEOUT_FRL_READY_MS 500
> #define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
>
> @@ -2597,10 +2593,12 @@ static int intel_dp_pcon_start_frl_training(struct
> intel_dp *intel_dp)
> return -ETIMEDOUT;
>
> max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
> - ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw,
> PCON_SEQUENTIAL_MODE);
> + ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw,
> + DP_PCON_FRL_MODE_SEQUENTIAL);
> if (ret < 0)
> return ret;
> - ret = drm_dp_pcon_frl_configure_2(&intel_dp->aux, max_frl_bw_mask,
> PCON_NORMAL_TRAIN_MODE);
> + ret = drm_dp_pcon_frl_configure_2(&intel_dp->aux, max_frl_bw_mask,
> +
Re: [Intel-gfx] [PATCH 3/3] i915/display: Remove FRL related code from disable DP sequence for older platforms
On Thu, Feb 04, 2021 at 12:18:42PM +0530, Ankit Nautiyal wrote: > Remove code for resetting frl related members from intel_disable_dp, as > this is not applicable for older platforms. > > Signed-off-by: Ankit Nautiyal > --- > drivers/gpu/drm/i915/display/intel_dp.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 1962d6dd8641..9d94bdf5f517 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -2387,8 +2387,6 @@ static void intel_disable_dp(struct intel_atomic_state > *state, > intel_edp_backlight_off(old_conn_state); > intel_dp_set_power(intel_dp, DP_SET_POWER_D3); > intel_pps_off(intel_dp); > - intel_dp->frl.is_trained = false; > - intel_dp->frl.trained_rate_gbps = 0; If we don't need it in the ddi path we don't need it here. Reviewed-by: Ville Syrjälä > } > > static void g4x_disable_dp(struct intel_atomic_state *state, > -- > 2.29.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 1/3] i915/display/intel_dp: Read PCON DSC ENC caps only for DPCD rev >= 1.4
On Fri, Feb 05, 2021 at 09:58:07PM +0200, Ville Syrjälä wrote: > On Thu, Feb 04, 2021 at 12:18:40PM +0530, Ankit Nautiyal wrote: > > DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E. > > Do not read the registers if DPCD rev < 1.4. > > > > Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/2868 > > Signed-off-by: Ankit Nautiyal > > --- > > drivers/gpu/drm/i915/display/intel_dp.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > b/drivers/gpu/drm/i915/display/intel_dp.c > > index 8c12d5375607..2b83f0f433a2 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > @@ -2489,9 +2489,11 @@ static void intel_dp_get_pcon_dsc_cap(struct > > intel_dp *intel_dp) > > struct drm_i915_private *i915 = dp_to_i915(intel_dp); > > > > /* Clear the cached register set to avoid using stale values */ > > - > > memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd)); > > > > + if (intel_dp->dpcd[DP_DPCD_REV] < 0x14) > > + return; > > + > > Can't check the spec, but makes sense that this stuff is only valid > for recent DCPD revisions. > > Acked-by: Ville Syrjälä Yes checked the DP 1.4 spec and this is correct Reviewed-by: Manasi Navare Manasi > > > if (drm_dp_dpcd_read(&intel_dp->aux, DP_PCON_DSC_ENCODER, > > intel_dp->pcon_dsc_dpcd, > > sizeof(intel_dp->pcon_dsc_dpcd)) < 0) > > -- > > 2.29.2 > > -- > Ville Syrjälä > Intel > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] i915/display/intel_dp: Read PCON DSC ENC caps only for DPCD rev >= 1.4
On Fri, Feb 05, 2021 at 12:07:41PM -0800, Navare, Manasi wrote: > On Fri, Feb 05, 2021 at 09:58:07PM +0200, Ville Syrjälä wrote: > > On Thu, Feb 04, 2021 at 12:18:40PM +0530, Ankit Nautiyal wrote: > > > DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E. > > > Do not read the registers if DPCD rev < 1.4. > > > > > > Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/2868 > > > Signed-off-by: Ankit Nautiyal > > > --- > > > drivers/gpu/drm/i915/display/intel_dp.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > > b/drivers/gpu/drm/i915/display/intel_dp.c > > > index 8c12d5375607..2b83f0f433a2 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > > @@ -2489,9 +2489,11 @@ static void intel_dp_get_pcon_dsc_cap(struct > > > intel_dp *intel_dp) > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp); > > > > > > /* Clear the cached register set to avoid using stale values */ > > > - > > > memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd)); > > > > > > + if (intel_dp->dpcd[DP_DPCD_REV] < 0x14) > > > + return; > > > + > > > > Can't check the spec, but makes sense that this stuff is only valid > > for recent DCPD revisions. > > > > Acked-by: Ville Syrjälä > > Yes checked the DP 1.4 spec and this is correct I didn't think this is in the DP spec, but rather some special extra spec which I do not have. > > Reviewed-by: Manasi Navare > > Manasi > > > > > > if (drm_dp_dpcd_read(&intel_dp->aux, DP_PCON_DSC_ENCODER, > > >intel_dp->pcon_dsc_dpcd, > > >sizeof(intel_dp->pcon_dsc_dpcd)) < 0) > > > -- > > > 2.29.2 > > > > -- > > Ville Syrjälä > > Intel > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] i915/display/intel_dp: Read PCON DSC ENC caps only for DPCD rev >= 1.4
On Fri, Feb 05, 2021 at 10:06:48PM +0200, Ville Syrjälä wrote: > On Fri, Feb 05, 2021 at 12:07:41PM -0800, Navare, Manasi wrote: > > On Fri, Feb 05, 2021 at 09:58:07PM +0200, Ville Syrjälä wrote: > > > On Thu, Feb 04, 2021 at 12:18:40PM +0530, Ankit Nautiyal wrote: > > > > DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E. > > > > Do not read the registers if DPCD rev < 1.4. > > > > > > > > Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/2868 > > > > Signed-off-by: Ankit Nautiyal > > > > --- > > > > drivers/gpu/drm/i915/display/intel_dp.c | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > > > b/drivers/gpu/drm/i915/display/intel_dp.c > > > > index 8c12d5375607..2b83f0f433a2 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > > > @@ -2489,9 +2489,11 @@ static void intel_dp_get_pcon_dsc_cap(struct > > > > intel_dp *intel_dp) > > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp); > > > > > > > > /* Clear the cached register set to avoid using stale values */ > > > > - > > > > memset(intel_dp->pcon_dsc_dpcd, 0, > > > > sizeof(intel_dp->pcon_dsc_dpcd)); > > > > > > > > + if (intel_dp->dpcd[DP_DPCD_REV] < 0x14) > > > > + return; > > > > + > > > > > > Can't check the spec, but makes sense that this stuff is only valid > > > for recent DCPD revisions. > > > > > > Acked-by: Ville Syrjälä > > > > Yes checked the DP 1.4 spec and this is correct > > I didn't think this is in the DP spec, but rather some special extra > spec which I do not have. Yes I meant just double checked that the DSC support itself from DP 1.4 and hence makes sense that the PCON DSC regs also from >= 1.4 Manasi > > > > > Reviewed-by: Manasi Navare > > > > Manasi > > > > > > > > > if (drm_dp_dpcd_read(&intel_dp->aux, DP_PCON_DSC_ENCODER, > > > > intel_dp->pcon_dsc_dpcd, > > > > sizeof(intel_dp->pcon_dsc_dpcd)) < 0) > > > > -- > > > > 2.29.2 > > > > > > -- > > > Ville Syrjälä > > > Intel > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Add link rate and lane count to i915_display_info
On Fri, Feb 05, 2021 at 11:09:36AM -0800, Khaled Almahallawy wrote: > Link rate and lane count information are more easier and faster to check in > i915_display_info > than checking kernel logs for people not familiar with i915 in the following > scenarios: > * Debugging DP tunnel bandwidth usage in Thunderbolt driver. > * In USB4 certification, it is a requirement to know which link rate used by > monitor to prove that DP tunnel handle up to HBR3 > * In PHY Compliance, when the connector propes are not mounted correctly, > some display lanes will not show up in the DP Oscilloscope and will fail > CTS. > Just give the tester an easy way to identify where the problem is. > > v2(Ville): Uniform style for '=' and use 'port clock' instead of 'link rate' Yes this is really good, having this as part of display_info. I am just wondering if this makes sense to be part of connector_info or crtc_info What would be more readable and intuitive. But again since its part of crtc_state, may be easier to be part of crtc_info. Manasi > > Cc: Imre Deak > Cc: Ville Syrjälä > CC: José Roberto de Souza > Signed-off-by: Khaled Almahallawy > --- > drivers/gpu/drm/i915/display/intel_display_debugfs.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > index d62b18d5ecd8..cb088a0a26f3 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > @@ -990,9 +990,10 @@ static void intel_crtc_info(struct seq_file *m, struct > intel_crtc *crtc) > yesno(crtc_state->hw.active), > DRM_MODE_ARG(&crtc_state->hw.adjusted_mode)); > > - seq_printf(m, "\tpipe src size=%dx%d, dither=%s, bpp=%d\n", > + seq_printf(m, "\tpipe src size=%dx%d, dither=%s, bpp=%d, port > clock=%d, lane count=%d\n", > crtc_state->pipe_src_w, crtc_state->pipe_src_h, > -yesno(crtc_state->dither), crtc_state->pipe_bpp); > +yesno(crtc_state->dither), crtc_state->pipe_bpp, > +crtc_state->port_clock, crtc_state->lane_count); > > intel_scaler_info(m, crtc); > } > -- > 2.25.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALID
From: Ville Syrjälä
We tend to use output_format!=RGB as a shorthand for YCbCr, but
this fails if we have a disabled crtc where output_format==INVALID.
We're now getting some fail from intel_color_check() when we have:
hw.enable==false
hw.ctm!=NULL
output_format==INVALID
Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the
dumpster, and thus everything defaults to RGB when the crtc
is disabled.
This does beg the deeper question of how much of the state
should we in fact be validating when hw/uapi.enable==false.
And should we even be doing the uapi->hw copy when
uapi.enable==false? So far I've not been able to come up with
satisfactory answers for myself, so I'm putting it off for the
moment.
Cc: Lee Shawn C
Fixes: 0aa5c3835c8a ("drm/i915: support two CSC module on gen11 and later")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 1 -
drivers/gpu/drm/i915/display/intel_display.c | 3 +--
drivers/gpu/drm/i915/display/intel_display_types.h | 1 -
3 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 57b0a3ebe908..8e77ca7ddf11 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -109,7 +109,6 @@ void intel_crtc_state_reset(struct intel_crtc_state
*crtc_state,
crtc_state->cpu_transcoder = INVALID_TRANSCODER;
crtc_state->master_transcoder = INVALID_TRANSCODER;
crtc_state->hsw_workaround_pipe = INVALID_PIPE;
- crtc_state->output_format = INTEL_OUTPUT_FORMAT_INVALID;
crtc_state->scaler_state.scaler_id = -1;
crtc_state->mst_master_transcoder = INVALID_TRANSCODER;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 92c14f3f0abf..46d0093187f8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10220,7 +10220,6 @@ static void snprintf_output_types(char *buf, size_t len,
}
static const char * const output_format_str[] = {
- [INTEL_OUTPUT_FORMAT_INVALID] = "Invalid",
[INTEL_OUTPUT_FORMAT_RGB] = "RGB",
[INTEL_OUTPUT_FORMAT_YCBCR420] = "YCBCR4:2:0",
[INTEL_OUTPUT_FORMAT_YCBCR444] = "YCBCR4:4:4",
@@ -10229,7 +10228,7 @@ static const char * const output_format_str[] = {
static const char *output_formats(enum intel_output_format format)
{
if (format >= ARRAY_SIZE(output_format_str))
- format = INTEL_OUTPUT_FORMAT_INVALID;
+ return "invalid";
return output_format_str[format];
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 307ff4b771f4..b3ac39fea6f0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -830,7 +830,6 @@ struct intel_crtc_wm_state {
};
enum intel_output_format {
- INTEL_OUTPUT_FORMAT_INVALID,
INTEL_OUTPUT_FORMAT_RGB,
INTEL_OUTPUT_FORMAT_YCBCR420,
INTEL_OUTPUT_FORMAT_YCBCR444,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Ratelimit heartbeat completion probing (rev7)
== Series Details == Series: drm/i915/gt: Ratelimit heartbeat completion probing (rev7) URL : https://patchwork.freedesktop.org/series/86665/ State : success == Summary == CI Bug Log - changes from CI_DRM_9740 -> Patchwork_19607 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19607/index.html Known issues Here are the changes found in Patchwork_19607 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#2411] / [i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19607/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-byt-j1900: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19607/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html * igt@kms_chamelium@hdmi-crc-fast: - fi-byt-j1900: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19607/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html * igt@prime_vgem@basic-fence-flip: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19607/fi-tgl-y/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@prime_self_import@basic-with_one_bo_two_files: - 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_9740/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19607/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 38) -- Additional (1): fi-byt-j1900 Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9740 -> Patchwork_19607 CI-20190529: 20190529 CI_DRM_9740: d0d6b3dabc3c5f35990abedf7361eb27f7123f4d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5993: b1225ec25d5671a985c5bb48739111d2e8a723cf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19607: 4f05cc2083694c58b54d71fd79bed6ef83180f05 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4f05cc208369 drm/i915/gt: Ratelimit heartbeat completion probing == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19607/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/vbt: update DP max link rate table
On Mon, Feb 01, 2021 at 11:02:28PM +0800, Lee Shawn C wrote:
> According to Bspec #20124, max link rate table for DP was updated
> at BDB version 230. Max link rate can support upto UHBR.
>
> After migrate to BDB v230, the definition for LBR, HBR2 and HBR3
> were changed. For backward compatibility. If BDB version was
> from 216 to 229. Driver have to follow original rule to configure
> DP max link rate value from VBT.
>
> Cc: Ville Syrjala
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Cooper Chiou
> Cc: William Tseng
> Signed-off-by: Lee Shawn C
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 24 ++-
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 14 +++
> 2 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 04337ac6f8c4..be1f732e6550 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1876,7 +1876,15 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv,
> /* DP max link rate for CNL+ */
> if (bdb_version >= 216) {
> switch (child->dp_max_link_rate) {
> - default:
> + case VBT_DP_MAX_LINK_RATE_UHBR20:
> + info->dp_max_link_rate = 200;
> + break;
> + case VBT_DP_MAX_LINK_RATE_UHBR13P5:
> + info->dp_max_link_rate = 135;
> + break;
> + case VBT_DP_MAX_LINK_RATE_UHBR10:
> + info->dp_max_link_rate = 100;
> + break;
> case VBT_DP_MAX_LINK_RATE_HBR3:
> info->dp_max_link_rate = 81;
> break;
> @@ -1889,7 +1897,21 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv,
> case VBT_DP_MAX_LINK_RATE_LBR:
> info->dp_max_link_rate = 162000;
> break;
> + case VBT_DP_MAX_LINK_RATE_DEFAULT:
> + default:
> + info->dp_max_link_rate = 0;
> + break;
> + }
> +
> + if (bdb_version < 230) {
> + if (child->dp_max_link_rate ==
> VBT_DP_MAX_LINK_RATE_DEFAULT)
> + info->dp_max_link_rate = 81;
> + else if (child->dp_max_link_rate ==
> VBT_DP_MAX_LINK_RATE_LBR)
> + info->dp_max_link_rate = 54;
> + else if (child->dp_max_link_rate ==
> VBT_DP_MAX_LINK_RATE_HBR2)
> + info->dp_max_link_rate = 162000;
> }
I would split this into two separate functions, one does the new
mapping, the other the old mapping.
> +
> drm_dbg_kms(&dev_priv->drm,
> "VBT DP max link rate for port %c: %d\n",
> port_name(port), info->dp_max_link_rate);
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 6d10fa037751..578a54b33f32 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -343,10 +343,14 @@ enum vbt_gmbus_ddi {
> #define DP_AUX_H 0x80
> #define DP_AUX_I 0x90
>
> -#define VBT_DP_MAX_LINK_RATE_HBR30
> -#define VBT_DP_MAX_LINK_RATE_HBR21
> +#define VBT_DP_MAX_LINK_RATE_DEFAULT 0
> +#define VBT_DP_MAX_LINK_RATE_LBR 1
> #define VBT_DP_MAX_LINK_RATE_HBR 2
> -#define VBT_DP_MAX_LINK_RATE_LBR 3
> +#define VBT_DP_MAX_LINK_RATE_HBR23
> +#define VBT_DP_MAX_LINK_RATE_HBR34
> +#define VBT_DP_MAX_LINK_RATE_UHBR10 5
> +#define VBT_DP_MAX_LINK_RATE_UHBR13P56
> +#define VBT_DP_MAX_LINK_RATE_UHBR20 7
And we should keep both old and new names for these.
Sadly I can't right now check the spec since it no longer has the
old stuff apparently, and the VBT section got moved around so the
history no longer shows anything either :( I'll have to pull the whole
thing down I guess so I can double check against the old version.
>
> /*
> * The child device config, aka the display device data structure, provides a
> @@ -445,8 +449,8 @@ struct child_device_config {
> u16 dp_gpio_pin_num;/* 195 */
> u8 dp_iboost_level:4; /* 196 */
> u8 hdmi_iboost_level:4; /* 196 */
> - u8 dp_max_link_rate:2; /* 216 CNL+ */
> - u8 dp_max_link_rate_reserved:6; /* 216 */
> + u8 dp_max_link_rate:3; /* 230 */
> + u8 dp_max_link_rate_reserved:5; /* 230 */
> } __packed;
>
> struct bdb_general_definitions {
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: refactor intel_display.c + a bit more (rev2)
== Series Details ==
Series: drm/i915: refactor intel_display.c + a bit more (rev2)
URL : https://patchwork.freedesktop.org/series/86723/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2685c66ddd72 drm/i915: migrate skl planes code new file (v5)
-:2738: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#2738:
new file mode 100644
-:3213: CHECK:LINE_SPACING: Please don't use multiple blank lines
#3213: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:471:
+
+
-:3784: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#3784: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:1042:
+ (plane_state->color_plane[1].y << 16) |
plane_state->color_plane[1].x);
-:4091: CHECK:LINE_SPACING: Please don't use multiple blank lines
#4091: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:1349:
+
+
-:4479: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#4479: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:1737:
+ return skl_planar_formats;
+ } else {
-:4492: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#4492: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:1750:
+ return glk_planar_formats;
+ } else {
-:4508: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#4508: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:1766:
+ return icl_sdr_y_plane_formats;
+ } else {
-:4851: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#4851: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:2109:
+ drm_plane_create_scaling_filter_property(&plane->base,
+ BIT(DRM_SCALING_FILTER_DEFAULT)
|
total: 0 errors, 5 warnings, 3 checks, 4928 lines checked
bb3d788424ca drm/i915: move pipe update code into crtc. (v2)
-:247: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#247: FILE: drivers/gpu/drm/i915/display/intel_crtc.c:541:
+* while ... */
total: 0 errors, 1 warnings, 0 checks, 506 lines checked
4e167ec1a05f drm/i915: split fb scalable checks into g4x and skl versions
839eee02c59c drm/i915: move is_ccs_modifier to an inline
f98c7886db90 drm/i915: migrate pll enable/disable code to intel_dpll.[ch]
-:640: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#640: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1399:
+ udelay(150);
-:658: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#658: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1417:
+ udelay(150); /* wait for warmup */
-:699: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#699: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1458:
+ udelay(150);
-:724: CHECK:LINE_SPACING: Please don't use multiple blank lines
#724: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1483:
+
+
-:808: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#808: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1567:
+ pipe_config->dpll_hw_state.dpll & ~(DPLL_VCO_ENABLE |
DPLL_EXT_BUFFER_ENABLE_VLV));
-:861: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#861: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1620:
+ vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW10(pipe),
+0x009f0003);
-:864: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#864: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1623:
+ vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW10(pipe),
+0x00df);
-:870: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#870: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1629:
+ vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW5(pipe),
+0x0df4);
-:873: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#873: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1632:
+ vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW5(pipe),
+0x0df7);
-:878: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#878: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1637:
+ vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW5(pipe),
+0x0df7);
-:881: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#881: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1640:
+ vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW5(pipe),
+0x0df4);
-:929: CHECK:PARENTHESIS_ALIGNME
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: refactor intel_display.c + a bit more (rev2)
== Series Details == Series: drm/i915: refactor intel_display.c + a bit more (rev2) URL : https://patchwork.freedesktop.org/series/86723/ 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/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 8/8] drm/i915: move ddi pll state get to dpll mgr
On Fri, Feb 05, 2021 at 05:09:14PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 05, 2021 at 04:48:43PM +0200, Jani Nikula wrote:
> > From: Dave Airlie
> >
> > This just migrates the hsw+ code to a better place.
> >
> > Signed-off-by: Dave Airlie
> > Signed-off-by: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 219 +
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 223 ++
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 2 +
> > 3 files changed, 226 insertions(+), 218 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index beed08c00b6c..f7c1f036d38f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -6520,212 +6520,6 @@ static bool ilk_get_pipe_config(struct intel_crtc
> > *crtc,
> > return ret;
> > }
> >
> > -static void dg1_get_ddi_pll(struct drm_i915_private *dev_priv, enum port
> > port,
> > - struct intel_crtc_state *pipe_config)
> > -{
> > - enum icl_port_dpll_id port_dpll_id = ICL_PORT_DPLL_DEFAULT;
> > - enum phy phy = intel_port_to_phy(dev_priv, port);
> > - struct icl_port_dpll *port_dpll;
> > - struct intel_shared_dpll *pll;
> > - enum intel_dpll_id id;
> > - bool pll_active;
> > - u32 clk_sel;
> > -
> > - clk_sel = intel_de_read(dev_priv, DG1_DPCLKA_CFGCR0(phy)) &
> > DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> > - id = DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_DPLL_MAP(clk_sel, phy);
>
> Hmm. Since this mostly about DPCLKA_CFGCR/PORT_CLK_SEL/etc.
> I think intel_ddi.c would the more approriate place, especially
> when considering my recent DDI clock routing refactoring.
> I guess we could even consider intel_ddi_clock.c or
> somesuch to stuff all of it into. Now I'm also tempted
> to turn this stuff into vfuncs as well, to partner up
> with the new encoder->{enable,disable}_clock().
Temptation turned into code. I think I have a decent way forward
with this idea on top of my other refactorings, so I'd just drop
this patch.
--
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] kernel: Expose SYS_kcmp by default
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote: > > On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote: > > Userspace has discovered the functionality offered by SYS_kcmp and has > > started to depend upon it. In particular, Mesa uses SYS_kcmp for > > os_same_file_description() in order to identify when two fd (e.g. device > > or dmabuf) point to the same struct file. Since they depend on it for > > core functionality, lift SYS_kcmp out of the non-default > > CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. > > > > Signed-off-by: Chris Wilson > > Cc: Kees Cook > > Cc: Andy Lutomirski > > Cc: Will Drewry > > Cc: Andrew Morton > > Cc: Dave Airlie > > Cc: Daniel Vetter > > Cc: Lucas Stach > > --- > > init/Kconfig | 11 +++ > > kernel/Makefile | 2 +- > > tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- > > 3 files changed, 13 insertions(+), 2 deletions(-) > > > > diff --git a/init/Kconfig b/init/Kconfig > > index b77c60f8b963..f62fca13ac5b 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -1194,6 +1194,7 @@ endif # NAMESPACES > > config CHECKPOINT_RESTORE > > bool "Checkpoint/restore support" > > select PROC_CHILDREN > > + select KCMP > > default n > > help > > Enables additional kernel features in a sake of checkpoint/restore. > > @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS > > config ARCH_HAS_MEMBARRIER_SYNC_CORE > > bool > > > > +config KCMP > > + bool "Enable kcmp() system call" if EXPERT > > + default y > > I would expect this to be not default-y, especially if > CHECKPOINT_RESTORE does a "select" on it. > > This is a really powerful syscall, but it is bounded by ptrace access > controls, and uses pointer address obfuscation, so it may be okay to > expose this. As it is, at least Ubuntu already has > CONFIG_CHECKPOINT_RESTORE, so really, there's probably not much > difference on exposure. > > So, if you drop the "default y", I'm fine with this. It was maybe stupid, but our userspace started relying on fd comaprison through sys_kcomp. So for better or worse, if you want to run the mesa3d gl/vk stacks, you need this. Was maybe not the brighest ideas, but since enough distros had this enabled by defaults, it wasn't really discovered, and now we're shipping this everywhere. Ofc we can leave the default n, but the select if CONFIG_DRM is unfortunately needed I think. For that part: Acked-by: Daniel Vetter Also adding Dave Airlie for his take. -Daniel > > -Kees > > > + help > > + Enable the file descriptor comparison system call. It provides > > + user-space with the ability to compare two fd to see if they > > + point to the same file, and check other attributes. > > + > > + If unsure, say Y. > > + > > config RSEQ > > bool "Enable rseq() system call" if EXPERT > > default y > > diff --git a/kernel/Makefile b/kernel/Makefile > > index aa7368c7eabf..320f1f3941b7 100644 > > --- a/kernel/Makefile > > +++ b/kernel/Makefile > > @@ -51,7 +51,7 @@ obj-y += livepatch/ > > obj-y += dma/ > > obj-y += entry/ > > > > -obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o > > +obj-$(CONFIG_KCMP) += kcmp.o > > obj-$(CONFIG_FREEZER) += freezer.o > > obj-$(CONFIG_PROFILING) += profile.o > > obj-$(CONFIG_STACKTRACE) += stacktrace.o > > diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c > > b/tools/testing/selftests/seccomp/seccomp_bpf.c > > index 26c72f2b61b1..1b6c7d33c4ff 100644 > > --- a/tools/testing/selftests/seccomp/seccomp_bpf.c > > +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c > > @@ -315,7 +315,7 @@ TEST(kcmp) > > ret = __filecmp(getpid(), getpid(), 1, 1); > > EXPECT_EQ(ret, 0); > > if (ret != 0 && errno == ENOSYS) > > - SKIP(return, "Kernel does not support kcmp() (missing > > CONFIG_CHECKPOINT_RESTORE?)"); > > + SKIP(return, "Kernel does not support kcmp() (missing > > CONFIG_KCMP?)"); > > } > > > > TEST(mode_strict_support) > > -- > > 2.20.1 > > > > -- > Kees Cook -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: refactor intel_display.c + a bit more (rev2)
== Series Details == Series: drm/i915: refactor intel_display.c + a bit more (rev2) URL : https://patchwork.freedesktop.org/series/86723/ State : success == Summary == CI Bug Log - changes from CI_DRM_9740 -> Patchwork_19608 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19608/index.html Known issues Here are the changes found in Patchwork_19608 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_9740/fi-tgl-y/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19608/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_huc_copy@huc-copy: - fi-byt-j1900: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19608/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html * igt@kms_chamelium@hdmi-crc-fast: - fi-byt-j1900: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19608/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([i915#2128]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19608/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html Possible fixes * igt@prime_self_import@basic-with_one_bo_two_files: - 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_9740/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19608/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2128]: https://gitlab.freedesktop.org/drm/intel/issues/2128 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 38) -- Additional (1): fi-byt-j1900 Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9740 -> Patchwork_19608 CI-20190529: 20190529 CI_DRM_9740: d0d6b3dabc3c5f35990abedf7361eb27f7123f4d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5993: b1225ec25d5671a985c5bb48739111d2e8a723cf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19608: f08f7fd56aa6493d50ebafcdec37cdce548189fb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f08f7fd56aa6 drm/i915: move ddi pll state get to dpll mgr a69fe8588de2 drm/i915: refactor skylake scaler code into new file. 2758eb6d6841 drm/i915: migrate i9xx plane get config f98c7886db90 drm/i915: migrate pll enable/disable code to intel_dpll.[ch] 839eee02c59c drm/i915: move is_ccs_modifier to an inline 4e167ec1a05f drm/i915: split fb scalable checks into g4x and skl versions bb3d788424ca drm/i915: move pipe update code into crtc. (v2) 2685c66ddd72 drm/i915: migrate skl planes code new file (v5) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19608/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915: cleanup the region class/instance encoding
== Series Details == Series: series starting with [v2,1/2] drm/i915: cleanup the region class/instance encoding URL : https://patchwork.freedesktop.org/series/86753/ State : success == Summary == CI Bug Log - changes from CI_DRM_9737_full -> Patchwork_19602_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19602_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-glk: [PASS][1] -> [TIMEOUT][2] ([i915#2918]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-glk7/igt@gem_ctx_persiste...@close-replace-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-glk3/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][3] -> [FAIL][4] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-kbl4/igt@gem_exec_f...@basic-deadline.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-kbl4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-kbl: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2849]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#2389]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-apl7/igt@gem_exec_reloc@basic-many-act...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-apl7/igt@gem_exec_reloc@basic-many-act...@rcs0.html - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2389]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-glk8/igt@gem_exec_reloc@basic-many-act...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-glk2/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1610] / [i915#2803]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-skl4/igt@gem_exec_schedule@u-fairsl...@vcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-skl1/igt@gem_exec_schedule@u-fairsl...@vcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][19] -> [SKIP][20] ([i915#2190]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-tglb5/igt@gem_huc_c...@huc-copy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#644]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9737/shard-glk6/igt@gem_pp...@flink-and-close-vma-leak.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-glk1/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_hangman@engine-error@vecs0: - shard-kbl: NOTRUN -> [SKIP][23] ([fdo#109271]) +40 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-kbl2/igt@i915_hangman@engine-er...@vecs0.html * igt@i915_pm_rpm@modeset-pc8-residency-stress: - shard-tglb: NOTRUN -> [SKIP][24] ([fdo#109506] / [i915#2411]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-tglb5/igt@i915_pm_...@modeset-pc8-residency-stress.html * igt@i915_selftest@live@gt_lrc: - shard-tglb: NOTRUN -> [DMESG-FAIL][25] ([i915#2373]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19602/shard-tglb5/igt@i915_s
[Intel-gfx] [PATCH v2] kernel: Expose SYS_kcmp by default
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend upon it. In particular, Mesa uses SYS_kcmp for
os_same_file_description() in order to identify when two fd (e.g. device
or dmabuf) point to the same struct file. Since they depend on it for
core functionality, lift SYS_kcmp out of the non-default
CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
Note that some distributions such as Ubuntu are already enabling
CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
Signed-off-by: Chris Wilson
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Andrew Morton
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
Acked-by: Daniel Vetter # DRM depends on SYS_kcmp
---
v2:
- Default n.
- Borrrow help message from man kcmp.
- Export get_epoll_tfile_raw_ptr() for CONFIG_KCMP
---
fs/eventpoll.c| 4 ++--
include/linux/eventpoll.h | 2 +-
init/Kconfig | 12
kernel/Makefile | 2 +-
tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
5 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index a829af074eb5..3196474cbe24 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -979,7 +979,7 @@ static struct epitem *ep_find(struct eventpoll *ep, struct
file *file, int fd)
return epir;
}
-#ifdef CONFIG_CHECKPOINT_RESTORE
+#ifdef CONFIG_KCMP
static struct epitem *ep_find_tfd(struct eventpoll *ep, int tfd, unsigned long
toff)
{
struct rb_node *rbp;
@@ -1021,7 +1021,7 @@ struct file *get_epoll_tfile_raw_ptr(struct file *file,
int tfd,
return file_raw;
}
-#endif /* CONFIG_CHECKPOINT_RESTORE */
+#endif /* CONFIG_KCMP */
/**
* Adds a new entry to the tail of the list in a lockless way, i.e.
diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
index 0350393465d4..593322c946e6 100644
--- a/include/linux/eventpoll.h
+++ b/include/linux/eventpoll.h
@@ -18,7 +18,7 @@ struct file;
#ifdef CONFIG_EPOLL
-#ifdef CONFIG_CHECKPOINT_RESTORE
+#ifdef CONFIG_KCMP
struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, unsigned long
toff);
#endif
diff --git a/init/Kconfig b/init/Kconfig
index b77c60f8b963..1b75141bc18b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1194,6 +1194,7 @@ endif # NAMESPACES
config CHECKPOINT_RESTORE
bool "Checkpoint/restore support"
select PROC_CHILDREN
+ select KCMP
default n
help
Enables additional kernel features in a sake of checkpoint/restore.
@@ -1737,6 +1738,17 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS
config ARCH_HAS_MEMBARRIER_SYNC_CORE
bool
+config KCMP
+ bool "Enable kcmp() system call" if EXPERT
+ default n
+ help
+ Enable the kernel resource comparison system call. It provides
+ user-space with the ability to compare two processes to see if they
+ share a common resource, such as a file descriptor or even virtual
+ memory space.
+
+ If unsure, say N.
+
config RSEQ
bool "Enable rseq() system call" if EXPERT
default y
diff --git a/kernel/Makefile b/kernel/Makefile
index aa7368c7eabf..320f1f3941b7 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -51,7 +51,7 @@ obj-y += livepatch/
obj-y += dma/
obj-y += entry/
-obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o
+obj-$(CONFIG_KCMP) += kcmp.o
obj-$(CONFIG_FREEZER) += freezer.o
obj-$(CONFIG_PROFILING) += profile.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 26c72f2b61b1..1b6c7d33c4ff 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -315,7 +315,7 @@ TEST(kcmp)
ret = __filecmp(getpid(), getpid(), 1, 1);
EXPECT_EQ(ret, 0);
if (ret != 0 && errno == ENOSYS)
- SKIP(return, "Kernel does not support kcmp() (missing
CONFIG_CHECKPOINT_RESTORE?)");
+ SKIP(return, "Kernel does not support kcmp() (missing
CONFIG_KCMP?)");
}
TEST(mode_strict_support)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] kernel: Expose SYS_kcmp by default
The subject should of course be changed, as it is no longer being
enabled by default.
Something like
kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
Quoting Chris Wilson (2021-02-05 21:06:10)
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf) point to the same struct file. Since they depend on it for
> core functionality, lift SYS_kcmp out of the non-default
> CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
>
> Note that some distributions such as Ubuntu are already enabling
> CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
> Signed-off-by: Chris Wilson
> Cc: Kees Cook
> Cc: Andy Lutomirski
> Cc: Will Drewry
> Cc: Andrew Morton
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Lucas Stach
> Acked-by: Daniel Vetter # DRM depends on SYS_kcmp
>
> ---
> v2:
> - Default n.
> - Borrrow help message from man kcmp.
> - Export get_epoll_tfile_raw_ptr() for CONFIG_KCMP
> ---
> fs/eventpoll.c| 4 ++--
> include/linux/eventpoll.h | 2 +-
> init/Kconfig | 12
> kernel/Makefile | 2 +-
> tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
> 5 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index a829af074eb5..3196474cbe24 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -979,7 +979,7 @@ static struct epitem *ep_find(struct eventpoll *ep,
> struct file *file, int fd)
> return epir;
> }
>
> -#ifdef CONFIG_CHECKPOINT_RESTORE
> +#ifdef CONFIG_KCMP
> static struct epitem *ep_find_tfd(struct eventpoll *ep, int tfd, unsigned
> long toff)
> {
> struct rb_node *rbp;
> @@ -1021,7 +1021,7 @@ struct file *get_epoll_tfile_raw_ptr(struct file *file,
> int tfd,
>
> return file_raw;
> }
> -#endif /* CONFIG_CHECKPOINT_RESTORE */
> +#endif /* CONFIG_KCMP */
>
> /**
> * Adds a new entry to the tail of the list in a lockless way, i.e.
> diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
> index 0350393465d4..593322c946e6 100644
> --- a/include/linux/eventpoll.h
> +++ b/include/linux/eventpoll.h
> @@ -18,7 +18,7 @@ struct file;
>
> #ifdef CONFIG_EPOLL
>
> -#ifdef CONFIG_CHECKPOINT_RESTORE
> +#ifdef CONFIG_KCMP
> struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, unsigned
> long toff);
> #endif
>
> diff --git a/init/Kconfig b/init/Kconfig
> index b77c60f8b963..1b75141bc18b 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1194,6 +1194,7 @@ endif # NAMESPACES
> config CHECKPOINT_RESTORE
> bool "Checkpoint/restore support"
> select PROC_CHILDREN
> + select KCMP
> default n
> help
> Enables additional kernel features in a sake of checkpoint/restore.
> @@ -1737,6 +1738,17 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS
> config ARCH_HAS_MEMBARRIER_SYNC_CORE
> bool
>
> +config KCMP
> + bool "Enable kcmp() system call" if EXPERT
> + default n
> + help
> + Enable the kernel resource comparison system call. It provides
> + user-space with the ability to compare two processes to see if they
> + share a common resource, such as a file descriptor or even virtual
> + memory space.
> +
> + If unsure, say N.
> +
> config RSEQ
> bool "Enable rseq() system call" if EXPERT
> default y
> diff --git a/kernel/Makefile b/kernel/Makefile
> index aa7368c7eabf..320f1f3941b7 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -51,7 +51,7 @@ obj-y += livepatch/
> obj-y += dma/
> obj-y += entry/
>
> -obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o
> +obj-$(CONFIG_KCMP) += kcmp.o
> obj-$(CONFIG_FREEZER) += freezer.o
> obj-$(CONFIG_PROFILING) += profile.o
> obj-$(CONFIG_STACKTRACE) += stacktrace.o
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index 26c72f2b61b1..1b6c7d33c4ff 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -315,7 +315,7 @@ TEST(kcmp)
> ret = __filecmp(getpid(), getpid(), 1, 1);
> EXPECT_EQ(ret, 0);
> if (ret != 0 && errno == ENOSYS)
> - SKIP(return, "Kernel does not support kcmp() (missing
> CONFIG_CHECKPOINT_RESTORE?)");
> + SKIP(return, "Kernel does not support kcmp() (missing
> CONFIG_KCMP?)");
> }
>
> TEST(mode_strict_support)
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice
On Fri, Feb 05, 2021 at 06:24:08PM +0200, Ville Syrjälä wrote: > On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote: > > On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote: > > > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote: > > > > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote: > > > > > From: Ville Syrjälä > > > > > > > > > > drm_vblank_restore() exists because certain power saving states > > > > > can clobber the hardware frame counter. The way it does this is > > > > > by guesstimating how many frames were missed purely based on > > > > > the difference between the last stored timestamp vs. a newly > > > > > sampled timestamp. > > > > > > > > > > If we should call this function before a full frame has > > > > > elapsed since we sampled the last timestamp we would end up > > > > > with a possibly slightly different timestamp value for the > > > > > same frame. Currently we will happily overwrite the already > > > > > stored timestamp for the frame with the new value. This > > > > > could cause userspace to observe two different timestamps > > > > > for the same frame (and the timestamp could even go > > > > > backwards depending on how much error we introduce when > > > > > correcting the timestamp based on the scanout position). > > > > > > > > > > To avoid that let's not update the stored timestamp unless we're > > > > > also incrementing the sequence counter. We do still want to update > > > > > vblank->last with the freshly sampled hw frame counter value so > > > > > that subsequent vblank irqs/queries can actually use the hw frame > > > > > counter to determine how many frames have elapsed. > > > > > > > > Hm I'm not getting the reason for why we store the updated hw vblank > > > > counter? > > > > > > Because next time a vblank irq happens the code will do: > > > diff = current_hw_counter - vblank->last > > > > > > which won't work very well if vblank->last is garbage. > > > > > > Updating vblank->last is pretty much why drm_vblank_restore() > > > exists at all. > > > > Oh sure, _restore has to update this, together with the timestamp. > > > > But your code adds such an update where we update the hw vblank counter, > > but not the timestamp, and that feels buggy. Either we're still in the > > same frame, and then we should story nothing. Or we advanced, and then we > > probably want a new timestampt for that frame too. > > Even if we're still in the same frame the hw frame counter may already > have been reset due to the power well having been turned off. That is > what I'm trying to fix here. > > Now I suppose that's fairly unlikely, at least with PSR which probably > does impose some extra delays before the power gets yanked. But at least > theoretically possible. Pondering about this a bit further. I think the fact that the current code takes the round-to-closest approach I used for the vblank handler is perhaps a bit bad. It could push the seq counter forward if we're past the halfway point of a frame. I think that rounding behaviour makes sense for the irq since those tick steadily and so allowing a bit of error either way seems correct to me. Perhaps round-down might be the better option for _restore(). Not quites sure, need more thinking probably. Another idea that came to me now is that maybe we should actually just check if the current hw frame counter value looks sane, as in something like: diff_hw_counter = current_hw_counter-stored_hw_counter diff_ts = (current_ts-stored_ts)/framedur if (diff_hw_counter ~= diff_ts) diff = diff_hw_counter; else diff = diff_ts; and if they seem to match then just keep trusting the hw counter. So only if there's a significant difference would we disregard the diff of the hw counter and instead use the diff based on the timestamps. Not sure what "significant" is though; One frame, two frames? -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] kernel: Expose SYS_kcmp by default
On Fri, Feb 05, 2021 at 09:16:01PM +, Chris Wilson wrote:
> The subject should of course be changed, as it is no longer being
> enabled by default.
"default n" is redundant. I thought Daniel said CONFIG_DRM needed to
"select" it too, though? Otherwise, yeah, this looks good. Was the
export due to the 0-day bot failure reports?
-Kees
>
> Something like
>
> kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
>
> Quoting Chris Wilson (2021-02-05 21:06:10)
> > Userspace has discovered the functionality offered by SYS_kcmp and has
> > started to depend upon it. In particular, Mesa uses SYS_kcmp for
> > os_same_file_description() in order to identify when two fd (e.g. device
> > or dmabuf) point to the same struct file. Since they depend on it for
> > core functionality, lift SYS_kcmp out of the non-default
> > CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
> >
> > Note that some distributions such as Ubuntu are already enabling
> > CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
> >
> > References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
> > Signed-off-by: Chris Wilson
> > Cc: Kees Cook
> > Cc: Andy Lutomirski
> > Cc: Will Drewry
> > Cc: Andrew Morton
> > Cc: Dave Airlie
> > Cc: Daniel Vetter
> > Cc: Lucas Stach
> > Acked-by: Daniel Vetter # DRM depends on SYS_kcmp
> >
> > ---
> > v2:
> > - Default n.
> > - Borrrow help message from man kcmp.
> > - Export get_epoll_tfile_raw_ptr() for CONFIG_KCMP
> > ---
> > fs/eventpoll.c| 4 ++--
> > include/linux/eventpoll.h | 2 +-
> > init/Kconfig | 12
> > kernel/Makefile | 2 +-
> > tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
> > 5 files changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> > index a829af074eb5..3196474cbe24 100644
> > --- a/fs/eventpoll.c
> > +++ b/fs/eventpoll.c
> > @@ -979,7 +979,7 @@ static struct epitem *ep_find(struct eventpoll *ep,
> > struct file *file, int fd)
> > return epir;
> > }
> >
> > -#ifdef CONFIG_CHECKPOINT_RESTORE
> > +#ifdef CONFIG_KCMP
> > static struct epitem *ep_find_tfd(struct eventpoll *ep, int tfd, unsigned
> > long toff)
> > {
> > struct rb_node *rbp;
> > @@ -1021,7 +1021,7 @@ struct file *get_epoll_tfile_raw_ptr(struct file
> > *file, int tfd,
> >
> > return file_raw;
> > }
> > -#endif /* CONFIG_CHECKPOINT_RESTORE */
> > +#endif /* CONFIG_KCMP */
> >
> > /**
> > * Adds a new entry to the tail of the list in a lockless way, i.e.
> > diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
> > index 0350393465d4..593322c946e6 100644
> > --- a/include/linux/eventpoll.h
> > +++ b/include/linux/eventpoll.h
> > @@ -18,7 +18,7 @@ struct file;
> >
> > #ifdef CONFIG_EPOLL
> >
> > -#ifdef CONFIG_CHECKPOINT_RESTORE
> > +#ifdef CONFIG_KCMP
> > struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, unsigned
> > long toff);
> > #endif
> >
> > diff --git a/init/Kconfig b/init/Kconfig
> > index b77c60f8b963..1b75141bc18b 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -1194,6 +1194,7 @@ endif # NAMESPACES
> > config CHECKPOINT_RESTORE
> > bool "Checkpoint/restore support"
> > select PROC_CHILDREN
> > + select KCMP
> > default n
> > help
> > Enables additional kernel features in a sake of
> > checkpoint/restore.
> > @@ -1737,6 +1738,17 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS
> > config ARCH_HAS_MEMBARRIER_SYNC_CORE
> > bool
> >
> > +config KCMP
> > + bool "Enable kcmp() system call" if EXPERT
> > + default n
> > + help
> > + Enable the kernel resource comparison system call. It provides
> > + user-space with the ability to compare two processes to see if
> > they
> > + share a common resource, such as a file descriptor or even virtual
> > + memory space.
> > +
> > + If unsure, say N.
> > +
> > config RSEQ
> > bool "Enable rseq() system call" if EXPERT
> > default y
> > diff --git a/kernel/Makefile b/kernel/Makefile
> > index aa7368c7eabf..320f1f3941b7 100644
> > --- a/kernel/Makefile
> > +++ b/kernel/Makefile
> > @@ -51,7 +51,7 @@ obj-y += livepatch/
> > obj-y += dma/
> > obj-y += entry/
> >
> > -obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o
> > +obj-$(CONFIG_KCMP) += kcmp.o
> > obj-$(CONFIG_FREEZER) += freezer.o
> > obj-$(CONFIG_PROFILING) += profile.o
> > obj-$(CONFIG_STACKTRACE) += stacktrace.o
> > diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> > b/tools/testing/selftests/seccomp/seccomp_bpf.c
> > index 26c72f2b61b1..1b6c7d33c4ff 100644
> > --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> > +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> > @@ -315,7 +315,7 @@ TEST(kcmp)
> > ret = __filecmp(getpid(), getpid(), 1, 1);
Re: [Intel-gfx] [PATCH v2] kernel: Expose SYS_kcmp by default
Quoting Kees Cook (2021-02-05 21:20:33) > On Fri, Feb 05, 2021 at 09:16:01PM +, Chris Wilson wrote: > > The subject should of course be changed, as it is no longer being > > enabled by default. > > "default n" is redundant. I thought being explicit would be preferred. There are a few other default n, so at least it's not the odd-one-out! > I thought Daniel said CONFIG_DRM needed to > "select" it too, though? Yes. We will need to select it for any DRM driver so that the Vulkan/GL stacks can rely on having SYS_kcmp. That deserves to be handled and explain within drm/Kconfig, and as they are already shipping with calls to SYS_kcmp we may have to ask for a stable backport. > Otherwise, yeah, this looks good. Was the > export due to the 0-day bot failure reports? Yes. -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/display: Allow PSR2 selective fetch to be enabled at run-time
== Series Details == Series: drm/i915/display: Allow PSR2 selective fetch to be enabled at run-time URL : https://patchwork.freedesktop.org/series/86773/ State : success == Summary == CI Bug Log - changes from CI_DRM_9740 -> Patchwork_19609 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19609/index.html Known issues Here are the changes found in Patchwork_19609 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@bad-flink: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19609/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html * igt@gem_huc_copy@huc-copy: - fi-byt-j1900: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19609/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html * igt@kms_chamelium@hdmi-crc-fast: - fi-byt-j1900: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19609/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html Possible fixes * igt@gem_ringfill@basic-all: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9740/fi-tgl-y/igt@gem_ringf...@basic-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19609/fi-tgl-y/igt@gem_ringf...@basic-all.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 38) -- Additional (1): fi-byt-j1900 Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9740 -> Patchwork_19609 CI-20190529: 20190529 CI_DRM_9740: d0d6b3dabc3c5f35990abedf7361eb27f7123f4d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5993: b1225ec25d5671a985c5bb48739111d2e8a723cf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19609: 0a3f51f0aa083f72e8e2d5dfc910c3fd89ce64d1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0a3f51f0aa08 drm/i915/display: Allow PSR2 selective fetch to be enabled at run-time == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19609/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 00/15] drm/i915: Clean up the DDI clock routing mess
From: Ville Syrjälä
Sorry for spamming the same series again and again.
v2 still had some issues around FDI, and to fix those
I had to stick a fresh patch to the start of the series.
Hopefully it's now solid.
I have a few more patches already cooked up on top to
clean up the readout side too. But I'm going to try
land this part first.
Ville Syrjälä (15):
drm/i915: Use intel_ddi_clk_select() for FDI
drm/i915: Introduce .{enable,disable}_clock() encoder vfuncs
drm/i915: Extract hsw_ddi_{enable,disable}_clock()
drm/i915: Extract skl_ddi_{enable,disable}_clock()
drm/i195: Extract cnl_ddi_{enable,disable}_clock()
drm/i915: Convert DG1 over to .{enable,disable}_clock()
drm/i915: Extract icl+ .{enable,disable}_clock() vfuncs
drm/i915: Use intel_de_rmw() for DDI clock routing
drm/i915: Sprinkle a few missing locks around shared DDI clock
registers
drm/i915: Sprinkle WARN(!pll) into icl/dg1 .clock_enable()
drm/i915: Extract _cnl_ddi_{enable,disable}_clock()
drm/i915: Split adl-s/rkl from icl_ddi_combo_{enable,disable}_clock()
drm/i915: Use .disable_clock() for pll sanitation
drm/i915: Relocate icl_sanitize_encoder_pll_mapping()
drm/i915: s/dev_priv/i915/ for the remainder of DDI clock routing
drivers/gpu/drm/i915/display/icl_dsi.c| 1 +
drivers/gpu/drm/i915/display/intel_crt.c | 2 +
drivers/gpu/drm/i915/display/intel_ddi.c | 578 ++
drivers/gpu/drm/i915/display/intel_ddi.h | 6 +-
.../drm/i915/display/intel_display_types.h| 6 +
drivers/gpu/drm/i915/display/intel_fdi.c | 7 +-
6 files changed, 326 insertions(+), 274 deletions(-)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 02/15] drm/i915: Introduce .{enable, disable}_clock() encoder vfuncs
From: Ville Syrjälä
The current code dealing with the clock routing for DDI encoders
is a maintenance nightmare. Let's start cleaning it up by allowing
the encoder to provide vfuncs for enablign/disabling the clock.
We leave them initially unimplemented, falling back to the old
if-else approach.
v2: Convert the FDI enable sequence
Reviewed-by: Lucas De Marchi #v2
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 29 +++
drivers/gpu/drm/i915/display/intel_ddi.h | 4 +--
.../drm/i915/display/intel_display_types.h| 6
drivers/gpu/drm/i915/display/intel_fdi.c | 2 +-
4 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index dbef228555a0..ebfbd68b8e82 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1927,6 +1927,23 @@ static void intel_ddi_clk_disable(struct intel_encoder
*encoder)
}
}
+void intel_ddi_enable_clock(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ if (encoder->enable_clock)
+ encoder->enable_clock(encoder, crtc_state);
+ else
+ intel_ddi_clk_select(encoder, crtc_state);
+}
+
+static void intel_ddi_disable_clock(struct intel_encoder *encoder)
+{
+ if (encoder->disable_clock)
+ encoder->disable_clock(encoder);
+ else
+ intel_ddi_clk_disable(encoder);
+}
+
static void
icl_program_mg_dp_mode(struct intel_digital_port *dig_port,
const struct intel_crtc_state *crtc_state)
@@ -2171,7 +2188,7 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
* hsw_crtc_enable()->intel_enable_shared_dpll(). We need only
* configure the PLL to port mapping here.
*/
- intel_ddi_clk_select(encoder, crtc_state);
+ intel_ddi_enable_clock(encoder, crtc_state);
/* 5. If IO power is controlled through PWR_WELL_CTL, Enable IO Power */
if (!intel_phy_is_tc(dev_priv, phy) ||
@@ -2292,7 +2309,7 @@ static void hsw_ddi_pre_enable_dp(struct
intel_atomic_state *state,
intel_pps_on(intel_dp);
- intel_ddi_clk_select(encoder, crtc_state);
+ intel_ddi_enable_clock(encoder, crtc_state);
if (!intel_phy_is_tc(dev_priv, phy) ||
dig_port->tc_mode != TC_PORT_TBT_ALT) {
@@ -2367,7 +2384,7 @@ static void intel_ddi_pre_enable_hdmi(struct
intel_atomic_state *state,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
- intel_ddi_clk_select(encoder, crtc_state);
+ intel_ddi_enable_clock(encoder, crtc_state);
drm_WARN_ON(&dev_priv->drm, dig_port->ddi_io_wakeref);
dig_port->ddi_io_wakeref = intel_display_power_get(dev_priv,
@@ -2519,7 +2536,7 @@ static void intel_ddi_post_disable_dp(struct
intel_atomic_state *state,
dig_port->ddi_io_power_domain,
fetch_and_zero(&dig_port->ddi_io_wakeref));
- intel_ddi_clk_disable(encoder);
+ intel_ddi_disable_clock(encoder);
}
static void intel_ddi_post_disable_hdmi(struct intel_atomic_state *state,
@@ -2542,7 +2559,7 @@ static void intel_ddi_post_disable_hdmi(struct
intel_atomic_state *state,
dig_port->ddi_io_power_domain,
fetch_and_zero(&dig_port->ddi_io_wakeref));
- intel_ddi_clk_disable(encoder);
+ intel_ddi_disable_clock(encoder);
intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
}
@@ -2642,7 +2659,7 @@ void intel_ddi_fdi_post_disable(struct intel_atomic_state
*state,
intel_de_write(dev_priv, FDI_RX_CTL(PIPE_A), val);
intel_disable_ddi_buf(encoder, old_crtc_state);
- intel_ddi_clk_disable(encoder);
+ intel_ddi_disable_clock(encoder);
val = intel_de_read(dev_priv, FDI_RX_MISC(PIPE_A));
val &= ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index e618e1c80252..1aa0eedbf342 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -28,8 +28,8 @@ void intel_ddi_fdi_post_disable(struct intel_atomic_state
*state,
struct intel_encoder *intel_encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state
*old_conn_state);
-void intel_ddi_clk_select(struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state);
+void intel_ddi_enable_clock(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state);
void
[Intel-gfx] [PATCH v3 01/15] drm/i915: Use intel_ddi_clk_select() for FDI
From: Ville Syrjälä
We want to put all DDI clock routing code into one place.
Unify the FDI enable sequence to use the standard function
instead of hand rolling its own. The disable sequence already
uses the normal thing.
Cc: Lucas De Marchi
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 +++---
drivers/gpu/drm/i915/display/intel_ddi.h | 3 ++-
drivers/gpu/drm/i915/display/intel_fdi.c | 7 +++
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 28877a31adc0..dbef228555a0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -184,7 +184,7 @@ static void intel_wait_ddi_buf_active(struct
drm_i915_private *dev_priv,
port_name(port));
}
-u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll *pll)
+static u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll *pll)
{
switch (pll->info->id) {
case DPLL_ID_WRPLL1:
@@ -1845,8 +1845,8 @@ void icl_sanitize_encoder_pll_mapping(struct
intel_encoder *encoder)
icl_sanitize_port_clk_off(dev_priv, port_mask, ddi_clk_needed);
}
-static void intel_ddi_clk_select(struct intel_encoder *encoder,
-const struct intel_crtc_state *crtc_state)
+void intel_ddi_clk_select(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = encoder->port;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index f9a916cad7e7..e618e1c80252 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -28,7 +28,8 @@ void intel_ddi_fdi_post_disable(struct intel_atomic_state
*state,
struct intel_encoder *intel_encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state
*old_conn_state);
-u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll *pll);
+void intel_ddi_clk_select(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state);
void intel_prepare_dp_ddi_buffers(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state);
void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c
b/drivers/gpu/drm/i915/display/intel_fdi.c
index 77df675e607e..dbd6be3342c0 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -565,7 +565,7 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- u32 temp, i, rx_ctl_val, ddi_pll_sel;
+ u32 temp, i, rx_ctl_val;
int n_entries;
intel_ddi_get_buf_trans_fdi(dev_priv, &n_entries);
@@ -595,9 +595,8 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
intel_de_write(dev_priv, FDI_RX_CTL(PIPE_A), rx_ctl_val);
/* Configure Port Clock Select */
- ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc_state->shared_dpll);
- intel_de_write(dev_priv, PORT_CLK_SEL(PORT_E), ddi_pll_sel);
- drm_WARN_ON(&dev_priv->drm, ddi_pll_sel != PORT_CLK_SEL_SPLL);
+ drm_WARN_ON(&dev_priv->drm, crtc_state->shared_dpll->info->id !=
DPLL_ID_SPLL);
+ intel_ddi_clk_select(encoder, crtc_state);
/* Start the training iterating through available voltages and emphasis,
* testing each value twice. */
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 03/15] drm/i915: Extract hsw_ddi_{enable, disable}_clock()
From: Ville Syrjälä
Yank out the HSW/BDW code from intel_ddi_clk_{select,disable}()
and put it into the new encoder .{enable,disable}_clock() vfuncs.
v2: s/dev_priv/i915/ (Lucas)
v3: Deal with FDI
Reviewed-by: Lucas De Marchi #v2
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crt.c | 2 ++
drivers/gpu/drm/i915/display/intel_ddi.c | 32 +++-
drivers/gpu/drm/i915/display/intel_ddi.h | 3 +++
3 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index 077ebc7e6396..91a8a42b4aa2 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -1076,6 +1076,8 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
crt->base.enable = hsw_enable_crt;
crt->base.disable = hsw_disable_crt;
crt->base.post_disable = hsw_post_disable_crt;
+ crt->base.enable_clock = hsw_ddi_enable_clock;
+ crt->base.disable_clock = hsw_ddi_disable_clock;
} else {
if (HAS_PCH_SPLIT(dev_priv)) {
crt->base.compute_config = pch_crt_compute_config;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ebfbd68b8e82..806712020530 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1896,9 +1896,6 @@ void intel_ddi_clk_select(struct intel_encoder *encoder,
intel_de_write(dev_priv, DPLL_CTRL2, val);
- } else if (INTEL_GEN(dev_priv) < 9) {
- intel_de_write(dev_priv, PORT_CLK_SEL(port),
- hsw_pll_to_ddi_pll_sel(pll));
}
mutex_unlock(&dev_priv->dpll.lock);
@@ -1921,12 +1918,30 @@ static void intel_ddi_clk_disable(struct intel_encoder
*encoder)
} else if (IS_GEN9_BC(dev_priv)) {
intel_de_write(dev_priv, DPLL_CTRL2,
intel_de_read(dev_priv, DPLL_CTRL2) |
DPLL_CTRL2_DDI_CLK_OFF(port));
- } else if (INTEL_GEN(dev_priv) < 9) {
- intel_de_write(dev_priv, PORT_CLK_SEL(port),
- PORT_CLK_SEL_NONE);
}
}
+void hsw_ddi_enable_clock(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ const struct intel_shared_dpll *pll = crtc_state->shared_dpll;
+ enum port port = encoder->port;
+
+ if (drm_WARN_ON(&i915->drm, !pll))
+ return;
+
+ intel_de_write(i915, PORT_CLK_SEL(port), hsw_pll_to_ddi_pll_sel(pll));
+}
+
+void hsw_ddi_disable_clock(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ enum port port = encoder->port;
+
+ intel_de_write(i915, PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
+}
+
void intel_ddi_enable_clock(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
@@ -4073,6 +4088,11 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
encoder->cloneable = 0;
encoder->pipe_mask = ~0;
+ if (IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv)) {
+ encoder->enable_clock = hsw_ddi_enable_clock;
+ encoder->disable_clock = hsw_ddi_disable_clock;
+ }
+
if (IS_DG1(dev_priv))
encoder->hpd_pin = dg1_hpd_pin(dev_priv, port);
else if (IS_ROCKETLAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 1aa0eedbf342..4a0c1d5c85e7 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -30,6 +30,9 @@ void intel_ddi_fdi_post_disable(struct intel_atomic_state
*state,
const struct drm_connector_state
*old_conn_state);
void intel_ddi_enable_clock(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state);
+void hsw_ddi_enable_clock(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state);
+void hsw_ddi_disable_clock(struct intel_encoder *encoder);
void intel_prepare_dp_ddi_buffers(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state);
void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 04/15] drm/i915: Extract skl_ddi_{enable, disable}_clock()
From: Ville Syrjälä
Extract the DDI clock routing clode for skl/derivatives
into the new encoder vfuncs.
v2: s/dev_priv/i915/ (Lucas)
Reviewed-by: Lucas De Marchi
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 53 +---
1 file changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 806712020530..3bd7dd28a4fc 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1885,17 +1885,6 @@ void intel_ddi_clk_select(struct intel_encoder *encoder,
val = intel_de_read(dev_priv, DPCLKA_CFGCR0);
val &= ~DPCLKA_CFGCR0_DDI_CLK_OFF(port);
intel_de_write(dev_priv, DPCLKA_CFGCR0, val);
- } else if (IS_GEN9_BC(dev_priv)) {
- /* DDI -> PLL mapping */
- val = intel_de_read(dev_priv, DPLL_CTRL2);
-
- val &= ~(DPLL_CTRL2_DDI_CLK_OFF(port) |
-DPLL_CTRL2_DDI_CLK_SEL_MASK(port));
- val |= (DPLL_CTRL2_DDI_CLK_SEL(pll->info->id, port) |
- DPLL_CTRL2_DDI_SEL_OVERRIDE(port));
-
- intel_de_write(dev_priv, DPLL_CTRL2, val);
-
}
mutex_unlock(&dev_priv->dpll.lock);
@@ -1915,12 +1904,43 @@ static void intel_ddi_clk_disable(struct intel_encoder
*encoder)
} else if (IS_CANNONLAKE(dev_priv)) {
intel_de_write(dev_priv, DPCLKA_CFGCR0,
intel_de_read(dev_priv, DPCLKA_CFGCR0) |
DPCLKA_CFGCR0_DDI_CLK_OFF(port));
- } else if (IS_GEN9_BC(dev_priv)) {
- intel_de_write(dev_priv, DPLL_CTRL2,
- intel_de_read(dev_priv, DPLL_CTRL2) |
DPLL_CTRL2_DDI_CLK_OFF(port));
}
}
+static void skl_ddi_enable_clock(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ const struct intel_shared_dpll *pll = crtc_state->shared_dpll;
+ enum port port = encoder->port;
+ u32 val;
+
+ if (drm_WARN_ON(&i915->drm, !pll))
+ return;
+
+ mutex_lock(&i915->dpll.lock);
+
+ val = intel_de_read(i915, DPLL_CTRL2);
+
+ val &= ~(DPLL_CTRL2_DDI_CLK_OFF(port) |
+DPLL_CTRL2_DDI_CLK_SEL_MASK(port));
+ val |= (DPLL_CTRL2_DDI_CLK_SEL(pll->info->id, port) |
+ DPLL_CTRL2_DDI_SEL_OVERRIDE(port));
+
+ intel_de_write(i915, DPLL_CTRL2, val);
+
+ mutex_unlock(&i915->dpll.lock);
+}
+
+static void skl_ddi_disable_clock(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ enum port port = encoder->port;
+
+ intel_de_write(i915, DPLL_CTRL2,
+ intel_de_read(i915, DPLL_CTRL2) |
DPLL_CTRL2_DDI_CLK_OFF(port));
+}
+
void hsw_ddi_enable_clock(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
@@ -4088,7 +4108,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
encoder->cloneable = 0;
encoder->pipe_mask = ~0;
- if (IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv)) {
+ if (IS_GEN9_BC(dev_priv)) {
+ encoder->enable_clock = skl_ddi_enable_clock;
+ encoder->disable_clock = skl_ddi_disable_clock;
+ } else if (IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv)) {
encoder->enable_clock = hsw_ddi_enable_clock;
encoder->disable_clock = hsw_ddi_disable_clock;
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 06/15] drm/i915: Convert DG1 over to .{enable, disable}_clock()
From: Ville Syrjälä
Replace dg1_{map,unmap}_plls_to_ports() with the appropriate
encoder vfuncs. And let's relocate the disable function next to
the enable function while at it.
Reviewed-by: Lucas De Marchi
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 43
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5c6cd71557a4..94df5e897d19 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1597,8 +1597,8 @@ static u32 icl_dpclka_cfgcr0_clk_off(struct
drm_i915_private *dev_priv,
return 0;
}
-static void dg1_map_plls_to_ports(struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state)
+static void dg1_ddi_enable_clock(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_shared_dpll *pll = crtc_state->shared_dpll;
@@ -1631,6 +1631,19 @@ static void dg1_map_plls_to_ports(struct intel_encoder
*encoder,
mutex_unlock(&dev_priv->dpll.lock);
}
+static void dg1_ddi_disable_clock(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
+
+ mutex_lock(&dev_priv->dpll.lock);
+
+ intel_de_rmw(dev_priv, DG1_DPCLKA_CFGCR0(phy), 0,
+DG1_DPCLKA_CFGCR0_DDI_CLK_OFF(phy));
+
+ mutex_unlock(&dev_priv->dpll.lock);
+}
+
static void icl_map_plls_to_ports(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
@@ -1683,19 +1696,6 @@ static void icl_map_plls_to_ports(struct intel_encoder
*encoder,
mutex_unlock(&dev_priv->dpll.lock);
}
-static void dg1_unmap_plls_to_ports(struct intel_encoder *encoder)
-{
- struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
-
- mutex_lock(&dev_priv->dpll.lock);
-
- intel_de_rmw(dev_priv, DG1_DPCLKA_CFGCR0(phy), 0,
-DG1_DPCLKA_CFGCR0_DDI_CLK_OFF(phy));
-
- mutex_unlock(&dev_priv->dpll.lock);
-}
-
static void icl_unmap_plls_to_ports(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -2477,9 +2477,7 @@ static void intel_ddi_pre_enable(struct
intel_atomic_state *state,
drm_WARN_ON(&dev_priv->drm, crtc_state->has_pch_encoder);
- if (IS_DG1(dev_priv))
- dg1_map_plls_to_ports(encoder, crtc_state);
- else if (INTEL_GEN(dev_priv) >= 11)
+ if (!IS_DG1(dev_priv) && INTEL_GEN(dev_priv) >= 11)
icl_map_plls_to_ports(encoder, crtc_state);
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
@@ -2680,9 +2678,7 @@ static void intel_ddi_post_disable(struct
intel_atomic_state *state,
intel_ddi_post_disable_dp(state, encoder, old_crtc_state,
old_conn_state);
- if (IS_DG1(dev_priv))
- dg1_unmap_plls_to_ports(encoder);
- else if (INTEL_GEN(dev_priv) >= 11)
+ if (!IS_DG1(dev_priv) && INTEL_GEN(dev_priv) >= 11)
icl_unmap_plls_to_ports(encoder);
if (intel_crtc_has_dp_encoder(old_crtc_state) || is_tc_port)
@@ -4127,7 +4123,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
encoder->cloneable = 0;
encoder->pipe_mask = ~0;
- if (IS_CANNONLAKE(dev_priv)) {
+ if (IS_DG1(dev_priv)) {
+ encoder->enable_clock = dg1_ddi_enable_clock;
+ encoder->disable_clock = dg1_ddi_disable_clock;
+ } else if (IS_CANNONLAKE(dev_priv)) {
encoder->enable_clock = cnl_ddi_enable_clock;
encoder->disable_clock = cnl_ddi_disable_clock;
} else if (IS_GEN9_BC(dev_priv)) {
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 05/15] drm/i195: Extract cnl_ddi_{enable, disable}_clock()
From: Ville Syrjälä
Extract the DDI clock routing for CNL into the new vfuncs.
v2: s/dev_priv/i915/ (Lucas)
Reviewed-by: Lucas De Marchi
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 62
1 file changed, 42 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3bd7dd28a4fc..5c6cd71557a4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1851,7 +1851,6 @@ void intel_ddi_clk_select(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = encoder->port;
enum phy phy = intel_port_to_phy(dev_priv, port);
- u32 val;
const struct intel_shared_dpll *pll = crtc_state->shared_dpll;
if (drm_WARN_ON(&dev_priv->drm, !pll))
@@ -1870,21 +1869,6 @@ void intel_ddi_clk_select(struct intel_encoder *encoder,
*/
intel_de_write(dev_priv, DDI_CLK_SEL(port),
DDI_CLK_SEL_MG);
- } else if (IS_CANNONLAKE(dev_priv)) {
- /* Configure DPCLKA_CFGCR0 to map the DPLL to the DDI. */
- val = intel_de_read(dev_priv, DPCLKA_CFGCR0);
- val &= ~DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
- val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, port);
- intel_de_write(dev_priv, DPCLKA_CFGCR0, val);
-
- /*
-* Configure DPCLKA_CFGCR0 to turn on the clock for the DDI.
-* This step and the step before must be done with separate
-* register writes.
-*/
- val = intel_de_read(dev_priv, DPCLKA_CFGCR0);
- val &= ~DPCLKA_CFGCR0_DDI_CLK_OFF(port);
- intel_de_write(dev_priv, DPCLKA_CFGCR0, val);
}
mutex_unlock(&dev_priv->dpll.lock);
@@ -1901,12 +1885,47 @@ static void intel_ddi_clk_disable(struct intel_encoder
*encoder)
(IS_JSL_EHL(dev_priv) && port >= PORT_C))
intel_de_write(dev_priv, DDI_CLK_SEL(port),
DDI_CLK_SEL_NONE);
- } else if (IS_CANNONLAKE(dev_priv)) {
- intel_de_write(dev_priv, DPCLKA_CFGCR0,
- intel_de_read(dev_priv, DPCLKA_CFGCR0) |
DPCLKA_CFGCR0_DDI_CLK_OFF(port));
}
}
+static void cnl_ddi_enable_clock(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ const struct intel_shared_dpll *pll = crtc_state->shared_dpll;
+ enum port port = encoder->port;
+ u32 val;
+
+ if (drm_WARN_ON(&i915->drm, !pll))
+ return;
+
+ mutex_lock(&i915->dpll.lock);
+
+ val = intel_de_read(i915, DPCLKA_CFGCR0);
+ val &= ~DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
+ val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, port);
+ intel_de_write(i915, DPCLKA_CFGCR0, val);
+
+ /*
+* "This step and the step before must be
+* done with separate register writes."
+*/
+ val = intel_de_read(i915, DPCLKA_CFGCR0);
+ val &= ~DPCLKA_CFGCR0_DDI_CLK_OFF(port);
+ intel_de_write(i915, DPCLKA_CFGCR0, val);
+
+ mutex_unlock(&i915->dpll.lock);
+}
+
+static void cnl_ddi_disable_clock(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ enum port port = encoder->port;
+
+ intel_de_write(i915, DPCLKA_CFGCR0,
+ intel_de_read(i915, DPCLKA_CFGCR0) |
DPCLKA_CFGCR0_DDI_CLK_OFF(port));
+}
+
static void skl_ddi_enable_clock(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
@@ -4108,7 +4127,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
encoder->cloneable = 0;
encoder->pipe_mask = ~0;
- if (IS_GEN9_BC(dev_priv)) {
+ if (IS_CANNONLAKE(dev_priv)) {
+ encoder->enable_clock = cnl_ddi_enable_clock;
+ encoder->disable_clock = cnl_ddi_disable_clock;
+ } else if (IS_GEN9_BC(dev_priv)) {
encoder->enable_clock = skl_ddi_enable_clock;
encoder->disable_clock = skl_ddi_disable_clock;
} else if (IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv)) {
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 08/15] drm/i915: Use intel_de_rmw() for DDI clock routing
From: Ville Syrjälä
The DDI clock routing programming is riddled with shared
registers, forcing us to do a lot of RMW. Switch over to
intel_de_rmw() to make that a bit less obnoxious.
Reviewed-by: Lucas De Marchi
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 77 +---
1 file changed, 28 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index d6f94a1e320e..0cb20163fb1f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1603,7 +1603,6 @@ static void dg1_ddi_enable_clock(struct intel_encoder
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_shared_dpll *pll = crtc_state->shared_dpll;
enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
- u32 val;
/*
* If we fail this, something went very wrong: first 2 PLLs should be
@@ -1616,17 +1615,12 @@ static void dg1_ddi_enable_clock(struct intel_encoder
*encoder,
mutex_lock(&dev_priv->dpll.lock);
- val = intel_de_read(dev_priv, DG1_DPCLKA_CFGCR0(phy));
- drm_WARN_ON(&dev_priv->drm,
- (val & DG1_DPCLKA_CFGCR0_DDI_CLK_OFF(phy)) == 0);
+ intel_de_rmw(dev_priv, DG1_DPCLKA_CFGCR0(phy),
+DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy),
+DG1_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy));
- val &= ~DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- val |= DG1_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
- intel_de_write(dev_priv, DG1_DPCLKA_CFGCR0(phy), val);
- intel_de_posting_read(dev_priv, DG1_DPCLKA_CFGCR0(phy));
-
- val &= ~DG1_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
- intel_de_write(dev_priv, DG1_DPCLKA_CFGCR0(phy), val);
+ intel_de_rmw(dev_priv, DG1_DPCLKA_CFGCR0(phy),
+DG1_DPCLKA_CFGCR0_DDI_CLK_OFF(phy), 0);
mutex_unlock(&dev_priv->dpll.lock);
}
@@ -1638,8 +1632,8 @@ static void dg1_ddi_disable_clock(struct intel_encoder
*encoder)
mutex_lock(&dev_priv->dpll.lock);
- intel_de_rmw(dev_priv, DG1_DPCLKA_CFGCR0(phy), 0,
-DG1_DPCLKA_CFGCR0_DDI_CLK_OFF(phy));
+ intel_de_rmw(dev_priv, DG1_DPCLKA_CFGCR0(phy),
+0, DG1_DPCLKA_CFGCR0_DDI_CLK_OFF(phy));
mutex_unlock(&dev_priv->dpll.lock);
}
@@ -1650,7 +1644,7 @@ static void icl_ddi_combo_enable_clock(struct
intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_shared_dpll *pll = crtc_state->shared_dpll;
enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
- u32 val, mask, sel;
+ u32 mask, sel;
i915_reg_t reg;
if (IS_ALDERLAKE_S(dev_priv)) {
@@ -1669,10 +1663,6 @@ static void icl_ddi_combo_enable_clock(struct
intel_encoder *encoder,
mutex_lock(&dev_priv->dpll.lock);
- val = intel_de_read(dev_priv, reg);
- drm_WARN_ON(&dev_priv->drm,
- (val & icl_dpclka_cfgcr0_clk_off(dev_priv, phy)) == 0);
-
/*
* Even though this register references DDIs, note that we
* want to pass the PHY rather than the port (DDI). For
@@ -1683,13 +1673,10 @@ static void icl_ddi_combo_enable_clock(struct
intel_encoder *encoder,
* Clock Select chooses the PLL for both DDIA and DDID and
* drives port A in all cases."
*/
- val &= ~mask;
- val |= sel;
- intel_de_write(dev_priv, reg, val);
- intel_de_posting_read(dev_priv, reg);
+ intel_de_rmw(dev_priv, reg, mask, sel);
- val &= ~icl_dpclka_cfgcr0_clk_off(dev_priv, phy);
- intel_de_write(dev_priv, reg, val);
+ intel_de_rmw(dev_priv, reg,
+icl_dpclka_cfgcr0_clk_off(dev_priv, phy), 0);
mutex_unlock(&dev_priv->dpll.lock);
}
@@ -1698,7 +1685,6 @@ static void icl_ddi_combo_disable_clock(struct
intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
- u32 val;
i915_reg_t reg;
mutex_lock(&dev_priv->dpll.lock);
@@ -1708,10 +1694,10 @@ static void icl_ddi_combo_disable_clock(struct
intel_encoder *encoder)
else
reg = ICL_DPCLKA_CFGCR0;
- val = intel_de_read(dev_priv, reg);
- val |= icl_dpclka_cfgcr0_clk_off(dev_priv, phy);
+ mutex_lock(&dev_priv->dpll.lock);
- intel_de_write(dev_priv, reg, val);
+ intel_de_rmw(dev_priv, reg,
+0, icl_dpclka_cfgcr0_clk_off(dev_priv, phy));
mutex_unlock(&dev_priv->dpll.lock);
}
@@ -1916,25 +1902,22 @@ static void cnl_ddi_enable_clock(struct intel_encoder
*encoder,
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
const struct intel_shared_dpll *pll = crtc_state->shared_dpll
