== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Pull checking rps->pm_events
under the irq_lock
URL : https://patchwork.freedesktop.org/series/74574/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8117_full -> Patchwork_16924_full
== Series Details ==
Series: Gen11 workarounds (rev3)
URL : https://patchwork.freedesktop.org/series/74475/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8125 -> Patchwork_16945
Summary
---
**FAILURE**
Serious
== Series Details ==
Series: Re-org uC debugfs files and move them under GT (rev2)
URL : https://patchwork.freedesktop.org/series/74051/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8125 -> Patchwork_16944
Summary
---
== Series Details ==
Series: drm/i915: Extend i915_request_await_active to use all timelines
URL : https://patchwork.freedesktop.org/series/74573/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8117_full -> Patchwork_16923_full
== Series Details ==
Series: Re-org uC debugfs files and move them under GT (rev2)
URL : https://patchwork.freedesktop.org/series/74051/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/gt: allow setting generic data pointer
Okay!
Commit:
== Series Details ==
Series: Re-org uC debugfs files and move them under GT (rev2)
URL : https://patchwork.freedesktop.org/series/74051/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
aafc4bae71e6 drm/i915/gt: allow setting generic data pointer
c507de64233a drm/i915/guc: drop
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gem: Mark up sw-fence notify
function
URL : https://patchwork.freedesktop.org/series/74605/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8125 -> Patchwork_16942
== Series Details ==
Series: drm/i915: Support for integrated privacy screens
URL : https://patchwork.freedesktop.org/series/74607/
State : failure
== Summary ==
Applying: intel_acpi: Rename drm_dev local variable to dev
Applying: drm/connector: Add support for privacy-screen property
Using
On Thu, Mar 12, 2020 at 01:11:21AM +, Patchwork wrote:
> == Series Details ==
>
> Series: Gen11 workarounds (rev2)
> URL : https://patchwork.freedesktop.org/series/74475/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8124 -> Patchwork_16936
>
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gem: Mark up sw-fence notify
function
URL : https://patchwork.freedesktop.org/series/74605/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
782209a9a5e2 drm/i915/gem: Mark up sw-fence notify function
== Series Details ==
Series: drm/i915/gem: Mark up sw-fence notify function
URL : https://patchwork.freedesktop.org/series/74604/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8124 -> Patchwork_16941
Summary
---
== Series Details ==
Series: drm/i915/debugfs: print more workaround registers
URL : https://patchwork.freedesktop.org/series/74571/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8116_full -> Patchwork_16921_full
Summary
On Tue, 10 Mar 2020 08:47:49 -0700 "Paul E. McKenney"
wrote:
> On Tue, Mar 10, 2020 at 03:05:57PM +, David Laight wrote:
> > From: Marco Elver
> > > Sent: 10 March 2020 14:10
> > ...
> > > FWIW, for writes we're already being quite generous, in that plain
> > > aligned writes up to
== Series Details ==
Series: Per client engine busyness (rev6)
URL : https://patchwork.freedesktop.org/series/70977/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8124 -> Patchwork_16938
Summary
---
**FAILURE**
== Series Details ==
Series: GPU-bound energy efficiency improvements for the intel_pstate driver
(v2). (rev2)
URL : https://patchwork.freedesktop.org/series/74540/
State : failure
== Summary ==
Applying: PM: QoS: Add CPU_RESPONSE_FREQUENCY global PM QoS limit.
error: sha1 information is
== Series Details ==
Series: GPU-bound energy efficiency improvements for the intel_pstate driver
(v2). (rev2)
URL : https://patchwork.freedesktop.org/series/74540/
State : failure
== Summary ==
Applying: PM: QoS: Add CPU_RESPONSE_FREQUENCY global PM QoS limit.
error: sha1 information is
== Series Details ==
Series: Per client engine busyness (rev6)
URL : https://patchwork.freedesktop.org/series/70977/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Expose list of clients in sysfs
Okay!
Commit: drm/i915: Update client name
== Series Details ==
Series: Per client engine busyness (rev6)
URL : https://patchwork.freedesktop.org/series/70977/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
29248a8e5b5b drm/i915: Expose list of clients in sysfs
-:74: WARNING:FILE_PATH_CHANGES: added, moved or deleted
== Series Details ==
Series: drm/i915/gem: Take a copy of the engines for context_barrier_task (rev3)
URL : https://patchwork.freedesktop.org/series/74583/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8124 -> Patchwork_16937
We currently initialize HuC support based on GuC being enabled in
modparam; this means that huc_is_supported() can return false on HW that
does have a HuC when enable_guc=0. The rationale for this behavior is
that HuC requires GuC for authentication and therefore is not supported
by itself.
uC is a component of the GT, so it makes sense for the uC debugfs files
to be in the GT folder. A subfolder has been used to keep the same
structure we have for the code.
v2: use intel_* prefix (Jani), rebase on new gt_debugfs_register_files,
fix permissions for writable debugfs files.
we do call uc_fini if there is an issue while loading the GuC, so we
can't delete in there the logs we need to debug the load failure.
Moving the log free to driver remove ensures the logs stick around ong
enough for us to dump them.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
The pool will be private to GuC in the new submission scheme, so we
won't be able to print it and we can just drop the current legacy code.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gpu/drm/i915/i915_debugfs.c | 53
Rebased on top of Andi's patch. Note that some discussion is still
ongoing on that patch.
Also dropped the patch that caused a const->non-const conversion and
fixed a couple of bugs:
- keep printing HUC_STATUS register
- correcly set permissions for writable debugfs files
Cc: Andi Shyti
Cc:
From: Andi Shyti
When registering debugfs files the intel gt debugfs library
forces a 'struct *gt' private data on the caller.
To be open to different usages make the new
"intel_gt_debugfs_register_files()"[*] function more generic by
converting the 'struct *gt' pointer to a 'void *' type.
I
Move the printers to the respective files for clarity. The
guc_load_status debugfs has been squashed in the guc_info one, has
having separate ones wasn't very useful. The HuC debugfs has been
renamed huc_info to match.
v2: keep printing HUC_STATUS2 (Tony), avoid const->non-const
container_of
== Series Details ==
Series: drm/i915/gem: Take a copy of the engines for context_barrier_task (rev3)
URL : https://patchwork.freedesktop.org/series/74583/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
475d71c63cfe drm/i915/gem: Take a copy of the engines for
Add helper functions that can allow i915 to detect and control
an integrated privacy screen via ACPI methods. These shall be used
in the next patch.
Signed-off-by: Rajat Jain
---
v8: Initial version. formed by refactoring the previous patch 4.
print the connector name in the debug messages.
== Series Details ==
Series: Gen11 workarounds (rev2)
URL : https://patchwork.freedesktop.org/series/74475/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8124 -> Patchwork_16936
Summary
---
**FAILURE**
Serious
On 3/11/20 1:24 AM, Andi Shyti wrote:
Hi Daniele,
Quoting Andi Shyti (2020-03-06 23:03:44)
-void debugfs_gt_register_files(struct intel_gt *gt,
- struct dentry *root,
- const struct debugfs_gt_file *files,
-
On Thu, 2020-03-05 at 17:33 -0800, José Roberto de Souza wrote:
> On Thu, 2020-02-20 at 19:26 +0200, Ville Syrjälä wrote:
> > On Tue, Feb 18, 2020 at 05:42:30PM -0800, José Roberto de Souza
> > wrote:
> > > dGFX have local memory so it do not have aperture and do not
> > > support
> > > CPU fences
== Series Details ==
Series: drm/i915/gem: Drop cached obj->bind_count
URL : https://patchwork.freedesktop.org/series/74593/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8124 -> Patchwork_16935
Summary
---
== Series Details ==
Series: drm/i915/gem: Drop cached obj->bind_count
URL : https://patchwork.freedesktop.org/series/74593/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a6b8e6fc24fe drm/i915/gem: Drop cached obj->bind_count
-:159: WARNING:LONG_LINE: line over 100 characters
== Series Details ==
Series: drm/i915/gem: Drop relocation slowpath
URL : https://patchwork.freedesktop.org/series/74592/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8124 -> Patchwork_16934
Summary
---
**SUCCESS**
+/**
+ * intel_huc_load_status - dump information about HuC load status
+ * @huc: the HuC
+ * @p: the _printer
+ *
+ * Pretty printer for HuC load status.
+ */
+void intel_huc_load_status(const struct intel_huc *huc, struct
drm_printer *p)
+{
+ struct intel_gt *gt = huc_to_gt(huc);
+
On Tue, 2020-01-07 at 01:41 +0800, Lee Shawn C wrote:
> Driver report physcial bandwidth for max dot clock rate.
> It would caused compatibility issue sometimes when physical
> bandwidth exceed MST hub output ability.
>
> For example, here is a MST hub with HDMI 1.4 and DP 1.2 output.
> And
== Series Details ==
Series: drm/i915/gt: Use scnprintf() for avoiding potential buffer overflow
URL : https://patchwork.freedesktop.org/series/74562/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112_full -> Patchwork_16919_full
When applying the context-barrier, we only care about the current
engines, as the next set of engines will be naturally after the barrier.
So we can skip holding the ctx->engines_mutex while constructing the
request by taking a sneaky reference to the i915_gem_engines instead.
Signed-off-by:
The sw-fence notify function requires to be at least 4-byte aligned so
that we can use the low bits in the function pointer for internal fence
flags. Make it so.
References: https://gitlab.freedesktop.org/drm/intel/issues/1433
Fixes: 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests
The sw-fence notify function requires to be at least 4-byte aligned so
that we can use the low bits in the function pointer for internal fence
flags. Make it so.
References: https://gitlab.freedesktop.org/drm/intel/issues/1433
Fixes: 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests
== Series Details ==
Series: drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)
URL : https://patchwork.freedesktop.org/series/71525/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8121 -> Patchwork_16933
== Series Details ==
Series: drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)
URL : https://patchwork.freedesktop.org/series/71525/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
76d4a408c88b drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
== Series Details ==
Series: drm/i915: Hotplug cleanups (rev4)
URL : https://patchwork.freedesktop.org/series/72348/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8121 -> Patchwork_16932
Summary
---
**FAILURE**
== Series Details ==
Series: series starting with [v6,1/2] drm/edid: Name the detailed monitor range
flags
URL : https://patchwork.freedesktop.org/series/74541/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112_full -> Patchwork_16918_full
Tvrtko Ursulin writes:
> On 10/03/2020 22:26, Chris Wilson wrote:
>> Quoting Francisco Jerez (2020-03-10 21:41:55)
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> index b9b3f78f1324..a5d7a80b826d 100644
>>> ---
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev4)
URL : https://patchwork.freedesktop.org/series/74461/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8121 -> Patchwork_16931
Summary
---
**SUCCESS**
The purpose of this PM QoS limit is to give device drivers additional
control over the latency/energy efficiency trade-off made by the PM
subsystem (particularly the CPUFREQ governor). It allows device
drivers to set a lower bound on the response latency of PM (defined as
the time it takes from
Peter Zijlstra writes:
> On Tue, Mar 10, 2020 at 02:41:54PM -0700, Francisco Jerez wrote:
>> +static void cpu_response_frequency_qos_apply(struct pm_qos_request *req,
>> + enum pm_qos_req_action action,
>> + s32
== Series Details ==
Series: drm/i915: Remove debugfs i915_drpc_info and i915_forcewake_domains
URL : https://patchwork.freedesktop.org/series/74529/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112_full -> Patchwork_16913_full
== Series Details ==
Series: series starting with [1/6] lib/scatterlist: add sg_set_dma_addr()
function
URL : https://patchwork.freedesktop.org/series/74590/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8120 -> Patchwork_16930
On Tue, Mar 10, 2020 at 06:23:38PM +0200, Kai Vehmanen wrote:
> Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz
> and 593.4/594Mhz. Add the missing rates and add logic to ignore
> them if running on older hardware.
>
> Bspec: 49333
> Signed-off-by: Kai Vehmanen
> Reviewed-by:
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing
From: Tvrtko Ursulin
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 23
From: Tvrtko Ursulin
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 +++-
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
To enable lockless access to client name and pid data from the following
From: Tvrtko Ursulin
When available prefer context tracked context busyness because it provides
visibility into currently executing contexts as well.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drm_client.c | 68 --
1 file changed, 63 insertions(+), 5
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For
From: Tvrtko Ursulin
Another re-spin of the per-client engine busyness series. Highlights from this
version:
* Last two patches contain a hybrid method of tracking context runtime. PPHWSP
tracked one is used as a baseline and then on top i915 tracks the start time
of when context was
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
---
== Series Details ==
Series: drm/i915/gen12: Disable preemption timeout (rev2)
URL : https://patchwork.freedesktop.org/series/74526/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8112_full -> Patchwork_16912_full
Summary
== Series Details ==
Series: series starting with [1/6] lib/scatterlist: add sg_set_dma_addr()
function
URL : https://patchwork.freedesktop.org/series/74590/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cd419e3a5b69 lib/scatterlist: add sg_set_dma_addr() function
-:54:
== Series Details ==
Series: series starting with [01/12] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/74586/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8120 -> Patchwork_16929
When applying the context-barrier, we only care about the current
engines, as the next set of engines will be naturally after the barrier.
So we can skip holding the ctx->engines_mutex while constructing the
request by taking a sneaky reference to the i915_gem_engines instead.
Signed-off-by:
On Mon, 9 Mar 2020 at 20:27, Lyude Paul wrote:
>
> On Sat, 2020-03-07 at 14:00 +0530, Pankaj Bharadiya wrote:
> > drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical
> > amongst every driver and don't do anything other than calling
> > drm_connector_register().
> >
== Series Details ==
Series: series starting with [01/12] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/74586/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
337d76f47d6b drm/i915/selftests: Add request throughput
== Series Details ==
Series: drm/i915: Add missing HDMI audio pixel clocks for gen12 (rev4)
URL : https://patchwork.freedesktop.org/series/72617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112_full -> Patchwork_16911_full
== Series Details ==
Series: drm/i915/gem: Take a copy of the engines for context_barrier_task (rev2)
URL : https://patchwork.freedesktop.org/series/74583/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8120 -> Patchwork_16928
On Wed, 11 Mar 2020 18:04:24 +0100,
Kai Vehmanen wrote:
>
> Hey,
>
> On Wed, 11 Mar 2020, Takashi Iwai wrote:
>
> > The remaining question is whether this display_power() call is still
> > needed for the recent chips. Basically it's there for HSW/BDW type
> > chips that need already the power
== Series Details ==
Series: drm/i915/gem: Take a copy of the engines for context_barrier_task (rev2)
URL : https://patchwork.freedesktop.org/series/74583/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4501e90d5c16 drm/i915/gem: Take a copy of the engines for
== Series Details ==
Series: drm/i915/gem: Prefer unlocked engine iteration
URL : https://patchwork.freedesktop.org/series/74582/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8120 -> Patchwork_16927
Summary
---
Hey,
On Wed, 11 Mar 2020, Takashi Iwai wrote:
> The remaining question is whether this display_power() call is still
> needed for the recent chips. Basically it's there for HSW/BDW type
> chips that need already the power for the HDA link that is dedicated
> to HDMI. That is, a patch like
== Series Details ==
Series: drm/i915/execlists: Track active elements during dequeue (rev2)
URL : https://patchwork.freedesktop.org/series/74524/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8112_full -> Patchwork_16910_full
== Series Details ==
Series: drm/i915/selftests: Add request throughput measurement to perf (rev2)
URL : https://patchwork.freedesktop.org/series/73930/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8120 -> Patchwork_16926
On 11/03/2020 05:05, Dixit, Ashutosh wrote:
On Tue, 10 Mar 2020 13:44:30 -0700, Lionel Landwerlin wrote:
On 09/03/2020 21:51, Umesh Nerlige Ramappa wrote:
On Wed, Mar 04, 2020 at 09:56:28PM -0800, Dixit, Ashutosh wrote:
On Wed, 04 Mar 2020 00:52:34 -0800, Lionel Landwerlin wrote:
On
On Mon, Mar 09, 2020 at 06:12:00PM +0200, Stanislav Lisovskiy wrote:
> Currently intel_can_enable_sagv function contains
> a mix of workarounds for different platforms
> some of them are not valid for gens >= 11 already,
> so lets split it into separate functions.
>
> v2:
> - Rework watermark
The register this workaround updates is a render engine register in the
MCR range, so we should initialize this in rcs_engine_wa_init() rather
than gt_wa_init().
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1222
Fixes: 36204d80bacb ("drm/i915/icl: Wa_1406680159")
Cc: Mika Kuoppala
v2:
- Move to context workarounds. ROW_CHICKEN4 is part of the context
image on gen11 (although it isn't on gen12).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 4 insertions(+)
diff
The bspec description for this workaround tells us to program
0x_ into both FBC_RT_BASE_ADDR_REGISTER_* registers, but we've
previously found that this leads to failures in CI. Our suspicion is
that the failures are caused by this valid turning on the "address valid
bit" even though we're
This workaround appears under two different numbers (and with somewhat
confused stepping applicability on ICL). Ultimately it appears we
should just implement this for all stepping of ICL and EHL.
Note that this is identical to Wa_1407928979:tgl that already exists in
our driver too...yet
On gen11 the XY_FAST_COPY_BLT command has some size restrictions on its
usage. Although this instruction is mainly used by userspace, i915 also
uses it to copy object contents during some selftests, so let's ensure
the restrictions are followed.
Bspec: 6544
Signed-off-by: Matt Roper
---
Relatively minor changes from v1:
- Wa_1406306137:icl,ehl moves to the context workarounds rather than
the engine workarounds. On gen11 the register we're updating is part
of the render engine context (even though it isn't on gen12).
- Dropped Wa_1409178092:icl,ehl again. Even with the
The bspec documents multiple MCR ranges; make sure they're all captured
by the driver.
Bspec: 13991, 52079
Fixes: 592a7c5e082e ("drm/i915: Extend non readable mcr range")
Cc: Mika Kuoppala
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 25 ++---
1
== Series Details ==
Series: drm/i915/selftests: Add request throughput measurement to perf (rev2)
URL : https://patchwork.freedesktop.org/series/73930/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
773240d23fbd drm/i915/selftests: Add request throughput measurement to perf
== Series Details ==
Series: drm/i915/gt: Restrict gen7 w/a batch to Haswell
URL : https://patchwork.freedesktop.org/series/74577/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8120 -> Patchwork_16925
Summary
---
On Mon, Mar 09, 2020 at 06:11:58PM +0200, Stanislav Lisovskiy wrote:
> For future Gen12 SAGV implementation we need to
> seemlessly alter wm levels calculated, depending
> on whether we are allowed to enable SAGV or not.
>
> So this accessor will give additional flexibility
> to do that.
>
>
On Mon, Mar 09, 2020 at 06:11:59PM +0200, Stanislav Lisovskiy wrote:
> Add correspondent helpers to be able to get old/new bandwidth
> global state object.
>
> v2: - Fixed typo in function call
> v3: - Changed new functions naming to use convention proposed
> by Jani Nikula, i.e intel_bw_*
We cached the number of vma bound to the object in order to speed up
shrinker decisions. This has been superseded by being more proactive in
removing objects we cannot shrink from the shrinker lists, and so we can
drop the clumsy attempt at atomically counting the bind count and
comparing it to
== Series Details ==
Series: DP Phy compliance auto test (rev6)
URL : https://patchwork.freedesktop.org/series/71121/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112_full -> Patchwork_16909_full
Summary
---
Since the relocations are no longer performed under a global
struct_mutex, or any other lock, that is also held by pagefault handlers,
we can relax and allow our fast path to take a fault. As we no longer
need to abort the fast path for lock avoidance, we no longer need the
slow path handling at
On Wed, 11 Mar 2020 13:16:56 +0100,
Kai Vehmanen wrote:
>
> Hey,
>
> On Tue, 10 Mar 2020, Takashi Iwai wrote:
> > On Tue, 10 Mar 2020 19:25:22 +0100, Ville Syrjälä wrote:
> >> On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
> >>> One problematic scenario that this doesn't cover:
>
From: Ville Syrjälä
Get rid of several platform specific variants of
intel_digital_port_connected() and just use the ISR bits we've
stashed away.
v2: Duplicate stuff to avoid exposing platform specific
functions across files (Jani)
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Instead of constnantly having to figure out which hpd status bit
array to use let's store them under dev_priv.
Should perhaps take this further and stash even more stuff to
make the hpd handling more abstract yet.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Let's get rid of the platform if ladders in
intel_digital_port_connected() and make it a vfunc. Now the if
ladders are at the encoder initialization which makes them a bit
less convoluted.
v2: Add forward decl for intel_encoder in intel_tc.h
v3: Duplicate stuff to avoid
From: Ville Syrjälä
Remainder of my hotplug cleanups, rebased once more.
Ville Syrjälä (3):
drm/i915: Turn intel_digital_port_connected() in a vfunc
drm/i915: Stash hpd status bits under dev_priv
drm/i915: Use stashed away hpd isr bits in
intel_digital_port_connected()
On 11/03/2020 15:11, Ye, Tony wrote:
On 3/10/2020 5:19 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Certain workloads need the ability to disable preemption completely so
allow them to do that by whitelisting GEN8_CS_CHICKEN1.
Signed-off-by: Tvrtko Ursulin
Cc: Michal Mrozek
Cc: Tony
Currently intel_can_enable_sagv function contains
a mix of workarounds for different platforms
some of them are not valid for gens >= 11 already,
so lets split it into separate functions.
v2:
- Rework watermark calculation algorithm to
attempt to calculate Level 0 watermark
with
On 2/28/2020 10:28 AM, Daniele Ceraolo Spurio wrote:
Move the printers to the respective files for clarity. The
guc_load_status debugfs has been squashed in the guc_info one, has
having separate ones wasn't very useful. The HuC debugfs has been
renamed huc_info to match.
While at it, fix the
1 - 100 of 199 matches
Mail list logo
