The worker is canceled in the __gt_park path, but we still see it
running sometimes during suspend. This is likely because some code is
getting a gt wakeref in the __gt_park path.
Only update stats if gt is awake. If not, intel_guc_busyness_park would
have already updated the stats. Note that we
On Fri, 08 Sep 2023 18:16:26 -0700, Ashutosh Dixit wrote:
>
Hi Umesh,
> From: Umesh Nerlige Ramappa
>
> Correct values for OAR counters are still dependent on enabling the
> GEN12_OAG_OACONTROL_OA_COUNTER_ENABLE in OAG_OACONTROL. Enabling this
> bit means OAG unit will write reports to the OAG
From: Umesh Nerlige Ramappa
Correct values for OAR counters are still dependent on enabling the
GEN12_OAG_OACONTROL_OA_COUNTER_ENABLE in OAG_OACONTROL. Enabling this
bit means OAG unit will write reports to the OAG buffer, so
initialize the OAG buffer unconditionally for all use cases.
BSpec:
Ashutosh Dixit (2):
drm/i915/perf: Subtract gtt_offset from hw_tail
drm/i915/perf: Remove gtt_offset from stream->oa_buffer.head/.tail
Umesh Nerlige Ramappa (1):
drm/i915/perf: Initialize gen12 OA buffer unconditionally
drivers/gpu/drm/i915/i915_perf.c | 62
The code in oa_buffer_check_unlocked() is correct only if the OA buffer is
16 MB aligned (which seems to be the case today in i915). However when the
16 MB alignment is dropped, when we "Subtract partial amount off the tail",
the "& (OA_BUFFER_SIZE - 1)" operation in OA_TAKEN() will result in an
There is no reason to add gtt_offset to the cached head/tail pointers
stream->oa_buffer.head and stream->oa_buffer.tail. This causes the code to
constantly add gtt_offset and subtract gtt_offset and is error
prone (e.g. see previous patch).
It is much simpler to maintain stream->oa_buffer.head
On Fri, Sep 08, 2023 at 06:25:04PM -0500, Lucas De Marchi wrote:
> On Thu, Sep 07, 2023 at 09:10:44AM -0700, Matt Roper wrote:
> > On Thu, Sep 07, 2023 at 08:37:32AM -0700, Lucas De Marchi wrote:
> > > From: Balasubramani Vivekanandan
> > >
> > > Add Lunar Lake platform definitions for i915
On Thu, Sep 7, 2023 at 10:54 PM Ville Syrjälä
wrote:
>
> On Thu, Sep 07, 2023 at 11:49:10AM -0700, Manasi Navare wrote:
> > Hi Ville,
> >
> > Since we are always disabling when update_m_n, that means if in gaming
> > mode if VRR enable is requested by userspace, it cannot
> > be enabled if
On Thu, Sep 07, 2023 at 09:10:44AM -0700, Matt Roper wrote:
On Thu, Sep 07, 2023 at 08:37:32AM -0700, Lucas De Marchi wrote:
From: Balasubramani Vivekanandan
Add Lunar Lake platform definitions for i915 display. The support for
LNL will be added to the xe driver, with i915 only driving the
On Fri, Sep 08, 2023 at 06:32:46AM +, Patchwork wrote:
> == Series Details ==
>
> Series: Separate display workarounds from clock gating (rev4)
> URL : https://patchwork.freedesktop.org/series/123363/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_13612_full ->
On Thu, Sep 07, 2023 at 08:37:54AM -0700, Lucas De Marchi wrote:
> From: Stanislav Lisovskiy
>
> When we change MDCLK/CDCLK the BSpec now instructs us to write a ratio
> between MDCLK/CDCLK to MBUS CTL and DBUF CTL registers during that
> change.
>
> Previsouly DBuf state and CDCLK were not
Hi Rodrigo and Nirmoy,
On Thu, Sep 07, 2023 at 09:47:19AM -0400, Rodrigo Vivi wrote:
> On Thu, Sep 07, 2023 at 02:58:08PM +0200, Andi Shyti wrote:
> > From: Tvrtko Ursulin
> >
> > Walk all GTs when doing the respective bits of drop_caches work.
> >
> > Signed-off-by: Tvrtko Ursulin
> >
On Thu, Sep 07, 2023 at 08:37:55AM -0700, Lucas De Marchi wrote:
> From: Ravi Kumar Vodapalli
>
> Add CDCLK initialization sequence changes and CDCLK set frequency
The title and first line of this commit message don't seem to really
match the patch anymore. The changes here aren't about the
On Fri, Sep 08, 2023 at 02:50:55PM -0700, Matt Roper wrote:
On Fri, Sep 08, 2023 at 04:45:33PM -0500, Lucas De Marchi wrote:
On Wed, Sep 06, 2023 at 04:47:34PM -0700, Matt Roper wrote:
> In the early days of i915, pretty much every platform needed to
> initialize _something_ in the clock gating
On Wed, Sep 06, 2023 at 04:47:37PM -0700, Matt Roper wrote:
Rather than applying display workarounds as part of
intel_clock_gating_init() (which in turn is confusingly called from
i915_gem_init during device probe), handle them at the point we're
actually initializing the display hardware. This
On Wed, Sep 06, 2023 at 04:47:36PM -0700, Matt Roper wrote:
Several of the register updates that are currently done in the clock
gating init functions are actually display workarounds that should move
into the display-specific part of the code. Furthermore, some of the
registers being
On Fri, Sep 08, 2023 at 04:45:33PM -0500, Lucas De Marchi wrote:
> On Wed, Sep 06, 2023 at 04:47:34PM -0700, Matt Roper wrote:
> > In the early days of i915, pretty much every platform needed to
> > initialize _something_ in the clock gating init functions. In some
> > cases the items initialized
On Wed, Sep 06, 2023 at 04:47:35PM -0700, Matt Roper wrote:
The only programming that happens in gen12lp_init_clock_gating is for
display workarounds that are specific to display version 12 and are not
relevant to ADL-P's display version 13.
Signed-off-by: Matt Roper
Reviewed-by: Lucas De
On Wed, Sep 06, 2023 at 04:47:34PM -0700, Matt Roper wrote:
In the early days of i915, pretty much every platform needed to
initialize _something_ in the clock gating init functions. In some
cases the items initialized were inside the GT (and really should have
been initialized through the GT
== Series Details ==
Series: drm/i915: Run relevant bits of debugfs drop_caches per GT (rev5)
URL : https://patchwork.freedesktop.org/series/123386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13613_full -> Patchwork_123386v5_full
On Fri, Sep 08, 2023 at 10:25:59PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 24, 2023 at 11:05:01AM +0300, Imre Deak wrote:
> > Add intel_modeset_pipes_in_mask() to modeset a provided set of pipes,
> > used in a follow-up patch.
> >
> > While at it add DocBook descriptions for the exported
On Fri, Sep 08, 2023 at 12:39:18PM -0700, Matt Roper wrote:
> On Fri, Sep 08, 2023 at 03:11:42PM +0530, Dnyaneshwar Bhadane wrote:
> > This workaround has two different implementations,
> > one for gen 12 to DG2 and another for DG2 and later.
> > BSpec: 11354, 56551
>
> Side note: it's generally
On Fri, Sep 08, 2023 at 03:11:42PM +0530, Dnyaneshwar Bhadane wrote:
> This workaround has two different implementations,
> one for gen 12 to DG2 and another for DG2 and later.
> BSpec: 11354, 56551
Side note: it's generally not worth adding bspec references for simple
register pages these days.
On Thu, Aug 24, 2023 at 11:05:02AM +0300, Imre Deak wrote:
> Factor out intel_atomic_check_config() to check and compute all the CRTC
> states. This will be used by a follow up patch to recompute/check the
> state until required by BW limitations between CRTCs.
>
> Signed-off-by: Imre Deak
On Thu, Aug 24, 2023 at 11:05:01AM +0300, Imre Deak wrote:
> Add intel_modeset_pipes_in_mask() to modeset a provided set of pipes,
> used in a follow-up patch.
>
> While at it add DocBook descriptions for the exported functions.
>
> v2:
> - Add a flag controlling if active planes are force
== Series Details ==
Series: drm/i915: Added Wa_18022495364 (rev3)
URL : https://patchwork.freedesktop.org/series/123377/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13613_full -> Patchwork_123377v3_full
Summary
---
== Series Details ==
Series: drm/i915: Run relevant bits of debugfs drop_caches per GT (rev5)
URL : https://patchwork.freedesktop.org/series/123386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13613 -> Patchwork_123386v5
On Fri, Sep 08, 2023 at 09:03:40AM +0300, Ville Syrjälä wrote:
On Fri, Sep 08, 2023 at 08:56:53AM +0300, Ville Syrjälä wrote:
On Fri, Sep 08, 2023 at 12:51:09AM -0500, Lucas De Marchi wrote:
> On Fri, Sep 08, 2023 at 08:39:48AM +0300, Ville Syrjälä wrote:
> >On Thu, Sep 07, 2023 at 05:57:19PM
Quoting Lucas De Marchi (2023-09-07 12:37:39-03:00)
>Some registers for DDI A/B moved to PICA and now follow the same format
>as the ones for the PORT_TC ports. The wrapper here deals with 2 issues:
>
>- Share the implementation between xe2lpd and previous
> platforms: there are
== Series Details ==
Series: drm/i915: Run relevant bits of debugfs drop_caches per GT (rev4)
URL : https://patchwork.freedesktop.org/series/123386/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13613_full -> Patchwork_123386v4_full
Kunit test modules usually contain one test suite, named after the module
name with the trailing "_test" or "_kunit" suffix omitted. Since we
follow the same convention when we derive subtest names from module names,
there is a great chance that those two names match. Take this into
account when
There was an attempt to parse KTAP reports in the background while a kunit
test module is loading. However, since dynamic sub-subtests can be
executed only from the main thread, that attempt was not quite successful,
as IGT results from all executed kunit test cases were generated only
after
Similar to how igt_kselftest() handles kernel taints, fail current dynamic
sub-subtest and skip remaining ones when a kernel taint is detected during
execution of kunit test cases.
Signed-off-by: Janusz Krzysztofik
---
lib/igt_kmod.c | 12 +++-
1 file changed, 11 insertions(+), 1
If a user (an IGT test) doesn't provide a subtest name when calling
igt_kunit() then we now use the requested kernel module name as IGT
subtest name. Since names of kunit test modules usually end with a
"_test" or "_kunit" suffix, those parts of the names don't carry any
useful information.
For igt_runner to be able to correlate a stream of IGT results from
dynamic sub-subtests that correspond to individual kunit test cases, read
by the igt_runner from stdout / stderr of the test process, with a stream
of kernel messages read from /dev/kmsg, we need both result streams being
fed with
Current implementation of KTAP parser suffers from several issues:
- in most cases, kernel messages that are not part of KTAP output but
happen to appear in between break the parser,
- results from parametrized test cases, not preceded with a "1..N" test
plan, break the parser,
- skips are not
For code simplicity and clarity, use existing IGT linked lists library
instead of open coding a custom implementation of a list of KTAP results.
While being at it, flatten the code by inverting a check for pending
results.
Signed-off-by: Janusz Krzysztofik
---
lib/igt_kmod.c | 28
We obtain KTAP report from /dev/kmsg. That file is now opened from
igt_ktest_begin(), a function originally designed for i915 selftests and
now reused with kunit tests. The original intention of opening that file
was to dump kernel messages to stderr on selftest error. For that
purpose, the
Since we now call pthread_cancel() when we want to stop KTAP parser before
it completes, and we take care of returning failure in that case as a
result of KTAP parsing, we no longer need to check a flag that indicates
whether we should continue parsing or return a failure. Drop that flag.
For our KTAP parser to be running in parallel with kunit test module
loading, we now start it in a separate thread before we load the module.
If the module loading fails then we join the KTAP parser thread right
after that failure. If the KTAP thread sleeps for some reason then we
can fail to
While reading KTAP data from /dev/kmsg we now ignore interrupt signals
that may occur during read() and we continue reading the data. No
explanation has been provided on what that could be needed for.
Always return with an error code to the caller when read() fails with
errno == EINTR, so
After loading a kunit test module that executes some kunit test cases, we
evaluate overall result of an IGT subtest that corresponds to that module
based on an error code returned by kunit_parser_stop() helper, obtained
from a .ret field of a ktap_args structure. That code is now assigned to
that
In a body of a subtest with dynamic sub-subtests, it is illegal to call
igt_fail() and its variants from outside of a dynamic sub-subtest body.
On the other hand, it is perfectly legal to call either igt_skip() and
friends or __igt_abort() or its variant from there.
In the current implementation
Calling igt_success() explicitly at the end of subtest body is not needed.
Other calls to igt_success() can be usually avoided by inverting test
result checks. Optimize the code that now calls igt_success().
Moreover, using more advanced variants of igt_skip() and igt_fail() where
applicable
Since kmod functions we use for module loading can process module
dependencies, there is no need to load the "kunit" module explicitly
before loading a kunit test module. For the same reason we already don't
unload the "kunit" module explicitly on cleanup. Drop the unnecessary
operation.
We obtain a kmod_module structure for kunit module in order to check if
it is modular or built-in, then we never release that structure. Fix it.
Signed-off-by: Janusz Krzysztofik
---
lib/igt_kmod.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index
In the process of reviewing patches that introduced kunit support, I asked
once if we could use line buffered input instead of explicitly looking for
newlines in KTAP data. While my idea was wrong because reading raw data
from /dev/kmsg already returns full log records that always end with a
v2: Fix incorrect and missing includes in the test source file,
- add license and copyright clauses to the test source file.
Janusz Krzysztofik (17):
lib/kunit: Drop unused file stream
lib/kunit: Stop loading kunit module explicitly
lib/kunit: Fix struct kmod_module kunit_kmod not freed
== Series Details ==
Series: drm/i915: Only check eDP HPD when AUX CH is shared (rev2)
URL : https://patchwork.freedesktop.org/series/123389/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13613_full -> Patchwork_123389v2_full
Kunit test modules usually contain one test suite, named after the module
name with the trailing "_test" or "_kunit" suffix omitted. Since we
follow the same convention when we derive subtest names from module names,
there is a great chance that those two names match. Take this into
account when
There was an attempt to parse KTAP reports in the background while a kunit
test module is loading. However, since dynamic sub-subtests can be
executed only from the main thread, that attempt was not quite successful,
as IGT results from all executed kunit test cases were generated only
after
If a user (an IGT test) doesn't provide a subtest name when calling
igt_kunit() then we now use the requested kernel module name as IGT
subtest name. Since names of kunit test modules usually end with a
"_test" or "_kunit" suffix, those parts of the names don't carry any
useful information.
For igt_runner to be able to correlate a stream of IGT results from
dynamic sub-subtests that correspond to individual kunit test cases, read
by the igt_runner from stdout / stderr of the test process, with a stream
of kernel messages read from /dev/kmsg, we need both result streams being
fed with
Current implementation of KTAP parser suffers from several issues:
- in most cases, kernel messages that are not part of KTAP output but
happen to appear in between break the parser,
- results from parametrized test cases, not preceded with a "1..N" test
plan, break the parser,
- skips are not
For code simplicity and clarity, use existing IGT linked lists library
instead of open coding a custom implementation of a list of KTAP results.
While being at it, flatten the code by inverting a check for pending
results.
Signed-off-by: Janusz Krzysztofik
---
lib/igt_kmod.c | 28
Since we now call pthread_cancel() when we want to stop KTAP parser before
it completes, and we take care of returning failure in that case as a
result of KTAP parsing, we no longer need to check a flag that indicates
whether we should continue parsing or return a failure. Drop that flag.
Similar to how igt_kselftest() handles kernel taints, fail current dynamic
sub-subtest and skip remaining ones when a kernel taint is detected during
execution of kunit test cases.
Signed-off-by: Janusz Krzysztofik
---
lib/igt_kmod.c | 12 +++-
1 file changed, 11 insertions(+), 1
For our KTAP parser to be running in parallel with kunit test module
loading, we now start it in a separate thread before we load the module.
If the module loading fails then we join the KTAP parser thread right
after that failure. If the KTAP thread sleeps for some reason then we
can fail to
We obtain KTAP report from /dev/kmsg. That file is now opened from
igt_ktest_begin(), a function originally designed for i915 selftests and
now reused with kunit tests. The original intention of opening that file
was to dump kernel messages to stderr on selftest error. For that
purpose, the
While reading KTAP data from /dev/kmsg we now ignore interrupt signals
that may occur during read() and we continue reading the data. No
explanation has been provided on what that could be needed for.
Always return with an error code to the caller when read() fails with
errno == EINTR, so
We obtain a kmod_module structure for kunit module in order to check if
it is modular or built-in, then we never release that structure. Fix it.
Signed-off-by: Janusz Krzysztofik
---
lib/igt_kmod.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index
After loading a kunit test module that executes some kunit test cases, we
evaluate overall result of an IGT subtest that corresponds to that module
based on an error code returned by kunit_parser_stop() helper, obtained
from a .ret field of a ktap_args structure. That code is now assigned to
that
In a body of a subtest with dynamic sub-subtests, it is illegal to call
igt_fail() and its variants from outside of a dynamic sub-subtest body.
On the other hand, it is perfectly legal to call either igt_skip() and
friends or __igt_abort() or its variant from there.
In the current implementation
Calling igt_success() explicitly at the end of subtest body is not needed.
Other calls to igt_success() can be usually avoided by inverting test
result checks. Optimize the code that now calls igt_success().
Moreover, using more advanced variants of igt_skip() and igt_fail() where
applicable
Since kmod functions we use for module loading can process module
dependencies, there is no need to load the "kunit" module explicitly
before loading a kunit test module. For the same reason we already don't
unload the "kunit" module explicitly on cleanup. Drop the unnecessary
operation.
In the process of reviewing patches that introduced kunit support, I asked
once if we could use line buffered input instead of explicitly looking for
newlines in KTAP data. While my idea was wrong because reading raw data
from /dev/kmsg already returns full log records that always end with a
Janusz Krzysztofik (17):
lib/kunit: Drop unused file stream
lib/kunit: Stop loading kunit module explicitly
lib/kunit: Fix struct kmod_module kunit_kmod not freed
lib/kunit: Optimize calls to igt_success/skip/fail()
lib/kunit: Fix illegal igt_fail() calls inside subtest body
lib/ktap:
== Series Details ==
Series: drm/i915/dsc: Fix pic_width readout
URL : https://patchwork.freedesktop.org/series/123415/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13613_full -> Patchwork_123415v1_full
Summary
---
== Series Details ==
Series: drm/i915: Added Wa_18022495364 (rev3)
URL : https://patchwork.freedesktop.org/series/123377/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13613 -> Patchwork_123377v3
Summary
---
This workaround has two different implementations,
one for gen 12 to DG2 and another for DG2 and later.
BSpec: 11354, 56551
v2:
- Removed extra parentheses from the condition (Lucas)
- Fixed spacing and new line (Lucas)
v3:
- Fixed commit message.
Cc: Lucas De Marchi
Signed-off-by: Dnyaneshwar
This workaround has two different implementations,
one for gen 12 to DG2 and another for DG2 and later.
BSpec: 11354, 56551
v2:
- Removed extra parentheses from the condition (Lucas)
- Fixed spacing and new line (Lucas)
Signed-off-by: Dnyaneshwar Bhadane
Cc: Lucas De Marchi
Reviewed-by: Garg,
> -Original Message-
> From: De Marchi, Lucas
> Sent: Friday, September 8, 2023 3:58 AM
> To: Bhadane, Dnyaneshwar
> Cc: intel-gfx@lists.freedesktop.org; Roper, Matthew D
>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Added Wa_18022495364
>
> On Thu, Sep 07, 2023 at 12:27:34PM
On Thu, 2023-09-07 at 08:37 -0700, Lucas De Marchi wrote:
> From: Clint Taylor
>
> If a particular pipe is disabled by fuse also remove the FBC for that
> pipe.
>
> Bspec: 69464
> Cc: Anusha Srivatsa
> Cc: Gustavo Sousa
> Signed-off-by: Clint Taylor
> Reviewed-by: Matt Roper
>
On Thu, 2023-09-07 at 08:37 -0700, Lucas De Marchi wrote:
> From: Matt Roper
>
> FBC is no longer limited by pipe: add the defines for pipes B and C that
> will be used by platforms supporting FBC on such pipes.
>
> Bspec: 68881, 68904
> Signed-off-by: Matt Roper
> Signed-off-by: Lucas De
On Thu, 7 Sep 2023 12:31:47 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Tuesday, September 5, 2023 5:03 PM
> > To: Shankar, Uma
> > Cc: intel-gfx@lists.freedesktop.org; Borah, Chaitanya Kumar
> > ; dri-de...@lists.freedesktop.org; wayland-
> >
> Subject: RE: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and
> initialize
> HDMI audio capabilities
>
> Hi Suraj,
>
> > -Original Message-
> > From: Kandpal, Suraj
> > Sent: 05 September 2023 14:47
> > To: Golani, Mitulkumar Ajitkumar
> > ;
> > intel-gfx@lists.freedesktop.org
== Series Details ==
Series: drm/i915: Run relevant bits of debugfs drop_caches per GT (rev4)
URL : https://patchwork.freedesktop.org/series/123386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13613 -> Patchwork_123386v4
Am 07.09.23 um 18:33 schrieb suijingfeng:
Hi,
On 2023/9/7 17:08, Christian König wrote:
I strongly suggest that you just completely drop this here
Drop this is OK, no problem. Then I will go to develop something else.
This version is not intended to merge originally, as it's a RFC.
Also,
> -Original Message-
> From: De Marchi, Lucas
> Sent: Thursday, September 7, 2023 6:38 PM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Coelho, Luciano ; Kahola, Mika
> ; Roper, Matthew D
> ; De Marchi, Lucas
> Subject: [PATCH v2 17/27] drm/i915/xe2lpd:
== Series Details ==
Series: Separate display workarounds from clock gating (rev4)
URL : https://patchwork.freedesktop.org/series/123363/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13612_full -> Patchwork_123363v4_full
== Series Details ==
Series: drm/i915: Only check eDP HPD when AUX CH is shared (rev2)
URL : https://patchwork.freedesktop.org/series/123389/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13613 -> Patchwork_123389v2
On Fri, Sep 08, 2023 at 08:56:53AM +0300, Ville Syrjälä wrote:
> On Fri, Sep 08, 2023 at 12:51:09AM -0500, Lucas De Marchi wrote:
> > On Fri, Sep 08, 2023 at 08:39:48AM +0300, Ville Syrjälä wrote:
> > >On Thu, Sep 07, 2023 at 05:57:19PM -0700, Matt Roper wrote:
> > >> On Thu, Sep 07, 2023 at
82 matches
Mail list logo
