[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Use a bitmask for bigjoiner state tracking (rev3)
== Series Details == Series: drm/i915: Use a bitmask for bigjoiner state tracking (rev3) URL : https://patchwork.freedesktop.org/series/99680/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use a bitmask for bigjoiner state tracking (rev3)
== Series Details ==
Series: drm/i915: Use a bitmask for bigjoiner state tracking (rev3)
URL : https://patchwork.freedesktop.org/series/99680/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
70bac4e4c094 drm/i915: Flag crtc scaling_filter changes as modeset
af5ef233b8e4 drm/i915: Fix bigjoiner state copy fails
414ad2151468 drm/i915: Remove weird code from intel_atomic_check_bigjoiner()
1779ba955b06 drm/i915: Clean up the bigjoiner state copy logic
3dd5243283ec drm/i915: Nuke some dead code
5cb49a708185 drm/i915: Introduce intel_crtc_is_bigjoiner_{slave, master}()
-:46: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#46:
+ intel_crtc_is_bigjoiner_slave(S) ? E1 : intel_crtc_is_bigjoiner_master(S) ?
E2 : E3
total: 0 errors, 1 warnings, 0 checks, 222 lines checked
71cb08d3ef98 drm/i915: Convert for_each_intel_crtc_mask() to take a pipe mask
instead
-:31: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#31: FILE: drivers/gpu/drm/i915/display/intel_display.h:433:
+#define for_each_intel_crtc_in_pipe_mask(dev, intel_crtc, pipe_mask) \
list_for_each_entry(intel_crtc, \
&(dev)->mode_config.crtc_list, \
base.head) \
+ for_each_if((pipe_mask) & BIT(intel_crtc->pipe))
-:31: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_crtc' - possible
side-effects?
#31: FILE: drivers/gpu/drm/i915/display/intel_display.h:433:
+#define for_each_intel_crtc_in_pipe_mask(dev, intel_crtc, pipe_mask) \
list_for_each_entry(intel_crtc, \
&(dev)->mode_config.crtc_list, \
base.head) \
+ for_each_if((pipe_mask) & BIT(intel_crtc->pipe))
total: 1 errors, 0 warnings, 1 checks, 139 lines checked
abf4ac559145 drm/i915: Use for_each_intel_crtc_in_pipe_mask() more
72702ca376f8 drm/i915: Return both master and slave pipes from
enabled_bigjoiner_pipes()
d7ef79ee8751 drm/i915: Change bigjoiner state tracking to use the pipe bitmask
-:528: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#528: FILE: drivers/gpu/drm/i915/display/intel_display.c:10510:
+
intel_crtc_bigjoiner_slave_pipes(crtc_state)) {
-:531: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#531: FILE: drivers/gpu/drm/i915/display/intel_display.c:10513:
+ slave_crtc_state =
to_intel_crtc_state(slave_crtc->base.state);
total: 0 errors, 2 warnings, 0 checks, 597 lines checked
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Disable unused power wells left enabled by BIOS (rev2)
== Series Details ==
Series: drm/i915: Disable unused power wells left enabled by BIOS (rev2)
URL : https://patchwork.freedesktop.org/series/99615/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11180_full -> Patchwork_22160_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22160_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22160_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 13)
--
Additional (2): shard-rkl shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22160_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@system-suspend-devices:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb6/igt@i915_pm_...@system-suspend-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb7/igt@i915_pm_...@system-suspend-devices.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@suspend:
- {shard-dg1}:NOTRUN -> [DMESG-WARN][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-dg1-16/igt@gem_...@suspend.html
Known issues
Here are the changes found in Patchwork_22160_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_sseu@invalid-args:
- shard-tglb: NOTRUN -> [SKIP][4] ([i915#280])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-tglb1/igt@gem_ctx_s...@invalid-args.html
* igt@gem_exec_balancer@parallel:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb1/igt@gem_exec_balan...@parallel.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb8/igt@gem_exec_balan...@parallel.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl: NOTRUN -> [SKIP][7] ([fdo#109271]) +291 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-skl8/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html
- shard-tglb: NOTRUN -> [FAIL][10] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-tglb1/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2190])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-skl6/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@heavy-random:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#4613])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb3/igt@gem_lmem_swapp...@heavy-random.html
* igt@gem_lmem_swapping@parallel-random:
- shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +3
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-skl8/igt@gem_lmem_swapp...@parallel-random.html
* igt@gem_lmem_swapping@verify-random:
- shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613])
[20]:
[Intel-gfx] [PATCH v2 04/10] drm/i915: Clean up the bigjoiner state copy logic
From: Ville Syrjälä
Currently the bigjoiner state copy logic is kind of
a byzantine mess.
Clean it up to operate in the following manner during a full
modeset:
1) master uapi -> hw state copy
2) master hw -> slave hw state copy
And during a non-modeset update we do:
1) master uapi -> hw state light copy
2) master hw -> slave hw state light copy
I think that is now easier to reason about since we never do
any kind of master uapi -> slave hw state copy short circuit
that could happen previously.
Obviously this does now depend on the master uapi->hw copy
always happening before the master hw -> slave hw copy, but
that is guaranteed by the fact that we always add both crtcs
to the state early, the crtcs are registered in pipe
order (so the compute_config loop happens in pipe order),
and the hardware requires the master pipe has to be lower
than the slave pipe as well. And for good measure we shall
add a check+WARN for this before doing the bigjoiner crtc
assignment.
v2: Fix uapi.ctm vs. hw.ctm copy-paste fail
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 11 --
drivers/gpu/drm/i915/display/intel_atomic.h | 2 -
drivers/gpu/drm/i915/display/intel_display.c | 170 ---
3 files changed, 108 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 093904065112..e0667d163266 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -281,17 +281,6 @@ void intel_crtc_free_hw_state(struct intel_crtc_state
*crtc_state)
intel_crtc_put_color_blobs(crtc_state);
}
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
-const struct intel_crtc_state *from_crtc_state)
-{
- drm_property_replace_blob(_state->hw.degamma_lut,
- from_crtc_state->uapi.degamma_lut);
- drm_property_replace_blob(_state->hw.gamma_lut,
- from_crtc_state->uapi.gamma_lut);
- drm_property_replace_blob(_state->hw.ctm,
- from_crtc_state->uapi.ctm);
-}
-
/**
* intel_crtc_destroy_state - destroy crtc state
* @crtc: drm crtc
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index d2700c74c9da..1dc439983dd9 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -44,8 +44,6 @@ struct drm_crtc_state *intel_crtc_duplicate_state(struct
drm_crtc *crtc);
void intel_crtc_destroy_state(struct drm_crtc *crtc,
struct drm_crtc_state *state);
void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
-const struct intel_crtc_state
*from_crtc_state);
struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
void intel_atomic_state_free(struct drm_atomic_state *state);
void intel_atomic_state_clear(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 349cc3807e8b..b391cb98b12f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5818,32 +5818,37 @@ static bool check_digital_port_conflicts(struct
intel_atomic_state *state)
static void
intel_crtc_copy_uapi_to_hw_state_nomodeset(struct intel_atomic_state *state,
- struct intel_crtc_state *crtc_state)
+ struct intel_crtc *crtc)
{
- const struct intel_crtc_state *master_crtc_state;
- struct intel_crtc *master_crtc;
+ struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
- master_crtc = intel_master_crtc(crtc_state);
- master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
+ WARN_ON(crtc_state->bigjoiner_slave);
- /* No need to copy state if the master state is unchanged */
- if (master_crtc_state) {
- crtc_state->uapi.color_mgmt_changed =
master_crtc_state->uapi.color_mgmt_changed;
- intel_crtc_copy_color_blobs(crtc_state, master_crtc_state);
- }
+ drm_property_replace_blob(_state->hw.degamma_lut,
+ crtc_state->uapi.degamma_lut);
+ drm_property_replace_blob(_state->hw.gamma_lut,
+ crtc_state->uapi.gamma_lut);
+ drm_property_replace_blob(_state->hw.ctm,
+ crtc_state->uapi.ctm);
}
static void
-intel_crtc_copy_uapi_to_hw_state(struct intel_atomic_state *state,
-struct intel_crtc_state *crtc_state)
+intel_crtc_copy_uapi_to_hw_state_modeset(struct
[Intel-gfx] [PATCH v2 02/10] drm/i915: Fix bigjoiner state copy fails
From: Ville Syrjälä
We seem to be missing a few things from the bigjoiner state copy.
Namely hw.mode isn't getting copied (which probably causes PIPESRC
to be misconfigured), CTM/LUTs aren't getting copied (which could
cause the pipe to produced incorrect output), and we also forgot
to copy over the color_mgmt_changed flag so potentially we fail
to do the actual CTM/LUT programming (assuming we aren't doing
a full modeset or fastset). Fix it all.
v2: Fix uapi.ctm vs. hw.ctm copy-paste fail
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 85dce8a093d4..4f5f023417a6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5827,8 +5827,10 @@ intel_crtc_copy_uapi_to_hw_state_nomodeset(struct
intel_atomic_state *state,
master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
/* No need to copy state if the master state is unchanged */
- if (master_crtc_state)
+ if (master_crtc_state) {
+ crtc_state->uapi.color_mgmt_changed =
master_crtc_state->uapi.color_mgmt_changed;
intel_crtc_copy_color_blobs(crtc_state, master_crtc_state);
+ }
}
static void
@@ -5890,13 +5892,23 @@ copy_bigjoiner_crtc_state(struct intel_crtc_state
*crtc_state,
memset(_state->hw, 0, sizeof(saved_state->hw));
crtc_state->hw.enable = from_crtc_state->hw.enable;
crtc_state->hw.active = from_crtc_state->hw.active;
+ crtc_state->hw.mode = from_crtc_state->hw.mode;
crtc_state->hw.pipe_mode = from_crtc_state->hw.pipe_mode;
crtc_state->hw.adjusted_mode = from_crtc_state->hw.adjusted_mode;
+ crtc_state->hw.scaling_filter = from_crtc_state->hw.scaling_filter;
+
+ drm_property_replace_blob(_state->hw.degamma_lut,
+ from_crtc_state->hw.degamma_lut);
+ drm_property_replace_blob(_state->hw.gamma_lut,
+ from_crtc_state->hw.gamma_lut);
+ drm_property_replace_blob(_state->hw.ctm,
+ from_crtc_state->hw.ctm);
/* Some fixups */
crtc_state->uapi.mode_changed = from_crtc_state->uapi.mode_changed;
crtc_state->uapi.connectors_changed =
from_crtc_state->uapi.connectors_changed;
crtc_state->uapi.active_changed = from_crtc_state->uapi.active_changed;
+ crtc_state->uapi.color_mgmt_changed =
from_crtc_state->uapi.color_mgmt_changed;
crtc_state->nv12_planes = crtc_state->c8_planes =
crtc_state->update_planes = 0;
crtc_state->bigjoiner_linked_crtc =
to_intel_crtc(from_crtc_state->uapi.crtc);
crtc_state->bigjoiner_slave = true;
--
2.34.1
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix bigjoiner state copy fails
On Thu, Feb 03, 2022 at 02:13:41PM -0800, Navare, Manasi wrote:
> On Thu, Feb 03, 2022 at 08:38:15PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We seem to be missing a few things from the bigjoiner state copy.
> > Namely hw.mode isn't getting copied (which probably causes PIPESRC
> > to be misconfigured), CTM/LUTs aren't getting copied (which could
> > cause the pipe to produced incorrect output), and we also forgot
> > to copy over the color_mgmt_changed flag so potentially we fail
> > to do the actual CTM/LUT programming (assuming we aren't doing
> > a full modeset or fastset). Fix it all.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 85dce8a093d4..2006eec6e166 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5827,8 +5827,10 @@ intel_crtc_copy_uapi_to_hw_state_nomodeset(struct
> > intel_atomic_state *state,
> > master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
> >
> > /* No need to copy state if the master state is unchanged */
> > - if (master_crtc_state)
> > + if (master_crtc_state) {
> > + crtc_state->uapi.color_mgmt_changed =
> > master_crtc_state->uapi.color_mgmt_changed;
>
> Since in this function we are copying from uapi_to_hw_state, is this the
> right function to copy to uapi state ?
These *_changed flags aren't really state. They're just
ephemeral properties of the atomic transaction to indicate what
has changed since last time. I've occasionally pondered about
moving all them to live as bitmasks in the top level
drm_atomic_state instead to make that more clear, but haven't
actually gotten bored enough to do it. Also there are other things
hanging off the various state objects that arent really part of the
state proper either.
>
>
> > intel_crtc_copy_color_blobs(crtc_state, master_crtc_state);
> > + }
> > }
> >
> > static void
> > @@ -5890,13 +5892,23 @@ copy_bigjoiner_crtc_state(struct intel_crtc_state
> > *crtc_state,
> > memset(_state->hw, 0, sizeof(saved_state->hw));
> > crtc_state->hw.enable = from_crtc_state->hw.enable;
> > crtc_state->hw.active = from_crtc_state->hw.active;
> > + crtc_state->hw.mode = from_crtc_state->hw.mode;
> > crtc_state->hw.pipe_mode = from_crtc_state->hw.pipe_mode;
> > crtc_state->hw.adjusted_mode = from_crtc_state->hw.adjusted_mode;
> > + crtc_state->hw.scaling_filter = from_crtc_state->hw.scaling_filter;
> > +
> > + drm_property_replace_blob(_state->hw.degamma_lut,
> > + from_crtc_state->hw.degamma_lut);
> > + drm_property_replace_blob(_state->hw.gamma_lut,
> > + from_crtc_state->hw.gamma_lut);
> > + drm_property_replace_blob(_state->uapi.ctm,
Just noticed a copy pasta fail here...
> > + from_crtc_state->hw.ctm);
> >
> > /* Some fixups */
> > crtc_state->uapi.mode_changed = from_crtc_state->uapi.mode_changed;
> > crtc_state->uapi.connectors_changed =
> > from_crtc_state->uapi.connectors_changed;
> > crtc_state->uapi.active_changed = from_crtc_state->uapi.active_changed;
> > + crtc_state->uapi.color_mgmt_changed =
> > from_crtc_state->uapi.color_mgmt_changed;
> > crtc_state->nv12_planes = crtc_state->c8_planes =
> > crtc_state->update_planes = 0;
> > crtc_state->bigjoiner_linked_crtc =
> > to_intel_crtc(from_crtc_state->uapi.crtc);
> > crtc_state->bigjoiner_slave = true;
>
> This looks good
>
> Manasi
>
> > --
> > 2.34.1
> >
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 01/10] drm/i915: Flag crtc scaling_filter changes as modeset
On Thu, Feb 03, 2022 at 01:58:01PM -0800, Navare, Manasi wrote:
> On Thu, Feb 03, 2022 at 08:38:14PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The core doesn't flag scaling_filter prop changes as needing
> > a modeset. That doesn't work for us since we only reprogram the
> > pipe scaler during full modesets and fastsets. So we need to
> > flag the prop change as a modeset ourselves. Assuming nothing else
> > has changed the operation will get promoted (demoted?) to a fastset
> > later.
> >
> > Signed-off-by: Ville Syrjälä
>
> Makes sense, although not sure why this was sent as part of bigjoiner bitmask
> series
Because I noticed it while examining the bigjoiner state copy mess.
>
> Reviewed-by: Manasi Navare
Thanks.
>
> Manasi
>
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index df347329d90e..85dce8a093d4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -7846,6 +7846,10 @@ static int intel_atomic_check(struct drm_device *dev,
> > new_crtc_state, i) {
> > if (new_crtc_state->inherited != old_crtc_state->inherited)
> > new_crtc_state->uapi.mode_changed = true;
> > +
> > + if (new_crtc_state->uapi.scaling_filter !=
> > + old_crtc_state->uapi.scaling_filter)
> > + new_crtc_state->uapi.mode_changed = true;
> > }
> >
> > intel_vrr_check_modeset(state);
> > --
> > 2.34.1
> >
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Disable unused power wells left enabled by BIOS (rev2)
== Series Details ==
Series: drm/i915: Disable unused power wells left enabled by BIOS (rev2)
URL : https://patchwork.freedesktop.org/series/99615/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11180_full -> Patchwork_22160_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22160_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22160_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 13)
--
Additional (2): shard-rkl shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22160_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@system-suspend-devices:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb6/igt@i915_pm_...@system-suspend-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb7/igt@i915_pm_...@system-suspend-devices.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@suspend:
- {shard-dg1}:NOTRUN -> [DMESG-WARN][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-dg1-16/igt@gem_...@suspend.html
* igt@kms_scaling_modes@scaling-mode-center:
- {shard-rkl}:NOTRUN -> [SKIP][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-rkl-1/igt@kms_scaling_mo...@scaling-mode-center.html
* igt@perf_pmu@semaphore-busy@vcs0:
- {shard-dg1}:NOTRUN -> [FAIL][5] +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-dg1-16/igt@perf_pmu@semaphore-b...@vcs0.html
Known issues
Here are the changes found in Patchwork_22160_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_sseu@invalid-args:
- shard-tglb: NOTRUN -> [SKIP][6] ([i915#280])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-tglb1/igt@gem_ctx_s...@invalid-args.html
* igt@gem_exec_balancer@parallel:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#4525])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb1/igt@gem_exec_balan...@parallel.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb8/igt@gem_exec_balan...@parallel.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl: NOTRUN -> [SKIP][9] ([fdo#109271]) +291 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-skl8/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar
issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html
- shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-tglb1/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2849])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2190])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-skl6/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@heavy-random:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#4613])
[20]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (rev2)
== Series Details ==
Series: series starting with [1/2] drm/mm: Add an iterator to optimally walk
over holes for an allocation (rev2)
URL : https://patchwork.freedesktop.org/series/99597/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/i915_gem.o
drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_fits_in_aperture’:
drivers/gpu/drm/i915/i915_gem.c:944:2: error: implicit declaration of function
‘drm_mm_for_each_suitable_hole’; did you mean ‘drm_mm_for_each_best_hole’?
[-Werror=implicit-function-declaration]
drm_mm_for_each_suitable_hole(hole, >vm.mm, 0, ggtt->mappable_end,
^
drm_mm_for_each_best_hole
drivers/gpu/drm/i915/i915_gem.c:945:41: error: expected ‘;’ before ‘{’ token
fence_size, DRM_MM_INSERT_LOW) {
^~
;
drivers/gpu/drm/i915/i915_gem.c:889:15: error: unused variable ‘count’
[-Werror=unused-variable]
unsigned int count = 0;
^
drivers/gpu/drm/i915/i915_gem.c:887:35: error: unused variable ‘end’
[-Werror=unused-variable]
u64 hole_start, hole_end, start, end;
^~~
drivers/gpu/drm/i915/i915_gem.c:887:28: error: unused variable ‘start’
[-Werror=unused-variable]
u64 hole_start, hole_end, start, end;
^
drivers/gpu/drm/i915/i915_gem.c:887:18: error: unused variable ‘hole_end’
[-Werror=unused-variable]
u64 hole_start, hole_end, start, end;
^~~~
drivers/gpu/drm/i915/i915_gem.c:887:6: error: unused variable ‘hole_start’
[-Werror=unused-variable]
u64 hole_start, hole_end, start, end;
^~
drivers/gpu/drm/i915/i915_gem.c:964:1: error: control reaches end of non-void
function [-Werror=return-type]
}
^
cc1: all warnings being treated as errors
scripts/Makefile.build:288: recipe for target 'drivers/gpu/drm/i915/i915_gem.o'
failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem.o] Error 1
scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:550: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1831: recipe for target 'drivers' failed
make: *** [drivers] Error 2
[Intel-gfx] [PATCH 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v6)
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.
This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Therefore, to fix this issue, we try to see if there is space to map
at-least two objects of a given size and return early if there isn't. This
would ensure that we do not try with PIN_MAPPABLE for any objects that
are too big to map thereby preventing unncessary unbind.
Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.
Here is the ftrace snippet that shows the source of the ~10ms latency:
i915_gem_object_pin_to_display_plane() {
0.102 us |i915_gem_object_set_cache_level();
i915_gem_object_ggtt_pin_ww() {
0.390 us | i915_vma_instance();
0.178 us | i915_vma_misplaced();
i915_vma_unbind() {
__i915_active_wait() {
0.082 us |i915_active_acquire_if_busy();
0.475 us | }
intel_runtime_pm_get() {
0.087 us |intel_runtime_pm_acquire();
0.259 us | }
__i915_active_wait() {
0.085 us |i915_active_acquire_if_busy();
0.240 us | }
__i915_vma_evict() {
ggtt_unbind_vma() {
gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us | }
10508.516 us | }
v2: Instead of using bigjoiner checks, determine whether a scanout
buffer is too big by checking to see if it is possible to map
two of them into the ggtt.
v3 (Ville):
- Count how many fb objects can be fit into the available holes
instead of checking for a hole twice the object size.
- Take alignment constraints into account.
- Limit this large scanout buffer check to >= Gen 11 platforms.
v4:
- Remove existing heuristic that checks just for size. (Ville)
- Return early if we find space to map at-least two objects. (Tvrtko)
- Slightly update the commit message.
v5: (Tvrtko)
- Rename the function to indicate that the object may be too big to
map into the aperture.
- Account for guard pages while calculating the total size required
for the object.
- Do not subject all objects to the heuristic check and instead
consider objects only of a certain size.
- Do the hole walk using the rbtree.
- Preserve the existing PIN_NONBLOCK logic.
- Drop the PIN_MAPPABLE check while pinning the VMA.
v6: (Tvrtko)
- Return 0 on success and the specific error code on failure to
preserve the existing behavior.
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Manasi Navare
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/i915_gem.c | 120
1 file changed, 90 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e3a2c2a0e156..39f0d17550c3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -46,6 +46,7 @@
#include "gem/i915_gem_mman.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_userptr.h"
+#include "gem/i915_gem_tiling.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
@@ -876,6 +877,92 @@ static void discard_ggtt_vma(struct i915_vma *vma)
spin_unlock(>vma.lock);
}
+static int
+i915_gem_object_fits_in_aperture(struct drm_i915_gem_object *obj,
+u64 alignment, u64 flags)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+ struct drm_mm_node *hole;
+ u64 hole_start, hole_end, start, end;
+ u64 fence_size, fence_alignment;
+ unsigned int count = 0;
+
+ /*
+* If the required space is larger than the available
+* aperture, we will not able to find a slot for the
+* object and unbinding the object now will be in
+* vain. Worse, doing so may cause us to ping-pong
+* the object in and out of the Global GTT and
+* waste a lot of cycles under the mutex.
+*/
+ if (obj->base.size > ggtt->mappable_end)
+
[Intel-gfx] [PATCH 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v2)
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficiently traversing the rbtree associated with the given
allocator.
It replaces the for loop in drm_mm_insert_node_in_range() and can
also be used by drm drivers to quickly identify holes of a certain
size within a given range.
v2: (Tvrtko)
- Prepend a double underscore for the newly exported first/next_hole
- s/each_best_hole/each_suitable_hole/g
- Mask out DRM_MM_INSERT_ONCE from the mode before calling
first/next_hole and elsewhere.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/drm_mm.c | 38 ++
include/drm/drm_mm.h | 36
2 files changed, 54 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..b6da1dffcfcb 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -352,10 +352,10 @@ static struct drm_mm_node *find_hole_addr(struct drm_mm
*mm, u64 addr, u64 size)
return node;
}
-static struct drm_mm_node *
-first_hole(struct drm_mm *mm,
- u64 start, u64 end, u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+__drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -374,6 +374,7 @@ first_hole(struct drm_mm *mm,
hole_stack);
}
}
+EXPORT_SYMBOL(__drm_mm_first_hole);
/**
* DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
@@ -410,11 +411,11 @@ static struct drm_mm_node *name(struct drm_mm_node
*entry, u64 size) \
DECLARE_NEXT_HOLE_ADDR(next_hole_high_addr, rb_left, rb_right)
DECLARE_NEXT_HOLE_ADDR(next_hole_low_addr, rb_right, rb_left)
-static struct drm_mm_node *
-next_hole(struct drm_mm *mm,
- struct drm_mm_node *node,
- u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+__drm_mm_next_hole(struct drm_mm *mm,
+ struct drm_mm_node *node,
+ u64 size,
+ enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -432,6 +433,7 @@ next_hole(struct drm_mm *mm,
return >hole_stack == >hole_stack ? NULL : node;
}
}
+EXPORT_SYMBOL(__drm_mm_next_hole);
/**
* drm_mm_reserve_node - insert an pre-initialized node
@@ -520,7 +522,6 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
{
struct drm_mm_node *hole;
u64 remainder_mask;
- bool once;
DRM_MM_BUG_ON(range_start > range_end);
@@ -533,22 +534,19 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
if (alignment <= 1)
alignment = 0;
- once = mode & DRM_MM_INSERT_ONCE;
- mode &= ~DRM_MM_INSERT_ONCE;
-
remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
- for (hole = first_hole(mm, range_start, range_end, size, mode);
-hole;
-hole = once ? NULL : next_hole(mm, hole, size, mode)) {
+ drm_mm_for_each_suitable_hole(hole, mm, range_start, range_end,
+ size, mode) {
u64 hole_start = __drm_mm_hole_node_start(hole);
u64 hole_end = hole_start + hole->hole_size;
u64 adj_start, adj_end;
u64 col_start, col_end;
+ enum drm_mm_insert_mode placement = mode & ~DRM_MM_INSERT_ONCE;
- if (mode == DRM_MM_INSERT_LOW && hole_start >= range_end)
+ if (placement == DRM_MM_INSERT_LOW && hole_start >= range_end)
break;
- if (mode == DRM_MM_INSERT_HIGH && hole_end <= range_start)
+ if (placement == DRM_MM_INSERT_HIGH && hole_end <= range_start)
break;
col_start = hole_start;
@@ -562,7 +560,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
if (adj_end <= adj_start || adj_end - adj_start < size)
continue;
- if (mode == DRM_MM_INSERT_HIGH)
+ if (placement == DRM_MM_INSERT_HIGH)
adj_start = adj_end - size;
if (alignment) {
@@ -574,7 +572,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
div64_u64_rem(adj_start, alignment, );
if (rem) {
adj_start -= rem;
- if (mode != DRM_MM_INSERT_HIGH)
+ if (placement != DRM_MM_INSERT_HIGH)
adj_start += alignment;
if (adj_start < max(col_start, range_start) ||
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
Re: [Intel-gfx] [PATCH] drm/i915: Add fallback inside memcpy_from_wc functions
Hi Balasubramani,
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 drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.17-rc2 next-20220203]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Balasubramani-Vivekanandan/drm-i915-Add-fallback-inside-memcpy_from_wc-functions/20220204-002704
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-s001
(https://download.01.org/0day-ci/archive/20220204/202202040609.osw2rfil-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
#
https://github.com/0day-ci/linux/commit/66de634b392157effc065df388510df67de59f2b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Balasubramani-Vivekanandan/drm-i915-Add-fallback-inside-memcpy_from_wc-functions/20220204-002704
git checkout 66de634b392157effc065df388510df67de59f2b
# save the config file to linux build tree
mkdir build_dir
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir
ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/ net/ipv6/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/i915_memcpy.c:189:42: sparse: sparse: incorrect type in
>> argument 2 (different address spaces) @@ expected void const *src @@
>> got void const [noderef] __iomem *src @@
drivers/gpu/drm/i915/i915_memcpy.c:189:42: sparse: expected void const
*src
drivers/gpu/drm/i915/i915_memcpy.c:189:42: sparse: got void const
[noderef] __iomem *src
>> drivers/gpu/drm/i915/i915_memcpy.c:191:45: sparse: sparse: incorrect type in
>> argument 2 (different address spaces) @@ expected void const *[assigned]
>> src @@ got void const [noderef] __iomem *src @@
drivers/gpu/drm/i915/i915_memcpy.c:191:45: sparse: expected void const
*[assigned] src
drivers/gpu/drm/i915/i915_memcpy.c:191:45: sparse: got void const
[noderef] __iomem *src
drivers/gpu/drm/i915/i915_memcpy.c:187:6: sparse: sparse: symbol
'i915_io_memcpy_from_wc' redeclared with different type (incompatible argument
2 (different address spaces)):
>> drivers/gpu/drm/i915/i915_memcpy.c:187:6: sparse:void extern
>> [addressable] [toplevel] i915_io_memcpy_from_wc( ... )
drivers/gpu/drm/i915/i915_memcpy.c: note: in included file:
drivers/gpu/drm/i915/i915_memcpy.h:17:6: sparse: note: previously declared
as:
>> drivers/gpu/drm/i915/i915_memcpy.h:17:6: sparse:void extern
>> [addressable] [toplevel] i915_io_memcpy_from_wc( ... )
--
>> drivers/gpu/drm/i915/gem/i915_gem_object.c:449:37: sparse: sparse: incorrect
>> type in argument 2 (different address spaces) @@ expected void const
>> *src @@ got void [noderef] __iomem *[assigned] src_ptr @@
drivers/gpu/drm/i915/gem/i915_gem_object.c:449:37: sparse: expected void
const *src
drivers/gpu/drm/i915/gem/i915_gem_object.c:449:37: sparse: got void
[noderef] __iomem *[assigned] src_ptr
vim +189 drivers/gpu/drm/i915/i915_memcpy.c
175
176 /**
177 * i915_io_memcpy_from_wc: perform an accelerated *aligned* read from WC
178 * @dst: destination pointer
179 * @src: source pointer
180 * @len: how many bytes to copy
181 *
182 * To be used when the when copying from io memory.
183 *
184 * memcpy_fromio() is used as fallback otherewise no difference to
185 * i915_memcpy_from_wc()
186 */
> 187 void i915_io_memcpy_from_wc(void *dst, const void __iomem *src,
> unsigned long len)
188 {
> 189 if (i915_can_memcpy_from_wc(dst, src, len)) {
190 if (likely(len))
> 191 __memcpy_ntdqa(dst, src, len >> 4);
192 return;
193 }
194
195 /* Fallback */
196 memcpy_fromio(dst, src, len);
197 }
198
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
CC'ing more reviewers for comments. On 1/20/22 14:16, Casey Bowman wrote: In this RFC I would like to ask the community their thoughts on how we can best handle splitting architecture-specific calls. I would like to address the following: 1. How do we want to split architecture calls? Different object files per platform? Separate function calls within the same object file? 2. How do we address dummy functions? If we have a function call that is used for one or more platforms, but is not used in another, what should we do for this case? I've given an example of splitting an architecture call in my patch with run_as_guest() being split into different implementations for x86 and arm64 in separate object files, sharing a single header. Another suggestion from Michael (michael.ch...@intel.com) involved using a single object file, a single header, and splitting various functions calls via ifdefs in the header file. I would appreciate any input on how we can avoid scaling issues when including multiple architectures and multiple functions (as the number of function calls will inevitably increase with more architectures). Casey Bowman (1): i915/drm: Split out x86 and arm64 functionality drivers/gpu/drm/i915/Makefile | 4 +++ drivers/gpu/drm/i915/i915_drv.h| 6 +--- drivers/gpu/drm/i915/i915_platform.h | 16 +++ drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++ drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++ 5 files changed, 87 insertions(+), 5 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_platform.h create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
Re: [Intel-gfx] [PATCH 16/19] drm/i915/guc: Use a single pass to calculate regset
On Tue, Feb 01, 2022 at 02:42:20PM -0800, Daniele Ceraolo Spurio wrote:
On 1/26/2022 12:36 PM, Lucas De Marchi wrote:
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.
However in order to maintain an ordered set of registers to pass to guc,
each register needs to be added and moved in the final array. The second
phase may actually happen in IO memory rather than system memory and
accessing IO memory by simply dereferencing the pointer doesn't work on
all architectures. Other places of the ADS initializaition were
converted to use the dma_buf_map API, but here there may be a lot more
accesses to IO memory. So, instead of following that same approach,
convert the regset initialization to calculate the final array in 1
pass and in the second pass that array is just copied to its final
location, updating the pointers for each engine written to the ADS blob.
One important thing is that struct temp_regset now have
different semantics: `registers` continues to track the registers of a
single engine, however the other fields are updated together, according
to the newly added `storage`, which tracks the memory allocated for
all the registers. So rename some of these fields and add a
__mmio_reg_add(): this function (possibly) allocates memory and operates
on the storage pointer while guc_mmio_reg_add() continues to manage the
registers pointer.
On a Tiger Lake system using enable_guc=3, the following log message is
now seen:
[ 187.334310] i915 :00:02.0: [drm:intel_guc_ads_create [i915]]
Used 4 KB for temporary ADS regset
This change has also been tested on an ARM64 host with DG2 and other
discrete graphics cards.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 7 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 117 +
2 files changed, 79 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index e2e0df1c3d91..4c852eee3ad8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -152,6 +152,13 @@ struct intel_guc {
struct dma_buf_map ads_map;
/** @ads_regset_size: size of the save/restore regsets in the ADS */
u32 ads_regset_size;
+ /**
+* @ads_regset_count: number of save/restore registers in the ADS for
+* each engine
+*/
+ u32 ads_regset_count[I915_NUM_ENGINES];
+ /** @ads_regset: save/restore regsets in the ADS */
+ struct guc_mmio_reg *ads_regset;
/** @ads_golden_ctxt_size: size of the golden contexts in the ADS */
u32 ads_golden_ctxt_size;
/** @ads_engine_usage_size: size of engine usage in the ADS */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 73ca34de44f7..390101ee3661 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -226,14 +226,13 @@ static void guc_mapping_table_init(struct intel_gt *gt,
/*
* The save/restore register list must be pre-calculated to a temporary
- * buffer of driver defined size before it can be generated in place
- * inside the ADS.
+ * buffer before it can be copied inside the ADS.
*/
-#define MAX_MMIO_REGS 128 /* Arbitrary size, increase as needed */
struct temp_regset {
struct guc_mmio_reg *registers;
- u32 used;
- u32 size;
+ struct guc_mmio_reg *storage;
I think this could use a comment to distinguish between registers and
storage. Something like.:
/* ptr to the base of the allocated storage for all engines */
struct guc_mmio_reg *storage;
/* ptr to the section of the storage for the engine currently being
worked on */
struct guc_mmio_reg *registers;
agreed, I will add that
+ u32 storage_used;
+ u32 storage_max;
};
static int guc_mmio_reg_cmp(const void *a, const void *b)
@@ -244,18 +243,44 @@ static int guc_mmio_reg_cmp(const void *a, const void *b)
return (int)ra->offset - (int)rb->offset;
}
+static struct guc_mmio_reg * __must_check
+__mmio_reg_add(struct temp_regset *regset, struct guc_mmio_reg *reg)
+{
+ u32 pos = regset->storage_used;
+ struct guc_mmio_reg *slot;
+
+ if (pos >= regset->storage_max) {
+ size_t size = ALIGN((pos + 1) * sizeof(*slot), PAGE_SIZE);
+ struct guc_mmio_reg *r = krealloc(regset->storage,
+ size, GFP_KERNEL);
+ if (!r) {
+ WARN_ONCE(1, "Incomplete regset list: can't add register
(%d)\n",
+ -ENOMEM);
+
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/uapi: Add query for hwconfig table
Jordan Justen writes:
> John, Rodrigo,
>
> It is now clear to me just how dependent i915 is going to be on the
> closed source guc software, and that's just a fact of life for our
> graphics stack going forward.
>
> In that context, it seems kind of pointless for me to make a big deal
> out of this peripheral "query item" commit message. I still think
> something as simple and to the point as:
>
> "In this interface i915 is returning a blob of data which it receives
> from the guc software. This blob provides some useful data about the
> hardware for drivers. The format of this blob will be documented in the
> Programmer Reference Manuals when released."
As I said on the internal email thread, *if you use my commit message
suggestion*, then, begrudgingly, you can add my:
Acked-by: Jordan Justen
to the patch.
Regardless of the commit message, I think you can add:
Tested-by: Jordan Justen
In truth, I've only tested this via the "prelim" i915 Linux uapi fork on
an internal kernel tree, but I think that probably is close enough.
In case you find it helpful, maybe:
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14511
-Jordan
>
> ... would be better, but obviously this is really just down in the noise
> in terms of concerns about the greater issue. So, feel free (to
> continue) to ignore my suggestion.
>
> Sorry for having wasted your time,
>
> -Jordan
>
> john.c.harri...@intel.com writes:
>
>> From: Rodrigo Vivi
>>
>> GuC contains a consolidated table with a bunch of information about the
>> current device.
>>
>> Previously, this information was spread and hardcoded to all the components
>> including GuC, i915 and various UMDs. The goal here is to consolidate
>> the data into GuC in a way that all interested components can grab the
>> very latest and synchronized information using a simple query.
>>
>> As per most of the other queries, this one can be called twice.
>> Once with item.length=0 to determine the exact buffer size, then
>> allocate the user memory and call it again for to retrieve the
>> table data. For example:
>> struct drm_i915_query_item item = {
>> .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>> };
>> query.items_ptr = (int64_t)
>> query.num_items = 1;
>>
>> ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>> if (item.length <= 0)
>> return -ENOENT;
>>
>> data = malloc(item.length);
>> item.data_ptr = (int64_t)
>> ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>> // Parse the data as appropriate...
>>
>> The returned array is a simple and flexible KLV (Key/Length/Value)
>> formatted table. For example, it could be just:
>> enum device_attr {
>> ATTR_SOME_VALUE = 0,
>> ATTR_SOME_MASK = 1,
>> };
>>
>> static const u32 hwconfig[] = {
>> ATTR_SOME_VALUE,
>> 1, // Value Length in DWords
>> 8, // Value
>>
>> ATTR_SOME_MASK,
>> 3,
>> 0x00, 0x, 0xFF00,
>> };
>>
>> The attribute ids are defined in a hardware spec.
>>
>> Cc: Tvrtko Ursulin
>> Cc: Kenneth Graunke
>> Cc: Michal Wajdeczko
>> Cc: Slawomir Milczarek
>> Signed-off-by: Rodrigo Vivi
>> Signed-off-by: John Harrison
>> Reviewed-by: Matthew Brost
>> ---
>> drivers/gpu/drm/i915/i915_query.c | 23 +++
>> include/uapi/drm/i915_drm.h | 1 +
>> 2 files changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_query.c
>> b/drivers/gpu/drm/i915/i915_query.c
>> index 2dfbc22857a3..609e64d5f395 100644
>> --- a/drivers/gpu/drm/i915/i915_query.c
>> +++ b/drivers/gpu/drm/i915/i915_query.c
>> @@ -479,12 +479,35 @@ static int query_memregion_info(struct
>> drm_i915_private *i915,
>> return total_length;
>> }
>>
>> +static int query_hwconfig_table(struct drm_i915_private *i915,
>> +struct drm_i915_query_item *query_item)
>> +{
>> +struct intel_gt *gt = to_gt(i915);
>> +struct intel_guc_hwconfig *hwconfig = >uc.guc.hwconfig;
>> +
>> +if (!hwconfig->size || !hwconfig->ptr)
>> +return -ENODEV;
>> +
>> +if (query_item->length == 0)
>> +return hwconfig->size;
>> +
>> +if (query_item->length < hwconfig->size)
>> +return -EINVAL;
>> +
>> +if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
>> + hwconfig->ptr, hwconfig->size))
>> +return -EFAULT;
>> +
>> +return hwconfig->size;
>> +}
>> +
>> static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
>> struct drm_i915_query_item *query_item)
>> = {
>> query_topology_info,
>> query_engine_info,
>> query_perf_config,
>> query_memregion_info,
>> +query_hwconfig_table,
>> };
>>
>> int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file
>> *file)
>> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
>> index 914ebd9290e5..132515199f27 100644
>> ---
Re: [Intel-gfx] [PATCH 03/10] drm/i915: Remove weird code from intel_atomic_check_bigjoiner()
On Thu, Feb 03, 2022 at 08:38:16PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> There's some weird junk in intel_atomic_check_bigjoiner()
> that's trying to look at the old crtc state's bigjoiner
> usage for some reason. That code is totally unnecessary,
> and maybe even actively harmful. Not entirely sure which
> since it's such a mess that I can't actually wrap my brain
> around what it ends up doing.
>
> Either way, thanks to intel_bigjoiner_add_affected_crtcs()
> all of the old bigjoiner crtcs are guaranteed to be in the
> state already if any one of them is in the state. Also if
> any one of those crtcs got flagged for a modeset, then all
> of them will have been flagged, and the bigjoiner links
> will have been detached via kill_bigjoiner_slave().
>
> So there is no need to look examing any old bigjoiner
> usage in intel_atomic_check_bigjoiner(). All we have to care
> about is whether bigjoiner is needed for the new state,
> and whether we can get the slave crtc we need.
>
> Signed-off-by: Ville Syrjälä
Completely agree with this cleanup, makes it so much easier to add new future
code
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 33 +++-
> 1 file changed, 11 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 2006eec6e166..b5701ca57889 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7584,38 +7584,28 @@ static bool intel_cpu_transcoders_need_modeset(struct
> intel_atomic_state *state,
> }
>
> static int intel_atomic_check_bigjoiner(struct intel_atomic_state *state,
> - struct intel_crtc *crtc,
> - struct intel_crtc_state *old_crtc_state,
> - struct intel_crtc_state *new_crtc_state)
> + struct intel_crtc *master_crtc)
> {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> - struct intel_crtc_state *slave_crtc_state, *master_crtc_state;
> - struct intel_crtc *slave_crtc, *master_crtc;
> + struct intel_crtc_state *master_crtc_state =
> + intel_atomic_get_new_crtc_state(state, master_crtc);
> + struct intel_crtc_state *slave_crtc_state;
> + struct intel_crtc *slave_crtc;
>
> - /* slave being enabled, is master is still claiming this crtc? */
> - if (old_crtc_state->bigjoiner_slave) {
> - slave_crtc = crtc;
> - master_crtc = old_crtc_state->bigjoiner_linked_crtc;
> - master_crtc_state = intel_atomic_get_new_crtc_state(state,
> master_crtc);
> - if (!master_crtc_state ||
> !intel_crtc_needs_modeset(master_crtc_state))
> - goto claimed;
> - }
> -
> - if (!new_crtc_state->bigjoiner)
> + if (!master_crtc_state->bigjoiner)
> return 0;
>
> - slave_crtc = intel_dsc_get_bigjoiner_secondary(crtc);
> + slave_crtc = intel_dsc_get_bigjoiner_secondary(master_crtc);
> if (!slave_crtc) {
> drm_dbg_kms(>drm,
> "[CRTC:%d:%s] Big joiner configuration requires "
> "CRTC + 1 to be used, doesn't exist\n",
> - crtc->base.base.id, crtc->base.name);
> + master_crtc->base.base.id, master_crtc->base.name);
> return -EINVAL;
> }
>
> - new_crtc_state->bigjoiner_linked_crtc = slave_crtc;
> + master_crtc_state->bigjoiner_linked_crtc = slave_crtc;
> slave_crtc_state = intel_atomic_get_crtc_state(>base,
> slave_crtc);
> - master_crtc = crtc;
> if (IS_ERR(slave_crtc_state))
> return PTR_ERR(slave_crtc_state);
>
> @@ -7627,7 +7617,7 @@ static int intel_atomic_check_bigjoiner(struct
> intel_atomic_state *state,
> "[CRTC:%d:%s] Used as slave for big joiner\n",
> slave_crtc->base.base.id, slave_crtc->base.name);
>
> - return copy_bigjoiner_crtc_state(slave_crtc_state, new_crtc_state);
> + return copy_bigjoiner_crtc_state(slave_crtc_state, master_crtc_state);
>
> claimed:
> drm_dbg_kms(>drm,
> @@ -7899,8 +7889,7 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> - ret = intel_atomic_check_bigjoiner(state, crtc, old_crtc_state,
> -new_crtc_state);
> + ret = intel_atomic_check_bigjoiner(state, crtc);
> if (ret)
> goto fail;
> }
> --
> 2.34.1
>
[Intel-gfx] ✗ Fi.CI.IGT: failure for Use drm_clflush* instead of clflush (rev3)
== Series Details == Series: Use drm_clflush* instead of clflush (rev3) URL : https://patchwork.freedesktop.org/series/99450/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11185_full -> Patchwork_22172_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22172_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22172_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22172_full: ### IGT changes ### Possible regressions * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-skl8/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-skl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html Known issues Here are the changes found in Patchwork_22172_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2410]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-iclb4/igt@gem_exec_balan...@parallel-keep-submit-fence.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-iclb6/igt@gem_exec_balan...@parallel-keep-submit-fence.html * igt@gem_exec_capture@pi@bcs0: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#4547]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-skl6/igt@gem_exec_capture@p...@bcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-skl9/igt@gem_exec_capture@p...@bcs0.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][9] ([i915#2846]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-kbl7/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2849]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-tglb5/igt@gem_huc_c...@huc-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-skl2/igt@gem_lmem_swapp...@verify-random.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [WARN][17] ([i915#2658]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-skl2/igt@gem_pr...@exhaustion.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1436] / [i915#716]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-skl8/igt@gen9_exec_pa...@allowed-single.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-skl7/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][20] -> [FAIL][21] ([i915#454]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-iclb2/igt@i915_pm...@dc6-dpms.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/shard-iclb3/igt@i915_pm...@dc6-dpms.html - shard-skl: NOTRUN -> [FAIL][22] ([i915#454])
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix bigjoiner state copy fails
On Thu, Feb 03, 2022 at 08:38:15PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We seem to be missing a few things from the bigjoiner state copy.
> Namely hw.mode isn't getting copied (which probably causes PIPESRC
> to be misconfigured), CTM/LUTs aren't getting copied (which could
> cause the pipe to produced incorrect output), and we also forgot
> to copy over the color_mgmt_changed flag so potentially we fail
> to do the actual CTM/LUT programming (assuming we aren't doing
> a full modeset or fastset). Fix it all.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 85dce8a093d4..2006eec6e166 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5827,8 +5827,10 @@ intel_crtc_copy_uapi_to_hw_state_nomodeset(struct
> intel_atomic_state *state,
> master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
>
> /* No need to copy state if the master state is unchanged */
> - if (master_crtc_state)
> + if (master_crtc_state) {
> + crtc_state->uapi.color_mgmt_changed =
> master_crtc_state->uapi.color_mgmt_changed;
Since in this function we are copying from uapi_to_hw_state, is this the right
function to copy to uapi state ?
> intel_crtc_copy_color_blobs(crtc_state, master_crtc_state);
> + }
> }
>
> static void
> @@ -5890,13 +5892,23 @@ copy_bigjoiner_crtc_state(struct intel_crtc_state
> *crtc_state,
> memset(_state->hw, 0, sizeof(saved_state->hw));
> crtc_state->hw.enable = from_crtc_state->hw.enable;
> crtc_state->hw.active = from_crtc_state->hw.active;
> + crtc_state->hw.mode = from_crtc_state->hw.mode;
> crtc_state->hw.pipe_mode = from_crtc_state->hw.pipe_mode;
> crtc_state->hw.adjusted_mode = from_crtc_state->hw.adjusted_mode;
> + crtc_state->hw.scaling_filter = from_crtc_state->hw.scaling_filter;
> +
> + drm_property_replace_blob(_state->hw.degamma_lut,
> + from_crtc_state->hw.degamma_lut);
> + drm_property_replace_blob(_state->hw.gamma_lut,
> + from_crtc_state->hw.gamma_lut);
> + drm_property_replace_blob(_state->uapi.ctm,
> + from_crtc_state->hw.ctm);
>
> /* Some fixups */
> crtc_state->uapi.mode_changed = from_crtc_state->uapi.mode_changed;
> crtc_state->uapi.connectors_changed =
> from_crtc_state->uapi.connectors_changed;
> crtc_state->uapi.active_changed = from_crtc_state->uapi.active_changed;
> + crtc_state->uapi.color_mgmt_changed =
> from_crtc_state->uapi.color_mgmt_changed;
> crtc_state->nv12_planes = crtc_state->c8_planes =
> crtc_state->update_planes = 0;
> crtc_state->bigjoiner_linked_crtc =
> to_intel_crtc(from_crtc_state->uapi.crtc);
> crtc_state->bigjoiner_slave = true;
This looks good
Manasi
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v5 01/10] drm/i915/guc: Update GuC ADS size for error capture lists
So we are coming to an agreement... I will go with the option of ADS calling intel_guc_capture and asking it for the temp buf ptr and size and let ADS do the actual copying. I will have to see how straight forward the copying will be (if u see RFC-rev1 of this series, the ADS does the full population and calls intel_guc_capture just for the external (not io-mem) register list pointer. But a lot of code that got injected into ADS as it traversed through individual error capture substructure members. One last comment on below: > > Alan: The first part of above is already what is happening in my series > > today, > > we have a seperate register list in the intel_guc_capture module > > no, what you have in this patch I commented on is: > > > > > > > > + /* Lists for error capture debug */ > > > > > > > + intel_guc_capture_prep_lists(guc, (struct guc_ads *)blob, > > > > > > > base, > > you are passing the complete ads blob outside. I'd even try to avoid passing > the second level struct depending on the case, but that would be > much more acceptable. I'm sorry I wasnt clear, what i meant is just the part about having an interim buffer for the error capture register list outside of ADS blob io-memory. That already exists in all rev's of this series but in rev 3 onwards, as u pointed out above, the external buffer ptr was not passed to ADS and i was taking the blob ptr from ADS. Rev-1-RFC probably is closer to what we want. ...alan
Re: [Intel-gfx] [PATCH 01/10] drm/i915: Flag crtc scaling_filter changes as modeset
On Thu, Feb 03, 2022 at 08:38:14PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The core doesn't flag scaling_filter prop changes as needing
> a modeset. That doesn't work for us since we only reprogram the
> pipe scaler during full modesets and fastsets. So we need to
> flag the prop change as a modeset ourselves. Assuming nothing else
> has changed the operation will get promoted (demoted?) to a fastset
> later.
>
> Signed-off-by: Ville Syrjälä
Makes sense, although not sure why this was sent as part of bigjoiner bitmask
series
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index df347329d90e..85dce8a093d4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7846,6 +7846,10 @@ static int intel_atomic_check(struct drm_device *dev,
> new_crtc_state, i) {
> if (new_crtc_state->inherited != old_crtc_state->inherited)
> new_crtc_state->uapi.mode_changed = true;
> +
> + if (new_crtc_state->uapi.scaling_filter !=
> + old_crtc_state->uapi.scaling_filter)
> + new_crtc_state->uapi.mode_changed = true;
> }
>
> intel_vrr_check_modeset(state);
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v5 01/10] drm/i915/guc: Update GuC ADS size for error capture lists
On Thu, Feb 03, 2022 at 12:40:54PM -0800, Teres Alexis, Alan Previn wrote:
Apologies, please ignore last reply (wrestling with my VNC). Proper reply:
On Thu, 2022-02-03 at 12:39 -0800, Alan Previn Teres Alexis wrote:
On Thu, 2022-02-03 at 12:04 -0800, Lucas De Marchi wrote:
> On Thu, Feb 03, 2022 at 11:03:24AM -0800, Matthew Brost wrote:
> > On Wed, Jan 26, 2022 at 02:46:19PM -0800, Lucas De Marchi wrote:
> > > On Wed, Jan 26, 2022 at 02:48:13AM -0800, Alan Previn wrote:
> > > > Update GuC ADS size allocation to include space for
> > > > the lists of error state capture register descriptors.
> > > >
> > > > Also, populate the lists of registers we want GuC to report back to
> > > > Host on engine reset events. This list should include global,
> > > > engine-class and engine-instance registers for every engine-class
> > > > type on the current hardware.
> > > >
> > > > NOTE: Start with a sample table of register lists to layout the
> > > > framework before adding real registers in subsequent patch.
> > > >
> > > > Signed-off-by: Alan Previn
> > > > ---
> > >
> > > ...
> > >
> > > > static void __guc_ads_init(struct intel_guc *guc)
> > > > {
> > > > struct intel_gt *gt = guc_to_gt(guc);
> > > > @@ -573,9 +553,9 @@ static void __guc_ads_init(struct intel_guc *guc)
> > > >
> > > > base = intel_guc_ggtt_offset(guc, guc->ads_vma);
> > > >
> > > > - /* Capture list for hang debug */
> > > > - guc_capture_list_init(guc, blob);
> > > > -
> > > > + /* Lists for error capture debug */
> > > > + intel_guc_capture_prep_lists(guc, (struct guc_ads *)blob, base,
> > >
> > > no, please don't cast/export struct guc_ads like this. We can't really
> > > dereference it since it may be in IO memory.
> > >
> > > See https://patchwork.freedesktop.org/series/99378/ with the huge
> > > refactor in this file to make it conform to the rules of accessing IO
> > > memory.
> > >
> > > Maybe this list could be appended in the same reglist buffer and we just
> > > copy it once to its final location, like we are doing with the reglist?
> > >
> >
> > Agree with Lucas here, let's create the capture list on probe and store
> > it somewhere in the device data. On ADS population this more or less
> > turns into a memcpy (or after Lucas's series a dma-buf-map call). And on
> > fini, just free to stored data. The create capture list IMO is fine to
> > be done in an external file and return the data to the ADS code but
> > let's make sure everyone is on board with that. Maybe ping Lucas
> > directly about this?
>
> yeah, sounds good to me. My worry is exporting ADS struct layout to
> other compilation units. Asking for the entire ads blob
> (or what would be dma_buf_map in my patches, or iosys_map in the new
> version I will send soon) could quickly spread too much knowledge about it to
> the rest of the driver.
>
I'm in partial disagreement with above. Based on above statement, are we
enforcing
that we must always continue to only have ADS know the 2nd level blobl
structure layout?
no
Doesn't that also force that intelligence of knowing its substructure contents
to
always be in ADS only? So ADS C file continues to grow larger and larger with
completely
orthogonal domain specific knowledge? (golden context: engine info,
error-capture: debug registers, etc..).
no, see below
I believe ADS should really let the substructure headers be accessible to
external
modules to deal with the parsing, size determination and preparing its contents.
NOTE: see my next comment specifically regarding the pointer access.
I think we should at most export the speficic offset inside the buffer
> another compilation unit can fill out. In that case with the
> iosys_buf API we would return a shallow copy of our guc->ads_map +
> offset.
>
> And the other alternative would be as you suggested: save the list in a
> temporary buffer and when needed call intel_guc_ads() to populate that
> into ads in the right place.
>
Alan: The first part of above is already what is happening in my series today,
we have a seperate register list in the intel_guc_capture module
no, what you have in this patch I commented on is:
> > > > + /* Lists for error capture debug */
> > > > + intel_guc_capture_prep_lists(guc, (struct guc_ads *)blob, base,
you are passing the complete ads blob outside. I'd even try to avoid passing
the second level struct depending on the case, but that would be
much more acceptable.
that also determines (based on device and fusing) which registers
to include or exclude. There is are static global lists and
per-gt-allocated lists (based on fuse masks). The latter
is not in current rev but already commented as planned change.
So in response to the original review comment, I can change this
patch so that the ADS gets a regular heap-kzalloc-allocated pointer and
size from the error-capture module and ADS do the copying into the
io-mem ptr but i want to ensure the layout of the error-capture
lists
Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
Hi Daniel, > > > + kfree(ops->cursor_state.mask); > > + kfree(ops->cursor_data); > > + kfree(ops->cursor_src); > > + kfree(ops->fontbuffer); > > + kfree(oldinfo->fbcon_par); > > + oldinfo->fbcon_par = NULL; > These all look like candidates to stuff into fbcon_release() > That would drop the nice symmetry but make it more consistent. > > I think we miss freeing ops->cursor_data in fbcon_exit(), > but I did not follow all the code. We agree as I can see this was done in a later patch. Sam
Re: [Intel-gfx] [PATCH 10/21] fb: Delete fb_info->queue
On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> It was only used by fbcon, and that now switched to its own,
> private work.
>
> Signed-off-by: Daniel Vetter
> Cc: Helge Deller
> Cc: linux-fb...@vger.kernel.org
I would merge this with the patch that drops the usage
> ---
> include/linux/fb.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 02f362c661c8..a8a00d2ba1f3 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -449,7 +449,6 @@ struct fb_info {
> struct fb_var_screeninfo var; /* Current var */
> struct fb_fix_screeninfo fix; /* Current fix */
> struct fb_monspecs monspecs;/* Current Monitor specs */
> - struct work_struct queue; /* Framebuffer event queue */
> struct fb_pixmap pixmap;/* Image hardware mapper */
> struct fb_pixmap sprite;/* Cursor hardware mapper */
> struct fb_cmap cmap;/* Current cmap */
> --
> 2.33.0
Re: [Intel-gfx] [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
On Mon, Jan 31, 2022 at 10:05:40PM +0100, Daniel Vetter wrote: > It's only one flag and slightly tidier code. > > Signed-off-by: Daniel Vetter > Cc: Daniel Vetter > Cc: Tetsuo Handa > Cc: Greg Kroah-Hartman > Cc: Du Cheng > Cc: Thomas Zimmermann > Cc: Claudio Suarez Acked-by: Sam Ravnborg Next step is to convert some of the int flags to bool - so it is obvious this is bool and not an int. I do not like bitfields for bools when there is no big win in memory usage - so not fan of that suggestion. Sam
Re: [Intel-gfx] [PATCH 07/21] fbdev/sysfs: Fix locking
On Mon, Jan 31, 2022 at 10:05:38PM +0100, Daniel Vetter wrote: > fb_set_var requires we hold the fb_info lock. Or at least this now > matches what the ioctl does ... > > Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here, > but I will not fix them up. > > Also in practice this isn't a big deal, because really variable fbdev > state is actually protected by console_lock (because fbcon just > doesn't bother with lock_fb_info() at all), and lock_fb_info > protecting anything is really just a neat lie. But that's a much > bigger fish to fry. > > Signed-off-by: Daniel Vetter > Cc: Helge Deller > Cc: Daniel Vetter > Cc: Qing Wang > Cc: Sam Ravnborg Acked-by: Sam Ravnborg
Re: [Intel-gfx] [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup
On Mon, Jan 31, 2022 at 10:05:36PM +0100, Daniel Vetter wrote: > Half of it is protected by console_lock, but the other half is a lot > more awkward: Registration/deregistration of fbdev are serialized, but > we don't really clear out anything in con2fb_map and so there's > potential for use-after free mixups. > > First step is to encapsulate the lookup. > > Signed-off-by: Daniel Vetter > Cc: Helge Deller > Cc: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: Tetsuo Handa > Cc: Du Cheng > Cc: Claudio Suarez > Cc: Thomas Zimmermann Acked-by: Sam Ravnborg
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use a bitmask for bigjoiner state tracking
== Series Details == Series: drm/i915: Use a bitmask for bigjoiner state tracking URL : https://patchwork.freedesktop.org/series/99680/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11185_full -> Patchwork_22171_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22171_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22171_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22171_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gem_contexts: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-skl8/igt@i915_selftest@live@gem_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-skl3/igt@i915_selftest@live@gem_contexts.html Known issues Here are the changes found in Patchwork_22171_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@many-contexts: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk5/igt@gem_ctx_persiste...@many-contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-glk1/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-iclb4/igt@gem_exec_balan...@parallel-keep-submit-fence.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-iclb5/igt@gem_exec_balan...@parallel-keep-submit-fence.html * igt@gem_exec_capture@pi@rcs0: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#4547]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-skl6/igt@gem_exec_capture@p...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-skl9/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][9] ([i915#2846]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-kbl3/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-apl4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2842]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2849]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_lmem_swapping@verify-random: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-skl7/igt@gem_lmem_swapp...@verify-random.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-skl7/igt@gem_pr...@exhaustion.html * igt@i915_pm_dc@dc6-dpms: - shard-skl: NOTRUN -> [FAIL][20] ([i915#454]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-skl2/igt@i915_pm...@dc6-dpms.html * igt@i915_selftest@live@hangcheck: - shard-snb: NOTRUN -> [INCOMPLETE][21] ([i915#3921]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/shard-snb6/igt@i915_selftest@l...@hangcheck.html *
Re: [Intel-gfx] [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo
On Mon, Jan 31, 2022 at 10:05:43PM +0100, Daniel Vetter wrote: > It doesn't ever fail anymore. > > Signed-off-by: Daniel Vetter > Cc: Daniel Vetter > Cc: Thomas Zimmermann > Cc: Greg Kroah-Hartman > Cc: Claudio Suarez > Cc: Du Cheng > Cc: Tetsuo Handa Acked-by: Sam Ravnborg
Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> There's two minor behaviour changes in here:
> - in error paths we now consistently call fb_ops->fb_release
> - fb_release really can't fail (fbmem.c ignores it too) and there's no
> reasonable cleanup we can do anyway.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Claudio Suarez
> Cc: Greg Kroah-Hartman
> Cc: Tetsuo Handa
> Cc: Du Cheng
> ---
> drivers/video/fbdev/core/fbcon.c | 107 +++
> 1 file changed, 53 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index fa30e1909164..eea2ee14b64c 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info
> *info, unsigned charcount)
>
> #endif /* CONFIG_MISC_TILEBLITTING */
>
> +static int fbcon_open(struct fb_info *info)
> +{
> + if (!try_module_get(info->fbops->owner))
> + return -ENODEV;
> +
> + if (info->fbops->fb_open &&
> + info->fbops->fb_open(info, 0)) {
> + module_put(info->fbops->owner);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> +static void fbcon_release(struct fb_info *info)
> +{
> + if (info->fbops->fb_release)
> + info->fbops->fb_release(info, 0);
> +
> + module_put(info->fbops->owner);
> +}
>
> static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> int unit, int oldidx)
> {
> struct fbcon_ops *ops = NULL;
> - int err = 0;
> -
> - if (!try_module_get(info->fbops->owner))
> - err = -ENODEV;
> + int err;
>
> - if (!err && info->fbops->fb_open &&
> - info->fbops->fb_open(info, 0))
> - err = -ENODEV;
> + err = fbcon_open(info);
> + if (err)
> + return err;
>
> if (!err) {
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
> struct fb_info *info,
>
> if (err) {
> con2fb_map[unit] = oldidx;
> - module_put(info->fbops->owner);
> + fbcon_release(info);
> }
>
> return err;
> @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc,
> struct fb_info *oldinfo,
> int oldidx, int found)
> {
> struct fbcon_ops *ops = oldinfo->fbcon_par;
> - int err = 0, ret;
> + int ret;
>
> - if (oldinfo->fbops->fb_release &&
> - oldinfo->fbops->fb_release(oldinfo, 0)) {
> - con2fb_map[unit] = oldidx;
The old code assigns con2fb_map[unit] before is calls
newinfo->fbops->fb_release).
I wonder if there can be any callback to fbcon where the value
of con2fb_map[unit] matters?
> - if (!found && newinfo->fbops->fb_release)
> - newinfo->fbops->fb_release(newinfo, 0);
> - if (!found)
> - module_put(newinfo->fbops->owner);
> - err = -ENODEV;
> - }
> + fbcon_release(oldinfo);
>
> - if (!err) {
> - fbcon_del_cursor_work(oldinfo);
> - kfree(ops->cursor_state.mask);
> - kfree(ops->cursor_data);
> - kfree(ops->cursor_src);
> - kfree(ops->fontbuffer);
> - kfree(oldinfo->fbcon_par);
> - oldinfo->fbcon_par = NULL;
> - module_put(oldinfo->fbops->owner);
> - /*
> - If oldinfo and newinfo are driving the same hardware,
> - the fb_release() method of oldinfo may attempt to
> - restore the hardware state. This will leave the
> - newinfo in an undefined state. Thus, a call to
> - fb_set_par() may be needed for the newinfo.
> - */
> - if (newinfo && newinfo->fbops->fb_set_par) {
> - ret = newinfo->fbops->fb_set_par(newinfo);
> + fbcon_del_cursor_work(oldinfo);
> + kfree(ops->cursor_state.mask);
> + kfree(ops->cursor_data);
> + kfree(ops->cursor_src);
> + kfree(ops->fontbuffer);
> + kfree(oldinfo->fbcon_par);
> + oldinfo->fbcon_par = NULL;
These all look like candidates to stuff into fbcon_release()
That would drop the nice symmetry but make it more consistent.
I think we miss freeing ops->cursor_data in fbcon_exit(),
but I did not follow all the code.
With my ramblings considered the patch is
Acked-by: Sam Ravnborg
Sam
> + /*
> + If oldinfo and newinfo are driving the same hardware,
> + the fb_release() method of oldinfo may attempt to
> + restore the hardware state. This will leave the
> + newinfo in an undefined state. Thus, a call to
> + fb_set_par() may be needed for the newinfo.
> + */
> + if (newinfo &&
[Intel-gfx] ✓ Fi.CI.BAT: success for Use drm_clflush* instead of clflush (rev3)
== Series Details ==
Series: Use drm_clflush* instead of clflush (rev3)
URL : https://patchwork.freedesktop.org/series/99450/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11185 -> Patchwork_22172
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/index.html
Participating hosts (50 -> 44)
--
Missing(6): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 shard-rkl
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22172 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [PASS][2] -> [FAIL][3] ([i915#4547])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [PASS][4] -> [DMESG-FAIL][5] ([i915#4494] /
[i915#4957])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-4770:[PASS][6] -> [INCOMPLETE][7] ([i915#3303])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][8] -> [DMESG-WARN][9] ([i915#4269])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#1436] /
[i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-hsw-4770/igt@run...@aborted.html
- fi-skl-6600u: NOTRUN -> [FAIL][11] ([i915#4312])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-skl-6600u/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [INCOMPLETE][12] ([i915#4418]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6700k2: [DMESG-FAIL][14] ([i915#2291] / [i915#541]) ->
[PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-tgl-1115g4: [DMESG-FAIL][16] ([i915#3987]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][18] ([i915#3921]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][20] ([i915#295]) -> [PASS][21] +12
similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22172/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3921]:
Re: [Intel-gfx] [PATCH 06/21] fbcon: delete delayed loading code
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> Before
>
> commit 6104c37094e729f3d4ce65797002112735d49cd1
> Author: Daniel Vetter
> Date: Tue Aug 1 17:32:07 2017 +0200
>
> fbcon: Make fbcon a built-time depency for fbdev
>
> it was possible to load fbcon and fbdev drivers in any order, which
> means that fbcon init had to handle the case where fbdev drivers where
> already registered.
>
> This is no longer possible, hence delete that code.
>
> Note that the exit case is a bit more complex and will be done in a
> separate patch.
>
> Signed-off-by: Daniel Vetter
> Cc: Helge Deller
> Cc: Daniel Vetter
> Cc: Claudio Suarez
> Cc: Greg Kroah-Hartman
> Cc: Tetsuo Handa
> Cc: Du Cheng
> ---
> drivers/video/fbdev/core/fbcon.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 8f971de35885..814b648e8f09 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> return display_desc;
> /*
>* Instead of blindly using registered_fb[0], we use info_idx, set by
> - * fb_console_init();
> + * fbcon_fb_registered();
>*/
This comment change looks like it does not belong in this patch.
Also, the comment is wrong as info_idx is set in several places.
Like set_con2fb_map(), fbcon_remap_all(), and more.
Though it is not set by fb_console_init - so partly OK.
With the comment adjustment dropped.
Acked-by: Sam Ravnborg
at least the code deletion looked OK, I failed to follow all the logic.
So would be good if someone else could ack it too.
Sam
> info = registered_fb[info_idx];
> if (!info)
> @@ -3316,17 +3316,6 @@ static void fbcon_start(void)
> return;
> }
> #endif
> -
> - if (num_registered_fb) {
> - int i;
> -
> - for_each_registered_fb(i) {
> - info_idx = i;
> - break;
> - }
> -
> - do_fbcon_takeover(0);
> - }
> }
>
> static void fbcon_exit(void)
> --
> 2.33.0
Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
Hi Daniel, On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote: > Ever since Tomi extracted the core code in 2014 it's been defacto me > maintaining this, with help from others from dri-devel and sometimes > Linus (but those are mostly merge conflicts): > > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 > 35 Daniel Vetter > 23 Linus Torvalds > 10 Hans de Goede > 9 Dave Airlie > 6 Peter Rosin > > I think ideally we'd also record that the various firmware fb drivers > (efifb, vesafb, ...) are also maintained in drm-misc because for the > past few years the patches have either been to fix handover issues > with drm drivers, or caused handover issues with drm drivers. So any > other tree just doesn't make sense. But also, there's plenty of > outdated MAINTAINER entries for these with people and git trees that > haven't been active in years, so maybe let's just leave them alone. > And furthermore distros are now adopting simpledrm as the firmware fb > driver, so hopefully the need to care about the fbdev firmware drivers > will go down going forward. > > Note that drm-misc is group maintained, I expect that to continue like > we've done before, so no new expectations that patches all go through > my hands. That would be silly. This also means I'm happy to put any > other volunteer's name in the M: line, but otherwise git log says I'm > the one who's stuck with this. > > Cc: Dave Airlie > Cc: Jani Nikula > Cc: Linus Torvalds > Cc: Linux Fbdev development list > Cc: Pavel Machek > Cc: Sam Ravnborg > Cc: Greg Kroah-Hartman > Cc: Javier Martinez Canillas > Cc: DRI Development > Cc: Linux Kernel Mailing List > Cc: Claudio Suarez > Cc: Tomi Valkeinen > Cc: Geert Uytterhoeven > Cc: Thomas Zimmermann > Cc: Daniel Vetter > Cc: Sven Schnelle > Cc: Gerd Hoffmann > Signed-off-by: Daniel Vetter > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ea3e6c914384..49809eaa3096 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7573,6 +7573,12 @@ S: Maintained > W: http://floatingpoint.sourceforge.net/emulator/index.html > F: arch/x86/math-emu/ > > +FRAMEBUFFER CORE > +M: Daniel Vetter > +F: drivers/video/fbdev/core/ Maybe add: include/linux/fb.h include/uapi/linux/fb.h Both edited within some months - so they see a little changes. With or without this: Acked-by: Sam Ravnborg
Re: [Intel-gfx] [PATCH v5 01/10] drm/i915/guc: Update GuC ADS size for error capture lists
Apologies, please ignore last reply (wrestling with my VNC). Proper reply:
On Thu, 2022-02-03 at 12:39 -0800, Alan Previn Teres Alexis wrote:
>
>
> On Thu, 2022-02-03 at 12:04 -0800, Lucas De Marchi wrote:
> > On Thu, Feb 03, 2022 at 11:03:24AM -0800, Matthew Brost wrote:
> > > On Wed, Jan 26, 2022 at 02:46:19PM -0800, Lucas De Marchi wrote:
> > > > On Wed, Jan 26, 2022 at 02:48:13AM -0800, Alan Previn wrote:
> > > > > Update GuC ADS size allocation to include space for
> > > > > the lists of error state capture register descriptors.
> > > > >
> > > > > Also, populate the lists of registers we want GuC to report back to
> > > > > Host on engine reset events. This list should include global,
> > > > > engine-class and engine-instance registers for every engine-class
> > > > > type on the current hardware.
> > > > >
> > > > > NOTE: Start with a sample table of register lists to layout the
> > > > > framework before adding real registers in subsequent patch.
> > > > >
> > > > > Signed-off-by: Alan Previn
> > > > > ---
> > > >
> > > > ...
> > > >
> > > > > static void __guc_ads_init(struct intel_guc *guc)
> > > > > {
> > > > > struct intel_gt *gt = guc_to_gt(guc);
> > > > > @@ -573,9 +553,9 @@ static void __guc_ads_init(struct intel_guc *guc)
> > > > >
> > > > > base = intel_guc_ggtt_offset(guc, guc->ads_vma);
> > > > >
> > > > > - /* Capture list for hang debug */
> > > > > - guc_capture_list_init(guc, blob);
> > > > > -
> > > > > + /* Lists for error capture debug */
> > > > > + intel_guc_capture_prep_lists(guc, (struct guc_ads *)blob, base,
> > > >
> > > > no, please don't cast/export struct guc_ads like this. We can't really
> > > > dereference it since it may be in IO memory.
> > > >
> > > > See https://patchwork.freedesktop.org/series/99378/ with the huge
> > > > refactor in this file to make it conform to the rules of accessing IO
> > > > memory.
> > > >
> > > > Maybe this list could be appended in the same reglist buffer and we just
> > > > copy it once to its final location, like we are doing with the reglist?
> > > >
> > >
> > > Agree with Lucas here, let's create the capture list on probe and store
> > > it somewhere in the device data. On ADS population this more or less
> > > turns into a memcpy (or after Lucas's series a dma-buf-map call). And on
> > > fini, just free to stored data. The create capture list IMO is fine to
> > > be done in an external file and return the data to the ADS code but
> > > let's make sure everyone is on board with that. Maybe ping Lucas
> > > directly about this?
> >
> > yeah, sounds good to me. My worry is exporting ADS struct layout to
> > other compilation units. Asking for the entire ads blob
> > (or what would be dma_buf_map in my patches, or iosys_map in the new
> > version I will send soon) could quickly spread too much knowledge about it
> > to
> > the rest of the driver.
> >
>
I'm in partial disagreement with above. Based on above statement, are we
enforcing
that we must always continue to only have ADS know the 2nd level blobl
structure layout?
Doesn't that also force that intelligence of knowing its substructure contents
to
always be in ADS only? So ADS C file continues to grow larger and larger with
completely
orthogonal domain specific knowledge? (golden context: engine info,
error-capture: debug registers, etc..).
I believe ADS should really let the substructure headers be accessible to
external
modules to deal with the parsing, size determination and preparing its contents.
NOTE: see my next comment specifically regarding the pointer access.
> I think we should at most export the speficic offset inside the buffer
>
> > another compilation unit can fill out. In that case with the
> > iosys_buf API we would return a shallow copy of our guc->ads_map +
> > offset.
> >
> > And the other alternative would be as you suggested: save the list in a
> > temporary buffer and when needed call intel_guc_ads() to populate that
> > into ads in the right place.
> >
>
Alan: The first part of above is already what is happening in my series today,
we have a seperate register list in the intel_guc_capture module
that also determines (based on device and fusing) which registers
to include or exclude. There is are static global lists and
per-gt-allocated lists (based on fuse masks). The latter
is not in current rev but already commented as planned change.
So in response to the original review comment, I can change this
patch so that the ADS gets a regular heap-kzalloc-allocated pointer and
size from the error-capture module and ADS do the copying into the
io-mem ptr but i want to ensure the layout of the error-capture
lists are not private to ADS only.
Are we okay with that?
>
> > The integration with iosys-map I can figure out if my patch series lands
> > after this one, or I can help rebasing this otherwise. But IMO we
> > should not pass the plain blob pointer around regardless of iosys-map.
> >
> >
> >
Re: [Intel-gfx] [PATCH v5 01/10] drm/i915/guc: Update GuC ADS size for error capture lists
I can refactor my code to enforce an owner module to only return the size and
an interim
buffer pointer (kzalloc, not io mem) and have ADS memcpy from that pointer into
the ADS
substructure pointer..
But I hope we can make it a rule that its okay for an external owner-module to
know and define the layout of the 2nd level substructure layout. This would
allow
future new ADS substructure to have separate owner-modules handle the definition
of the substructure layout
something like this:
guc_ads_top_fwif.h
ADS owns top level ADS
{
u32 ptr1;// substruct_foo1
u32 ptr2;// substruct_foo2
u32 ptr3;// substruct_foo3
...
}
guc_capture_private.h
substruct_foo
So putting aside the fact that already have ADS containing the knowledge for
golden context, register-save-restore, and others, but moving forward i am
hoping
we can avoid piling on more and more unrelated low level knowledge inside of
ADS.
The the error capture substructure layout has awareness of per PF-vs-VF, global
vs
engine-class vs engine-instance and other fuse-specific awareness. So i am
hoping
we can allow other moules to own the definition and parsing of the substructure
layout.
...alan
On Thu, 2022-02-03 at 12:04 -0800, Lucas De Marchi wrote:
> On Thu, Feb 03, 2022 at 11:03:24AM -0800, Matthew Brost wrote:
> > On Wed, Jan 26, 2022 at 02:46:19PM -0800, Lucas De Marchi wrote:
> > > On Wed, Jan 26, 2022 at 02:48:13AM -0800, Alan Previn wrote:
> > > > Update GuC ADS size allocation to include space for
> > > > the lists of error state capture register descriptors.
> > > >
> > > > Also, populate the lists of registers we want GuC to report back to
> > > > Host on engine reset events. This list should include global,
> > > > engine-class and engine-instance registers for every engine-class
> > > > type on the current hardware.
> > > >
> > > > NOTE: Start with a sample table of register lists to layout the
> > > > framework before adding real registers in subsequent patch.
> > > >
> > > > Signed-off-by: Alan Previn
> > > > ---
> > >
> > > ...
> > >
> > > > static void __guc_ads_init(struct intel_guc *guc)
> > > > {
> > > > struct intel_gt *gt = guc_to_gt(guc);
> > > > @@ -573,9 +553,9 @@ static void __guc_ads_init(struct intel_guc *guc)
> > > >
> > > > base = intel_guc_ggtt_offset(guc, guc->ads_vma);
> > > >
> > > > - /* Capture list for hang debug */
> > > > - guc_capture_list_init(guc, blob);
> > > > -
> > > > + /* Lists for error capture debug */
> > > > + intel_guc_capture_prep_lists(guc, (struct guc_ads *)blob, base,
> > >
> > > no, please don't cast/export struct guc_ads like this. We can't really
> > > dereference it since it may be in IO memory.
> > >
> > > See https://patchwork.freedesktop.org/series/99378/ with the huge
> > > refactor in this file to make it conform to the rules of accessing IO
> > > memory.
> > >
> > > Maybe this list could be appended in the same reglist buffer and we just
> > > copy it once to its final location, like we are doing with the reglist?
> > >
> >
> > Agree with Lucas here, let's create the capture list on probe and store
> > it somewhere in the device data. On ADS population this more or less
> > turns into a memcpy (or after Lucas's series a dma-buf-map call). And on
> > fini, just free to stored data. The create capture list IMO is fine to
> > be done in an external file and return the data to the ADS code but
> > let's make sure everyone is on board with that. Maybe ping Lucas
> > directly about this?
>
> yeah, sounds good to me. My worry is exporting ADS struct layout to
> other compilation units. Asking for the entire ads blob
> (or what would be dma_buf_map in my patches, or iosys_map in the new
> version I will send soon) could quickly spread too much knowledge about it to
> the rest of the driver.
>
I'm in partial disagreement with above. Based on above statement, are we
enforcing
that we must always continue to only have ADS know the 2nd level blobl
structure layout?
Doesn't that also force that intelligence of knowing its substructure contents
to
always be in ADS only? So ADS C file continues to grow larger and larger with
completely
orthogonal domain specific knowledge? (golden context: engine info,
error-capture: debug registers, etc..).
I believe ADS should really let the substructure headers be accessible to
external
modules to deal with the parsing, size determination and preparing its contents.
NOTE: see my next comment specifically regarding the pointer access.
> I think we should at most export the speficic offset inside the buffer
> another compilation unit can fill out. In that case with the
> iosys_buf API we would return a shallow copy of our guc->ads_map +
> offset.
>
> And the other alternative would be as you suggested: save the list in a
> temporary buffer and when needed call intel_guc_ads() to populate that
> into ads in the right place.
>
Alan: The first part of above is already
Re: [Intel-gfx] [PATCH 04/21] fbcon: delete a few unneeded forward decl
On Mon, Jan 31, 2022 at 10:05:35PM +0100, Daniel Vetter wrote: > I didn't bother with any code movement to fix the others, these just > got a bit in the way. > > Signed-off-by: Daniel Vetter > Cc: Helge Deller > Cc: Daniel Vetter > Cc: Thomas Zimmermann > Cc: Du Cheng > Cc: Tetsuo Handa > Cc: Claudio Suarez > Cc: Greg Kroah-Hartman Acked-by: Sam Ravnborg
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add fallback inside memcpy_from_wc functions
== Series Details == Series: drm/i915: Add fallback inside memcpy_from_wc functions URL : https://patchwork.freedesktop.org/series/99675/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11185_full -> Patchwork_22170_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22170_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22170_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22170_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock@vma: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/shard-skl6/igt@i915_selftest@m...@vma.html * igt@kms_flip@flip-vs-fences-interruptible@a-vga1: - shard-snb: [PASS][2] -> [DMESG-FAIL][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-snb6/igt@kms_flip@flip-vs-fences-interrupti...@a-vga1.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/shard-snb6/igt@kms_flip@flip-vs-fences-interrupti...@a-vga1.html * igt@kms_flip@flip-vs-fences-interruptible@b-vga1: - shard-snb: [PASS][4] -> [INCOMPLETE][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-snb6/igt@kms_flip@flip-vs-fences-interrupti...@b-vga1.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/shard-snb6/igt@kms_flip@flip-vs-fences-interrupti...@b-vga1.html Known issues Here are the changes found in Patchwork_22170_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30]) -> ([PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [FAIL][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55]) ([i915#4392]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk9/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk8/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk8/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk7/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk4/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk3/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk3/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk2/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/shard-glk1/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/shard-glk9/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/shard-glk1/boot.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Use drm_clflush* instead of clflush (rev3)
== Series Details == Series: Use drm_clflush* instead of clflush (rev3) URL : https://patchwork.freedesktop.org/series/99450/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Use drm_clflush* instead of clflush (rev3)
== Series Details == Series: Use drm_clflush* instead of clflush (rev3) URL : https://patchwork.freedesktop.org/series/99450/ State : warning == Summary == $ dim checkpatch origin/drm-tip f5dee7fefc3b drm/i915/gt: Re-work intel_write_status_page 71ea7ccbe1e3 drm/i915/gt: Drop invalidate_csb_entries -:49: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #49: FILE: drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2781: + drm_clflush_virt_range(>csb_status[0], + sizeof(>csb_status[reset_value])); -:49: WARNING:SIZEOF_ADDRESS: sizeof(& should be avoided #49: FILE: drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2781: + sizeof(>csb_status[reset_value])); total: 0 errors, 1 warnings, 1 checks, 30 lines checked 0e3e2dcb944a drm/i915/gt: Re-work reset_csb -:28: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #28: FILE: drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2948: + drm_clflush_virt_range(execlists->csb_write, + sizeof(execlists->csb_write)); total: 0 errors, 0 warnings, 1 checks, 11 lines checked 0314edfdf5da drm/i915/: Re-work clflush_write32
Re: [Intel-gfx] [PATCH v5 01/10] drm/i915/guc: Update GuC ADS size for error capture lists
On Thu, Feb 03, 2022 at 11:03:24AM -0800, Matthew Brost wrote:
On Wed, Jan 26, 2022 at 02:46:19PM -0800, Lucas De Marchi wrote:
On Wed, Jan 26, 2022 at 02:48:13AM -0800, Alan Previn wrote:
> Update GuC ADS size allocation to include space for
> the lists of error state capture register descriptors.
>
> Also, populate the lists of registers we want GuC to report back to
> Host on engine reset events. This list should include global,
> engine-class and engine-instance registers for every engine-class
> type on the current hardware.
>
> NOTE: Start with a sample table of register lists to layout the
> framework before adding real registers in subsequent patch.
>
> Signed-off-by: Alan Previn
> ---
...
> static void __guc_ads_init(struct intel_guc *guc)
> {
>struct intel_gt *gt = guc_to_gt(guc);
> @@ -573,9 +553,9 @@ static void __guc_ads_init(struct intel_guc *guc)
>
>base = intel_guc_ggtt_offset(guc, guc->ads_vma);
>
> - /* Capture list for hang debug */
> - guc_capture_list_init(guc, blob);
> -
> + /* Lists for error capture debug */
> + intel_guc_capture_prep_lists(guc, (struct guc_ads *)blob, base,
no, please don't cast/export struct guc_ads like this. We can't really
dereference it since it may be in IO memory.
See https://patchwork.freedesktop.org/series/99378/ with the huge
refactor in this file to make it conform to the rules of accessing IO
memory.
Maybe this list could be appended in the same reglist buffer and we just
copy it once to its final location, like we are doing with the reglist?
Agree with Lucas here, let's create the capture list on probe and store
it somewhere in the device data. On ADS population this more or less
turns into a memcpy (or after Lucas's series a dma-buf-map call). And on
fini, just free to stored data. The create capture list IMO is fine to
be done in an external file and return the data to the ADS code but
let's make sure everyone is on board with that. Maybe ping Lucas
directly about this?
yeah, sounds good to me. My worry is exporting ADS struct layout to
other compilation units. Asking for the entire ads blob
(or what would be dma_buf_map in my patches, or iosys_map in the new
version I will send soon) could quickly spread too much knowledge about it to
the rest of the driver.
I think we should at most export the speficic offset inside the buffer
another compilation unit can fill out. In that case with the
iosys_buf API we would return a shallow copy of our guc->ads_map +
offset.
And the other alternative would be as you suggested: save the list in a
temporary buffer and when needed call intel_guc_ads() to populate that
into ads in the right place.
The integration with iosys-map I can figure out if my patch series lands
after this one, or I can help rebasing this otherwise. But IMO we
should not pass the plain blob pointer around regardless of iosys-map.
thanks
Lucas De Marchi
Specific patch Lucas's is referencing:
https://patchwork.freedesktop.org/patch/471051/?series=99378=1
Matt
Lucas De Marchi
[Intel-gfx] [PATCH v4 4/4] drm/i915/: Re-work clflush_write32
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 498b458fd784..0854276ff7ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1332,10 +1332,8 @@ static void *reloc_vaddr(struct i915_vma *vma,
static void clflush_write32(u32 *addr, u32 value, unsigned int flushes)
{
if (unlikely(flushes & (CLFLUSH_BEFORE | CLFLUSH_AFTER))) {
- if (flushes & CLFLUSH_BEFORE) {
- clflushopt(addr);
- mb();
- }
+ if (flushes & CLFLUSH_BEFORE)
+ drm_clflush_virt_range(addr, sizeof(addr));
*addr = value;
@@ -1347,7 +1345,7 @@ static void clflush_write32(u32 *addr, u32 value,
unsigned int flushes)
* to ensure ordering of clflush wrt to the system.
*/
if (flushes & CLFLUSH_AFTER)
- clflushopt(addr);
+ drm_clflush_virt_range(addr, sizeof(addr));
} else
*addr = value;
}
--
2.25.1
[Intel-gfx] [PATCH v4 3/4] drm/i915/gt: Re-work reset_csb
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 7500c06562da..22505aa428d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2944,9 +2944,8 @@ reset_csb(struct intel_engine_cs *engine, struct
i915_request **inactive)
{
struct intel_engine_execlists * const execlists = >execlists;
- mb(); /* paranoia: read the CSB pointers from after the reset */
- clflush(execlists->csb_write);
- mb();
+ drm_clflush_virt_range(execlists->csb_write,
+ sizeof(execlists->csb_write));
inactive = process_csb(engine, inactive); /* drain preemption events */
--
2.25.1
[Intel-gfx] [PATCH v4 0/4] Use drm_clflush* instead of clflush
This patch series re-work a few i915 functions to use drm_clflush_virt_range instead of calling clflush or clflushopt directly. This will prevent errors when building for non-x86 architectures. v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added more patches to convert additional clflush/clflushopt to use drm_clflush*. (Michael Cheng) v3: Drop invalidate_csb_entries and directly invoke drm_clflush_virt_ran v4: Remove extra memory barriers Michael Cheng (4): drm/i915/gt: Re-work intel_write_status_page drm/i915/gt: Drop invalidate_csb_entries drm/i915/gt: Re-work reset_csb drm/i915/: Re-work clflush_write32 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++- drivers/gpu/drm/i915/gt/intel_engine.h | 13 - .../drm/i915/gt/intel_execlists_submission.c| 17 + 3 files changed, 12 insertions(+), 26 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH v4 2/4] drm/i915/gt: Drop invalidate_csb_entries
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range. Thanks to Tvrtko for the
sugguestion.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 9bb7c863172f..7500c06562da 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1646,12 +1646,6 @@ cancel_port_requests(struct intel_engine_execlists *
const execlists,
return inactive;
}
-static void invalidate_csb_entries(const u64 *first, const u64 *last)
-{
- clflush((void *)first);
- clflush((void *)last);
-}
-
/*
* Starting with Gen12, the status has a new format:
*
@@ -1999,7 +1993,7 @@ process_csb(struct intel_engine_cs *engine, struct
i915_request **inactive)
* the wash as hardware, working or not, will need to do the
* invalidation before.
*/
- invalidate_csb_entries([0], [num_entries - 1]);
+ drm_clflush_virt_range([0], num_entries * sizeof(buf[0]));
/*
* We assume that any event reflects a change in context flow
@@ -2783,8 +2777,8 @@ static void reset_csb_pointers(struct intel_engine_cs
*engine)
/* Check that the GPU does indeed update the CSB entries! */
memset(execlists->csb_status, -1, (reset_value + 1) * sizeof(u64));
- invalidate_csb_entries(>csb_status[0],
- >csb_status[reset_value]);
+ drm_clflush_virt_range(>csb_status[0],
+ sizeof(>csb_status[reset_value]));
/* Once more for luck and our trusty paranoia */
ENGINE_WRITE(engine, RING_CONTEXT_STATUS_PTR,
--
2.25.1
[Intel-gfx] [PATCH v4 1/4] drm/i915/gt: Re-work intel_write_status_page
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0e353d8c2bc8..986777c2430d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
#include
@@ -143,15 +144,9 @@ intel_write_status_page(struct intel_engine_cs *engine,
int reg, u32 value)
* of extra paranoia to try and ensure that the HWS takes the value
* we give and that it doesn't end up trapped inside the CPU!
*/
- if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
- mb();
- clflush(>status_page.addr[reg]);
- engine->status_page.addr[reg] = value;
- clflush(>status_page.addr[reg]);
- mb();
- } else {
- WRITE_ONCE(engine->status_page.addr[reg], value);
- }
+ drm_clflush_virt_range(>status_page.addr[reg], sizeof(value));
+ WRITE_ONCE(engine->status_page.addr[reg], value);
+ drm_clflush_virt_range(>status_page.addr[reg], sizeof(value));
}
/*
--
2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use a bitmask for bigjoiner state tracking
== Series Details == Series: drm/i915: Use a bitmask for bigjoiner state tracking URL : https://patchwork.freedesktop.org/series/99680/ State : success == Summary == CI Bug Log - changes from CI_DRM_11185 -> Patchwork_22171 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/index.html Participating hosts (49 -> 42) -- Missing(7): fi-kbl-soraka fi-bdw-5557u shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Known issues Here are the changes found in Patchwork_22171 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@hangcheck: - bat-dg1-6: NOTRUN -> [DMESG-FAIL][1] ([i915#4957]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html - bat-dg1-5: [PASS][2] -> [DMESG-FAIL][3] ([i915#4494] / [i915#4957]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#3303]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - fi-blb-e6850: [PASS][6] -> [DMESG-FAIL][7] ([i915#5026]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-blb-e6850/igt@i915_selftest@l...@requests.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/fi-blb-e6850/igt@i915_selftest@l...@requests.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: [PASS][8] -> [INCOMPLETE][9] ([i915#4838]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-skl-6600u/igt@kms_psr@primary_page_flip.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/fi-skl-6600u/igt@kms_psr@primary_page_flip.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#1436] / [i915#4312]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/fi-hsw-4770/igt@run...@aborted.html - fi-blb-e6850: NOTRUN -> [FAIL][11] ([fdo#109271] / [i915#2403] / [i915#2426] / [i915#4312]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/fi-blb-e6850/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@gt_engines: - bat-dg1-6: [INCOMPLETE][12] ([i915#4418]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/bat-dg1-6/igt@i915_selftest@live@gt_engines.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/bat-dg1-6/igt@i915_selftest@live@gt_engines.html * igt@i915_selftest@live@gt_heartbeat: - fi-skl-6700k2: [DMESG-FAIL][14] ([i915#2291] / [i915#541]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-tgl-1115g4: [DMESG-FAIL][16] ([i915#3987]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html * igt@kms_force_connector_basic@prune-stale-modes: - fi-cfl-8109u: [DMESG-WARN][18] ([i915#295]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22171/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295 [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303 [i915#3987]: https://gitlab.freedesktop.org/drm/intel/issues/3987 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418 [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494 [i915#4838]: https://gitlab.freedesktop.org/drm/intel/issues/4838 [i915#4957]:
Re: [Intel-gfx] [PATCH v5 09/10] drm/i915/guc: Follow legacy register names
On Wed, Jan 26, 2022 at 02:48:21AM -0800, Alan Previn wrote:
> Before we print the GuC provided register dumps, modify the
> register tables to use string names as per the legacy error
> capture execlist codes.
>
> Signed-off-by: Alan Previn
I'd just squash this to the patches early in the series where these are
initially defined.
Matt
> ---
> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 70 +--
> 1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index 2f5dc413dddc..506496058daf 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -22,7 +22,7 @@
> * from the engine-mmio-base
> */
> #define COMMON_BASE_GLOBAL() \
> - {FORCEWAKE_MT, 0, 0, "FORCEWAKE_MT"}
> + {FORCEWAKE_MT, 0, 0, "FORCEWAKE"}
>
> #define COMMON_GEN9BASE_GLOBAL() \
> {GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0"}, \
> @@ -34,43 +34,43 @@
> #define COMMON_GEN12BASE_GLOBAL() \
> {GEN12_FAULT_TLB_DATA0,0, 0, "GEN12_FAULT_TLB_DATA0"}, \
> {GEN12_FAULT_TLB_DATA1,0, 0, "GEN12_FAULT_TLB_DATA1"}, \
> - {GEN12_AUX_ERR_DBG,0, 0, "GEN12_AUX_ERR_DBG"}, \
> - {GEN12_GAM_DONE, 0, 0, "GEN12_GAM_DONE"}, \
> - {GEN12_RING_FAULT_REG, 0, 0, "GEN12_RING_FAULT_REG"}
> + {GEN12_AUX_ERR_DBG,0, 0, "AUX_ERR_DBG"}, \
> + {GEN12_GAM_DONE, 0, 0, "GAM_DONE"}, \
> + {GEN12_RING_FAULT_REG, 0, 0, "FAULT_REG"}
>
> #define COMMON_BASE_ENGINE_INSTANCE() \
> - {RING_PSMI_CTL(0), 0, 0, "RING_PSMI_CTL"}, \
> - {RING_ESR(0), 0, 0, "RING_ESR"}, \
> - {RING_DMA_FADD(0), 0, 0, "RING_DMA_FADD_LOW32"}, \
> - {RING_DMA_FADD_UDW(0), 0, 0, "RING_DMA_FADD_UP32"}, \
> - {RING_IPEIR(0),0, 0, "RING_IPEIR"}, \
> - {RING_IPEHR(0),0, 0, "RING_IPEHR"}, \
> - {RING_INSTPS(0), 0, 0, "RING_INSTPS"}, \
> + {RING_PSMI_CTL(0), 0, 0, "RC PSMI"}, \
> + {RING_ESR(0), 0, 0, "ESR"}, \
> + {RING_DMA_FADD(0), 0, 0, "RING_DMA_FADD_LDW"}, \
> + {RING_DMA_FADD_UDW(0), 0, 0, "RING_DMA_FADD_UDW"}, \
> + {RING_IPEIR(0),0, 0, "IPEIR"}, \
> + {RING_IPEHR(0),0, 0, "IPEHR"}, \
> + {RING_INSTPS(0), 0, 0, "INSTPS"}, \
> {RING_BBADDR(0), 0, 0, "RING_BBADDR_LOW32"}, \
> {RING_BBADDR_UDW(0), 0, 0, "RING_BBADDR_UP32"}, \
> - {RING_BBSTATE(0), 0, 0, "RING_BBSTATE"}, \
> + {RING_BBSTATE(0), 0, 0, "BB_STATE"}, \
> {CCID(0), 0, 0, "CCID"}, \
> - {RING_ACTHD(0),0, 0, "RING_ACTHD_LOW32"}, \
> - {RING_ACTHD_UDW(0),0, 0, "RING_ACTHD_UP32"}, \
> - {RING_INSTPM(0), 0, 0, "RING_INSTPM"}, \
> + {RING_ACTHD(0),0, 0, "ACTHD_LDW"}, \
> + {RING_ACTHD_UDW(0),0, 0, "ACTHD_UDW"}, \
> + {RING_INSTPM(0), 0, 0, "INSTPM"}, \
> + {RING_INSTDONE(0), 0, 0, "INSTDONE"}, \
> {RING_NOPID(0),0, 0, "RING_NOPID"}, \
> - {RING_START(0),0, 0, "RING_START"}, \
> - {RING_HEAD(0), 0, 0, "RING_HEAD"}, \
> - {RING_TAIL(0), 0, 0, "RING_TAIL"}, \
> - {RING_CTL(0), 0, 0, "RING_CTL"}, \
> - {RING_MI_MODE(0), 0, 0, "RING_MI_MODE"}, \
> + {RING_START(0),0, 0, "START"}, \
> + {RING_HEAD(0), 0, 0, "HEAD"}, \
> + {RING_TAIL(0), 0, 0, "TAIL"}, \
> + {RING_CTL(0), 0, 0, "CTL"}, \
> + {RING_MI_MODE(0), 0, 0, "MODE"}, \
> {RING_CONTEXT_CONTROL(0), 0, 0, "RING_CONTEXT_CONTROL"}, \
> - {RING_INSTDONE(0), 0, 0, "RING_INSTDONE"}, \
> - {RING_HWS_PGA(0), 0, 0, "RING_HWS_PGA"}, \
> - {RING_MODE_GEN7(0),0, 0, "RING_MODE_GEN7"}, \
> - {GEN8_RING_PDP_LDW(0, 0), 0, 0, "GEN8_RING_PDP0_LDW"}, \
> - {GEN8_RING_PDP_UDW(0, 0), 0, 0, "GEN8_RING_PDP0_UDW"}, \
> - {GEN8_RING_PDP_LDW(0, 1), 0, 0, "GEN8_RING_PDP1_LDW"}, \
> - {GEN8_RING_PDP_UDW(0, 1), 0, 0, "GEN8_RING_PDP1_UDW"}, \
> - {GEN8_RING_PDP_LDW(0, 2), 0, 0, "GEN8_RING_PDP2_LDW"}, \
> - {GEN8_RING_PDP_UDW(0, 2), 0, 0, "GEN8_RING_PDP2_UDW"}, \
> - {GEN8_RING_PDP_LDW(0, 3), 0, 0, "GEN8_RING_PDP3_LDW"}, \
> - {GEN8_RING_PDP_UDW(0, 3), 0, 0, "GEN8_RING_PDP3_UDW"}
> + {RING_HWS_PGA(0), 0, 0, "HWS"}, \
> + {RING_MODE_GEN7(0),0, 0, "GFX_MODE"},
Re: [Intel-gfx] [PATCH v5 01/10] drm/i915/guc: Update GuC ADS size for error capture lists
On Wed, Jan 26, 2022 at 02:46:19PM -0800, Lucas De Marchi wrote:
> On Wed, Jan 26, 2022 at 02:48:13AM -0800, Alan Previn wrote:
> > Update GuC ADS size allocation to include space for
> > the lists of error state capture register descriptors.
> >
> > Also, populate the lists of registers we want GuC to report back to
> > Host on engine reset events. This list should include global,
> > engine-class and engine-instance registers for every engine-class
> > type on the current hardware.
> >
> > NOTE: Start with a sample table of register lists to layout the
> > framework before adding real registers in subsequent patch.
> >
> > Signed-off-by: Alan Previn
> > ---
>
> ...
>
> > static void __guc_ads_init(struct intel_guc *guc)
> > {
> > struct intel_gt *gt = guc_to_gt(guc);
> > @@ -573,9 +553,9 @@ static void __guc_ads_init(struct intel_guc *guc)
> >
> > base = intel_guc_ggtt_offset(guc, guc->ads_vma);
> >
> > - /* Capture list for hang debug */
> > - guc_capture_list_init(guc, blob);
> > -
> > + /* Lists for error capture debug */
> > + intel_guc_capture_prep_lists(guc, (struct guc_ads *)blob, base,
>
> no, please don't cast/export struct guc_ads like this. We can't really
> dereference it since it may be in IO memory.
>
> See https://patchwork.freedesktop.org/series/99378/ with the huge
> refactor in this file to make it conform to the rules of accessing IO
> memory.
>
> Maybe this list could be appended in the same reglist buffer and we just
> copy it once to its final location, like we are doing with the reglist?
>
Agree with Lucas here, let's create the capture list on probe and store
it somewhere in the device data. On ADS population this more or less
turns into a memcpy (or after Lucas's series a dma-buf-map call). And on
fini, just free to stored data. The create capture list IMO is fine to
be done in an external file and return the data to the ADS code but
let's make sure everyone is on board with that. Maybe ping Lucas
directly about this?
Specific patch Lucas's is referencing:
https://patchwork.freedesktop.org/patch/471051/?series=99378=1
Matt
> Lucas De Marchi
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Use a bitmask for bigjoiner state tracking
== Series Details == Series: drm/i915: Use a bitmask for bigjoiner state tracking URL : https://patchwork.freedesktop.org/series/99680/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use a bitmask for bigjoiner state tracking
== Series Details ==
Series: drm/i915: Use a bitmask for bigjoiner state tracking
URL : https://patchwork.freedesktop.org/series/99680/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9451ce773538 drm/i915: Flag crtc scaling_filter changes as modeset
a1b2697d7287 drm/i915: Fix bigjoiner state copy fails
30f3289be9ea drm/i915: Remove weird code from intel_atomic_check_bigjoiner()
eb369188b6f9 drm/i915: Clean up the bigjoiner state copy logic
b8c9664a64ec drm/i915: Nuke some dead code
c7593cfe9487 drm/i915: Introduce intel_crtc_is_bigjoiner_{slave, master}()
-:46: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#46:
+ intel_crtc_is_bigjoiner_slave(S) ? E1 : intel_crtc_is_bigjoiner_master(S) ?
E2 : E3
total: 0 errors, 1 warnings, 0 checks, 222 lines checked
530e8b8b8894 drm/i915: Convert for_each_intel_crtc_mask() to take a pipe mask
instead
-:31: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#31: FILE: drivers/gpu/drm/i915/display/intel_display.h:433:
+#define for_each_intel_crtc_in_pipe_mask(dev, intel_crtc, pipe_mask) \
list_for_each_entry(intel_crtc, \
&(dev)->mode_config.crtc_list, \
base.head) \
+ for_each_if((pipe_mask) & BIT(intel_crtc->pipe))
-:31: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_crtc' - possible
side-effects?
#31: FILE: drivers/gpu/drm/i915/display/intel_display.h:433:
+#define for_each_intel_crtc_in_pipe_mask(dev, intel_crtc, pipe_mask) \
list_for_each_entry(intel_crtc, \
&(dev)->mode_config.crtc_list, \
base.head) \
+ for_each_if((pipe_mask) & BIT(intel_crtc->pipe))
total: 1 errors, 0 warnings, 1 checks, 139 lines checked
d5dfb430dc97 drm/i915: Use for_each_intel_crtc_in_pipe_mask() more
2a5f134f4a89 drm/i915: Return both master and slave pipes from
enabled_bigjoiner_pipes()
e91cede7c36e drm/i915: Change bigjoiner state tracking to use the pipe bitmask
-:528: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#528: FILE: drivers/gpu/drm/i915/display/intel_display.c:10510:
+
intel_crtc_bigjoiner_slave_pipes(crtc_state)) {
-:531: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#531: FILE: drivers/gpu/drm/i915/display/intel_display.c:10513:
+ slave_crtc_state =
to_intel_crtc_state(slave_crtc->base.state);
total: 0 errors, 2 warnings, 0 checks, 597 lines checked
[Intel-gfx] [PATCH 10/10] drm/i915: Change bigjoiner state tracking to use the pipe bitmask
From: Ville Syrjälä
Get rid of the inflexible bigjoiner_linked_crtc pointer thing
and just track things as a bitmask of pipes instead. We can
also nuke the bigjoiner_slave boolean as the role of the pipe
can be determined from its position in the bitmask.
It might be possible to nuke the bigjoiner boolean as well
if we make encoder.compute_config() do the bitmask assignment
directly for the master pipe. But for now I left that alone so
that encoer.compute_config() will just flag the state as needing
bigjoiner, and the intel_atomic_check_bigjoiner() is still
responsible for determining the bitmask. But that may have to change
as the encoder may be in the best position to determine how
exactly we should populate the bitmask.
Most places that just looked at the single bigjoiner_linked_crtc
now iterate over the whole bitmask, eliminating the singular
slave pipe assumption.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 5 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 12 +-
drivers/gpu/drm/i915/display/intel_display.c | 305 --
drivers/gpu/drm/i915/display/intel_display.h | 2 +
.../drm/i915/display/intel_display_debugfs.c | 5 +-
.../drm/i915/display/intel_display_types.h| 7 +-
.../drm/i915/display/intel_plane_initial.c| 7 -
drivers/gpu/drm/i915/display/intel_vdsc.c | 43 ---
drivers/gpu/drm/i915/display/intel_vdsc.h | 1 -
9 files changed, 227 insertions(+), 160 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 41d52889dfce..0e15fe908855 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -404,9 +404,10 @@ int intel_plane_atomic_check(struct intel_atomic_state
*state,
intel_atomic_get_new_crtc_state(state, crtc);
if (new_crtc_state && intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
+ struct intel_crtc *master_crtc =
+ intel_master_crtc(new_crtc_state);
struct intel_plane *master_plane =
-
intel_crtc_get_plane(new_crtc_state->bigjoiner_linked_crtc,
-plane->id);
+ intel_crtc_get_plane(master_crtc, plane->id);
new_master_plane_state =
intel_atomic_get_new_plane_state(state, master_plane);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3f0e1e127595..9dee12986991 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2703,6 +2703,7 @@ static void intel_ddi_post_disable(struct
intel_atomic_state *state,
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
bool is_tc_port = intel_phy_is_tc(dev_priv, phy);
+ struct intel_crtc *slave_crtc;
if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
intel_crtc_vblank_off(old_crtc_state);
@@ -2721,9 +2722,8 @@ static void intel_ddi_post_disable(struct
intel_atomic_state *state,
ilk_pfit_disable(old_crtc_state);
}
- if (old_crtc_state->bigjoiner_linked_crtc) {
- struct intel_crtc *slave_crtc =
- old_crtc_state->bigjoiner_linked_crtc;
+ for_each_intel_crtc_in_pipe_mask(_priv->drm, slave_crtc,
+
intel_crtc_bigjoiner_slave_pipes(old_crtc_state)) {
const struct intel_crtc_state *old_slave_crtc_state =
intel_atomic_get_old_crtc_state(state, slave_crtc);
@@ -3041,6 +3041,7 @@ intel_ddi_update_prepare(struct intel_atomic_state *state,
struct intel_encoder *encoder,
struct intel_crtc *crtc)
{
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_crtc_state *crtc_state =
crtc ? intel_atomic_get_new_crtc_state(state, crtc) : NULL;
int required_lanes = crtc_state ? crtc_state->lane_count : 1;
@@ -3050,11 +3051,12 @@ intel_ddi_update_prepare(struct intel_atomic_state
*state,
intel_tc_port_get_link(enc_to_dig_port(encoder),
required_lanes);
if (crtc_state && crtc_state->hw.active) {
- struct intel_crtc *slave_crtc =
crtc_state->bigjoiner_linked_crtc;
+ struct intel_crtc *slave_crtc;
intel_update_active_dpll(state, crtc, encoder);
- if (slave_crtc)
+ for_each_intel_crtc_in_pipe_mask(>drm, slave_crtc,
+
intel_crtc_bigjoiner_slave_pipes(crtc_state))
intel_update_active_dpll(state, slave_crtc, encoder);
}
}
diff --git
[Intel-gfx] [PATCH 09/10] drm/i915: Return both master and slave pipes from enabled_bigjoiner_pipes()
From: Ville Syrjälä
Return both the master and slave pipe bitmasks from
enabled_bigjoiner_pipes(). We'll have use for both during
readout soon.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 25 +++-
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6df498fc720a..34b6b4ab3a1b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4064,11 +4064,14 @@ static bool transcoder_ddi_func_is_enabled(struct
drm_i915_private *dev_priv,
return tmp & TRANS_DDI_FUNC_ENABLE;
}
-static u8 enabled_bigjoiner_pipes(struct drm_i915_private *dev_priv)
+static void enabled_bigjoiner_pipes(struct drm_i915_private *dev_priv,
+ u8 *master_pipes, u8 *slave_pipes)
{
- u8 master_pipes = 0, slave_pipes = 0;
struct intel_crtc *crtc;
+ *master_pipes = 0;
+ *slave_pipes = 0;
+
for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc,
bigjoiner_pipes(dev_priv)) {
enum intel_display_power_domain power_domain;
@@ -4083,9 +4086,9 @@ static u8 enabled_bigjoiner_pipes(struct drm_i915_private
*dev_priv)
continue;
if (tmp & MASTER_BIG_JOINER_ENABLE)
- master_pipes |= BIT(pipe);
+ *master_pipes |= BIT(pipe);
else
- slave_pipes |= BIT(pipe);
+ *slave_pipes |= BIT(pipe);
}
if (DISPLAY_VER(dev_priv) < 13)
@@ -4096,18 +4099,16 @@ static u8 enabled_bigjoiner_pipes(struct
drm_i915_private *dev_priv)
u32 tmp = intel_de_read(dev_priv,
ICL_PIPE_DSS_CTL1(pipe));
if (tmp & UNCOMPRESSED_JOINER_MASTER)
- master_pipes |= BIT(pipe);
+ *master_pipes |= BIT(pipe);
if (tmp & UNCOMPRESSED_JOINER_SLAVE)
- slave_pipes |= BIT(pipe);
+ *slave_pipes |= BIT(pipe);
}
}
/* Bigjoiner pipes should always be consecutive master and slave */
- drm_WARN(_priv->drm, slave_pipes != master_pipes << 1,
+ drm_WARN(_priv->drm, *slave_pipes != *master_pipes << 1,
"Bigjoiner misconfigured (master pipes 0x%x, slave pipes
0x%x)\n",
-master_pipes, slave_pipes);
-
- return slave_pipes;
+*master_pipes, *slave_pipes);
}
static u8 hsw_panel_transcoders(struct drm_i915_private *i915)
@@ -4126,6 +4127,7 @@ static u8 hsw_enabled_transcoders(struct intel_crtc *crtc)
struct drm_i915_private *dev_priv = to_i915(dev);
u8 panel_transcoder_mask = hsw_panel_transcoders(dev_priv);
enum transcoder cpu_transcoder;
+ u8 master_pipes, slave_pipes;
u8 enabled_transcoders = 0;
/*
@@ -4177,7 +4179,8 @@ static u8 hsw_enabled_transcoders(struct intel_crtc *crtc)
enabled_transcoders |= BIT(cpu_transcoder);
/* bigjoiner slave -> consider the master pipe's transcoder as well */
- if (enabled_bigjoiner_pipes(dev_priv) & BIT(crtc->pipe)) {
+ enabled_bigjoiner_pipes(dev_priv, _pipes, _pipes);
+ if (slave_pipes & BIT(crtc->pipe)) {
cpu_transcoder = (enum transcoder) crtc->pipe - 1;
if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
enabled_transcoders |= BIT(cpu_transcoder);
--
2.34.1
[Intel-gfx] [PATCH 08/10] drm/i915: Use for_each_intel_crtc_in_pipe_mask() more
From: Ville Syrjälä
Convert a few hand roller for_each_intel_crtc_in_pipe_mask()
to the real thing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 9a7f40d17b79..6df498fc720a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4069,14 +4069,12 @@ static u8 enabled_bigjoiner_pipes(struct
drm_i915_private *dev_priv)
u8 master_pipes = 0, slave_pipes = 0;
struct intel_crtc *crtc;
- for_each_intel_crtc(_priv->drm, crtc) {
+ for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc,
+bigjoiner_pipes(dev_priv)) {
enum intel_display_power_domain power_domain;
enum pipe pipe = crtc->pipe;
intel_wakeref_t wakeref;
- if ((bigjoiner_pipes(dev_priv) & BIT(pipe)) == 0)
- continue;
-
power_domain = intel_dsc_power_domain(crtc, (enum transcoder)
pipe);
with_intel_display_power_if_enabled(dev_priv, power_domain,
wakeref) {
u32 tmp = intel_de_read(dev_priv,
ICL_PIPE_DSS_CTL1(pipe));
@@ -8993,10 +8991,8 @@ static u32 intel_encoder_possible_crtcs(struct
intel_encoder *encoder)
struct intel_crtc *crtc;
u32 possible_crtcs = 0;
- for_each_intel_crtc(dev, crtc) {
- if (encoder->pipe_mask & BIT(crtc->pipe))
- possible_crtcs |= drm_crtc_mask(>base);
- }
+ for_each_intel_crtc_in_pipe_mask(dev, crtc, encoder->pipe_mask)
+ possible_crtcs |= drm_crtc_mask(>base);
return possible_crtcs;
}
--
2.34.1
[Intel-gfx] [PATCH 07/10] drm/i915: Convert for_each_intel_crtc_mask() to take a pipe mask instead
From: Ville Syrjälä
Often using pipes is more convenient than crtc indices.
Convert the current for_each_intel_crtc_mask() to take a
pipe mask instead of a crtc index mask, and rename it to
for_each_intel_crtc_in_pipe_mask() to make it clear what
it does.
The current users of for_each_intel_crtc_mask() don't really
care which kind of mask we use, but for other uses a pipe
mask if better.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.h | 4 +--
drivers/gpu/drm/i915/display/intel_dp.c | 34 ++--
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 22e5f0d6e171..fe9eb3acee65 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -430,11 +430,11 @@ enum hpd_pin {
&(dev)->mode_config.crtc_list, \
base.head)
-#define for_each_intel_crtc_mask(dev, intel_crtc, crtc_mask) \
+#define for_each_intel_crtc_in_pipe_mask(dev, intel_crtc, pipe_mask) \
list_for_each_entry(intel_crtc, \
&(dev)->mode_config.crtc_list, \
base.head) \
- for_each_if((crtc_mask) & drm_crtc_mask(_crtc->base))
+ for_each_if((pipe_mask) & BIT(intel_crtc->pipe))
#define for_each_intel_encoder(dev, intel_encoder) \
list_for_each_entry(intel_encoder, \
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 146b83916005..3fb9f643ebb9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3810,14 +3810,14 @@ static bool intel_dp_has_connector(struct intel_dp
*intel_dp,
static int intel_dp_prep_link_retrain(struct intel_dp *intel_dp,
struct drm_modeset_acquire_ctx *ctx,
- u32 *crtc_mask)
+ u8 *pipe_mask)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct drm_connector_list_iter conn_iter;
struct intel_connector *connector;
int ret = 0;
- *crtc_mask = 0;
+ *pipe_mask = 0;
if (!intel_dp_needs_link_retrain(intel_dp))
return 0;
@@ -3851,12 +3851,12 @@ static int intel_dp_prep_link_retrain(struct intel_dp
*intel_dp,
!try_wait_for_completion(_state->commit->hw_done))
continue;
- *crtc_mask |= drm_crtc_mask(>base);
+ *pipe_mask |= BIT(crtc->pipe);
}
drm_connector_list_iter_end(_iter);
if (!intel_dp_needs_link_retrain(intel_dp))
- *crtc_mask = 0;
+ *pipe_mask = 0;
return ret;
}
@@ -3875,7 +3875,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_crtc *crtc;
- u32 crtc_mask;
+ u8 pipe_mask;
int ret;
if (!intel_dp_is_connected(intel_dp))
@@ -3886,17 +3886,17 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
if (ret)
return ret;
- ret = intel_dp_prep_link_retrain(intel_dp, ctx, _mask);
+ ret = intel_dp_prep_link_retrain(intel_dp, ctx, _mask);
if (ret)
return ret;
- if (crtc_mask == 0)
+ if (pipe_mask == 0)
return 0;
drm_dbg_kms(_priv->drm, "[ENCODER:%d:%s] retraining link\n",
encoder->base.base.id, encoder->base.name);
- for_each_intel_crtc_mask(_priv->drm, crtc, crtc_mask) {
+ for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc, pipe_mask) {
const struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
@@ -3907,7 +3907,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
intel_crtc_pch_transcoder(crtc), false);
}
- for_each_intel_crtc_mask(_priv->drm, crtc, crtc_mask) {
+ for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc, pipe_mask) {
const struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
@@ -3924,7 +3924,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
break;
}
- for_each_intel_crtc_mask(_priv->drm, crtc, crtc_mask) {
+ for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc, pipe_mask) {
const struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
@@ -3942,14
[Intel-gfx] [PATCH 03/10] drm/i915: Remove weird code from intel_atomic_check_bigjoiner()
From: Ville Syrjälä
There's some weird junk in intel_atomic_check_bigjoiner()
that's trying to look at the old crtc state's bigjoiner
usage for some reason. That code is totally unnecessary,
and maybe even actively harmful. Not entirely sure which
since it's such a mess that I can't actually wrap my brain
around what it ends up doing.
Either way, thanks to intel_bigjoiner_add_affected_crtcs()
all of the old bigjoiner crtcs are guaranteed to be in the
state already if any one of them is in the state. Also if
any one of those crtcs got flagged for a modeset, then all
of them will have been flagged, and the bigjoiner links
will have been detached via kill_bigjoiner_slave().
So there is no need to look examing any old bigjoiner
usage in intel_atomic_check_bigjoiner(). All we have to care
about is whether bigjoiner is needed for the new state,
and whether we can get the slave crtc we need.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 33 +++-
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2006eec6e166..b5701ca57889 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7584,38 +7584,28 @@ static bool intel_cpu_transcoders_need_modeset(struct
intel_atomic_state *state,
}
static int intel_atomic_check_bigjoiner(struct intel_atomic_state *state,
- struct intel_crtc *crtc,
- struct intel_crtc_state *old_crtc_state,
- struct intel_crtc_state *new_crtc_state)
+ struct intel_crtc *master_crtc)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
- struct intel_crtc_state *slave_crtc_state, *master_crtc_state;
- struct intel_crtc *slave_crtc, *master_crtc;
+ struct intel_crtc_state *master_crtc_state =
+ intel_atomic_get_new_crtc_state(state, master_crtc);
+ struct intel_crtc_state *slave_crtc_state;
+ struct intel_crtc *slave_crtc;
- /* slave being enabled, is master is still claiming this crtc? */
- if (old_crtc_state->bigjoiner_slave) {
- slave_crtc = crtc;
- master_crtc = old_crtc_state->bigjoiner_linked_crtc;
- master_crtc_state = intel_atomic_get_new_crtc_state(state,
master_crtc);
- if (!master_crtc_state ||
!intel_crtc_needs_modeset(master_crtc_state))
- goto claimed;
- }
-
- if (!new_crtc_state->bigjoiner)
+ if (!master_crtc_state->bigjoiner)
return 0;
- slave_crtc = intel_dsc_get_bigjoiner_secondary(crtc);
+ slave_crtc = intel_dsc_get_bigjoiner_secondary(master_crtc);
if (!slave_crtc) {
drm_dbg_kms(>drm,
"[CRTC:%d:%s] Big joiner configuration requires "
"CRTC + 1 to be used, doesn't exist\n",
- crtc->base.base.id, crtc->base.name);
+ master_crtc->base.base.id, master_crtc->base.name);
return -EINVAL;
}
- new_crtc_state->bigjoiner_linked_crtc = slave_crtc;
+ master_crtc_state->bigjoiner_linked_crtc = slave_crtc;
slave_crtc_state = intel_atomic_get_crtc_state(>base,
slave_crtc);
- master_crtc = crtc;
if (IS_ERR(slave_crtc_state))
return PTR_ERR(slave_crtc_state);
@@ -7627,7 +7617,7 @@ static int intel_atomic_check_bigjoiner(struct
intel_atomic_state *state,
"[CRTC:%d:%s] Used as slave for big joiner\n",
slave_crtc->base.base.id, slave_crtc->base.name);
- return copy_bigjoiner_crtc_state(slave_crtc_state, new_crtc_state);
+ return copy_bigjoiner_crtc_state(slave_crtc_state, master_crtc_state);
claimed:
drm_dbg_kms(>drm,
@@ -7899,8 +7889,7 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
- ret = intel_atomic_check_bigjoiner(state, crtc, old_crtc_state,
- new_crtc_state);
+ ret = intel_atomic_check_bigjoiner(state, crtc);
if (ret)
goto fail;
}
--
2.34.1
[Intel-gfx] [PATCH 06/10] drm/i915: Introduce intel_crtc_is_bigjoiner_{slave, master}()
From: Ville Syrjälä
Introduce helpers to query whether the crtc is the slave/master
for bigjoiner. This decouples most places from the exact
state layout we use to track this relationship, allowing us
to change and extend it more easily.
Performed with cocci:
@@
expression S, E;
@@
(
S->bigjoiner_slave = E;
|
- S->bigjoiner_slave
+ intel_crtc_is_bigjoiner_slave(S)
)
@@
expression S, E;
@@
(
- E && S->bigjoiner && !intel_crtc_is_bigjoiner_slave(S)
+ E && intel_crtc_is_bigjoiner_master(S)
|
- S->bigjoiner && !intel_crtc_is_bigjoiner_slave(S)
+ intel_crtc_is_bigjoiner_master(S)
)
@@
expression S;
@@
- (intel_crtc_is_bigjoiner_master(S))
+ intel_crtc_is_bigjoiner_master(S)
@@
expression S, E1, E2, E3;
@@
- intel_crtc_is_bigjoiner_slave(S) ? E1 : S->bigjoiner ? E2 : E3
+ intel_crtc_is_bigjoiner_slave(S) ? E1 : intel_crtc_is_bigjoiner_master(S) ?
E2 : E3
@@
typedef bool;
@@
+ bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state)
+ {
+ return crtc_state->bigjoiner_slave;
+ }
+
intel_master_crtc(...) {...}
@@
typedef bool;
@@
+ bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state *crtc_state)
+ {
+ return crtc_state->bigjoiner && !crtc_state->bigjoiner_slave;
+ }
+
intel_master_crtc(...) {...}
@@
typedef bool;
identifier S;
@@
- bool is_trans_port_sync_mode(const struct intel_crtc_state *S);
+ bool is_trans_port_sync_mode(const struct intel_crtc_state *state);
+ bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state);
+ bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state
*crtc_state);
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 51 +++
drivers/gpu/drm/i915/display/intel_display.h | 2 +
.../drm/i915/display/intel_display_debugfs.c | 2 +-
drivers/gpu/drm/i915/display/intel_vdsc.c | 4 +-
6 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index bec02333bdeb..41d52889dfce 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -403,7 +403,7 @@ int intel_plane_atomic_check(struct intel_atomic_state
*state,
struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
- if (new_crtc_state && new_crtc_state->bigjoiner_slave) {
+ if (new_crtc_state && intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
struct intel_plane *master_plane =
intel_crtc_get_plane(new_crtc_state->bigjoiner_linked_crtc,
plane->id);
@@ -633,7 +633,7 @@ int intel_atomic_plane_check_clipping(struct
intel_plane_state *plane_state,
}
/* right side of the image is on the slave crtc, adjust dst to match */
- if (crtc_state->bigjoiner_slave)
+ if (intel_crtc_is_bigjoiner_slave(crtc_state))
drm_rect_translate(dst, -crtc_state->pipe_src_w, 0);
/*
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 354b08d6f81d..3f0e1e127595 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2926,7 +2926,7 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
{
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
- if (!crtc_state->bigjoiner_slave)
+ if (!intel_crtc_is_bigjoiner_slave(crtc_state))
intel_ddi_enable_transcoder_func(encoder, crtc_state);
intel_vrr_enable(encoder, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index d5dc2c25c1f6..9a7f40d17b79 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -337,9 +337,19 @@ is_trans_port_sync_mode(const struct intel_crtc_state
*crtc_state)
is_trans_port_sync_slave(crtc_state);
}
+bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state)
+{
+ return crtc_state->bigjoiner_slave;
+}
+
+bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state *crtc_state)
+{
+ return crtc_state->bigjoiner && !crtc_state->bigjoiner_slave;
+}
+
static struct intel_crtc *intel_master_crtc(const struct intel_crtc_state
*crtc_state)
{
- if (crtc_state->bigjoiner_slave)
+ if (intel_crtc_is_bigjoiner_slave(crtc_state))
return crtc_state->bigjoiner_linked_crtc;
else
return to_intel_crtc(crtc_state->uapi.crtc);
@@ -1979,13 +1989,13 @@ static void icl_ddi_bigjoiner_pre_enable(struct
intel_atomic_state *state,
/*
* Enable sequence steps 1-7 on bigjoiner master
[Intel-gfx] [PATCH 01/10] drm/i915: Flag crtc scaling_filter changes as modeset
From: Ville Syrjälä
The core doesn't flag scaling_filter prop changes as needing
a modeset. That doesn't work for us since we only reprogram the
pipe scaler during full modesets and fastsets. So we need to
flag the prop change as a modeset ourselves. Assuming nothing else
has changed the operation will get promoted (demoted?) to a fastset
later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index df347329d90e..85dce8a093d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7846,6 +7846,10 @@ static int intel_atomic_check(struct drm_device *dev,
new_crtc_state, i) {
if (new_crtc_state->inherited != old_crtc_state->inherited)
new_crtc_state->uapi.mode_changed = true;
+
+ if (new_crtc_state->uapi.scaling_filter !=
+ old_crtc_state->uapi.scaling_filter)
+ new_crtc_state->uapi.mode_changed = true;
}
intel_vrr_check_modeset(state);
--
2.34.1
[Intel-gfx] [PATCH 05/10] drm/i915: Nuke some dead code
From: Ville Syrjälä
Remove all the dead code from icl_ddi_bigjoiner_pre_enable().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 48869478efc2..d5dc2c25c1f6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1974,23 +1974,7 @@ static void hsw_set_frame_start_delay(const struct
intel_crtc_state *crtc_state)
static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state *state,
const struct intel_crtc_state
*crtc_state)
{
- struct intel_crtc_state *master_crtc_state;
- struct intel_crtc *master_crtc;
- struct drm_connector_state *conn_state;
- struct drm_connector *conn;
- struct intel_encoder *encoder = NULL;
- int i;
-
- master_crtc = intel_master_crtc(crtc_state);
- master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
-
- for_each_new_connector_in_state(>base, conn, conn_state, i) {
- if (conn_state->crtc != _crtc->base)
- continue;
-
- encoder = to_intel_encoder(conn_state->best_encoder);
- break;
- }
+ struct intel_crtc *master_crtc = intel_master_crtc(crtc_state);
/*
* Enable sequence steps 1-7 on bigjoiner master
--
2.34.1
[Intel-gfx] [PATCH 04/10] drm/i915: Clean up the bigjoiner state copy logic
From: Ville Syrjälä
Currently the bigjoiner state copy logic is kind of
a byzantine mess.
Clean it up to operate in the following manner during a full
modeset:
1) master uapi -> hw state copy
2) master hw -> slave hw state copy
And during a non-modeset update we do:
1) master uapi -> hw state light copy
2) master hw -> slave hw state light copy
I think that is now easier to reason about since we never do
any kind of master uapi -> slave hw state copy short circuit
that could happen previously.
Obviously this does now depend on the master uapi->hw copy
always happening before the master hw -> slave hw copy, but
that is guaranteed by the fact that we always add both crtcs
to the state early, the crtcs are registered in pipe
order (so the compute_config loop happens in pipe order),
and the hardware requires the master pipe has to be lower
than the slave pipe as well. And for good measure we shall
add a check+WARN for this before doing the bigjoiner crtc
assignment.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 11 --
drivers/gpu/drm/i915/display/intel_atomic.h | 2 -
drivers/gpu/drm/i915/display/intel_display.c | 170 ---
3 files changed, 108 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 093904065112..e0667d163266 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -281,17 +281,6 @@ void intel_crtc_free_hw_state(struct intel_crtc_state
*crtc_state)
intel_crtc_put_color_blobs(crtc_state);
}
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
-const struct intel_crtc_state *from_crtc_state)
-{
- drm_property_replace_blob(_state->hw.degamma_lut,
- from_crtc_state->uapi.degamma_lut);
- drm_property_replace_blob(_state->hw.gamma_lut,
- from_crtc_state->uapi.gamma_lut);
- drm_property_replace_blob(_state->hw.ctm,
- from_crtc_state->uapi.ctm);
-}
-
/**
* intel_crtc_destroy_state - destroy crtc state
* @crtc: drm crtc
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index d2700c74c9da..1dc439983dd9 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -44,8 +44,6 @@ struct drm_crtc_state *intel_crtc_duplicate_state(struct
drm_crtc *crtc);
void intel_crtc_destroy_state(struct drm_crtc *crtc,
struct drm_crtc_state *state);
void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
-const struct intel_crtc_state
*from_crtc_state);
struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
void intel_atomic_state_free(struct drm_atomic_state *state);
void intel_atomic_state_clear(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b5701ca57889..48869478efc2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5818,32 +5818,37 @@ static bool check_digital_port_conflicts(struct
intel_atomic_state *state)
static void
intel_crtc_copy_uapi_to_hw_state_nomodeset(struct intel_atomic_state *state,
- struct intel_crtc_state *crtc_state)
+ struct intel_crtc *crtc)
{
- const struct intel_crtc_state *master_crtc_state;
- struct intel_crtc *master_crtc;
+ struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
- master_crtc = intel_master_crtc(crtc_state);
- master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
+ WARN_ON(crtc_state->bigjoiner_slave);
- /* No need to copy state if the master state is unchanged */
- if (master_crtc_state) {
- crtc_state->uapi.color_mgmt_changed =
master_crtc_state->uapi.color_mgmt_changed;
- intel_crtc_copy_color_blobs(crtc_state, master_crtc_state);
- }
+ drm_property_replace_blob(_state->hw.degamma_lut,
+ crtc_state->uapi.degamma_lut);
+ drm_property_replace_blob(_state->hw.gamma_lut,
+ crtc_state->uapi.gamma_lut);
+ drm_property_replace_blob(_state->hw.ctm,
+ crtc_state->uapi.ctm);
}
static void
-intel_crtc_copy_uapi_to_hw_state(struct intel_atomic_state *state,
-struct intel_crtc_state *crtc_state)
+intel_crtc_copy_uapi_to_hw_state_modeset(struct intel_atomic_state *state,
+
[Intel-gfx] [PATCH 02/10] drm/i915: Fix bigjoiner state copy fails
From: Ville Syrjälä
We seem to be missing a few things from the bigjoiner state copy.
Namely hw.mode isn't getting copied (which probably causes PIPESRC
to be misconfigured), CTM/LUTs aren't getting copied (which could
cause the pipe to produced incorrect output), and we also forgot
to copy over the color_mgmt_changed flag so potentially we fail
to do the actual CTM/LUT programming (assuming we aren't doing
a full modeset or fastset). Fix it all.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 85dce8a093d4..2006eec6e166 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5827,8 +5827,10 @@ intel_crtc_copy_uapi_to_hw_state_nomodeset(struct
intel_atomic_state *state,
master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
/* No need to copy state if the master state is unchanged */
- if (master_crtc_state)
+ if (master_crtc_state) {
+ crtc_state->uapi.color_mgmt_changed =
master_crtc_state->uapi.color_mgmt_changed;
intel_crtc_copy_color_blobs(crtc_state, master_crtc_state);
+ }
}
static void
@@ -5890,13 +5892,23 @@ copy_bigjoiner_crtc_state(struct intel_crtc_state
*crtc_state,
memset(_state->hw, 0, sizeof(saved_state->hw));
crtc_state->hw.enable = from_crtc_state->hw.enable;
crtc_state->hw.active = from_crtc_state->hw.active;
+ crtc_state->hw.mode = from_crtc_state->hw.mode;
crtc_state->hw.pipe_mode = from_crtc_state->hw.pipe_mode;
crtc_state->hw.adjusted_mode = from_crtc_state->hw.adjusted_mode;
+ crtc_state->hw.scaling_filter = from_crtc_state->hw.scaling_filter;
+
+ drm_property_replace_blob(_state->hw.degamma_lut,
+ from_crtc_state->hw.degamma_lut);
+ drm_property_replace_blob(_state->hw.gamma_lut,
+ from_crtc_state->hw.gamma_lut);
+ drm_property_replace_blob(_state->uapi.ctm,
+ from_crtc_state->hw.ctm);
/* Some fixups */
crtc_state->uapi.mode_changed = from_crtc_state->uapi.mode_changed;
crtc_state->uapi.connectors_changed =
from_crtc_state->uapi.connectors_changed;
crtc_state->uapi.active_changed = from_crtc_state->uapi.active_changed;
+ crtc_state->uapi.color_mgmt_changed =
from_crtc_state->uapi.color_mgmt_changed;
crtc_state->nv12_planes = crtc_state->c8_planes =
crtc_state->update_planes = 0;
crtc_state->bigjoiner_linked_crtc =
to_intel_crtc(from_crtc_state->uapi.crtc);
crtc_state->bigjoiner_slave = true;
--
2.34.1
[Intel-gfx] [PATCH 00/10] drm/i915: Use a bitmask for bigjoiner state tracking
From: Ville Syrjälä
An attempt at making the bigjoiner state tracking both smaller and
more flexible for future needs. All we really need is a bitmask of
pipes.
I also managed to fix a bunch of issues with the state copy ...
I think. It's a bit hard to know for sure since I don't have
a DSC capably displauy so I'm just forcing the driver to spew
out DSC but obviously I can't actually see anything on the screen.
The next thing that needs fixing is the actual modset sequence
since it's still kinda terrible. Also not flexible enough for
those future needs. I'm thinking we need suck all the logic into
the encoder hooks, and let those iterate over the pipes at
approprite times. But that's for another time.
Pushed the lot here if someone wants to consume it easier:
git://github.com/vsyrjala/linux.git bigjoiner_pipe_bitmask
Ville Syrjälä (10):
drm/i915: Flag crtc scaling_filter changes as modeset
drm/i915: Fix bigjoiner state copy fails
drm/i915: Remove weird code from intel_atomic_check_bigjoiner()
drm/i915: Clean up the bigjoiner state copy logic
drm/i915: Nuke some dead code
drm/i915: Introduce intel_crtc_is_bigjoiner_{slave,master}()
drm/i915: Convert for_each_intel_crtc_mask() to take a pipe mask
instead
drm/i915: Use for_each_intel_crtc_in_pipe_mask() more
drm/i915: Return both master and slave pipes from
enabled_bigjoiner_pipes()
drm/i915: Change bigjoiner state tracking to use the pipe bitmask
drivers/gpu/drm/i915/display/intel_atomic.c | 11 -
drivers/gpu/drm/i915/display/intel_atomic.h | 2 -
.../gpu/drm/i915/display/intel_atomic_plane.c | 9 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 14 +-
drivers/gpu/drm/i915/display/intel_display.c | 522 --
drivers/gpu/drm/i915/display/intel_display.h | 8 +-
.../drm/i915/display/intel_display_debugfs.c | 7 +-
.../drm/i915/display/intel_display_types.h| 7 +-
drivers/gpu/drm/i915/display/intel_dp.c | 34 +-
.../drm/i915/display/intel_plane_initial.c| 7 -
drivers/gpu/drm/i915/display/intel_vdsc.c | 47 +-
drivers/gpu/drm/i915/display/intel_vdsc.h | 1 -
12 files changed, 385 insertions(+), 284 deletions(-)
--
2.34.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: split out function structs from i915_drv.h
== Series Details == Series: drm/i915: split out function structs from i915_drv.h URL : https://patchwork.freedesktop.org/series/99669/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11184_full -> Patchwork_22168_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22168_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22168_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (12 -> 12) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22168_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@guc_multi_lrc: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-skl6/igt@i915_selftest@live@guc_multi_lrc.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][2] -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-skl10/igt@i915_selftest@m...@requests.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-skl7/igt@i915_selftest@m...@requests.html Known issues Here are the changes found in Patchwork_22168_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@create-shared-gtt: - shard-glk: [PASS][4] -> [DMESG-WARN][5] ([i915#118]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-glk8/igt@gem_ctx_sha...@create-shared-gtt.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-glk1/igt@gem_ctx_sha...@create-shared-gtt.html * igt@gem_eio@in-flight-10ms: - shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#3063]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-tglb6/igt@gem_...@in-flight-10ms.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-tglb2/igt@gem_...@in-flight-10ms.html * igt@gem_eio@in-flight-immediate: - shard-skl: [PASS][8] -> [TIMEOUT][9] ([i915#3063]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-skl10/igt@gem_...@in-flight-immediate.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-skl7/igt@gem_...@in-flight-immediate.html * igt@gem_exec_balancer@parallel-contexts: - shard-iclb: [PASS][10] -> [SKIP][11] ([i915#4525]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-iclb7/igt@gem_exec_balan...@parallel-contexts.html * igt@gem_exec_capture@pi@rcs0: - shard-skl: NOTRUN -> [INCOMPLETE][12] ([i915#4547]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-skl8/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][13] ([i915#2846]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-kbl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2842]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html - shard-apl: [PASS][18] -> [FAIL][19] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-apl3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-iclb: NOTRUN -> [FAIL][20] ([i915#2842]) +4 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/shard-iclb8/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#2842]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [22]:
Re: [Intel-gfx] [PATCH 10/19] drm/i915: Convert the u64 power well domains mask to a bitmap
On Tue, Feb 01, 2022 at 01:20:50PM +0200, Jani Nikula wrote:
> On Fri, 28 Jan 2022, Imre Deak wrote:
> > To remove the aliasing of the power domain enum values in a follow-up
> > patch in this patchset (requiring a bigger mask) and allow for defining
> > additional power domains in the future (at least some upcoming TypeC
> > changes requires this) convert the u64 i915_power_well_desc::domains
> > mask to a bitmap.
> >
> > For simplicity I changed the for_each_power_domain_well() macros to
> > accept one domain only instead of a mask, as there isn't any current
> > user passing multiple domains.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 65 -
> > .../drm/i915/display/intel_display_power.c| 123 +++---
> > .../drm/i915/display/intel_display_power.h| 16 ++-
> > .../display/intel_display_power_internal.h| 2 +-
> > .../i915/display/intel_display_power_map.c| 4 +-
> > 5 files changed, 119 insertions(+), 91 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 3094cfc668c81..d0b9618383ce3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -2372,66 +2372,71 @@ intel_legacy_aux_to_power_domain(enum aux_ch aux_ch)
> > }
> > }
> >
> > -static u64 get_crtc_power_domains(struct intel_crtc_state *crtc_state)
> > +static void get_crtc_power_domains(struct intel_crtc_state *crtc_state,
> > + intel_power_domain_mask_t *mask)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > struct drm_encoder *encoder;
> > enum pipe pipe = crtc->pipe;
> > - u64 mask;
> > +
> > + bitmap_zero(mask->bits, POWER_DOMAIN_NUM);
> >
> > if (!crtc_state->hw.active)
> > - return 0;
> > + return;
> >
> > - mask = BIT_ULL(POWER_DOMAIN_PIPE(pipe));
> > - mask |= BIT_ULL(POWER_DOMAIN_TRANSCODER(cpu_transcoder));
> > + set_bit(POWER_DOMAIN_PIPE(pipe), mask->bits);
> > + set_bit(POWER_DOMAIN_TRANSCODER(cpu_transcoder), mask->bits);
> > if (crtc_state->pch_pfit.enabled ||
> > crtc_state->pch_pfit.force_thru)
> > - mask |= BIT_ULL(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe));
> > + set_bit(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe), mask->bits);
> >
> > drm_for_each_encoder_mask(encoder, _priv->drm,
> > crtc_state->uapi.encoder_mask) {
> > struct intel_encoder *intel_encoder = to_intel_encoder(encoder);
> >
> > - mask |= BIT_ULL(intel_encoder->power_domain);
> > + set_bit(intel_encoder->power_domain, mask->bits);
> > }
> >
> > if (HAS_DDI(dev_priv) && crtc_state->has_audio)
> > - mask |= BIT_ULL(POWER_DOMAIN_AUDIO_MMIO);
> > + set_bit(POWER_DOMAIN_AUDIO_MMIO, mask->bits);
> >
> > if (crtc_state->shared_dpll)
> > - mask |= BIT_ULL(POWER_DOMAIN_DISPLAY_CORE);
> > + set_bit(POWER_DOMAIN_DISPLAY_CORE, mask->bits);
> >
> > if (crtc_state->dsc.compression_enable)
> > - mask |= BIT_ULL(intel_dsc_power_domain(crtc, cpu_transcoder));
> > -
> > - return mask;
> > + set_bit(intel_dsc_power_domain(crtc, cpu_transcoder),
> > mask->bits);
> > }
> >
> > -static u64
> > -modeset_get_crtc_power_domains(struct intel_crtc_state *crtc_state)
> > +static void
> > +modeset_get_crtc_power_domains(struct intel_crtc_state *crtc_state,
> > + intel_power_domain_mask_t *old_domains)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > enum intel_display_power_domain domain;
> > - u64 domains, new_domains, old_domains;
> > + intel_power_domain_mask_t domains, new_domains;
> >
> > - domains = get_crtc_power_domains(crtc_state);
> > + get_crtc_power_domains(crtc_state, );
> >
> > - new_domains = domains & ~crtc->enabled_power_domains.mask;
> > - old_domains = crtc->enabled_power_domains.mask & ~domains;
> > + bitmap_andnot(new_domains.bits,
> > + domains.bits,
> > + crtc->enabled_power_domains.mask.bits,
> > + POWER_DOMAIN_NUM);
> > + bitmap_andnot(old_domains->bits,
> > + crtc->enabled_power_domains.mask.bits,
> > + domains.bits,
> > + POWER_DOMAIN_NUM);
> >
> > - for_each_power_domain(domain, new_domains)
> > + for_each_power_domain(domain, _domains)
> > intel_display_power_get_in_set(dev_priv,
> >>enabled_power_domains,
> >domain);
> > -
> > - return
Re: [Intel-gfx] [PATCH 09/19] drm/i915: Convert the power well descriptor domain mask to a list
On Tue, Feb 01, 2022 at 01:10:18PM +0200, Jani Nikula wrote:
> On Fri, 28 Jan 2022, Imre Deak wrote:
> > The next patch converts the i915_power_well_desc::domain mask from a u64
> > mask to a bitmap. I didn't find a reasonably simple way to initialize
> > bitmaps statically, so prepare for the next patch here by converting the
> > masks to a list and initing the masks from these lists during module
> > loading.
>
> I think "list" is a very specific thing in the kernel, and I find the
> list naming here confusing.
It's an array of enums, so can call it that way instead.
> I'll try to give the initialization thing some thought.
Just for reference, I tried
https://github.com/ideak/linux/commit/de8daa5362ce
but I didn't find it simple/generic/fast-to-compile enough.
There's also the planned
https://www.mail-archive.com/netdev@vger.kernel.org/msg402394.html
and
https://www.mail-archive.com/netdev@vger.kernel.org/msg402398.html
This one requires disabling some 'struct-field-reinited' warning, not
sure if it's getting merged or not.
--Imre
> BR,
> Jani.
>
> >
> > Signed-off-by: Imre Deak
> > ---
> > .../drm/i915/display/intel_display_power.c| 12 +-
> > .../display/intel_display_power_internal.h|6 +-
> > .../i915/display/intel_display_power_map.c| 1426 +
> > 3 files changed, 756 insertions(+), 688 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 69b75752258d9..a370ef8376410 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -40,11 +40,11 @@
> >
> > #define for_each_power_domain_well(__dev_priv, __power_well,
> > __domain_mask)\
> > for_each_power_well(__dev_priv, __power_well)
> > \
> > - for_each_if((__power_well)->desc->domains & (__domain_mask))
> > + for_each_if((__power_well)->domains & (__domain_mask))
> >
> > #define for_each_power_domain_well_reverse(__dev_priv, __power_well,
> > __domain_mask) \
> > for_each_power_well_reverse(__dev_priv, __power_well)
> > \
> > - for_each_if((__power_well)->desc->domains & (__domain_mask))
> > + for_each_if((__power_well)->domains & (__domain_mask))
> >
> > struct i915_power_well_regs {
> > i915_reg_t bios;
> > @@ -465,7 +465,7 @@ static u64 async_put_domains_mask(struct
> > i915_power_domains *power_domains);
> > static int power_well_async_ref_count(struct drm_i915_private *dev_priv,
> > struct i915_power_well *power_well)
> > {
> > - int refs = hweight64(power_well->desc->domains &
> > + int refs = hweight64(power_well->domains &
> > async_put_domains_mask(_priv->power_domains));
> >
> > drm_WARN_ON(_priv->drm, refs > power_well->count);
> > @@ -3805,7 +3805,7 @@ static void intel_power_domains_dump_info(struct
> > drm_i915_private *i915)
> > drm_dbg(>drm, "%-25s %d\n",
> > power_well->desc->name, power_well->count);
> >
> > - for_each_power_domain(domain, power_well->desc->domains)
> > + for_each_power_domain(domain, power_well->domains)
> > drm_dbg(>drm, " %-23s %d\n",
> > intel_display_power_domain_str(domain),
> > power_domains->domain_use_count[domain]);
> > @@ -3847,7 +3847,7 @@ static void intel_power_domains_verify_state(struct
> > drm_i915_private *i915)
> > power_well->count, enabled);
> >
> > domains_count = 0;
> > - for_each_power_domain(domain, power_well->desc->domains)
> > + for_each_power_domain(domain, power_well->domains)
> > domains_count +=
> > power_domains->domain_use_count[domain];
> >
> > if (power_well->count != domains_count) {
> > @@ -3962,7 +3962,7 @@ void intel_display_power_debug(struct
> > drm_i915_private *i915, struct seq_file *m
> > seq_printf(m, "%-25s %d\n", power_well->desc->name,
> >power_well->count);
> >
> > - for_each_power_domain(power_domain, power_well->desc->domains)
> > + for_each_power_domain(power_domain, power_well->domains)
> > seq_printf(m, " %-23s %d\n",
> >intel_display_power_domain_str(power_domain),
> >
> > power_domains->domain_use_count[power_domain]);
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> > b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> > index fd1abb64a8a47..49f6155e62c47 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> > @@ -16,7 +16,10 @@ struct
Re: [Intel-gfx] [PATCH 04/19] drm/i915: Move the power domain->well mappings to intel_display_power_map.c
On Tue, Feb 01, 2022 at 01:22:41PM +0200, Jani Nikula wrote:
> On Tue, 01 Feb 2022, Jani Nikula wrote:
> > On Mon, 31 Jan 2022, Imre Deak wrote:
> >> On Mon, Jan 31, 2022 at 02:15:25PM +0200, Jani Nikula wrote:
> >>> On Fri, 28 Jan 2022, Imre Deak wrote:
> >>> > Move the list of platform specific power domain -> power well
> >>> > definitions to intel_display_power_map.c. While at it group the
> >>> > platforms' power domain macros with the corresponding power well lists
> >>> > and keep all the power domain lists in the same order (matching the enum
> >>> > order).
> >>> >
> >>> > No functional changes.
> >>> >
> >>> > Signed-off-by: Imre Deak
> >>>
> >>> The commit message should explain the why.
> >>>
> >>> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> >>> > b/drivers/gpu/drm/i915/display/intel_display_power.h
> >>> > index b30e6133c66d0..a0e68ae691021 100644
> >>> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> >>> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> >>> > @@ -197,6 +197,7 @@ struct intel_display_power_domain_set {
> >>> > for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++)
> >>> > \
> >>> > for_each_if(BIT_ULL(domain) & (mask))
> >>> >
> >>> > +/* intel_display_power.c */
> >>> > int intel_power_domains_init(struct drm_i915_private *dev_priv);
> >>> > void intel_power_domains_cleanup(struct drm_i915_private *dev_priv);
> >>> > void intel_power_domains_init_hw(struct drm_i915_private *dev_priv,
> >>> > bool resume);
> >>> > @@ -316,4 +317,8 @@ void chv_phy_powergate_lanes(struct intel_encoder
> >>> > *encoder,
> >>> > bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum
> >>> > dpio_phy phy,
> >>> > enum dpio_channel ch, bool override);
> >>> >
> >>> > +/* intel_display_power_map.c */
> >>> > +const char *
> >>> > +intel_display_power_domain_str(enum intel_display_power_domain domain);
> >>> > +
> >>> > #endif /* __INTEL_DISPLAY_POWER_H__ */
> >>> > diff --git
> >>> > a/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> >>> > b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> >>> > new file mode 100644
> >>> > index 0..3fc7c7d0bc9e9
> >>> > --- /dev/null
> >>> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> >>> > @@ -0,0 +1,93 @@
> >>> > +/* SPDX-License-Identifier: MIT */
> >>> > +/*
> >>> > + * Copyright © 2022 Intel Corporation
> >>> > + */
> >>> > +
> >>> > +#ifndef __INTEL_DISPLAY_POWER_INTERNAL_H__
> >>> > +#define __INTEL_DISPLAY_POWER_INTERNAL_H__
> >>> > +
> >>> > +#include "i915_reg_defs.h"
> >>> > +
> >>> > +#include "intel_display.h"
> >>> > +#include "intel_display_power.h"
> >>> > +
> >>> > +struct i915_power_well_regs;
> >>> > +
> >>> > +/* Power well structure for haswell */
> >>> > +struct i915_power_well_desc {
> >>> > + const char *name;
> >>> > + bool always_on;
> >>> > + u64 domains;
> >>> > + /* unique identifier for this power well */
> >>> > + enum i915_power_well_id id;
> >>> > + /*
> >>> > +* Arbitraty data associated with this power well. Platform and
> >>> > power
> >>> > +* well specific.
> >>> > +*/
> >>> > + union {
> >>> > + struct {
> >>> > + /*
> >>> > +* request/status flag index in the PUNIT power
> >>> > well
> >>> > +* control/status registers.
> >>> > +*/
> >>> > + u8 idx;
> >>> > + } vlv;
> >>> > + struct {
> >>> > + enum dpio_phy phy;
> >>> > + } bxt;
> >>> > + struct {
> >>> > + /*
> >>> > +* request/status flag index in the power well
> >>> > +* constrol/status registers.
> >>> > +*/
> >>> > + u8 idx;
> >>> > + /* Mask of pipes whose IRQ logic is backed by
> >>> > the pw */
> >>> > + u8 irq_pipe_mask;
> >>> > + /*
> >>> > +* Instead of waiting for the status bit to ack
> >>> > enables,
> >>> > +* just wait a specific amount of time and then
> >>> > consider
> >>> > +* the well enabled.
> >>> > +*/
> >>> > + u16 fixed_enable_delay;
> >>> > + /* The pw is backing the VGA functionality */
> >>> > + bool has_vga:1;
> >>> > + bool has_fuses:1;
> >>> > + /*
> >>> > +* The pw is for an ICL+ TypeC PHY port in
> >>> > +* Thunderbolt mode.
> >>> > +*/
> >>> > + bool is_tc_tbt:1;
> >>> > + } hsw;
>
Re: [Intel-gfx] [PATCH] drm/i915: Flip guc_id allocation partition
On Wed, Feb 02, 2022 at 11:15:00PM +0100, Michal Wajdeczko wrote: > > > On 13.01.2022 17:27, Matthew Brost wrote: > > Move the multi-lrc guc_id from the lower allocation partition (0 to > > number of multi-lrc guc_ids) to upper allocation partition (number of > > single-lrc to max guc_ids). > > > > This will help when a native driver transitions to a PF after driver > > load time. If the perma-pin guc_ids (kernel contexts) are in a low range > > it is easy reduce total number of guc_ids as the allocated slrc are in a > > valid range the mlrc range moves to an unused range. Assuming no mlrc > > are allocated and few slrc are used the native to PF transition is > > seamless for the guc_id resource. > > > > v2: > > (Michal / Tvrtko) > > - Add an explaination to commit message of why this patch is needed > > (Michal / Piotr) > > - Replace marcos with functions > > (Michal) > > - Rework logic flow in new_mlrc_guc_id > > - Unconditionally call bitmap_free > > v3: > > (Michal) > > - Move allocation of mlrc bitmap back submission init > > (CI) > > - Resend for CI > > > > Signed-off-by: Matthew Brost > > --- > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 77 ++- > > 1 file changed, 56 insertions(+), 21 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c > > index 23a40f10d376d..fce58365b3ff8 100644 > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c > > @@ -138,17 +138,6 @@ guc_create_parallel(struct intel_engine_cs **engines, > > > > #define GUC_REQUEST_SIZE 64 /* bytes */ > > > > -/* > > - * We reserve 1/16 of the guc_ids for multi-lrc as these need to be > > contiguous > > - * per the GuC submission interface. A different allocation algorithm is > > used > > - * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to > > - * partition the guc_id space. We believe the number of multi-lrc contexts > > in > > - * use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids > > for > > - * multi-lrc. > > - */ > > -#define NUMBER_MULTI_LRC_GUC_ID(guc) \ > > - ((guc)->submission_state.num_guc_ids / 16) > > - > > /* > > * Below is a set of functions which control the GuC scheduling state which > > * require a lock. > > @@ -1746,6 +1735,7 @@ void intel_guc_submission_reset_finish(struct > > intel_guc *guc) > > } > > > > static void destroyed_worker_func(struct work_struct *w); > > +static int number_mlrc_guc_id(struct intel_guc *guc); > > > > /* > > * Set up the memory resources to be shared with the GuC (via the GGTT) > > @@ -1778,7 +1768,7 @@ int intel_guc_submission_init(struct intel_guc *guc) > > destroyed_worker_func); > > > > guc->submission_state.guc_ids_bitmap = > > - bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL); > > + bitmap_zalloc(number_mlrc_guc_id(guc), GFP_KERNEL); > > to fully benefit from the id partition flip we likely will have to > allocate bitmap 'just-in-time' when first mlrc id is needed > No. At worst over allocate memory and don't use it. At the current ratio, number_mlrc_guc_id is 4k translates into a 1 page allocation. > so something like you had in early rev but abandon to avoid alloc inside > spinlock - but I'm wondering why we can't alloc bitmap for mlrc case, > while we allow allocation for slrc (as ida_simple_get may alloc, no? > That is a good question, more on that below. > > if (!guc->submission_state.guc_ids_bitmap) > > return -ENOMEM; > > > > @@ -1864,6 +1854,57 @@ static void guc_submit_request(struct i915_request > > *rq) > > spin_unlock_irqrestore(_engine->lock, flags); > > } > > > > +/* > > + * We reserve 1/16 of the guc_ids for multi-lrc as these need to be > > contiguous > > + * per the GuC submission interface. A different allocation algorithm is > > used > > + * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to > > + * partition the guc_id space. We believe the number of multi-lrc contexts > > in > > + * use should be low and 1/16 should be sufficient. > > do we have any other numbers as guideline ? > > while it is easy assumption that 1/16 from 64K contexts may be > sufficient, what about 1/16 of 1K contexts ? will that work too ? > Nope, just random split I choose. We might need to change this ratio on a VF or enforce a minimum of mlrc (e.g. 128). Easy enough to tune as needed. > also, do we have to make hard split ? what if there will be no users for > mlrc but more slrc contexts would be beneficial ? or the opposite ? > Hard split manages complexity. Could we cook some dynamic sharing algorith, sure. Would be it be overly complex and unnecessary, almost certainly. The only thing I can see changing is the ratio on a VF if needed. > > + */ > > +#define MLRC_GUC_ID_RATIO 16 > > + > > +static int
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/dp, drm/i915: 128b/132b updates (rev2)
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev2)
URL : https://patchwork.freedesktop.org/series/99324/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11184_full -> Patchwork_22165_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22165_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22165_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (12 -> 12)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22165_full:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload-with-fault-injection:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-iclb5/igt@i915_module_l...@reload-with-fault-injection.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-iclb4/igt@i915_module_l...@reload-with-fault-injection.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_scaling_modes@scaling-mode-full:
- {shard-rkl}:NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-rkl-2/igt@kms_scaling_mo...@scaling-mode-full.html
Known issues
Here are the changes found in Patchwork_22165_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-iclb8/igt@gem_exec_balan...@parallel-contexts.html
* igt@gem_exec_capture@pi@rcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][6] ([i915#4547])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-skl8/igt@gem_exec_capture@p...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: NOTRUN -> [FAIL][7] ([i915#2846])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-kbl4/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) +5 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-iclb3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2190])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-skl1/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random:
- shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) +3
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-skl8/igt@gem_lmem_swapp...@parallel-random.html
* igt@gem_lmem_swapping@random:
- shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/shard-apl1/igt@gem_lmem_swapp...@random.html
- shard-kbl:
Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
> -Original Message- > From: dri-devel On Behalf Of Harry > Wentland > Sent: Wednesday, February 2, 2022 9:42 PM > To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: sebast...@sebastianwick.net; shashank.sha...@amd.com > Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features > > > > On 2021-09-06 17:38, Uma Shankar wrote: > > This is how a typical display color hardware pipeline looks like: > > +---+ > > |RAM| > > | +--++-++-+ | > > | | FB 1 || FB 2 || FB N| | > > | +--++-++-+ | > > +---+ > >| Plane Color Hardware Block | > > ++ > > | +---v-+ +---v---+ +---v--+ | > > | | Plane A | | Plane B | | Plane N | | > > | | DeGamma | | Degamma | | Degamma | | > > | +---+-+ +---+---+ +---+--+ | > > | | | || > > | +---v-+ +---v---+ +---v--+ | > > | |Plane A | | Plane B | | Plane N | | > > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > | +---v-+ +v--+ +v-+ | > > | | Plane A | | Plane B | | Plane N | | > > | | Gamma | | Gamma | | Gamma| | > > | +---+-+ ++--+ ++-+ | > > We've had a number of discussions on naming for these properties but I don't > think > we've arrived at a consensus. It has come up repeatedly, though, that > gamma/degamma might be misleading terms. > > I've opened a ticket on gitlab to help track this item and would like it if > we could > discuss the merits of different naming schemes over > there: > > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/7 > > Uma, I tried to tag you but don't see you on gitlab.freedesktop.org. Thanks Harry for creating the issue. I have replied there and we can discuss and finalize the UAPI. Regards, Uma Shankar > Harry > > > | | | | | > > ++ > > +--v--v---v---| > > || || > > || Pipe Blender|| > > +++ > > ||| > > |+---v--+ | > > || Pipe DeGamma| | > > || | | > > |+---+--+ | > > ||Pipe Color | > > |+---v--+ Hardware| > > || Pipe CSC/CTM| | > > || | | > > |+---+--+ | > > ||| > > |+---v--+ | > > || Pipe Gamma | | > > || | | > > |+---+--+ | > > ||| > > +-+ > > | > > v > >Pipe Output > > > > This patch series adds properties for plane color features. It adds > > properties for degamma used to linearize data and CSC used for gamut > > conversion. It also includes Gamma support used to again non-linearize > > data as per panel supported color space. These can be utilize by user > > space to convert planes from one format to another, one color space to > > another etc. > > > > Userspace can take smart blending decisions and utilize these hardware > > supported plane color features to get accurate color profile. The same > > can help in consistent color quality from source to panel taking > > advantage of advanced color features in hardware. > > > > These patches add the property interfaces and enable helper functions. > > This series adds Intel's XE_LPD hw specific plane gamma feature. We > > can build up and add other platform/hardware specific implementation > > on top of this series. > > > > Credits: Special mention and credits to Ville Syrjala for coming up > > with a design for this feature and inputs. This series is based on his > > original design and idea. > > > > Note: Userspace support for this new UAPI will be done on Chrome in > > alignment with weston and general opensource community. > > Discussion ongoing with Harry Wentland, Pekka and community on color > > pipeline and UAPI design. Harry's RFC below: > > https://patchwork.freedesktop.org/series/89506/ > > We need to converge on a common UAPI interface which caters to
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add fallback inside memcpy_from_wc functions
== Series Details ==
Series: drm/i915: Add fallback inside memcpy_from_wc functions
URL : https://patchwork.freedesktop.org/series/99675/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11185 -> Patchwork_22170
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/index.html
Participating hosts (48 -> 45)
--
Additional (1): fi-pnv-d510
Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Known issues
Here are the changes found in Patchwork_22170 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][2] ([fdo#109271]) +57 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: NOTRUN -> [DMESG-FAIL][3] ([i915#4494] / [i915#4957])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-5: [PASS][4] -> [DMESG-FAIL][5] ([i915#4494] /
[i915#4957])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-4770:[PASS][6] -> [INCOMPLETE][7] ([i915#4785])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][8] -> [DMESG-WARN][9] ([i915#4269])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#1436] /
[i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rpls-1}: [INCOMPLETE][11] ([i915#4898]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [INCOMPLETE][13] ([i915#4418]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6700k2: [DMESG-FAIL][15] ([i915#2291] / [i915#541]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-tgl-1115g4: [DMESG-FAIL][17] ([i915#3987]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][19] ([i915#3921]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][21] ([i915#295]) -> [PASS][22] +12
similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22170/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add fallback inside memcpy_from_wc functions
== Series Details == Series: drm/i915: Add fallback inside memcpy_from_wc functions URL : https://patchwork.freedesktop.org/series/99675/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/gem/i915_gem_object.c:455:37:expected void const *src +drivers/gpu/drm/i915/gem/i915_gem_object.c:455:37:got void [noderef] __iomem *[assigned] src_ptr +drivers/gpu/drm/i915/gem/i915_gem_object.c:455:37: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/i915_memcpy.c:187:6: error: symbol 'i915_io_memcpy_from_wc' redeclared with different type (incompatible argument 2 (different address spaces)): +drivers/gpu/drm/i915/i915_memcpy.c:187:6:void extern [addressable] [toplevel] i915_io_memcpy_from_wc( ... ) +drivers/gpu/drm/i915/i915_memcpy.c:189:42:expected void const *src +drivers/gpu/drm/i915/i915_memcpy.c:189:42:got void const [noderef] __iomem *src +drivers/gpu/drm/i915/i915_memcpy.c:189:42: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/i915_memcpy.c:191:45:expected void const *[assigned] src +drivers/gpu/drm/i915/i915_memcpy.c:191:45:got void const [noderef] __iomem *src +drivers/gpu/drm/i915/i915_memcpy.c:191:45: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/i915_memcpy.h:17:6: note: previously declared as: +drivers/gpu/drm/i915/i915_memcpy.h:17:6:void extern [addressable] [toplevel] i915_io_memcpy_from_wc( ... )
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: move the DRIVER_* macros to i915_driver.[ch]
== Series Details == Series: drm/i915: move the DRIVER_* macros to i915_driver.[ch] URL : https://patchwork.freedesktop.org/series/99671/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11185 -> Patchwork_22169 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22169 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22169, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/index.html Participating hosts (48 -> 44) -- Additional (1): fi-pnv-d510 Missing(5): fi-hsw-4200u fi-bsw-cyan fi-icl-u2 fi-ctg-p8600 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22169: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-bdw-5557u: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html - fi-rkl-guc: [PASS][2] -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_22169 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-pnv-d510:NOTRUN -> [SKIP][4] ([fdo#109271]) +39 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@hangcheck: - bat-dg1-6: NOTRUN -> [DMESG-FAIL][5] ([i915#4494] / [i915#4957]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html - bat-dg1-5: [PASS][6] -> [DMESG-FAIL][7] ([i915#4494] / [i915#4957]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - fi-hsw-4770:[PASS][8] -> [INCOMPLETE][9] ([i915#4785]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - fi-pnv-d510:NOTRUN -> [DMESG-FAIL][10] ([i915#2927] / [i915#4528]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-pnv-d510/igt@i915_selftest@l...@requests.html * igt@kms_chamelium@vga-edid-read: - fi-bdw-5557u: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html * igt@kms_psr@cursor_plane_move: - fi-bdw-5557u: NOTRUN -> [SKIP][12] ([fdo#109271]) +13 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: [PASS][13] -> [INCOMPLETE][14] ([i915#4838]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-skl-6600u/igt@kms_psr@primary_page_flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-skl-6600u/igt@kms_psr@primary_page_flip.html * igt@runner@aborted: - fi-pnv-d510:NOTRUN -> [FAIL][15] ([fdo#109271] / [i915#2403] / [i915#4312]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-pnv-d510/igt@run...@aborted.html - fi-hsw-4770:NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#1436] / [i915#4312]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-hsw-4770/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@gt_engines: - bat-dg1-6: [INCOMPLETE][17] ([i915#4418]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/bat-dg1-6/igt@i915_selftest@live@gt_engines.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/bat-dg1-6/igt@i915_selftest@live@gt_engines.html * igt@i915_selftest@live@gt_heartbeat: - fi-skl-6700k2: [DMESG-FAIL][19] ([i915#2291] / [i915#541]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11185/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22169/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html *
[Intel-gfx] [PATCH] drm/i915: Add fallback inside memcpy_from_wc functions
memcpy_from_wc functions can fail if SSE4.1 is not supported or the
supplied addresses are not 16-byte aligned. It was then upto to the
caller to use memcpy as fallback.
Now fallback to memcpy is implemented inside memcpy_from_wc functions
relieving the user from checking the return value of i915_memcpy_from_wc
and doing fallback.
When doing copying from io memory address memcpy_fromio should be used
as fallback. So a new function is added to the family of memcpy_to_wc
functions which should be used while copying from io memory.
This change is implemented also with an intention to perpare for porting
memcpy_from_wc code to ARM64. Since SSE4.1 is not valid for ARM,
accelerated reads will not be supported and the driver should rely on
fallback always.
So there would be few more places in the code where fallback should be
introduced. For e.g. GuC log relay is currently not using fallback since
a GPU supporting GuC submission will mostly have SSE4.1 enabled CPU.
This is no more valid with Discrete GPU and with enabling support for
ARM64.
With fallback moved inside memcpy_from_wc function, call sites would
look neat and fallback can be implemented in a uniform way.
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 8 ++-
drivers/gpu/drm/i915/i915_gpu_error.c | 9 ++-
drivers/gpu/drm/i915/i915_memcpy.c | 78 --
drivers/gpu/drm/i915/i915_memcpy.h | 18 ++---
5 files changed, 77 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index e03e362d320b..b139a88fce70 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -452,8 +452,7 @@ i915_gem_object_read_from_page_iomap(struct
drm_i915_gem_object *obj, u64 offset
PAGE_SIZE);
src_ptr = src_map + offset_in_page(offset);
- if (!i915_memcpy_from_wc(dst, (void __force *)src_ptr, size))
- memcpy_fromio(dst, src_ptr, size);
+ i915_io_memcpy_from_wc(dst, src_ptr, size);
io_mapping_unmap(src_map);
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c
b/drivers/gpu/drm/i915/gt/selftest_reset.c
index 37c38bdd5f47..64b8521a8b28 100644
--- a/drivers/gpu/drm/i915/gt/selftest_reset.c
+++ b/drivers/gpu/drm/i915/gt/selftest_reset.c
@@ -99,8 +99,10 @@ __igt_reset_stolen(struct intel_gt *gt,
memset_io(s, STACK_MAGIC, PAGE_SIZE);
in = (void __force *)s;
- if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
+ if (i915_can_memcpy_from_wc(tmp, in, PAGE_SIZE)) {
+ i915_io_memcpy_from_wc(tmp, in, PAGE_SIZE);
in = tmp;
+ }
crc[page] = crc32_le(0, in, PAGE_SIZE);
io_mapping_unmap(s);
@@ -135,8 +137,10 @@ __igt_reset_stolen(struct intel_gt *gt,
PAGE_SIZE);
in = (void __force *)s;
- if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
+ if (i915_can_memcpy_from_wc(tmp, in, PAGE_SIZE)) {
+ i915_io_memcpy_from_wc(tmp, in, PAGE_SIZE);
in = tmp;
+ }
x = crc32_le(0, in, PAGE_SIZE);
if (x != crc[page] &&
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index aee42eae4729..90db5de86c25 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -296,8 +296,10 @@ static int compress_page(struct i915_vma_compress *c,
struct z_stream_s *zstream = >zstream;
zstream->next_in = src;
- if (wc && c->tmp && i915_memcpy_from_wc(c->tmp, src, PAGE_SIZE))
+ if (wc && c->tmp && i915_can_memcpy_from_wc(c->tmp, src, PAGE_SIZE)) {
+ i915_io_memcpy_from_wc(c->tmp, src, PAGE_SIZE);
zstream->next_in = c->tmp;
+ }
zstream->avail_in = PAGE_SIZE;
do {
@@ -396,8 +398,11 @@ static int compress_page(struct i915_vma_compress *c,
if (!ptr)
return -ENOMEM;
- if (!(wc && i915_memcpy_from_wc(ptr, src, PAGE_SIZE)))
+ if (wc)
+ i915_io_memcpy_from_wc(ptr, src, PAGE_SIZE);
+ else
memcpy(ptr, src, PAGE_SIZE);
+
list_add_tail(_to_page(ptr)->lru, >page_list);
cond_resched();
diff --git a/drivers/gpu/drm/i915/i915_memcpy.c
b/drivers/gpu/drm/i915/i915_memcpy.c
index 1b021a4902de..b1f8abf35452 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/i915/i915_memcpy.c
@@ -24,15 +24,10 @@
#include
#include
+#include
#include "i915_memcpy.h"
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
-#define CI_BUG_ON(expr) BUG_ON(expr)
-#else
-#define CI_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
-#endif
-
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: move the DRIVER_* macros to i915_driver.[ch]
== Series Details == Series: drm/i915: move the DRIVER_* macros to i915_driver.[ch] URL : https://patchwork.freedesktop.org/series/99671/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.IGT: success for dma-buf-map: Rename to iosys-map (rev2)
== Series Details ==
Series: dma-buf-map: Rename to iosys-map (rev2)
URL : https://patchwork.freedesktop.org/series/99612/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11183_full -> Patchwork_22164_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 12)
--
Missing(1): shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22164_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_scaling_modes@scaling-mode-center:
- {shard-rkl}:NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-rkl-1/igt@kms_scaling_mo...@scaling-mode-center.html
Known issues
Here are the changes found in Patchwork_22164_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_create@create-massive:
- shard-apl: NOTRUN -> [DMESG-WARN][2] ([i915#4991])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-apl8/igt@gem_cre...@create-massive.html
* igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11183/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-iclb6/igt@gem_exec_balan...@parallel-contexts.html
* igt@gem_exec_capture@pi@rcs0:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#4547])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11183/shard-skl3/igt@gem_exec_capture@p...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-skl10/igt@gem_exec_capture@p...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11183/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11183/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11183/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-iclb6/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_whisper@basic-forked-all:
- shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#118])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11183/shard-glk6/igt@gem_exec_whis...@basic-forked-all.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-glk9/igt@gem_exec_whis...@basic-forked-all.html
* igt@gem_userptr_blits@input-checking:
- shard-skl: NOTRUN -> [DMESG-WARN][16] ([i915#4990])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-skl8/igt@gem_userptr_bl...@input-checking.html
* igt@i915_pm_dc@dc6-dpms:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#454])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11183/shard-iclb1/igt@i915_pm...@dc6-dpms.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-iclb3/igt@i915_pm...@dc6-dpms.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs:
- shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271]) +31 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-apl8/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs.html
* igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3886]) +1
similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22164/shard-apl8/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][21] ([fdo#109271]) +6 similar issues
[21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: split out function structs from i915_drv.h
== Series Details ==
Series: drm/i915: split out function structs from i915_drv.h
URL : https://patchwork.freedesktop.org/series/99669/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11184 -> Patchwork_22168
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/index.html
Participating hosts (42 -> 43)
--
Additional (10): bat-dg1-6 bat-dg1-5 fi-adl-ddr4 fi-apl-guc bat-adlp-6
fi-pnv-d510 bat-rpls-1 bat-rpls-2 bat-jsl-2 bat-jsl-1
Missing(9): fi-rkl-11600 shard-tglu fi-hsw-4200u fi-icl-u2 fi-bsw-cyan
fi-ctg-p8600 fi-kbl-8809g shard-rkl fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22168:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s3@smem:
- {fi-adl-ddr4}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/fi-adl-ddr4/igt@gem_exec_suspend@basic...@smem.html
Known issues
Here are the changes found in Patchwork_22168 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: NOTRUN -> [DMESG-WARN][3] ([i915#1610])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/fi-apl-guc/igt@debugfs_test@read_all_entries.html
* igt@fbdev@nullptr:
- bat-dg1-6: NOTRUN -> [SKIP][4] ([i915#2582]) +4 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-6/igt@fb...@nullptr.html
* igt@gem_exec_gttfill@basic:
- bat-dg1-6: NOTRUN -> [SKIP][5] ([i915#4086])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-6/igt@gem_exec_gttf...@basic.html
- bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4086])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-5/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [PASS][7] -> [INCOMPLETE][8] ([i915#146])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +57 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4083])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-5/igt@gem_m...@basic.html
- bat-dg1-6: NOTRUN -> [SKIP][11] ([i915#4083])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-6/igt@gem_m...@basic.html
* igt@gem_mmap_gtt@basic:
- bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#4077]) +2 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-5/igt@gem_mmap_...@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-6: NOTRUN -> [SKIP][13] ([i915#4077]) +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-6/igt@gem_tiled_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-6: NOTRUN -> [SKIP][14] ([i915#4079]) +1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-6/igt@gem_tiled_pread_basic.html
- bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4079]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#1155])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-6: NOTRUN -> [SKIP][17] ([i915#1155])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: NOTRUN -> [DMESG-FAIL][18] ([i915#4494] / [i915#4957])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22168/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@kms_addfb_basic@addfb25-x-tiled-legacy:
- bat-dg1-6: NOTRUN -> [SKIP][19] ([i915#4212]) +7 similar issues
[19]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: split out function structs from i915_drv.h
== Series Details == Series: drm/i915: split out function structs from i915_drv.h URL : https://patchwork.freedesktop.org/series/99669/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.BUILD: warning for Add data flow metering support for HDMI2.1
== Series Details == Series: Add data flow metering support for HDMI2.1 URL : https://patchwork.freedesktop.org/series/99668/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o AR init/built-in.a LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.kallsyms1 drivers/gpu/drm/drm_frl_dfm_helper.o: In function `drm_frl_dsc_get_ftb_avg': /home/cidrm/kernel/drivers/gpu/drm/drm_frl_dfm_helper.c:608: undefined reference to `__udivdi3' drivers/gpu/drm/drm_frl_dfm_helper.o: In function `drm_frl_dsc_tactive_target_ns': /home/cidrm/kernel/drivers/gpu/drm/drm_frl_dfm_helper.c:635: undefined reference to `__udivdi3' Makefile:1155: recipe for target 'vmlinux' failed make: *** [vmlinux] Error 1 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/build_32bit.log
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add data flow metering support for HDMI2.1
== Series Details ==
Series: Add data flow metering support for HDMI2.1
URL : https://patchwork.freedesktop.org/series/99668/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11184 -> Patchwork_22167
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22167 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22167, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/index.html
Participating hosts (41 -> 45)
--
Additional (9): bat-dg1-6 bat-dg1-5 fi-adl-ddr4 fi-apl-guc bat-adlp-6
bat-rpls-1 bat-rpls-2 bat-jsl-2 bat-jsl-1
Missing(5): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22167:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s3@smem:
- {fi-adl-ddr4}: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/fi-adl-ddr4/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [PASS][4] -> [INCOMPLETE][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_22167 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: NOTRUN -> [DMESG-WARN][6] ([i915#1610])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/fi-apl-guc/igt@debugfs_test@read_all_entries.html
* igt@fbdev@nullptr:
- bat-dg1-6: NOTRUN -> [SKIP][7] ([i915#2582]) +4 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-6/igt@fb...@nullptr.html
* igt@gem_exec_gttfill@basic:
- bat-dg1-6: NOTRUN -> [SKIP][8] ([i915#4086])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-6/igt@gem_exec_gttf...@basic.html
- bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4086])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-5/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [PASS][10] -> [INCOMPLETE][11] ([i915#146])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#4083])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-5/igt@gem_m...@basic.html
- bat-dg1-6: NOTRUN -> [SKIP][13] ([i915#4083])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-6/igt@gem_m...@basic.html
* igt@gem_mmap_gtt@basic:
- bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#4077]) +2 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-5/igt@gem_mmap_...@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-6: NOTRUN -> [SKIP][15] ([i915#4077]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-6/igt@gem_tiled_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-6: NOTRUN -> [SKIP][16] ([i915#4079]) +1 similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-6/igt@gem_tiled_pread_basic.html
- bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#4079]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#1155])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22167/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-6: NOTRUN -> [SKIP][19] ([i915#1155])
[19]:
[Intel-gfx] [PATCH] drm/i915: move the DRIVER_* macros to i915_driver.[ch]
The macros are more at home in i915_driver.[ch].
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 1 +
drivers/gpu/drm/i915/i915_driver.c| 15
drivers/gpu/drm/i915/i915_driver.h| 5
drivers/gpu/drm/i915/i915_drv.h | 23 ---
drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
drivers/gpu/drm/i915/i915_irq.c | 1 +
drivers/gpu/drm/i915/i915_mitigations.c | 1 +
drivers/gpu/drm/i915/i915_module.c| 1 +
drivers/gpu/drm/i915/i915_request.c | 1 +
.../gpu/drm/i915/selftests/i915_selftest.c| 1 +
10 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 6da68b38f00f..00359ec9d58b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -10,6 +10,7 @@
#include "gt/intel_gt_pm.h"
#include "gt/intel_gt_requests.h"
+#include "i915_driver.h"
#include "i915_drv.h"
#if defined(CONFIG_X86)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 3d41f532a5d6..76c84b35884f 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1823,6 +1823,21 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_VM_DESTROY, i915_gem_vm_destroy_ioctl,
DRM_RENDER_ALLOW),
};
+/*
+ * Interface history:
+ *
+ * 1.1: Original.
+ * 1.2: Add Power Management
+ * 1.3: Add vblank support
+ * 1.4: Fix cmdbuffer path, add heap destroy
+ * 1.5: Add vblank pipe configuration
+ * 1.6: - New ioctl for scheduling buffer swaps on vertical blank
+ * - Support vertical blank on secondary display pipe
+ */
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 6
+#define DRIVER_PATCHLEVEL 0
+
static const struct drm_driver i915_drm_driver = {
/* Don't use MTRRs here; the Xserver or userspace app should
* deal with them for Intel hardware.
diff --git a/drivers/gpu/drm/i915/i915_driver.h
b/drivers/gpu/drm/i915/i915_driver.h
index 9ef8db4aa0a6..9d11de65daaf 100644
--- a/drivers/gpu/drm/i915/i915_driver.h
+++ b/drivers/gpu/drm/i915/i915_driver.h
@@ -12,6 +12,11 @@ struct pci_dev;
struct pci_device_id;
struct drm_i915_private;
+#define DRIVER_NAME"i915"
+#define DRIVER_DESC"Intel Graphics"
+#define DRIVER_DATE"20201103"
+#define DRIVER_TIMESTAMP 1604406085
+
extern const struct dev_pm_ops i915_pm_ops;
int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8c1706fd81f9..bd444e16ce5e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -106,15 +106,6 @@
#include "gt/intel_timeline.h"
#include "i915_vma.h"
-
-/* General customization:
- */
-
-#define DRIVER_NAME"i915"
-#define DRIVER_DESC"Intel Graphics"
-#define DRIVER_DATE"20201103"
-#define DRIVER_TIMESTAMP 1604406085
-
struct drm_i915_gem_object;
/* Threshold == 5 for long IRQs, 50 for short */
@@ -260,20 +251,6 @@ struct drm_i915_file_private {
unsigned long hang_timestamp;
};
-/* Interface history:
- *
- * 1.1: Original.
- * 1.2: Add Power Management
- * 1.3: Add vblank support
- * 1.4: Fix cmdbuffer path, add heap destroy
- * 1.5: Add vblank pipe configuration
- * 1.6: - New ioctl for scheduling buffer swaps on vertical blank
- * - Support vertical blank on secondary display pipe
- */
-#define DRIVER_MAJOR 1
-#define DRIVER_MINOR 6
-#define DRIVER_PATCHLEVEL 0
-
struct intel_overlay;
struct intel_overlay_error_state;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 127ff56c8ce6..54b2360dfd99 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -46,6 +46,7 @@
#include "gt/intel_gt_pm.h"
#include "gt/intel_gt_regs.h"
+#include "i915_driver.h"
#include "i915_drv.h"
#include "i915_gpu_error.h"
#include "i915_memcpy.h"
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c05eb09d8a66..78871518c67b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -49,6 +49,7 @@
#include "gt/intel_gt_regs.h"
#include "gt/intel_rps.h"
+#include "i915_driver.h"
#include "i915_drv.h"
#include "i915_irq.h"
#include "intel_pm.h"
diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
b/drivers/gpu/drm/i915/i915_mitigations.c
index 84f12598d145..def7302ef7fe 100644
--- a/drivers/gpu/drm/i915/i915_mitigations.c
+++ b/drivers/gpu/drm/i915/i915_mitigations.c
@@ -8,6 +8,7 @@
#include
#include
+#include "i915_driver.h"
#include "i915_drv.h"
#include "i915_mitigations.h"
diff --git a/drivers/gpu/drm/i915/i915_module.c
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add data flow metering support for HDMI2.1
== Series Details ==
Series: Add data flow metering support for HDMI2.1
URL : https://patchwork.freedesktop.org/series/99668/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
84a5cb52aee6 drm/hdmi21: Define frl_dfm structure
-:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#13:
new file mode 100644
-:40: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#40: FILE: include/drm/drm_frl_dfm_helper.h:23:
+struct drm_frl_dfm_input_config {
+
-:83: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#83: FILE: include/drm/drm_frl_dfm_helper.h:66:
+struct drm_frl_dfm_params {
+
total: 0 errors, 1 warnings, 2 checks, 126 lines checked
ef52becbce64 drm/hdmi21: Add non dsc frl capacity computation helpers
-:12: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#12:
new file mode 100644
-:138: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#138: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:122:
+drm_get_total_frl_char_per_line_period(u32 line_time_ns, u32
frl_char_rate_min_k,
+ u32 lanes)
-:215: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#215: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:199:
+ kcd = bpc/8;
^
-:218: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#218: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:202:
+ cfrl_free = max(((hblank * kcd) / k420 - 32 * audio_packets_line - 7),
+U32_MIN);
-:355: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#355: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:339:
+ nr = 3/2 * tribyte_active * FRL_TIMING_NS_MULTIPLIER;
^
-:369: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#369: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:353:
+drm_get_tblank_min(u32 num_lanes, u32 tribyte_blank,
+ u32 overhead_max_k, u32 frl_char_min_rate_k)
-:400: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#400: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:384:
+ frl_char_payload_actual = DIV_ROUND_UP(3 * tribytes_active, 2) +
tribytes_blank - cfrl_savings;
total: 0 errors, 2 warnings, 5 checks, 396 lines checked
cfe4d1abfbda drm/hdmi21: Add helpers to verify non-dsc DFM requirements
-:99: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#99: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:477:
+frl_dfm->params.tb_active,
frl_dfm->params.tb_blank,
-:112: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#112: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:490:
+ tblank_min_ns = drm_get_tblank_min(frl_dfm->config.lanes,
+frl_dfm->params.tb_blank,
-:116: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'tactive_ref_ns >= tactive_min_ns'
#116: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:494:
+ if ((tactive_ref_ns >= tactive_min_ns) &&
+ (tblank_ref_ns >= tblank_min_ns)) {
-:116: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'tblank_ref_ns >= tblank_min_ns'
#116: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:494:
+ if ((tactive_ref_ns >= tactive_min_ns) &&
+ (tblank_ref_ns >= tblank_min_ns)) {
-:123: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'tactive_ref_ns < tactive_min_ns'
#123: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:501:
+ if ((tactive_ref_ns < tactive_min_ns) &&
+ (tblank_ref_ns >= tblank_min_ns)) {
-:123: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'tblank_ref_ns >= tblank_min_ns'
#123: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:501:
+ if ((tactive_ref_ns < tactive_min_ns) &&
+ (tblank_ref_ns >= tblank_min_ns)) {
-:127: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#127: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:505:
+ frl_dfm->params.tb_borrowed =
drm_get_tribytes_borrowed(tborrowed_ns,
+
frl_dfm->params.ftb_avg_k);
-:151: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#151: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:529:
+ utilization = drm_compute_payload_utilization(frl_char_payload_actual,
+
frl_dfm->params.cfrl_line);
total: 0 errors, 1 warnings, 7 checks, 170 lines checked
d7bca9952da4 drm/hdmi21: Add support for DFM calculation with DSC
-:70: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#70: FILE: drivers/gpu/drm/drm_frl_dfm_helper.c:608:
+ return (hcactive_target_tb + hcblank_target_tb) * (fpixelclock_max_khz
/ (hactive + hblank));
-:146: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#146: FILE:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp, drm/i915: 128b/132b updates (rev2)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev2) URL : https://patchwork.freedesktop.org/series/99324/ State : success == Summary == CI Bug Log - changes from CI_DRM_11184 -> Patchwork_22165 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/index.html Participating hosts (40 -> 44) -- Additional (9): bat-dg1-6 bat-dg1-5 fi-apl-guc bat-adlp-6 fi-pnv-d510 bat-rpls-1 bat-rpls-2 bat-jsl-2 bat-jsl-1 Missing(5): fi-bxt-dsi fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Known issues Here are the changes found in Patchwork_22165 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-apl-guc: NOTRUN -> [DMESG-WARN][1] ([i915#1610]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/fi-apl-guc/igt@debugfs_test@read_all_entries.html * igt@fbdev@info: - bat-dg1-6: NOTRUN -> [SKIP][2] ([i915#2582]) +4 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-6/igt@fb...@info.html * igt@gem_exec_gttfill@basic: - bat-dg1-6: NOTRUN -> [SKIP][3] ([i915#4086]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-6/igt@gem_exec_gttf...@basic.html - bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4086]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-5/igt@gem_exec_gttf...@basic.html * igt@gem_exec_suspend@basic-s3@smem: - fi-bdw-5557u: [PASS][5] -> [INCOMPLETE][6] ([i915#146]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html - fi-skl-6600u: [PASS][7] -> [INCOMPLETE][8] ([i915#4547]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11184/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html * igt@gem_mmap@basic: - bat-dg1-6: NOTRUN -> [SKIP][9] ([i915#4083]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-6/igt@gem_m...@basic.html - bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4083]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_blits@basic: - bat-dg1-6: NOTRUN -> [SKIP][11] ([i915#4077]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-6/igt@gem_tiled_bl...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#4077]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4079]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-dg1-6: NOTRUN -> [SKIP][14] ([i915#4079]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-6/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#1155]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html - bat-dg1-6: NOTRUN -> [SKIP][16] ([i915#1155]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][17] ([i915#4494] / [i915#4957]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - bat-dg1-6: NOTRUN -> [DMESG-FAIL][18] ([i915#4494] / [i915#4957]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html * igt@kms_addfb_basic@addfb25-x-tiled-legacy: - bat-dg1-6: NOTRUN -> [SKIP][19] ([i915#4212]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-6/igt@kms_addfb_ba...@addfb25-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][20] ([i915#4215]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html - bat-dg1-6: NOTRUN -> [SKIP][21] ([i915#4215]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22165/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html *
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/7] drm/selftests: Move i915 buddy selftests into drm
== Series Details == Series: series starting with [1/7] drm/selftests: Move i915 buddy selftests into drm URL : https://patchwork.freedesktop.org/series/99663/ State : failure == Summary == Applying: drm/selftests: Move i915 buddy selftests into drm Applying: drm/selftests: add drm buddy alloc limit testcase Applying: drm/selftests: add drm buddy alloc range testcase Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_buddy.c M include/drm/drm_buddy.h Falling back to patching base and 3-way merge... Auto-merging include/drm/drm_buddy.h CONFLICT (content): Merge conflict in include/drm/drm_buddy.h Auto-merging drivers/gpu/drm/drm_buddy.c CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_buddy.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 drm/selftests: add drm buddy alloc range testcase When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH 19/20] drm/i915/lmem: don't treat small BAR as an error
On 03/02/2022 13:56, Thomas Hellström wrote:
On Thu, 2022-02-03 at 11:18 +, Matthew Auld wrote:
On 03/02/2022 09:48, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-
mappable.
Changes here LGTM.
It does leave open with what to do with stolen local-memory.
Are objects in stolen local required to be mappable?
From a quick look I don't really see such users on discrete, outside
of
maybe intelfb_create(), where I guess the initial fb might be located
in
stolen on DG1. But from DG2+ it looks like it will just be located in
normal LMEM. For that I was thinking we add something like
i915_gem_object_create_region_at(), and somehow wire that up to the
{fpfn, lpfn}...
So we could then skip STOLEN completely on DG2+? Could we then also do
the same on DG1, at least assuming that creating and pinning an object
for that initial fb would be done before any other pinning into LMEM?
It looks like fbc is the main user on discrete, AFAICT, but that doesn't
seem to use the gem object interface, and instead just plugs into the
underlying drm_mm directly. So AFAIK we still want stolen on DG2/DG1 for
that.
/Thomas
[Intel-gfx] [PATCH 7/7] drm/i915/pm: hide struct drm_i915_clock_gating_funcs
The struct is only needed in intel_pm.c, move it there.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 078fc50e7eb9..4ac0fcb9a4ca 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -107,6 +107,7 @@
#include "i915_vma.h"
struct dpll;
+struct drm_i915_clock_gating_funcs;
struct drm_i915_gem_object;
struct drm_i915_private;
struct intel_atomic_state;
@@ -302,11 +303,6 @@ struct sdvo_device_mapping {
u8 ddc_pin;
};
-/* functions used internal in intel_pm.c */
-struct drm_i915_clock_gating_funcs {
- void (*init_clock_gating)(struct drm_i915_private *dev_priv);
-};
-
/* functions used for watermark calcs for display. */
struct drm_i915_wm_disp_funcs {
/* update_wm is for legacy wm management */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 859be750fb22..2e84d45f9bf0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -55,6 +55,10 @@
#include "vlv_sideband.h"
#include "../../../platform/x86/intel_ips.h"
+struct drm_i915_clock_gating_funcs {
+ void (*init_clock_gating)(struct drm_i915_private *i915);
+};
+
/* Stores plane specific WM parameters */
struct skl_wm_params {
bool x_tiled, y_tiled;
--
2.30.2
[Intel-gfx] [PATCH 6/7] drm/i915/dpll: hide struct intel_dpll_funcs
The struct is only needed in intel_dpll.c, move it there.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dpll.c | 4
drivers/gpu/drm/i915/i915_drv.h | 5 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 809b2004e5b2..14f5ffe27d05 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -16,6 +16,10 @@
#include "intel_snps_phy.h"
#include "vlv_sideband.h"
+struct intel_dpll_funcs {
+ int (*crtc_compute_clock)(struct intel_crtc_state *crtc_state);
+};
+
struct intel_limit {
struct {
int min, max;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 784233ad9f16..078fc50e7eb9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -119,6 +119,7 @@ struct intel_color_funcs;
struct intel_connector;
struct intel_crtc;
struct intel_dp;
+struct intel_dpll_funcs;
struct intel_encoder;
struct intel_fbdev;
struct intel_fdi_funcs;
@@ -323,10 +324,6 @@ struct drm_i915_wm_disp_funcs {
int (*compute_global_watermarks)(struct intel_atomic_state *state);
};
-struct intel_dpll_funcs {
- int (*crtc_compute_clock)(struct intel_crtc_state *crtc_state);
-};
-
struct drm_i915_display_funcs {
/* Returns the active state of the crtc, and if the crtc is active,
* fills out the pipe-config with the hw state. */
--
2.30.2
[Intel-gfx] [PATCH 3/7] drm/i915/hpd: hide struct intel_hotplug_funcs
With intel_hpd_irq_setup() in i915_irq.c, struct intel_hotplug_funcs is
also only needed there.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 7 +--
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_irq.c | 10 ++
drivers/gpu/drm/i915/i915_irq.h | 1 +
4 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 912b7003dcfa..8204126d17f9 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -24,6 +24,7 @@
#include
#include "i915_drv.h"
+#include "i915_irq.h"
#include "intel_display_types.h"
#include "intel_hotplug.h"
@@ -213,12 +214,6 @@ intel_hpd_irq_storm_switch_to_polling(struct
drm_i915_private *dev_priv)
}
}
-static void intel_hpd_irq_setup(struct drm_i915_private *i915)
-{
- if (i915->display_irqs_enabled && i915->hotplug_funcs)
- i915->hotplug_funcs->hpd_irq_setup(i915);
-}
-
static void intel_hpd_irq_storm_reenable_work(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cac18b57808e..e13e0188530e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -121,6 +121,7 @@ struct intel_crtc;
struct intel_dp;
struct intel_encoder;
struct intel_fbdev;
+struct intel_hotplug_funcs;
struct intel_initial_plane_config;
struct intel_limit;
struct intel_overlay;
@@ -321,10 +322,6 @@ struct drm_i915_wm_disp_funcs {
int (*compute_global_watermarks)(struct intel_atomic_state *state);
};
-struct intel_hotplug_funcs {
- void (*hpd_irq_setup)(struct drm_i915_private *dev_priv);
-};
-
struct intel_fdi_funcs {
void (*fdi_link_train)(struct intel_crtc *crtc,
const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c05eb09d8a66..4e97d22ff081 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4347,6 +4347,10 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
return ret;
}
+struct intel_hotplug_funcs {
+ void (*hpd_irq_setup)(struct drm_i915_private *i915);
+};
+
#define HPD_FUNCS(platform) \
static const struct intel_hotplug_funcs platform##_hpd_funcs = { \
.hpd_irq_setup = platform##_hpd_irq_setup, \
@@ -4361,6 +4365,12 @@ HPD_FUNCS(spt);
HPD_FUNCS(ilk);
#undef HPD_FUNCS
+void intel_hpd_irq_setup(struct drm_i915_private *i915)
+{
+ if (i915->display_irqs_enabled && i915->hotplug_funcs)
+ i915->hotplug_funcs->hpd_irq_setup(i915);
+}
+
/**
* intel_irq_init - initializes irq support
* @dev_priv: i915 device instance
diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
index 0eb90d271fa7..82639d9d7e82 100644
--- a/drivers/gpu/drm/i915/i915_irq.h
+++ b/drivers/gpu/drm/i915/i915_irq.h
@@ -37,6 +37,7 @@ i915_disable_pipestat(struct drm_i915_private *dev_priv, enum
pipe pipe,
void valleyview_enable_display_irqs(struct drm_i915_private *dev_priv);
void valleyview_disable_display_irqs(struct drm_i915_private *dev_priv);
+void intel_hpd_irq_setup(struct drm_i915_private *i915);
void i915_hotplug_interrupt_update(struct drm_i915_private *dev_priv,
u32 mask,
u32 bits);
--
2.30.2
[Intel-gfx] [PATCH 4/7] drm/i915/fdi: hide struct intel_fdi_funcs
The struct is only needed in intel_fdi.c, move it there.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fdi.c | 5 +
drivers/gpu/drm/i915/i915_drv.h | 6 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c
b/drivers/gpu/drm/i915/display/intel_fdi.c
index 3d6e22923601..4e4b43669b14 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -10,6 +10,11 @@
#include "intel_display_types.h"
#include "intel_fdi.h"
+struct intel_fdi_funcs {
+ void (*fdi_link_train)(struct intel_crtc *crtc,
+ const struct intel_crtc_state *crtc_state);
+};
+
static void assert_fdi_tx(struct drm_i915_private *dev_priv,
enum pipe pipe, bool state)
{
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e13e0188530e..784233ad9f16 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -121,6 +121,7 @@ struct intel_crtc;
struct intel_dp;
struct intel_encoder;
struct intel_fbdev;
+struct intel_fdi_funcs;
struct intel_hotplug_funcs;
struct intel_initial_plane_config;
struct intel_limit;
@@ -322,11 +323,6 @@ struct drm_i915_wm_disp_funcs {
int (*compute_global_watermarks)(struct intel_atomic_state *state);
};
-struct intel_fdi_funcs {
- void (*fdi_link_train)(struct intel_crtc *crtc,
- const struct intel_crtc_state *crtc_state);
-};
-
struct intel_dpll_funcs {
int (*crtc_compute_clock)(struct intel_crtc_state *crtc_state);
};
--
2.30.2
[Intel-gfx] [PATCH 5/7] drm/i915/dpll: add intel_dpll_crtc_compute_clock()
Avoid referencing the function pointer directly to be able to abstract
the call better.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_dpll.c| 8
drivers/gpu/drm/i915/display/intel_dpll.h| 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index df347329d90e..04909088cae6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5266,7 +5266,7 @@ static int intel_crtc_atomic_check(struct
intel_atomic_state *state,
if (mode_changed && crtc_state->hw.enable &&
!drm_WARN_ON(_priv->drm, crtc_state->shared_dpll)) {
- ret = dev_priv->dpll_funcs->crtc_compute_clock(crtc_state);
+ ret = intel_dpll_crtc_compute_clock(crtc_state);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 1ce0c171f4fb..809b2004e5b2 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -1400,6 +1400,14 @@ static const struct intel_dpll_funcs i8xx_dpll_funcs = {
.crtc_compute_clock = i8xx_crtc_compute_clock,
};
+int intel_dpll_crtc_compute_clock(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+
+ return i915->dpll_funcs->crtc_compute_clock(crtc_state);
+}
+
void
intel_dpll_init_clock_hook(struct drm_i915_private *dev_priv)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.h
b/drivers/gpu/drm/i915/display/intel_dpll.h
index 1af0ac43cca4..69b06a9e473e 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.h
+++ b/drivers/gpu/drm/i915/display/intel_dpll.h
@@ -15,6 +15,7 @@ struct intel_crtc_state;
enum pipe;
void intel_dpll_init_clock_hook(struct drm_i915_private *dev_priv);
+int intel_dpll_crtc_compute_clock(struct intel_crtc_state *crtc_state);
int vlv_calc_dpll_params(int refclk, struct dpll *clock);
int pnv_calc_dpll_params(int refclk, struct dpll *clock);
int i9xx_calc_dpll_params(int refclk, struct dpll *clock);
--
2.30.2
[Intel-gfx] [PATCH 0/7] drm/i915: split out function structs from i915_drv.h
Most of the structs can be hidden away. Jani Nikula (7): drm/i915: group i915_drv.h forward declarations together drm/i915/color: hide struct intel_color_funcs drm/i915/hpd: hide struct intel_hotplug_funcs drm/i915/fdi: hide struct intel_fdi_funcs drm/i915/dpll: add intel_dpll_crtc_compute_clock() drm/i915/dpll: hide struct intel_dpll_funcs drm/i915/pm: hide struct drm_i915_clock_gating_funcs drivers/gpu/drm/i915/display/intel_color.c | 19 + drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/display/intel_dpll.c| 12 +++ drivers/gpu/drm/i915/display/intel_dpll.h| 1 + drivers/gpu/drm/i915/display/intel_fdi.c | 5 ++ drivers/gpu/drm/i915/display/intel_hotplug.c | 7 +- drivers/gpu/drm/i915/i915_drv.h | 86 ++-- drivers/gpu/drm/i915/i915_irq.c | 10 +++ drivers/gpu/drm/i915/i915_irq.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 4 + 10 files changed, 78 insertions(+), 69 deletions(-) -- 2.30.2
[Intel-gfx] [PATCH 2/7] drm/i915/color: hide struct intel_color_funcs
The struct is only needed in intel_color.c, move it there.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_color.c | 19 +++
drivers/gpu/drm/i915/i915_drv.h| 20 +---
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index de3ded1e327a..8f8b34b60f27 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -28,6 +28,25 @@
#include "intel_dpll.h"
#include "vlv_dsi_pll.h"
+struct intel_color_funcs {
+ int (*color_check)(struct intel_crtc_state *crtc_state);
+ /*
+* Program double buffered color management registers during
+* vblank evasion. The registers should then latch during the
+* next vblank start, alongside any other double buffered registers
+* involved with the same commit.
+*/
+ void (*color_commit)(const struct intel_crtc_state *crtc_state);
+ /*
+* Load LUTs (and other single buffered color management
+* registers). Will (hopefully) be called during the vblank
+* following the latching of any double buffered registers
+* involved with the same commit.
+*/
+ void (*load_luts)(const struct intel_crtc_state *crtc_state);
+ void (*read_luts)(struct intel_crtc_state *crtc_state);
+};
+
#define CTM_COEFF_SIGN (1ULL << 63)
#define CTM_COEFF_1_0 (1ULL << 32)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5a1615c02971..cac18b57808e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -115,6 +115,7 @@ struct intel_cdclk_config;
struct intel_cdclk_funcs;
struct intel_cdclk_state;
struct intel_cdclk_vals;
+struct intel_color_funcs;
struct intel_connector;
struct intel_crtc;
struct intel_dp;
@@ -320,25 +321,6 @@ struct drm_i915_wm_disp_funcs {
int (*compute_global_watermarks)(struct intel_atomic_state *state);
};
-struct intel_color_funcs {
- int (*color_check)(struct intel_crtc_state *crtc_state);
- /*
-* Program double buffered color management registers during
-* vblank evasion. The registers should then latch during the
-* next vblank start, alongside any other double buffered registers
-* involved with the same commit.
-*/
- void (*color_commit)(const struct intel_crtc_state *crtc_state);
- /*
-* Load LUTs (and other single buffered color management
-* registers). Will (hopefully) be called during the vblank
-* following the latching of any double buffered registers
-* involved with the same commit.
-*/
- void (*load_luts)(const struct intel_crtc_state *crtc_state);
- void (*read_luts)(struct intel_crtc_state *crtc_state);
-};
-
struct intel_hotplug_funcs {
void (*hpd_irq_setup)(struct drm_i915_private *dev_priv);
};
--
2.30.2
[Intel-gfx] [PATCH 1/7] drm/i915: group i915_drv.h forward declarations together
Group the forward declarations in i915_drv.h together near the top, like
in other header files, and sort.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 44 ++---
1 file changed, 19 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8c1706fd81f9..5a1615c02971 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -106,6 +106,25 @@
#include "gt/intel_timeline.h"
#include "i915_vma.h"
+struct dpll;
+struct drm_i915_gem_object;
+struct drm_i915_private;
+struct intel_atomic_state;
+struct intel_audio_funcs;
+struct intel_cdclk_config;
+struct intel_cdclk_funcs;
+struct intel_cdclk_state;
+struct intel_cdclk_vals;
+struct intel_connector;
+struct intel_crtc;
+struct intel_dp;
+struct intel_encoder;
+struct intel_fbdev;
+struct intel_initial_plane_config;
+struct intel_limit;
+struct intel_overlay;
+struct intel_overlay_error_state;
+struct vlv_s0ix_state;
/* General customization:
*/
@@ -115,8 +134,6 @@
#define DRIVER_DATE"20201103"
#define DRIVER_TIMESTAMP 1604406085
-struct drm_i915_gem_object;
-
/* Threshold == 5 for long IRQs, 50 for short */
#define HPD_STORM_DEFAULT_THRESHOLD 50
@@ -166,8 +183,6 @@ struct i915_hotplug {
I915_GEM_DOMAIN_INSTRUCTION | \
I915_GEM_DOMAIN_VERTEX)
-struct drm_i915_private;
-
struct drm_i915_file_private {
struct drm_i915_private *dev_priv;
@@ -274,9 +289,6 @@ struct drm_i915_file_private {
#define DRIVER_MINOR 6
#define DRIVER_PATCHLEVEL 0
-struct intel_overlay;
-struct intel_overlay_error_state;
-
struct sdvo_device_mapping {
u8 initialized;
u8 dvo_port;
@@ -286,18 +298,6 @@ struct sdvo_device_mapping {
u8 ddc_pin;
};
-struct intel_connector;
-struct intel_encoder;
-struct intel_atomic_state;
-struct intel_cdclk_config;
-struct intel_cdclk_funcs;
-struct intel_cdclk_state;
-struct intel_cdclk_vals;
-struct intel_initial_plane_config;
-struct intel_crtc;
-struct intel_limit;
-struct dpll;
-
/* functions used internal in intel_pm.c */
struct drm_i915_clock_gating_funcs {
void (*init_clock_gating)(struct drm_i915_private *dev_priv);
@@ -385,7 +385,6 @@ enum drrs_support_type {
SEAMLESS_DRRS_SUPPORT = 2
};
-struct intel_dp;
struct i915_drrs {
struct mutex mutex;
struct delayed_work work;
@@ -403,8 +402,6 @@ struct i915_drrs {
#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
#define QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK (1<<8)
-struct intel_fbdev;
-
struct intel_gmbus {
struct i2c_adapter adapter;
#define GMBUS_FORCE_BIT_RETRY (1U << 31)
@@ -423,8 +420,6 @@ struct i915_suspend_saved_registers {
u16 saveGCDGMBUS;
};
-struct vlv_s0ix_state;
-
#define MAX_L3_SLICES 2
struct intel_l3_parity {
u32 *remap_info[MAX_L3_SLICES];
@@ -613,7 +608,6 @@ struct i915_selftest_stash {
};
/* intel_audio.c private */
-struct intel_audio_funcs;
struct intel_audio_private {
/* Display internal audio functions */
const struct intel_audio_funcs *funcs;
--
2.30.2
Re: [Intel-gfx] [PATCH 19/20] drm/i915/lmem: don't treat small BAR as an error
On Thu, 2022-02-03 at 11:18 +, Matthew Auld wrote:
> On 03/02/2022 09:48, Thomas Hellström wrote:
> >
> > On 1/26/22 16:21, Matthew Auld wrote:
> > > Just pass along the probed io_size. The backend should be able to
> > > utilize the entire range here, even if some of it is non-
> > > mappable.
> > Changes here LGTM.
> > >
> > > It does leave open with what to do with stolen local-memory.
> >
> > Are objects in stolen local required to be mappable?
>
> From a quick look I don't really see such users on discrete, outside
> of
> maybe intelfb_create(), where I guess the initial fb might be located
> in
> stolen on DG1. But from DG2+ it looks like it will just be located in
> normal LMEM. For that I was thinking we add something like
> i915_gem_object_create_region_at(), and somehow wire that up to the
> {fpfn, lpfn}...
So we could then skip STOLEN completely on DG2+? Could we then also do
the same on DG1, at least assuming that creating and pinning an object
for that initial fb would be done before any other pinning into LMEM?
/Thomas
[Intel-gfx] [RFC 5/5] drm/hdmi21: Add frl_dfm_helper to Makefile
Add the new frl_dfm_helper file to drm Makefile Signed-off-by: Vandita Kulkarni --- drivers/gpu/drm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 8675c2af7ae1..4fa9b48995c8 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -17,7 +17,7 @@ drm-y :=drm_aperture.o drm_auth.o drm_cache.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ drm_client_modeset.o drm_atomic_uapi.o \ - drm_managed.o drm_vblank_work.o + drm_managed.o drm_vblank_work.o drm_frl_dfm_helper.o drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o drm_dma.o \ drm_hashtab.o drm_irq.o drm_legacy_misc.o drm_lock.o \ -- 2.32.0
[Intel-gfx] [RFC 3/5] drm/hdmi21: Add helpers to verify non-dsc DFM requirements
Add helpers to compute DFM variables and to verify if the
DFM requirements are met or not in non dsc cases.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/drm_frl_dfm_helper.c | 161 +++
include/drm/drm_frl_dfm_helper.h | 2 +
2 files changed, 163 insertions(+)
diff --git a/drivers/gpu/drm/drm_frl_dfm_helper.c
b/drivers/gpu/drm/drm_frl_dfm_helper.c
index 8498083adf72..087905ed630a 100644
--- a/drivers/gpu/drm/drm_frl_dfm_helper.c
+++ b/drivers/gpu/drm/drm_frl_dfm_helper.c
@@ -394,3 +394,164 @@ drm_compute_payload_utilization(u32
frl_char_payload_actual, u32 frl_char_per_li
utilization = (frl_char_payload_actual * EFFICIENCY_MULTIPLIER) /
frl_char_per_line_period;
return utilization;
}
+
+/* Collect link characteristics */
+static void
+drm_frl_dfm_compute_link_characteristics(struct drm_hdmi_frl_dfm *frl_dfm)
+{
+ u32 frl_bit_rate_min_kbps;
+
+ frl_dfm->params.pixel_clock_max_khz =
+
drm_get_max_legal_pixel_rate(frl_dfm->config.pixel_clock_nominal_khz);
+ frl_dfm->params.line_time_ns =
+ drm_get_min_video_line_period(frl_dfm->config.hblank,
+ frl_dfm->config.hactive,
+
frl_dfm->params.pixel_clock_max_khz);
+ frl_bit_rate_min_kbps =
drm_get_min_frl_bit_rate(frl_dfm->config.bit_rate_kbps);
+ frl_dfm->params.char_rate_min_kbps =
drm_get_min_frl_char_rate(frl_bit_rate_min_kbps);
+ frl_dfm->params.cfrl_line =
+
drm_get_total_frl_char_per_line_period(frl_dfm->params.line_time_ns,
+
frl_dfm->params.char_rate_min_kbps,
+ frl_dfm->config.lanes);
+}
+
+/* Determine FRL link overhead */
+static void drm_frl_dfm_compute_max_frl_link_overhead(struct drm_hdmi_frl_dfm
*frl_dfm)
+{
+ u32 overhead_min;
+
+ overhead_min = drm_get_total_minimum_overhead(frl_dfm->config.lanes);
+ frl_dfm->params.overhead_max = drm_get_max_overhead(overhead_min);
+}
+
+/* Audio support Verification computations */
+static void
+drm_frl_dfm_compute_audio_hblank_min(struct drm_hdmi_frl_dfm *frl_dfm)
+{
+ u32 num_audio_pkt, audio_pkt_rate;
+
+ /*
+* TBD: get the actual audio pkt type as described in
+* table 6.44 of HDMI2.1 spec to find the num_audio_pkt,
+* for now assume audio sample packet and audio packet
+* layout as 1, resulting in number of audio packets
+* required to carry each audio sample or audio frame
+* as 1
+*/
+ num_audio_pkt = 1;
+ audio_pkt_rate = drm_get_audio_pkt_rate(frl_dfm->config.audio_hz,
num_audio_pkt);
+ frl_dfm->params.num_audio_pkts_line =
+drm_get_audio_pkts_hblank(audio_pkt_rate,
frl_dfm->params.line_time_ns);
+ frl_dfm->params.hblank_audio_min =
+
drm_get_audio_hblank_min(frl_dfm->params.num_audio_pkts_line);
+}
+
+/*
+ * Determine the number of tribytes required for active video , blanking period
+ * with the pixel configuration
+ */
+static void
+drm_frl_dfm_compute_tbactive_tbblank(struct drm_hdmi_frl_dfm *frl_dfm)
+{
+ u32 bpp, bytes_per_line;
+
+ bpp = drm_get_frl_bits_per_pixel(frl_dfm->config.color_format,
frl_dfm->config.bpc);
+ bytes_per_line = drm_get_video_bytes_per_line(bpp,
frl_dfm->config.hactive);
+
+ frl_dfm->params.tb_active =
drm_get_active_video_tribytes_reqd(bytes_per_line);
+ frl_dfm->params.tb_blank =
+ drm_get_blanking_tribytes_avail(frl_dfm->config.color_format,
+ frl_dfm->config.hblank,
+ frl_dfm->config.bpc);
+}
+
+/* Verify the configuration meets the capacity requirements for the FRL
configuration*/
+static bool
+drm_frl_dfm_verify_frl_capacity_requirement(struct drm_hdmi_frl_dfm *frl_dfm)
+{
+ u32 tactive_ref_ns, tblank_ref_ns, tactive_min_ns, tblank_min_ns;
+ u32 tborrowed_ns;
+
+ frl_dfm->params.ftb_avg_k =
+
drm_get_avg_tribyte_rate(frl_dfm->params.pixel_clock_max_khz,
+frl_dfm->params.tb_active,
frl_dfm->params.tb_blank,
+frl_dfm->config.hactive,
frl_dfm->config.hblank);
+ tactive_ref_ns = drm_get_tactive_ref(frl_dfm->params.line_time_ns,
+frl_dfm->config.hblank,
+frl_dfm->config.hactive);
+ tblank_ref_ns = drm_get_tblank_ref(frl_dfm->params.line_time_ns,
+ frl_dfm->config.hblank,
+ frl_dfm->config.hactive);
+ tactive_min_ns = drm_get_tactive_min(frl_dfm->config.lanes,
+
[Intel-gfx] [RFC 4/5] drm/hdmi21: Add support for DFM calculation with DSC
From: Ankit Nautiyal
Add helper functions for calculating FRL capacity and DFM
requirements with given compressed bpp.
Signed-off-by: Ankit Nautiyal
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/drm_frl_dfm_helper.c | 298 +++
include/drm/drm_frl_dfm_helper.h | 3 +
2 files changed, 301 insertions(+)
diff --git a/drivers/gpu/drm/drm_frl_dfm_helper.c
b/drivers/gpu/drm/drm_frl_dfm_helper.c
index 087905ed630a..dbdcc509f791 100644
--- a/drivers/gpu/drm/drm_frl_dfm_helper.c
+++ b/drivers/gpu/drm/drm_frl_dfm_helper.c
@@ -555,3 +555,301 @@ drm_frl_dfm_nondsc_requirement_met(struct
drm_hdmi_frl_dfm *frl_dfm)
return false;
}
EXPORT_SYMBOL(drm_frl_dfm_nondsc_requirement_met);
+
+/* DSC DFM functions */
+/* Get FRL Available characters */
+static u32
+drm_get_frl_available_chars(u32 overhead_max, u32 cfrl_line)
+{
+ u32 frl_char_avlb = ((EFFICIENCY_MULTIPLIER - overhead_max) *
cfrl_line);
+
+ return frl_char_avlb / EFFICIENCY_MULTIPLIER;
+}
+
+/* Get required no. of tribytes during HCActive */
+static u32
+drm_get_frl_hcactive_tb_target(u32 dsc_bpp_x16, u32 slice_width, u32
num_slices)
+{
+ u32 bytes_target;
+
+ bytes_target = num_slices * DIV_ROUND_UP(dsc_bpp_x16 * slice_width,
+8 * BPP_MULTIPLIER);
+
+ return DIV_ROUND_UP(bytes_target, 3);
+}
+
+/* Get required no. of tribytes (estimate1) during HCBlank */
+static u32
+drm_get_frl_hcblank_tb_est1_target(u32 hcactive_target_tb,
+ u32 hactive, u32 hblank)
+{
+ return DIV_ROUND_UP(hcactive_target_tb * hblank, hactive);
+}
+
+/* Get required no. of tribytes during HCBlank */
+static u32
+drm_get_frl_hcblank_tb_target(u32 hcactive_target_tb, u32 hactive, u32 hblank,
+ u32 hcblank_audio_min, u32 cfrl_available)
+{
+ u32 hcblank_target_tb1 =
drm_get_frl_hcblank_tb_est1_target(hcactive_target_tb,
+ hactive,
hblank);
+ u32 hcblank_target_tb2 = max(hcblank_target_tb1, hcblank_audio_min);
+
+ return 4 * (min(hcblank_target_tb2,
+ (2 * cfrl_available - 3 * hcactive_target_tb) / 2) / 4);
+}
+
+/* Get the avg no of tribytes sent per sec (Kbps) */
+static u64
+drm_frl_dsc_get_ftb_avg(u32 hcactive_target_tb, u32 hcblank_target_tb,
+ u32 hactive, u32 hblank,
+ u64 fpixelclock_max_khz)
+{
+ return (hcactive_target_tb + hcblank_target_tb) * (fpixelclock_max_khz
/ (hactive + hblank));
+}
+
+/* Time to send Active tribytes in nanoseconds */
+static u32
+drm_frl_dsc_get_tactive_ref_ns(u32 line_time_ns, u32 hactive, u32 hblank)
+{
+ return (line_time_ns * hactive) / (hactive + hblank);
+}
+
+/* Time to send Blanking tribytes in nanoseconds */
+static u32
+drm_frl_dsc_get_tblank_ref_ns(u32 line_time_ns, u32 hactive, u32 hblank)
+{
+ return (line_time_ns * hblank) / (hactive + hblank);
+}
+
+/* Get time to send all tribytes in hcactive region in nsec*/
+static u32
+drm_frl_dsc_tactive_target_ns(u32 frl_lanes, u32 hcactive_target_tb, u64
ftb_avg_k,
+ u32 min_frl_char_rate_k, u32 overhead_max)
+{
+ u32 avg_tribyte_time_ns, tribyte_time_ns;
+ u32 num_chars_hcactive;
+ u32 frl_char_rate_k;
+
+ /* Avg time to transmit all active region tribytes */
+ avg_tribyte_time_ns = (hcactive_target_tb * FRL_TIMING_NS_MULTIPLIER) /
+ (ftb_avg_k * 1000);
+
+ /*
+* 2 bytes in active region = 1 FRL characters
+* 1 Tribyte in active region = 3/2 FRL characters
+*/
+
+ num_chars_hcactive = (hcactive_target_tb * 3) / 2;
+
+ /*
+* FRL rate = lanes * frl character rate
+* But actual bandwidth wil be less, due to FRL limitations so account
+* for the overhead involved.
+* FRL rate with overhead = FRL rate * (100 - overhead %) / 100
+*/
+ frl_char_rate_k = frl_lanes * min_frl_char_rate_k;
+ frl_char_rate_k = (frl_char_rate_k * (EFFICIENCY_MULTIPLIER -
overhead_max)) /
+ EFFICIENCY_MULTIPLIER;
+
+ /* Time to transmit all characters with FRL limitations */
+ tribyte_time_ns = (num_chars_hcactive * FRL_TIMING_NS_MULTIPLIER) /
+ frl_char_rate_k * 1000;
+
+ return max(avg_tribyte_time_ns, tribyte_time_ns);
+}
+
+/* Get no. of tri bytes borrowed with DSC enabled */
+static u32
+drm_frl_get_dsc_tri_bytes_borrowed(u32 tactive_target_ns, u32 ftb_avg_k,
+ u32 hcactive_target_tb)
+{
+ return (tactive_target_ns * FRL_TIMING_NS_MULTIPLIER * ftb_avg_k *
1000) -
+ hcactive_target_tb;
+}
+
+/* Get TBdelta */
+static u32
+drm_frl_get_dsc_tri_bytes_delta(u32 tactive_target_ns, u32 tactive_ref_ns,
+ u32 hcactive_target_tb, u32 ftb_avg_k,
+
[Intel-gfx] [RFC 1/5] drm/hdmi21: Define frl_dfm structure
Define frl_dfm structure to hold frl characteristics
needed for frl capacity computation in order to
meet the data flow metering requirement.
Signed-off-by: Vandita Kulkarni
---
include/drm/drm_frl_dfm_helper.h | 126 +++
1 file changed, 126 insertions(+)
create mode 100644 include/drm/drm_frl_dfm_helper.h
diff --git a/include/drm/drm_frl_dfm_helper.h b/include/drm/drm_frl_dfm_helper.h
new file mode 100644
index ..16b8fcc7cbcc
--- /dev/null
+++ b/include/drm/drm_frl_dfm_helper.h
@@ -0,0 +1,126 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright © 2022 Intel Corp
+ */
+
+#ifndef DRM_FRL_DFM_H_
+#define DRM_FRL_DFM_H_
+
+/* DFM constraints and tolerance values from HDMI2.1 spec */
+#define TB_BORROWED_MAX400
+#define FRL_CHAR_PER_CHAR_BLK 510
+/* Tolerance pixel clock unit is in mHz */
+#define TOLERANCE_PIXEL_CLOCK 5
+#define TOLERANCE_FRL_BIT_RATE 300
+#define TOLERANCE_AUDIO_CLOCK 1000
+#define ACR_RATE_MAX 1500
+#define EFFICIENCY_MULTIPLIER 1000
+#define OVERHEAD_M (3 * EFFICIENCY_MULTIPLIER / 1000)
+#define BPP_MULTIPLIER 16
+#define FRL_TIMING_NS_MULTIPLIER 10
+
+/* ALl the input config needed to compute DFM requirements */
+struct drm_frl_dfm_input_config {
+
+ /*
+* Pixel clock rate kHz, when FVA is
+* enabled this rate is the rate after adjustment
+*/
+ u32 pixel_clock_nominal_khz;
+
+ /* active pixels per line */
+ u32 hactive;
+
+ /* Blanking pixels per line */
+ u32 hblank;
+
+ /* Bits per component */
+ u32 bpc;
+
+ /* Pixel encoding */
+ u32 color_format;
+
+ /* FRL bit rate in kbps */
+ u32 bit_rate_kbps;
+
+ /* FRL lanes */
+ u32 lanes;
+
+ /* Number of audio channels */
+ u32 audio_channels;
+
+ /* Audio rate in Hz */
+ u32 audio_hz;
+
+ /* Selected bpp target value */
+ u32 target_bpp_16;
+
+ /*
+* Number of horizontal pixels in a slice.
+* Equivalent to PPS parameter slice_width
+*/
+ u32 slice_width;
+};
+
+/* Computed dfm parameters as per the HDMI2.1 spec */
+struct drm_frl_dfm_params {
+
+ /*
+* Link overhead in percentage
+* multiplied by 1000 (efficiency multiplier)
+*/
+ u32 overhead_max;
+
+ /* Maximum pixel rate in kHz */
+ u32 pixel_clock_max_khz;
+
+ /* Minimum video line period in nano sec */
+ u32 line_time_ns;
+
+ /* worst case slow frl character rate in kbps */
+ u32 char_rate_min_kbps;
+
+ /* minimum total frl charecters per line perios */
+ u32 cfrl_line;
+
+ /* Average tribyte rate in khz */
+ u32 ftb_avg_k;
+
+ /* Audio characteristics */
+
+ /* number of audio packets needed during hblank */
+ u32 num_audio_pkts_line;
+
+ /*
+* Minimum required hblank assuming no control preiod
+* RC compression
+*/
+ u32 hblank_audio_min;
+
+ /* Number of tribytes required to carry active video */
+ u32 tb_active;
+
+ /* Total available tribytes during the blanking period */
+ u32 tb_blank;
+
+ /*
+* Number of tribytes required to be transmitted during
+* the hblank period
+*/
+ u32 tb_borrowed;
+
+ /* DSC frl characteristics */
+
+ /* Tribytes required to carry the target bpp */
+ u32 hcactive_target;
+
+ /* tribytes available during blanking with target bpp */
+ u32 hcblank_target;
+};
+
+/* FRL DFM structure to hold involved in DFM computation */
+struct drm_hdmi_frl_dfm {
+ struct drm_frl_dfm_input_config config;
+ struct drm_frl_dfm_params params;
+};
+
+#endif
--
2.32.0
[Intel-gfx] [RFC 2/5] drm/hdmi21: Add non dsc frl capacity computation helpers
Add helper functions for computing non dsc frl
link characteristics
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/drm_frl_dfm_helper.c | 396 +++
1 file changed, 396 insertions(+)
create mode 100644 drivers/gpu/drm/drm_frl_dfm_helper.c
diff --git a/drivers/gpu/drm/drm_frl_dfm_helper.c
b/drivers/gpu/drm/drm_frl_dfm_helper.c
new file mode 100644
index ..8498083adf72
--- /dev/null
+++ b/drivers/gpu/drm/drm_frl_dfm_helper.c
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corp
+ */
+
+#include
+#include
+#include
+#include
+
+/* Total frl charecters per super block */
+static u32 drm_get_frl_char_per_super_blk(u32 lanes)
+{
+ u32 frl_char_per_sb;
+
+ frl_char_per_sb = (4 * FRL_CHAR_PER_CHAR_BLK) + lanes;
+ return frl_char_per_sb;
+}
+
+/*
+ * Determine the overhead due to the inclusion of
+ * the SR and SSB FRL charecters used for
+ * super block framing
+ */
+static u32 drm_get_overhead_super_blk(u32 lanes)
+{
+ return (lanes * EFFICIENCY_MULTIPLIER) /
drm_get_frl_char_per_super_blk(lanes);
+}
+
+/*
+ * Determine the overhead due to the inclusion of RS FEC pairity
+ * symbols. Each charecter block uses 8 FRL charecters for RS Pairity
+ * and there are 4 charecter blocks per super block
+ */
+static u32 drm_get_overhead_rs(u32 lanes)
+{
+ return (8 * 4 * EFFICIENCY_MULTIPLIER) /
drm_get_frl_char_per_super_blk(lanes);
+}
+
+/* Determine the overhead due to FRL Map charecters.
+ * In a bandwidth constrained application, the FRL packets will be long,
+ * there will typically be two FRL Map Charecters per Super Block most of the
time.
+ * When a tracnsition occurs between Hactive and Hblank (uncomperssed video) or
+ * HCactive and HCblank (compressed video transport), there may be a
+ * third FRL Map Charected. Therefore this spec assumes 2.5 FRL Map Charecters
+ * per Super Block.
+ */
+static u32 drm_get_overhead_frl_map_char(u32 lanes)
+{
+ return (25 * EFFICIENCY_MULTIPLIER) / (10 *
drm_get_frl_char_per_super_blk(lanes));
+}
+
+/* Total minimum overhead multiplied by EFFICIENCY_MULIPLIER */
+static u32 drm_get_total_minimum_overhead(u32 lanes)
+{
+ u32 total_overhead_min;
+ u32 overhead_sb = drm_get_overhead_super_blk(lanes);
+ u32 overhead_rs = drm_get_overhead_rs(lanes);
+ u32 overhead_map = drm_get_overhead_frl_map_char(lanes);
+
+ total_overhead_min = overhead_sb + overhead_rs + overhead_map;
+
+ return total_overhead_min;
+}
+
+/*
+ * Additional margin to the overhead is provided to account for the possibility
+ * of more Map Charecters, zero padding at the end of HCactive, and other minor
+ * items
+ */
+static u32 drm_get_max_overhead(u32 total_overhead_min)
+{
+ u32 total_overhead_max;
+
+ total_overhead_max = total_overhead_min + OVERHEAD_M;
+ return total_overhead_max;
+}
+
+/* Collect the link charecteristics */
+
+/* Determine the maximum legal pixel rate */
+static u32 drm_get_max_legal_pixel_rate(u32 fpixel_clock_nominal_k)
+{
+ u32 fpixel_clock_max_k = (fpixel_clock_nominal_k *
+ (1000 + TOLERANCE_PIXEL_CLOCK)) / 1000;
+ return fpixel_clock_max_k;
+}
+
+/* Determine the minimum Video Line period */
+static u32 drm_get_min_video_line_period(u32 hactive, u32 hblank,
+u32 fpixel_clock_max_k)
+{
+ u32 line_time_ns;
+
+ line_time_ns = ((hactive + hblank) * FRL_TIMING_NS_MULTIPLIER) /
+ fpixel_clock_max_k;
+ return line_time_ns;
+}
+
+/* Determine the worst-case slow FRL Bit Rate in kbps*/
+static u32 drm_get_min_frl_bit_rate(u32 frl_bit_rate_nominal_k)
+{
+ u32 frl_bit_rate_min_k;
+
+ frl_bit_rate_min_k = (frl_bit_rate_nominal_k / 100) *
+(100 - TOLERANCE_FRL_BIT_RATE);
+ return frl_bit_rate_min_k;
+}
+
+/* Determine the worst-case slow FRL Charecter Rate */
+static u32 drm_get_min_frl_char_rate(u32 frl_bit_rate_min_k)
+{
+ u32 frl_char_rate_min_k;
+
+ frl_char_rate_min_k = frl_bit_rate_min_k / 18;
+ return frl_char_rate_min_k;
+}
+
+/* Determine the Minimum Total FRL charecters per line period */
+static u32
+drm_get_total_frl_char_per_line_period(u32 line_time_ns, u32
frl_char_rate_min_k,
+ u32 lanes)
+{
+ u32 frl_char_per_line_period;
+
+ frl_char_per_line_period = (line_time_ns * frl_char_rate_min_k * lanes *
+ 1000) / FRL_TIMING_NS_MULTIPLIER;
+ return frl_char_per_line_period;
+}
+
+/* Audio Support Verification Computations */
+
+/*
+ * Determine Audio Related Packet Rate considering the audio clock
+ * increased to maximim rate permitted by Tolerance Audio clock
+ */
+static u32
+drm_get_audio_pkt_rate(u32 f_audio, u32 num_audio_pkt)
+{
+ u32 audio_pkt_rate;
+
+ audio_pkt_rate = ((f_audio * num_audio_pkt + (2 *
[Intel-gfx] [RFC 0/5] Add data flow metering support for HDMI2.1
The below patches add support for data flow metering as mentioned in the section 6.5.6 FRL data flow metering of HDMI 2.1 specification. Add functions to calclulate the DFM parameters for the given frl config, which is further used to evaluate the data flow metering requirement as specified in the spec. As per the spec the below patches implement the frl capacity computation functions for both compressed and uncompressed video. Finally exposing 1 function each for compressed and uncompressed video to figure out if the data flow metering requirement is met or not. Ankit Nautiyal (1): drm/hdmi21: Add support for DFM calculation with DSC Vandita Kulkarni (4): drm/hdmi21: Define frl_dfm structure drm/hdmi21: Add non dsc frl capacity computation helpers drm/hdmi21: Add helpers to verify non-dsc DFM requirements drm/hdmi21: Add frl_dfm_helper to Makefile drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_frl_dfm_helper.c | 855 +++ include/drm/drm_frl_dfm_helper.h | 131 3 files changed, 987 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/drm_frl_dfm_helper.c create mode 100644 include/drm/drm_frl_dfm_helper.h -- 2.32.0
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, drm/i915: 128b/132b updates (rev2)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev2) URL : https://patchwork.freedesktop.org/series/99324/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
On Wed, Feb 2, 2022 at 10:25 AM Thomas Zimmermann wrote:
> Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> > It's only one flag and slightly tidier code.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > Cc: Tetsuo Handa
> > Cc: Greg Kroah-Hartman
> > Cc: Du Cheng
> > Cc: Thomas Zimmermann
> > Cc: Claudio Suarez
>
> Acked-by: Thomas Zimmermann
> > +++ b/drivers/video/fbdev/core/fbcon.h
> > @@ -18,8 +18,6 @@
> >
> > #include
> >
> > -#define FBCON_FLAGS_INIT 1
> > -
> > /*
> > *This is the interface between the low-level console driver and
> > the
> > *low-level frame buffer device
> > @@ -77,7 +75,7 @@ struct fbcon_ops {
> > intblank_state;
> > intgraphics;
> > intsave_graphics; /* for debug enter/leave */
> > - intflags;
> > + bool initialized;
>
> This will add 3 bytes of padding. Maybe you can put the bool elsewhere.
Several of the int variables are used as boolean flags, too.
Perhaps convert them all to bitfields?
unsigned int initialized : 1;
...
> > introtate;
> > intcur_rotate;
> > char *cursor_data;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp, drm/i915: 128b/132b updates (rev2)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev2) URL : https://patchwork.freedesktop.org/series/99324/ State : warning == Summary == $ dim checkpatch origin/drm-tip fa52ddc057cc drm/dp: add drm_dp_128b132b_read_aux_rd_interval() 8868dda00c11 drm/dp: add 128b/132b link status helpers from DP 2.0 E11 aa504c844e66 drm/dp: add some new DPCD macros from DP 2.0 E11 c276bc031945 drm/i915/dp: move intel_dp_prepare_link_train() call 4ef9c6a284b7 drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata -:52: CHECK:LINE_SPACING: Please don't use multiple blank lines #52: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:1105: + total: 0 errors, 0 warnings, 1 checks, 296 lines checked 69106275030a drm/i915/dp: add 128b/132b support to link status checks 9f32a3cf117e drm/i915/mst: update slot information for 128b/132b 3ded6992902f HACK: drm/i915/dp: give more time for CDS
