[Intel-gfx] ✗ Fi.CI.BAT: failure for Allow privileged user to map the OA buffer (rev4)

== Series Details == Series: Allow privileged user to map the OA buffer (rev4) URL : https://patchwork.freedesktop.org/series/79460/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8775 -> Patchwork_18221 Summary --- *

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On 2020-07-22 00:45, Dave Airlie wrote: On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel) wrote: On 7/21/20 9:45 AM, Christian König wrote: Am 21.07.20 um 09:41 schrieb Daniel Vetter: On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) wrote: Hi, On 7/9/20 2:33 PM, Dan

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow privileged user to map the OA buffer (rev4)

== Series Details == Series: Allow privileged user to map the OA buffer (rev4) URL : https://patchwork.freedesktop.org/series/79460/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. __

[Intel-gfx] [PATCH 3/4] drm/i915/perf: Whitelist OA counter and buffer registers

From: Piotr Maciejewski It is useful to have markers in the OA reports to identify triggered reports. Whitelist some OA counters that can be used as markers. A triggered report can be found faster if we can sample the HW tail and head registers when the report was triggered. Whitelist OA buffer

[Intel-gfx] [PATCH 0/4] Allow privileged user to map the OA buffer

This cover letter is included to trigger "Test-with" an IGT patch. Tests - https://patchwork.freedesktop.org/series/79745/ Signed-off-by: Umesh Nerlige Ramappa Test-with: 20200722053805.57139-1-umesh.nerlige.rama...@intel.com Piotr Maciejewski (4): drm/i915/perf: Ensure observation logic is n

[Intel-gfx] [PATCH 2/4] drm/i915/perf: Whitelist OA report trigger registers

From: Piotr Maciejewski OA reports can be triggered into the OA buffer by writing into the OAREPORTTRIG registers. Whitelist the registers to allow user to trigger reports. v2: - Move related change to this patch (Lionel) - Bump up perf revision (Lionel) v3: Pardon whitelisted registers for sel

[Intel-gfx] [PATCH 4/4] drm/i915/perf: Map OA buffer to user space for gen12 performance query

From: Piotr Maciejewski i915 used to support time based sampling mode which is good for overall system monitoring, but is not enough for query mode used to measure a single draw call or dispatch. Gen9-Gen11 are using current i915 perf implementation for query, but Gen12+ requires a new approach f

[Intel-gfx] [PATCH 1/4] drm/i915/perf: Ensure observation logic is not clock gated

From: Piotr Maciejewski A clock gating switch can control if the performance monitoring and observation logic is enaled or not. Ensure that we enable the clocks. v2: Separate code from other patches (Lionel) v3: Reset PMON enable when disabling perf to save power (Lionel) Fixes: 00a7f0d7155c ("

Re: [Intel-gfx] [PULL] gvt-next

On 2020.07.21 14:04:41 +0300, Joonas Lahtinen wrote: > Quoting Zhenyu Wang (2020-07-20 11:05:41) > > > > Hi, > > > > Sorry that this might be a bit late as last week our QA people were > > busy on something else..So this is gvt changes queued for 5.9 which is > > to improve guest suspend/resume w

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel) wrote: > > > On 7/21/20 9:45 AM, Christian König wrote: > > Am 21.07.20 um 09:41 schrieb Daniel Vetter: > >> On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) > >> wrote: > >>> Hi, > >>> > >>> On 7/9/20 2:33 PM, Daniel Vetter

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

> > >> That's also why I'm not positive on the "no hw preemption, only > >> scheduler" case: You still have a dma_fence for the batch itself, > >> which means still no userspace controlled synchronization or other > >> form of indefinite batches allowed. So not getting us any closer to > >> enablin

[Intel-gfx] [PATCH] drm/i915: Copy default modparams to mock i915_device

Since we use the module parameters stored inside the drm_i915_device itself, we need to ensure the mock i915_device also sets up the right defaults. Fixes: 8a25c4be583d ("drm/i915/params: switch to device specific parameters") Signed-off-by: Chris Wilson Cc: Jani Nikula --- drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

On Mon, Jul 20, 2020 at 05:40:10PM -0700, Almahallawy, Khaled wrote: > On Mon, 2020-07-20 at 17:07 -0700, Manasi Navare wrote: > > On Mon, Jul 20, 2020 at 04:41:25PM -0700, Khaled Almahallawy wrote: > > > Add the missing CP2520 pattern 2 and 3 phy compliance patterns > > > > > > Signed-off-by: Khal

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On Tue, Jul 21, 2020 at 7:46 PM Thomas Hellström (Intel) wrote: > > > On 2020-07-21 15:59, Christian König wrote: > > Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel): > ... > >> Yes, we can't do magic. As soon as an indefinite batch makes it to > >> such hardware we've lost. But since we can

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On 2020-07-21 15:59, Christian König wrote: Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel): ... Yes, we can't do magic. As soon as an indefinite batch makes it to such hardware we've lost. But since we can break out while the batch is stuck in the scheduler waiting, what I believe we *

Re: [Intel-gfx] [RFC] drm/i915: Disable connector polling at runtime suspend

On 2020-07-21 at 16:32:17 +0300, Imre Deak wrote: > On Fri, Jul 17, 2020 at 05:34:25PM +0530, Anshuman Gupta wrote: > > While i915 device is in runtime suspend, DRM connector polling > > causing device to wakeup from runtime suspend. > > This harm overall cpu idle statistics, therefore > > disablin

Re: [Intel-gfx] [PATCH v1] drm/i915/dsi: Drop double check for ACPI companion device

On Fri, May 29, 2020 at 03:33:17PM +0300, Andy Shevchenko wrote: > acpi_dev_get_resources() does perform the NULL pointer check against > ACPI companion device which is given as function parameter. Thus, > there is no need to duplicate this check in the caller. Any comment so far? > Signed-off-by

Re: [Intel-gfx] [PATCH 06/66] drm/i915: Export a preallocate variant of i915_active_acquire()

On 2020-07-15 13:50, Chris Wilson wrote: Sometimes we have to be very careful not to allocate underneath a mutex (or spinlock) and yet still want to track activity. Enter i915_active_acquire_for_context(). This raises the activity counter on i915_active prior to use and ensures that the fence-t

Re: [Intel-gfx] [PATCH 1/1] drm/i915/tgl: Load DMC firmware v2.07 for Tigerlake

On Tue, 2020-07-21 at 04:43 -0700, Anusha Srivatsa wrote: > Bump TGL DMC version to 2.07. this new version has power > saving enhancements. > Reviewed-by: José Roberto de Souza > Cc: José Roberto de Souza < > jose.so...@intel.com > > > Signed-off-by: Anusha Srivatsa < > anusha.sriva...@intel.co

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel): On 7/21/20 11:50 AM, Daniel Vetter wrote: On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel) wrote: On 7/21/20 10:55 AM, Christian König wrote: Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel): On 7/21/20 9:45 AM, Christian

Re: [Intel-gfx] [RFC] drm/i915: Disable connector polling at runtime suspend

On Fri, Jul 17, 2020 at 05:34:25PM +0530, Anshuman Gupta wrote: > While i915 device is in runtime suspend, DRM connector polling > causing device to wakeup from runtime suspend. > This harm overall cpu idle statistics, therefore > disabling polling while in runtime suspend. Before disabling pollin

Re: [Intel-gfx] [PATCH v8 00/12] Introduce CAP_PERFMON to secure system performance monitoring and observability

On 13.07.2020 21:51, Arnaldo Carvalho de Melo wrote: > Em Mon, Jul 13, 2020 at 03:37:51PM +0300, Alexey Budankov escreveu: >> >> On 13.07.2020 15:17, Arnaldo Carvalho de Melo wrote: >>> Em Mon, Jul 13, 2020 at 12:48:25PM +0300, Alexey Budankov escreveu: On 10.07.2020 20:09, Arnaldo Carva

Re: [Intel-gfx] [PATCH 05/66] drm/i915: Skip taking acquire mutex for no ref->active callback

On 2020-07-15 13:50, Chris Wilson wrote: If no active callback is defined for i915_active, we do not need to serialise its enabling with the mutex. We still do only want to call the debug activate once, and must still serialise with a concurrent retire. Signed-off-by: Chris Wilson Minor nit

Re: [Intel-gfx] [PATCH 04/66] drm/i915: Add a couple of missing i915_active_fini()

On 2020-07-15 13:50, Chris Wilson wrote: We use i915_active_fini() as a debug check on the i915_active state before freeing. If we forget to call it, we may end up angering the debugobjects contained within. Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström ___

[Intel-gfx] [PATCH 1/1] drm/i915/tgl: Load DMC firmware v2.07 for Tigerlake

Bump TGL DMC version to 2.07. this new version has power saving enhancements. Cc: José Roberto de Souza Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/display/intel_csr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_csr.c b

[Intel-gfx] [PATCH 0/1] PR for new DMC updates

Adding PR generated from drm-firmware repo for CI to pull. This has TGL DMC and also adding the RKL DMC that got missed while adding the patch. The following changes since commit 1d1c80b696539caa1d8a51d5f573012fbfa7eb5d: Update to 20200629111339 version to aligh SDK. Mainly fix DFS false alarm

Re: [Intel-gfx] [PULL] gvt-next

Quoting Zhenyu Wang (2020-07-20 11:05:41) > > Hi, > > Sorry that this might be a bit late as last week our QA people were > busy on something else..So this is gvt changes queued for 5.9 which is > to improve guest suspend/resume with proper PCI PM state tracking for > resource handling, e.g ppgtt

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On 7/21/20 11:50 AM, Daniel Vetter wrote: On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel) wrote: On 7/21/20 10:55 AM, Christian König wrote: Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel): On 7/21/20 9:45 AM, Christian König wrote: Am 21.07.20 um 09:41 schrieb Daniel Vette

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel) wrote: > > > On 7/21/20 10:55 AM, Christian König wrote: > > Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel): > >> > >> On 7/21/20 9:45 AM, Christian König wrote: > >>> Am 21.07.20 um 09:41 schrieb Daniel Vetter: > On Mon, Jul 20

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On 7/21/20 10:55 AM, Christian König wrote: Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel): On 7/21/20 9:45 AM, Christian König wrote: Am 21.07.20 um 09:41 schrieb Daniel Vetter: On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) wrote: Hi, On 7/9/20 2:33 PM, Daniel

[Intel-gfx] [PATCH] HAX sched/core: Paper over the ttwu() race [take two]

On all Core platforms we see <4> [181.766629] WARNING: CPU: 0 PID: 1524 at kernel/sched/core.c:2388 ttwu_queue_wakelist+0xbc/0xd0 <4> [181.766637] Modules linked in: i915(+) vgem snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio amdgpu mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pc

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On Tue, Jul 21, 2020 at 11:16 AM Daniel Vetter wrote: > > On Tue, Jul 21, 2020 at 10:55 AM Christian König > wrote: > > > > Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel): > > > > > > On 7/21/20 9:45 AM, Christian König wrote: > > >> Am 21.07.20 um 09:41 schrieb Daniel Vetter: > > >>> On M

[Intel-gfx] [CI] HAX sched/core: Paper over the ttwu() race [take two]

On all Core platforms we see <4> [181.766629] WARNING: CPU: 0 PID: 1524 at kernel/sched/core.c:2388 ttwu_queue_wakelist+0xbc/0xd0 <4> [181.766637] Modules linked in: i915(+) vgem snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio amdgpu mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pc

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On Tue, Jul 21, 2020 at 10:55 AM Christian König wrote: > > Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel): > > > > On 7/21/20 9:45 AM, Christian König wrote: > >> Am 21.07.20 um 09:41 schrieb Daniel Vetter: > >>> On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) > >>> wrot

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel): On 7/21/20 9:45 AM, Christian König wrote: Am 21.07.20 um 09:41 schrieb Daniel Vetter: On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) wrote: Hi, On 7/9/20 2:33 PM, Daniel Vetter wrote: Comes up every few years, gets

Re: [Intel-gfx] [PATCH 4/4] drm/i915/perf: Map OA buffer to user space for gen12 performance query

Quoting Umesh Nerlige Ramappa (2020-07-21 03:17:59) > Hi Chris, > > I have added your comments, but I have a few questions below: > > Thanks for your help, > Umesh > > On Mon, Jul 20, 2020 at 07:00:12PM -0700, Umesh Nerlige Ramappa wrote: > >From: Piotr Maciejewski > >+static void vm_open_oa(st

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On 7/21/20 9:45 AM, Christian König wrote: Am 21.07.20 um 09:41 schrieb Daniel Vetter: On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) wrote: Hi, On 7/9/20 2:33 PM, Daniel Vetter wrote: Comes up every few years, gets somewhat tedious to discuss, let's write this down once

Re: [Intel-gfx] [PATCH 05/10] drm/i915/gt: Distinguish the virtual breadcrumbs from the irq breadcrumbs

Hi Chris, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on drm-tip/drm-tip next-20200720] [cannot apply to linus/master v5.8-rc6] [If your patch is applied to the wrong git tree, kindly drop us a note. And whe

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

Am 21.07.20 um 09:41 schrieb Daniel Vetter: On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) wrote: Hi, On 7/9/20 2:33 PM, Daniel Vetter wrote: Comes up every few years, gets somewhat tedious to discuss, let's write this down once and for all. What I'm not sure about is whet

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) wrote: > Hi, > > On 7/9/20 2:33 PM, Daniel Vetter wrote: > > Comes up every few years, gets somewhat tedious to discuss, let's > > write this down once and for all. > > > > What I'm not sure about is whether the text should be mor

Re: [Intel-gfx] Fixes that failed to apply to v5.8-rc5

Hi, Based on there being no replies, I'll assume the below mentioned patches can be skipped. There is one new commit, which I'll skip considering we're at -rc7 already: b588e7015c92 ("drm/i915: Provide the perf pmu.module") Regards, Joonas Quoting Jani Nikula (2020-07-15 16:16:19) > > Hi all