== Series Details ==
Series: drm/i915/vm_bind: Add VM_BIND functionality (rev5)
URL : https://patchwork.freedesktop.org/series/105879/
State : warning
== Summary ==
Error: dim checkpatch failed
09e6e3a66907 drm/i915/vm_bind: Expose vm lookup function
bda985316d2b drm/i915/vm_bind: Add __i915_s
== Series Details ==
Series: drm/i915/vm_bind: Add VM_BIND functionality (rev5)
URL : https://patchwork.freedesktop.org/series/105879/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
bits in PSR_IMR/IIR registers:
/*
* gen12+ has registers relative to transcoder and one per transcoder
* using the same bit definition: handle it as TRANSCODER_EDP to force
* 0 shift in bit definition
*/
At the time of wr
== Series Details ==
Series: drm/i915/vm_bind: Add VM_BIND functionality (rev5)
URL : https://patchwork.freedesktop.org/series/105879/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204 -> Patchwork_105879v5
Summary
--
On Thu, 2022-09-29 at 22:38 +, Sean Christopherson wrote:
> On Mon, Aug 08, 2022, Maxim Levitsky wrote:
> > Hi Sean, Paolo, and everyone else who wants to review my nested AVIC work.
>
> Before we dive deep into design details, I think we should first decide
> whether
> or not nested AVIC is
== Series Details ==
Series: drm/i915/psr: Fix PSR_IMR/IIR field handling (rev4)
URL : https://patchwork.freedesktop.org/series/108811/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On 30/09/2022 18:44, John Harrison wrote:
On 9/30/2022 02:22, Tvrtko Ursulin wrote:
On 29/09/2022 17:21, John Harrison wrote:
On 9/29/2022 00:42, Tvrtko Ursulin wrote:
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptib
== Series Details ==
Series: drm/i915/psr: Fix PSR_IMR/IIR field handling (rev4)
URL : https://patchwork.freedesktop.org/series/108811/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204 -> Patchwork_108811v4
Summary
-
On 30/09/2022 15:52, Andrzej Hajda wrote:
On 30.09.2022 11:47, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context and let the
backend handle it from there.
GuC backend c
On 03/10/2022 06:34, Dixit, Ashutosh wrote:
On Tue, 27 Sep 2022 07:17:23 -0700, Tvrtko Ursulin wrote:
Hi Tvrtko,
I am adding some people who may have more background/history into this.
On 10/09/2022 15:38, Ashutosh Dixit wrote:
From: Tilak Tangudu
Add perf_limit_reasons in debugfs. Th
Touching bo->resource looks like it should require first locking the
object, since this state is dynamic and could potentially change from
under us. It looks we can just use obj->base.size here, which avoids any
issues with locking, since this is immutable state.
Signed-off-by: Matthew Auld
Cc: C
On 02/10/2022 07:28, Niranjana Vishwanathapura wrote:
On Fri, Sep 30, 2022 at 10:47:48AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
Signed-off-by: Niranjana Vishwanath
On Sat, Oct 01, 2022 at 11:23:17PM -, Patchwork wrote:
> * igt@gem_exec_balancer@parallel-balancer:
> - shard-iclb: [PASS][58] -> [SKIP][59] ([i915#4525])
>[58]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
>
== Series Details ==
Series: drm/i915/vm_bind: Add VM_BIND functionality (rev5)
URL : https://patchwork.freedesktop.org/series/105879/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12204_full -> Patchwork_105879v5_full
Summ
> On Sat, Oct 01, 2022 at 11:23:17PM -, Patchwork wrote:
> > * igt@gem_exec_balancer@parallel-balancer:
> > - shard-iclb: [PASS][58] -> [SKIP][59] ([i915#4525])
> >[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/shard-
> iclb2/igt@gem_exec_balan...@parallel-balanc
On Sat, Oct 01, 2022 at 11:23:17PM -, Patchwork wrote:
> * igt@kms_frontbuffer_tracking@fbcdrrs-slowdraw (NEW):
> - shard-tglb: NOTRUN -> [FAIL][2] +12 similar issues
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v2/shard-tglb2/igt@kms_frontbuffer_track...@
== Series Details ==
Series: drm/ttm: fix bo->resource check in vm_access
URL : https://patchwork.freedesktop.org/series/109356/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204 -> Patchwork_109356v1
Summary
---
*
Hi Matt,
On 01/10/2022 01:45, Matt Roper wrote:
MTL's media GT only has a single type of steering ("OAADDRM") which
selects between media slice 0 and media slice 1. We'll always steer to
media slice 0 unless it is fused off (which is the case when VD0, VE0,
and SFC0 are all reported as unavai
On 03.10.2022 09:59, Tvrtko Ursulin wrote:
On 30/09/2022 15:52, Andrzej Hajda wrote:
On 30.09.2022 11:47, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context and let the
b
== Series Details ==
Series: drm/i915/psr: Fix PSR_IMR/IIR field handling (rev4)
URL : https://patchwork.freedesktop.org/series/108811/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204_full -> Patchwork_108811v4_full
Sum
On Wed, Aug 24, 2022 at 06:57:04PM +0300, Kai Vehmanen wrote:
> Hi,
>
> On Wed, 24 Aug 2022, Jani Nikula wrote:
>
> > On Wed, 24 Aug 2022, "Borah, Chaitanya Kumar"
> > wrote:
> > > In certain scenarios, we might have to filter out some audio
> > > configuration depending on HW limitation. For e
== Series Details ==
Series: drm/ttm: fix bo->resource check in vm_access
URL : https://patchwork.freedesktop.org/series/109356/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12204_full -> Patchwork_109356v1_full
Summary
--
Prior to display version 12, platforms had DDI ports A,B,C,D,E,F
represented by enums PORT_A,PORT_B...PORT_F. The DDI register offsets of
the ports were in the same order as the ports. So the port enums
were directly used as index to calculate the r
This is a prep patch for a patch series in which register offset of the
DDI ports are not calculated using the port enums but using a different
datastructure part of the device info.
So the device info is passed as a parameter to the macro DDI_BUF_CTL but
unused yet.
Signed-off-by: Balasubramani V
Prior to display version 12, platforms had DDI ports A,B,C,D,E,F
represented by enums PORT_A,PORT_B...PORT_F. The DDI register offsets of
the ports was in the same order as the ports. So the port enums
were directly used as index to calculate the register offset of the
ports.
Starting in display ve
With the index required for DDI register offset calculation available in
the device info, DDI_BUF_CTL macro updated to make use of it.
Any new macros to access the DDI registers should follow the same
procedure.
This would free the port enums from tied to the register offset of DDI
registers. We ca
port_identifier function was broken when TypeC ports were using enum
aliases. It would return wrong string for TypeC ports.
With unique enums for DDI ports now, fix port_identifier to cover all
ports.
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/i915/display/intel_display.h | 12
Port enums are no more used in the DDI register offset caculcation. We
can remove the platform specific port redefinitions. Along with it we
also get rid of the code required for handling these special
definitions.
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/i915/display/intel_
DDI port enums PORT_G/H/I were added in the commit -
"6c8337dafaa9 drm/i915/tgl: Add additional ports for Tiger Lake" to
identify new ports added in the platform.
In the subsequent commits those ports were identified by new enums
PORT_TC1/TC2/TC3.. to differentiate TypeC ports from non-TypeC.
Howev
On Tue, 27 Sep 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make sure modes with crazy big dotclocks are rejected early,
> so as to not cause problems for subsequent code via integer
> overflows and whatnot.
>
> These would eventually be rejected in intel_crtc_compute_pipe_mode()
> but th
From: Ville Syrjälä
We are neglegting to consider all the new CCS modifiers as
Y-tiled in the watermark calculations. So we are incorrectrly
calculation the watermarks as if dealing with a linear surface.
v2: Fix tgl RC CCS vs. MC CCS to separate patches since they
need separate fixes tags
From: Ville Syrjälä
Take the gen12+ RC CCS modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
Y-tiled modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
v2: Split RC CCS vs. MC CCS t
From: Ville Syrjälä
Take the gen12+ MC CCS modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
Y-tiled modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
v2: Split RC CCS vs. MC CCS t
From: Ville Syrjälä
Take the gen12+ CCS+CC modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
Y-tiled modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Cc: sta...@vger.kernel.org
Fi
From: Ville Syrjälä
Take the DG2 CCS modifiers into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking these
tile-4 modifiers are linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Cc: sta...@vger.kernel.org
Fixes
From: Ville Syrjälä
Take the DG2 CCS+CC modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
tile-4 modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Cc: sta...@vger.kernel.org
Fixes:
From: Ville Syrjälä
Replace the huge modifier lists in the watermark code with
a few calls to intel_fb.c.
Reviewed-by: Juha-Pekka Heikkila
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 13
drivers/gpu/drm/i915/display/intel_fb.h | 1 +
driv
On Fri, 30 Sep 2022, Vinay Belgaumkar wrote:
> Create a wrapper to print out the frequency debugfs for
> SLPC and non-SLPC cases. Most of the RPS related information
> is no longer valid when SLPC is enabled.
Please split code movement and functional changes to separate patches.
BR,
Jani.
>
> S
== Series Details ==
Series: drm/i915/display: Don't use port enum as register offset (rev6)
URL : https://patchwork.freedesktop.org/series/108833/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
From: Ville Syrjälä
The stuff in the DRRS debugs is currently a hodgepode mix
of camelcase, lowercase, spaces, undescores, you name it.
Convert over to a reasonably common style.
Also move the busy bits thing to be the last sine it's
generally the least interesting thing in there.
Reviewed-by:
From: Ville Syrjälä
Change DRRS debugfs to be per-crtc/connector.
v2: for ci to actually run the drrs tests...
v3: filter out bogus DRRS capability from connector
Test-with: 20220929032642.16556-1-ville.syrj...@linux.intel.com
Ville Syrjälä (6):
drm/i915: Move DRRS debugfs next to the implem
From: Ville Syrjälä
Move the DRRS debugfs stuff next to the actual implementation
so that it's easier to deal with the whole.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 96 +---
drivers/gpu/drm/i915/display/intel_drrs
From: Ville Syrjälä
Now that we track the VBT drrs type per-panel we can move the
has_drrs_modes() check to the panel init rather than doing it
for every intel_panel_drrs_type() call.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_panel.c | 6 +++---
1 file changed, 3 inse
From: Ville Syrjälä
Since I already broke anything that relied on the old contents
of the DRRS debugfs files might as well finish the breakage
and convert the files to be per-crtc/connector so we don't need
to have annoying code in igt to parse these.
Reviewed-by: Jani Nikula
Signed-off-by: Vil
From: Ville Syrjälä
Grab the crtc mutex so that looking at the crtc state is
actually safe.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i91
From: Ville Syrjälä
Only report DRRS capability for the connector if its fixed_modes
list contains at least two modes capable of seamless DRRS switch
between them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_panel.c | 19 +--
1 file changed, 17 insertion
== Series Details ==
Series: drm/i915/display: Don't use port enum as register offset (rev6)
URL : https://patchwork.freedesktop.org/series/108833/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12204 -> Patchwork_108833v6
S
On 03/10/2022 08:53, Tvrtko Ursulin wrote:
On 30/09/2022 18:44, John Harrison wrote:
On 9/30/2022 02:22, Tvrtko Ursulin wrote:
On 29/09/2022 17:21, John Harrison wrote:
On 9/29/2022 00:42, Tvrtko Ursulin wrote:
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
Co
From: Tvrtko Ursulin
Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context and let the
backend handle it from there.
GuC backend cannot handle it because it runs independently in the
firmware and driver might not see the
On 03/10/2022 07:12, Niranjana Vishwanathapura wrote:
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
v2: Ensure requests wait for bindings to complete.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_
== Series Details ==
Series: drm/i915: Fix watermark calculations with various CCS modifiers (rev2)
URL : https://patchwork.freedesktop.org/series/109303/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204 -> Patchwork_109303v2
== Series Details ==
Series: drm/i915: Per-crtc/connector DRRS debugfs (rev3)
URL : https://patchwork.freedesktop.org/series/109175/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bi
== Series Details ==
Series: drm/i915: Per-crtc/connector DRRS debugfs (rev3)
URL : https://patchwork.freedesktop.org/series/109175/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204 -> Patchwork_109175v3
Summary
---
== Series Details ==
Series: drm/i915/guc: Fix revocation of non-persistent contexts (rev2)
URL : https://patchwork.freedesktop.org/series/109299/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204 -> Patchwork_109299v2
Su
== Series Details ==
Series: drm/i915: Fix watermark calculations with various CCS modifiers (rev2)
URL : https://patchwork.freedesktop.org/series/109303/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204_full -> Patchwork_109303v2_full
==
On Mon, 2022-10-03 at 10:20 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
>
> /*
> * gen12+ has registers relative to transcoder and one per transcoder
> * using the same bit definition: handle it as TRANSC
On Mon, Aug 08, 2022, Maxim Levitsky wrote:
> Hi Sean, Paolo, and everyone else who wants to review my nested AVIC work.
Before we dive deep into design details, I think we should first decide whether
or not nested AVIC is worth pursing/supporting.
- Rome has a ucode/silicon bug with no known w
On Mon, 2022-10-03 at 09:30 +, Patchwork wrote:
Patch Details
Series: drm/i915/psr: Fix PSR_IMR/IIR field handling (rev4)
URL:https://patchwork.freedesktop.org/series/108811/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108811v4/index.html
CI Bug Log -
It looks like we need this for local-memory, if we want to use ptrace.
Something more is still needed if we want to handle non-mappable memory,
which looks quite annoying.
v2: ttm_bo_kmap doesn't seem to work well here, and seems to expect
contiguous resource
References: https://gitlab.freedeskto
> -Original Message-
> From: De Marchi, Lucas
> Sent: Thursday, September 29, 2022 5:11 PM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH v4.1] drm/i915/mtl: Define engine context layouts
>
> On Wed, Sep 28, 202
== Series Details ==
Series: drm/i915/guc: Fix revocation of non-persistent contexts (rev2)
URL : https://patchwork.freedesktop.org/series/109299/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204_full -> Patchwork_109299v2_full
==
Hi Niranjana,
[...]
> + for_each_child(ce, child) {
> + err = intel_context_pin_ww(child, ww);
> + GEM_BUG_ON(err);/* perma-pinned should incr a counter */
> + }
> +
> + for_each_child(ce, child) {
> + err = eb_pin_timeline(child, throttle,
Hi Niranjana,
On Sun, Oct 02, 2022 at 11:12:42PM -0700, Niranjana Vishwanathapura wrote:
> Rename __i915_request_await_bind() as i915_request_await_bind()
> and make it non-static as it will be used in execbuf3 ioctl path.
>
> Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Andi Shyti
A
On Mon, 03 Oct 2022 01:11:21 -0700, Tvrtko Ursulin wrote:
> On 03/10/2022 06:34, Dixit, Ashutosh wrote:
> > On Tue, 27 Sep 2022 07:17:23 -0700, Tvrtko Ursulin wrote:
> >
> > Hi Tvrtko,
> >
> > I am adding some people who may have more background/history into this.
> >
> >> On 10/09/2022 15:38, Ashu
== Series Details ==
Series: drm/i915/ttm: implement access_memory (rev2)
URL : https://patchwork.freedesktop.org/series/109315/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204 -> Patchwork_109315v2
Summary
---
*
On 03/10/2022 17:16, Dixit, Ashutosh wrote:
On Mon, 03 Oct 2022 01:11:21 -0700, Tvrtko Ursulin wrote:
On 03/10/2022 06:34, Dixit, Ashutosh wrote:
On Tue, 27 Sep 2022 07:17:23 -0700, Tvrtko Ursulin wrote:
Hi Tvrtko,
I am adding some people who may have more background/history into this.
On
Hi Matt,
[...]
> +static int i915_ttm_access_memory(struct ttm_buffer_object *bo,
> + unsigned long offset, void *buf,
> + int len, int write)
> +{
> + struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> + resource_size_t io
DDI_CLK_SEL is an another macro which returns the register offset based
on DDI port enum. So DDI_CLK_SEL has to be prepared for the new method
being developed for calculating the register offsets of DDI ports.
Macro receives i915 private structure as new parameter for the upcoming
changes.
Signed-
Prior to display version 12, platforms had DDI ports A,B,C,D,E,F
represented by enums PORT_A,PORT_B...PORT_F. The DDI register offsets of
the ports was in the same order as the ports. So the port enums
were directly used as index to calculate the register offset of the
ports.
Starting in display ve
Prior to display version 12, platforms had DDI ports A,B,C,D,E,F
represented by enums PORT_A,PORT_B...PORT_F. The DDI register offsets of
the ports were in the same order as the ports. So the port enums
were directly used as index to calculate the r
With the index required for DDI register offset calculation available in
the device info, the macros which used port enums to calculate the DDI
register offsets i.e. DDI_BUF_CTL and DDI_CLK_SEL are updated to make
use of the index rather than enum directly.
Any new macros access that DDI registers
This is a prep patch for a patch series in which register offset of the
DDI ports are not calculated using the port enums but using a different
datastructure part of the device info.
So the device info is passed as a parameter to the macro DDI_BUF_CTL but
unused yet.
Signed-off-by: Balasubramani V
Port enums are no more used in the DDI register offset caculcation. We
can remove the platform specific port redefinitions. Along with it we
also get rid of the code required for handling these special
definitions.
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/i915/display/intel_
port_identifier function was broken when TypeC ports were using enum
aliases. It would return wrong string for TypeC ports.
With unique enums for DDI ports now, fix port_identifier to cover all
ports.
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/i915/display/intel_display.h | 12
DDI port enums PORT_G/H/I were added in the commit -
"6c8337dafaa9 drm/i915/tgl: Add additional ports for Tiger Lake" to
identify new ports added in the platform.
In the subsequent commits those ports were identified by new enums
PORT_TC1/TC2/TC3.. to differentiate TypeC ports from non-TypeC.
Howev
Remove unused function prototype; intel_gt_create_kobj()
Cc: Andi Shyti
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
index
On Tue, Sep 27, 2022 at 06:47:28PM -0700, Dixit, Ashutosh wrote:
> On Tue, 27 Sep 2022 04:35:29 -0700, Badal Nilawar wrote:
> >
> > From: Don Hiatt
> >
> > On GEN12 and above use GEN12_RPSTAT register to get Current
> > Actual Graphics Frequency of GT
>
> I think even for the purposes of reviewin
Get the small-bar related stuff at: 525e93f6317a ("drm/i915/uapi: add
NEEDS_CPU_ACCESS hint"), and drop the local related bits.
Signed-off-by: Matthew Auld
Cc: Andrzej Hajda
Cc: Nirmoy Das
---
include/drm-uapi/i915_drm.h| 182 +
lib/i915/i915_drm_local.h
Make sure we can always place an object at some GTT address, so
long as we adhere to the min GTT alignment for the given region.
Signed-off-by: Matthew Auld
Cc: Andrzej Hajda
Cc: Nirmoy Das
---
tests/i915/gem_create.c | 117
1 file changed, 117 insertio
rsvd1 is u64 here.
Signed-off-by: Matthew Auld
Cc: Andrzej Hajda
Cc: Nirmoy Das
---
tests/i915/i915_query.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index 2744421c..b92d7593 100644
--- a/tests/i915/i915_query.c
+++ b/
Ensure the kernel is reporting "normal" values here, based on our
current expectations.
Signed-off-by: Matthew Auld
Cc: Andrzej Hajda
Cc: Nirmoy Das
---
tests/i915/i915_query.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tests/i915/i915_query.c b/tests/i91
It looks like we need this for local-memory, if we want to use ptrace.
Something more is still needed if we want to handle non-mappable memory,
which looks quite annoying.
v2:
- ttm_bo_kmap doesn't seem to work well here, and seems to expect
contiguous resource.
v3(Andi):
- s/PAGE_SIZE/byt
Hi Andrzej,
On Thu, Sep 29, 2022 at 03:44:40PM -0700, Nathan Chancellor wrote:
> On Fri, Sep 30, 2022 at 12:34:41AM +0200, Andrzej Hajda wrote:
> > On 22.09.2022 21:51, Nathan Chancellor wrote:
> > > When booting with clang's kernel control flow integrity series [1],
> > > there are numerous viola
On Mon, Oct 03, 2022 at 08:45:18PM +0300, Ville Syrjälä wrote:
> On Sat, Oct 01, 2022 at 12:07:39PM +0200, Thorsten Leemhuis wrote:
> > On 30.09.22 14:26, Jerry Ling wrote:
> > >
> > > looks like someone has done it:
> > > https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
> > >
> > > a
Hi John - how would you like to proceed? I have re-rev'd as per your original
review comment on rev1.
Shall we adopt this rev2's "drm_warn" for the worst-case (knowing well that
gpu_core_dump is still an external subsystem
that can cull our data, but at least within this subsystem we are adding
On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
> On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> > I disagree because its unlikely that all engines can reset all at once (we
> > probably have bigger problems at the at
> > point) and if they all occurred within the same G2H han
On 03.10.22 19:48, Ville Syrjälä wrote:
> On Mon, Oct 03, 2022 at 08:45:18PM +0300, Ville Syrjälä wrote:
>> On Sat, Oct 01, 2022 at 12:07:39PM +0200, Thorsten Leemhuis wrote:
>>> On 30.09.22 14:26, Jerry Ling wrote:
looks like someone has done it:
https://bbs.archlinux.org/viewtop
== Series Details ==
Series: drm/i915/ttm: implement access_memory (rev2)
URL : https://patchwork.freedesktop.org/series/109315/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12204_full -> Patchwork_109315v2_full
Summary
--
PMU and sysfs use different wakeref's to "interpret" zero freq. Sysfs uses
runtime PM wakeref (see intel_rps_read_punit_req and
intel_rps_read_actual_frequency). PMU uses the GT parked/unparked
wakeref. In general the GT wakeref is held for less time that the runtime
PM wakeref which causes PMU to
On Mon, Oct 03, 2022 at 09:56:18AM +0100, Tvrtko Ursulin wrote:
>
> Hi Matt,
>
> On 01/10/2022 01:45, Matt Roper wrote:
> > MTL's media GT only has a single type of steering ("OAADDRM") which
> > selects between media slice 0 and media slice 1. We'll always steer to
> > media slice 0 unless it i
On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
I disagree because its unlikely that all engines can reset all at once (we
probably have bigger problems at the at
point) and if
Both of below are not related to GuC: ICL didn't have GuC support and TGL was
not using GuC-submission.
...alan
On Sat, 2022-10-01 at 20:05 +, Patchwork wrote:
> Patch Details
> Series:Fix Guc-Err-Capture sizing warning
> (rev2)URL:https://patchwork.freedesktop.org/series/109276/State:failu
Hi G.G.
On Mon, Oct 03, 2022 at 08:02:42PM +0300, Gwan-gyeong Mun wrote:
> Remove unused function prototype; intel_gt_create_kobj()
>
> Cc: Andi Shyti
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a
The following changes since commit fdf1a65258522edf18a0a1768fbafa61ed07e598:
linux-firmware: Update AMD cpu microcode (2022-09-30 17:33:35 -0400)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware dg2_huc_7.10.6_pr
for you to fetch changes up to b3110904e
Hi Matt,
On Mon, Oct 03, 2022 at 06:28:19PM +0100, Matthew Auld wrote:
> It looks like we need this for local-memory, if we want to use ptrace.
> Something more is still needed if we want to handle non-mappable memory,
> which looks quite annoying.
>
> v2:
> - ttm_bo_kmap doesn't seem to work w
Hi Badal,
On Tue, Sep 27, 2022 at 11:20:14AM +0530, Badal Nilawar wrote:
> From: Dale B Stimson
>
> The i915 HWMON module will be used to expose voltage, power and energy
> values for dGfx. Here we set up i915 hwmon infrastructure including i915
> hwmon registration, basic data structures and fu
Hi Badal,
[...]
> static void
> hwm_get_preregistration_info(struct drm_i915_private *i915)
> {
> + struct i915_hwmon *hwmon = i915->hwmon;
> +
> + if (IS_DG1(i915) || IS_DG2(i915))
why not GRAPHICS_VER(i915) >= 12 here?
Andi
> + hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
Hi Badal,
[...]
> hwm_get_preregistration_info(struct drm_i915_private *i915)
> {
> struct i915_hwmon *hwmon = i915->hwmon;
> + struct intel_uncore *uncore = &i915->uncore;
> + intel_wakeref_t wakeref;
> + u32 val_sku_unit;
>
> - if (IS_DG1(i915) || IS_DG2(i915))
> +
On Mon, Oct 03, 2022 at 05:53:37PM +0200, Andi Shyti wrote:
Hi Niranjana,
[...]
+ for_each_child(ce, child) {
+ err = intel_context_pin_ww(child, ww);
+ GEM_BUG_ON(err);/* perma-pinned should incr a counter */
+ }
+
+ for_each_child(ce, chi
On Mon, 2022-10-03 at 12:47 -0700, Harrison, John C wrote:
> On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
> > On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
> > > On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> > > > I disagree because its unlikely that all engines can
1 - 100 of 137 matches
Mail list logo
