Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
On 21/02/2024 00:14, Andi Shyti wrote:
Hi Tvrtko,
On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
On 20/02/2024 14:35, Andi Shyti wrote:
Enable only one CCS engine by default with all the compute sices
slices
Thanks!
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 833987015b8b..7041acc77810 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -243,6 +243,15 @@ void intel_engines_driver_register(struct drm_i915_private
*i915)
if (engine->uabi_class == I915_NO_UABI_CLASS)
continue;
+ /*
+* Do not list and do not count CCS engines other than the first
+*/
+ if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
+ engine->uabi_instance > 0) {
+ i915->engine_uabi_class_count[engine->uabi_class]--;
+ continue;
+ }
It's a bit ugly to decrement after increment, instead of somehow
restructuring the loop to satisfy both cases more elegantly.
yes, agree, indeed I had a hard time here to accept this change
myself.
But moving the check above where the counter was incremented it
would have been much uglier.
This check looks ugly everywhere you place it :-)
One idea would be to introduce a separate local counter array for
name_instance, so not use i915->engine_uabi_class_count[]. First one
increments for every engine, second only for the exposed ones. That way
feels wouldn't be too ugly.
In any case, I'm working on a patch that is splitting this
function in two parts and there is some refactoring happening
here (for the first initialization and the dynamic update).
Please let me know if it's OK with you or you want me to fix it
in this run.
And I wonder if
internally (in dmesg when engine name is logged) we don't end up with ccs0
ccs0 ccs0 ccs0.. for all instances.
I don't see this. Even in sysfs we see only one ccs. Where is it?
When you run this patch on something with two or more ccs-es, the
"renamed ccs... to ccs.." debug logs do not all log the new name as ccs0?
Regards,
Tvrtko
+
rb_link_node(&engine->uabi_node, prev, p);
rb_insert_color(&engine->uabi_node, &i915->uabi_engines);
[...]
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 3baa2f54a86e..d5a5143971f5 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -124,6 +124,7 @@ static int query_geometry_subslices(struct drm_i915_private
*i915,
return fill_topology_info(sseu, query_item,
sseu->geometry_subslice_mask);
}
+
Zap please.
yes... yes... I noticed it after sending the patch :-)
Thanks,
Andi
Re: [RFC] drm/i915: Support replaying GPU hangs with captured context image
On 20/02/2024 22:50, Rodrigo Vivi wrote:
On Tue, Feb 13, 2024 at 01:14:34PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When debugging GPU hangs Mesa developers are finding it useful to replay
the captured error state against the simulator. But due various simulator
limitations which prevent replicating all hangs, one step further is being
able to replay against a real GPU.
This is almost doable today with the missing part being able to upload the
captured context image into the driver state prior to executing the
uploaded hanging batch and all the buffers.
To enable this last part we add a new context parameter called
I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU
configuration pattern of being able to select which context to apply
against, paired with the actual image and its size.
Since this is adding a new concept of debug only uapi, we hide it behind
a new kconfig option and also require activation with a module parameter.
Together with a warning banner printed at driver load, all those combined
should be sufficient to guard against inadvertently enabling the feature.
In terms of implementation the only trivial change is shadowing of the
default state from engine to context. We also allow the legacy context
set param to be used since that removes the need to record the per context
data in the proto context, while still allowing flexibility of specifying
context images for any context.
Mesa MR using the uapi can be seen at:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594
I just wonder if it would be better to split the default_state in a separate
patch but from what I could see it looks correct.
It definitely makes sense to split it. I was just a bit lazy while
testing the waters. After all this is a very novel idea of debug only
uapi outside debugfs so I wasn't too sure how it will be received. Stay
tuned for v2.
Regards,
Tvrtko
Also, I have to say that this approach is nice, clean and well protected.
And much simpler then I imagined when I saw the idea around.
Feel free to use:
Reviewed-by: Rodrigo Vivi
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc: Carlos Santa
---
drivers/gpu/drm/i915/Kconfig.debug| 17 +++
drivers/gpu/drm/i915/gem/i915_gem_context.c | 106 ++
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
drivers/gpu/drm/i915/gt/intel_context.h | 22
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 8 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 8 +-
drivers/gpu/drm/i915/i915_params.c| 5 +
drivers/gpu/drm/i915/i915_params.h| 3 +-
include/uapi/drm/i915_drm.h | 27 +
10 files changed, 194 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 5b7162076850..32e9f70e91ed 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -16,6 +16,23 @@ config DRM_I915_WERROR
If in doubt, say "N".
+config DRM_I915_REPLAY_GPU_HANGS_API
+ bool "Enable GPU hang replay userspace API"
+ depends on DRM_I915
+ depends on EXPERT
+ default n
+ help
+ Choose this option if you want to enable special and unstable
+ userspace API used for replaying GPU hangs on a running system.
+
+ This API is intended to be used by userspace graphics stack developers
+ and provides no stability guarantees.
+
+ The API needs to be activated at boot time using the
+ enable_debug_only_api module parameter.
+
+ If in doubt, say "N".
+
config DRM_I915_DEBUG
bool "Enable additional driver debugging"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..1cfd624bd978 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -78,6 +78,7 @@
#include "gt/intel_engine_user.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_ring.h"
+#include "gt/shmem_utils.h"
#include "pxp/intel_pxp.h"
@@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct drm_i915_file_private *fpriv,
case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
+ case I915_CONTEXT_PARAM_CONTEXT_IMAGE:
default:
ret = -EINVAL;
break;
@@ -2092,6 +2094,88 @@ static int get_protected(struct i915_gem_context *ctx,
return 0;
}
+static int set_context_image(struct i915_gem_context *ctx,
+struct drm_i915_gem_context_param *args)
+{
+ struct i915_gem_context_param_context_image user;
+ struct intel_context *ce;
+ struct file *shmem_state;
+ unsigned long lookup;
+ void
✗ Fi.CI.BAT: failure for drm/ttm: Fix an invalid freeing on already freed page in error path
== Series Details ==
Series: drm/ttm: Fix an invalid freeing on already freed page in error path
URL : https://patchwork.freedesktop.org/series/130170/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14305 -> Patchwork_130170v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_130170v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_130170v1, please notify your bug team
(i915-ci-in...@lists.freedesktop.org) 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_130170v1/index.html
Participating hosts (40 -> 37)
--
Missing(3): bat-mtlp-8 fi-snb-2520m fi-bsw-n3050
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_130170v1:
### IGT changes ###
Possible regressions
* igt@dmabuf@all-tests@dma_fence:
- fi-kbl-guc: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-kbl-guc/igt@dmabuf@all-tests@dma_fence.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130170v1/fi-kbl-guc/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@sanitycheck:
- fi-kbl-guc: [PASS][3] -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-kbl-guc/igt@dmabuf@all-te...@sanitycheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130170v1/fi-kbl-guc/igt@dmabuf@all-te...@sanitycheck.html
Known issues
Here are the changes found in Patchwork_130170v1 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_create@basic@smem:
- {bat-arls-1}: [DMESG-WARN][5] ([i915#10194]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-1/igt@gem_exec_create@ba...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130170v1/bat-arls-1/igt@gem_exec_create@ba...@smem.html
* igt@vgem_basic@create:
- {bat-arls-2}: [FAIL][7] ([i915#10294]) -> [PASS][8] +4 other tests
pass
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-2/igt@vgem_ba...@create.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130170v1/bat-arls-2/igt@vgem_ba...@create.html
* igt@vgem_basic@dmabuf-mmap:
- {bat-arls-2}: [INCOMPLETE][9] ([i915#10294]) -> [PASS][10] +6 other
tests pass
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-2/igt@vgem_ba...@dmabuf-mmap.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130170v1/bat-arls-2/igt@vgem_ba...@dmabuf-mmap.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10196]: https://gitlab.freedesktop.org/drm/intel/issues/10196
[i915#10212]: https://gitlab.freedesktop.org/drm/intel/issues/10212
[i915#10213]: https://gitlab.freedesktop.org/drm/intel/issues/10213
[i915#10214]: https://gitlab.freedesktop.org/drm/intel/issues/10214
[i915#10215]: https://gitlab.freedesktop.org/drm/intel/issues/10215
[i915#10216]: https://gitlab.freedesktop.org/drm/intel/issues/10216
[i915#10294]: https://gitlab.freedesktop.org/drm/intel/issues/10294
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
Build changes
-
* Linux: CI_DRM_14305 -> Patchwork_130170v1
CI-20190529: 20190529
CI_DRM_14305: 4b8a238dee9c18201f3652695414587cd2ef6d8f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7718: 40e8b9122853f455c84afcfa56469a6bc9a0d564 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_130170v1: 4b8a238dee9c18201f3652695414587cd2ef6d8f @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
fd3077a5c869 drm/ttm: Fix an invalid freeing on already freed page in error path
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130170v1/index.html
[RFC v1 0/3] drm/i915: Add support for XRandR Border property
Some customers and users have expressed interest in adding borders (or margins) to certain displays in their multi-display configurations. To address this need, this patchset implements the XRandR Border property as defined here: https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n2032 --- Patchset overview: Patch 1: Create skl_program_crtc_scaler() to program scaler for crtc Patch 2: Create and attach the Border property to DP and HDMI Patch 3: Implement Border property by enabling crtc scalar This series is tested using following method: - Run the following xrandr command with different parameters: xrandr --output HDMI-3 --pos 1920x0 --mode 1280x1024 --fb 3840x2160 --scale 2.11x2.11 --set "Border" 150,0,150,0 The following patch was also added to the modesetting driver to implement the Border property: https://gitlab.freedesktop.org/Vivek/xserver/-/commit/62abfc438f0d17fe7f88bf2826c9784c2b36443b Cc: Ville Syrjälä Cc: Matt Roper Cc: Dongwon Kim Vivek Kasireddy (3): drm/i915: Rename skl_pfit_enable() to skl_program_crtc_scaler() drm/i915: Attach the Border property to DP and HDMI connectors drm/i915: Apply border adjustments and enable scaler on the crtc drivers/gpu/drm/i915/display/intel_atomic.c | 29 ++- .../gpu/drm/i915/display/intel_connector.c| 49 +++ .../gpu/drm/i915/display/intel_connector.h| 3 ++ drivers/gpu/drm/i915/display/intel_display.c | 25 -- .../gpu/drm/i915/display/intel_display_core.h | 1 + .../drm/i915/display/intel_display_types.h| 6 +++ drivers/gpu/drm/i915/display/intel_dp.c | 11 + drivers/gpu/drm/i915/display/intel_hdmi.c | 11 + drivers/gpu/drm/i915/display/skl_scaler.c | 27 ++ drivers/gpu/drm/i915/display/skl_scaler.h | 3 +- 10 files changed, 149 insertions(+), 16 deletions(-) -- 2.43.0
[RFC v1 2/3] drm/i915: Attach the Border property to DP and HDMI connectors
The Border property is created as a blob if it doesn't exist and
then attached to DP and HDMI connectors. When userspace wants
to populate this blob, it is expected that it provides data of
size sizeof(struct drm_rect).
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/display/intel_atomic.c | 29 ++-
.../gpu/drm/i915/display/intel_connector.c| 20 +
.../gpu/drm/i915/display/intel_connector.h| 1 +
.../gpu/drm/i915/display/intel_display_core.h | 1 +
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 ++
7 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index ec0d5168b503..76cdcad175cc 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -67,6 +67,9 @@ int intel_digital_connector_atomic_get_property(struct
drm_connector *connector,
*val = intel_conn_state->force_audio;
else if (property == dev_priv->display.properties.broadcast_rgb)
*val = intel_conn_state->broadcast_rgb;
+ else if (property == dev_priv->display.properties.border)
+ *val = (intel_conn_state->border) ?
+ intel_conn_state->border->base.id : 0;
else {
drm_dbg_atomic(&dev_priv->drm,
"Unknown property [PROP:%d:%s]\n",
@@ -95,6 +98,8 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_digital_connector_state *intel_conn_state =
to_intel_digital_connector_state(state);
+ bool replaced;
+ int ret;
if (property == dev_priv->display.properties.force_audio) {
intel_conn_state->force_audio = val;
@@ -106,11 +111,32 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
return 0;
}
+ if (property == dev_priv->display.properties.border) {
+ ret = drm_property_replace_blob_from_id(dev,
+ &intel_conn_state->border,
+ val,
+ sizeof(struct drm_rect), -1,
+ &replaced);
+ return ret;
+ }
+
drm_dbg_atomic(&dev_priv->drm, "Unknown property [PROP:%d:%s]\n",
property->base.id, property->name);
return -EINVAL;
}
+static bool intel_connector_blob_equal(struct drm_property_blob *old_blob,
+ struct drm_property_blob *new_blob)
+{
+ if (!old_blob || !new_blob)
+ return false;
+
+ if (old_blob->length != new_blob->length)
+ return false;
+
+ return !memcmp(old_blob->data, new_blob->data, old_blob->length);
+}
+
int intel_digital_connector_atomic_check(struct drm_connector *conn,
struct drm_atomic_state *state)
{
@@ -142,7 +168,8 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode ||
new_conn_state->base.privacy_screen_sw_state !=
old_conn_state->base.privacy_screen_sw_state ||
- !drm_connector_atomic_hdr_metadata_equal(old_state, new_state))
+ !drm_connector_atomic_hdr_metadata_equal(old_state, new_state) ||
+ !intel_connector_blob_equal(old_conn_state->border,
new_conn_state->border))
crtc_state->mode_changed = true;
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index c65887870ddc..05185db6635e 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -308,3 +308,23 @@ intel_attach_scaling_mode_property(struct drm_connector
*connector)
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
+
+void
+intel_attach_border_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_property *prop;
+
+ prop = dev_priv->display.properties.border;
+ if (prop == NULL) {
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "Border", 0);
+ if (prop == NULL)
+ return;
+
+ dev_priv->display.properties.border = prop;
+ }
+
+ drm_object_attach_property(&connec
[RFC v1 1/3] drm/i915: Rename skl_pfit_enable() to skl_program_crtc_scaler()
Given that skl_pfit_enable() mostly enables (or programs) the scaler
at the crtc level, it makes sense to change its name to
skl_program_crtc_scaler(). Also, the rename and the addition of
struct drm_rect * parameter helps if we'd like to use this
function to enable the scaler at the crtc level for features other
than panel fitting.
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/display/intel_display.c | 14 ++
drivers/gpu/drm/i915/display/skl_scaler.c| 7 ++-
drivers/gpu/drm/i915/display/skl_scaler.h| 3 ++-
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c5de4561f458..0ea62c278948 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1678,10 +1678,14 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
if (psl_clkgate_wa)
glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
- if (DISPLAY_VER(dev_priv) >= 9)
- skl_pfit_enable(new_crtc_state);
- else
+ if (DISPLAY_VER(dev_priv) >= 9) {
+ const struct drm_rect *dst = &new_crtc_state->pch_pfit.dst;
+
+ if (new_crtc_state->pch_pfit.enabled)
+ skl_program_crtc_scaler(new_crtc_state, dst);
+ } else {
ilk_pfit_enable(new_crtc_state);
+ }
/*
* On ILK+ LUT must be loaded before the pipe is running but with
@@ -6560,8 +6564,10 @@ static void intel_pipe_fastset(const struct
intel_crtc_state *old_crtc_state,
/* on skylake this is done by detaching scalers */
if (DISPLAY_VER(dev_priv) >= 9) {
+ const struct drm_rect *dst = &new_crtc_state->pch_pfit.dst;
+
if (new_crtc_state->pch_pfit.enabled)
- skl_pfit_enable(new_crtc_state);
+ skl_program_crtc_scaler(new_crtc_state, dst);
} else if (HAS_PCH_SPLIT(dev_priv)) {
if (new_crtc_state->pch_pfit.enabled)
ilk_pfit_enable(new_crtc_state);
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index 8a934bada624..67a87cc0411a 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -704,13 +704,13 @@ static void skl_scaler_setup_filter(struct
drm_i915_private *dev_priv, enum pipe
}
}
-void skl_pfit_enable(const struct intel_crtc_state *crtc_state)
+void skl_program_crtc_scaler(const struct intel_crtc_state *crtc_state,
+const struct drm_rect *dst)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct intel_crtc_scaler_state *scaler_state =
&crtc_state->scaler_state;
- const struct drm_rect *dst = &crtc_state->pch_pfit.dst;
u16 uv_rgb_hphase, uv_rgb_vphase;
enum pipe pipe = crtc->pipe;
int width = drm_rect_width(dst);
@@ -722,9 +722,6 @@ void skl_pfit_enable(const struct intel_crtc_state
*crtc_state)
int id;
u32 ps_ctrl;
- if (!crtc_state->pch_pfit.enabled)
- return;
-
if (drm_WARN_ON(&dev_priv->drm,
crtc_state->scaler_state.scaler_id < 0))
return;
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.h
b/drivers/gpu/drm/i915/display/skl_scaler.h
index 63f93ca03c89..45b9ac3ec779 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.h
+++ b/drivers/gpu/drm/i915/display/skl_scaler.h
@@ -24,7 +24,8 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
struct intel_crtc *intel_crtc,
struct intel_crtc_state *crtc_state);
-void skl_pfit_enable(const struct intel_crtc_state *crtc_state);
+void skl_program_crtc_scaler(const struct intel_crtc_state *crtc_state,
+const struct drm_rect *dst);
void skl_program_plane_scaler(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
--
2.43.0
[RFC v1 3/3] drm/i915: Apply border adjustments and enable scaler on the crtc
If the userspace has enabled the border property on a given
connector, then relevant adjustments to position and size are made
in addition to enabling the scaler on the associated crtc.
Similar to how the panel fitter is implemented, the visible area
of the crtc is tracked using a struct drm_rect object that is
part of the crtc_state. This object is added to the state checker
and support for hardware readout is also included.
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Vivek Kasireddy
---
.../gpu/drm/i915/display/intel_connector.c| 29 +++
.../gpu/drm/i915/display/intel_connector.h| 2 ++
drivers/gpu/drm/i915/display/intel_display.c | 17 ---
.../drm/i915/display/intel_display_types.h| 5
drivers/gpu/drm/i915/display/intel_dp.c | 9 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 9 ++
drivers/gpu/drm/i915/display/skl_scaler.c | 20 ++---
7 files changed, 83 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 05185db6635e..8c5dfbb98811 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -219,6 +219,35 @@ static const struct drm_prop_enum_list force_audio_names[]
= {
{ HDMI_AUDIO_ON, "on" },
};
+int intel_connector_apply_border(struct intel_crtc_state *crtc_state,
+void *border_data)
+{
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->hw.adjusted_mode;
+ int width = adjusted_mode->crtc_hdisplay;
+ int height = adjusted_mode->crtc_vdisplay;
+ struct drm_rect *border = border_data;
+ int left = border->x1;
+ int top = border->y1;
+ int right = border->x2;
+ int bottom = border->y2;
+
+ if (left < 0 || top < 0 || right < 0 || bottom < 0)
+ return -EINVAL;
+
+ if (left + right >= width || top + bottom >= height)
+ return -EINVAL;
+
+ width -= (left + right);
+ height -= (top + bottom);
+
+ drm_rect_init(&crtc_state->border.dst,
+ left, top, width, height);
+ crtc_state->border.enabled = true;
+
+ return 0;
+}
+
void
intel_attach_force_audio_property(struct drm_connector *connector)
{
diff --git a/drivers/gpu/drm/i915/display/intel_connector.h
b/drivers/gpu/drm/i915/display/intel_connector.h
index ab88b57d475b..93106d855452 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.h
+++ b/drivers/gpu/drm/i915/display/intel_connector.h
@@ -26,6 +26,8 @@ bool intel_connector_get_hw_state(struct intel_connector
*connector);
enum pipe intel_connector_get_pipe(struct intel_connector *connector);
int intel_connector_update_modes(struct drm_connector *connector,
const struct drm_edid *drm_edid);
+int intel_connector_apply_border(struct intel_crtc_state *crtc_state,
+void *border_data);
int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *ddc);
void intel_attach_force_audio_property(struct drm_connector *connector);
void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0ea62c278948..af615e576fe7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1679,9 +1679,12 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
if (DISPLAY_VER(dev_priv) >= 9) {
- const struct drm_rect *dst = &new_crtc_state->pch_pfit.dst;
+ const struct drm_rect *dst = new_crtc_state->pch_pfit.enabled ?
+&new_crtc_state->pch_pfit.dst :
+&new_crtc_state->border.dst;
- if (new_crtc_state->pch_pfit.enabled)
+ if (new_crtc_state->pch_pfit.enabled ||
+ new_crtc_state->border.enabled)
skl_program_crtc_scaler(new_crtc_state, dst);
} else {
ilk_pfit_enable(new_crtc_state);
@@ -5196,6 +5199,9 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_BOOL(pch_pfit.enabled);
PIPE_CONF_CHECK_RECT(pch_pfit.dst);
+ PIPE_CONF_CHECK_BOOL(border.enabled);
+ PIPE_CONF_CHECK_RECT(border.dst);
+
PIPE_CONF_CHECK_I(scaler_state.scaler_id);
PIPE_CONF_CHECK_I(pixel_rate);
@@ -6564,9 +6570,12 @@ static void intel_pipe_fastset(const struct
intel_crtc_state *old_crtc_state,
/* on skylake this is done by detaching scalers */
if (DISPLAY_VER(dev_priv) >= 9) {
- const struct drm_rect *dst = &n
Re: [PATCH] drm/ttm: Fix an invalid freeing on already freed page in error path
On 21/02/2024 07:33, Thomas Hellström wrote:
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-de...@lists.freedesktop.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
Re: [PATCH] drm/i915/guc: Add Compute context hint
On 21/02/2024 00:14, Vinay Belgaumkar wrote:
Allow user to provide a context hint. When this is set, KMD will
send a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches to this context. The down freq threshold will also be
lower so GuC will ramp down the GT freq for this context more slowly.
We also disable waitboost for this context as that will interfere with
the strategy.
We need to enable the use of Compute strategy during SLPC init, but
it will apply only to contexts that set this bit during context
creation.
Userland can check whether this feature is supported using a new param-
I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true for all guc submission
enabled platforms since they use SLPC for freq management.
The Mesa usage model for this flag is here -
https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
This allows for setting it for the whole application, correct? Upsides,
downsides? Are there any plans for per context?
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++
.../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++
drivers/gpu/drm/i915/i915_getparam.c | 11 ++
include/uapi/drm/i915_drm.h | 15 +
9 files changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..ceab7dbe9b47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct drm_i915_file_private
*fpriv,
struct i915_gem_proto_context *pc,
struct drm_i915_gem_context_param *args)
{
+ struct drm_i915_private *i915 = fpriv->i915;
int ret = 0;
switch (args->param) {
@@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
drm_i915_file_private *fpriv,
pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
break;
+ case I915_CONTEXT_PARAM_IS_COMPUTE:
+ if (!intel_uc_uses_guc_submission(&to_gt(i915)->uc))
+ ret = -EINVAL;
+ else
+ pc->user_flags |= BIT(UCONTEXT_COMPUTE);
+ break;
+
case I915_CONTEXT_PARAM_RECOVERABLE:
if (args->size)
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 03bc7f9d191b..db86d6f6245f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -338,6 +338,7 @@ struct i915_gem_context {
#define UCONTEXT_BANNABLE 2
#define UCONTEXT_RECOVERABLE 3
#define UCONTEXT_PERSISTENCE 4
+#define UCONTEXT_COMPUTE 5
What is the GuC behaviour when SLPC_CTX_FREQ_REQ_IS_COMPUTE is set for
non-compute engines? Wondering if per intel_context is what we want
instead. (Which could then be the i915_context_param_engines extension
to mark individual contexts as compute strategy.)
/**
* @flags: small set of booleans
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 4feef874e6d6..1ed40cd61b70 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -24,6 +24,7 @@
#include "intel_pcode.h"
#include "intel_rps.h"
#include "vlv_sideband.h"
+#include "../gem/i915_gem_context.h"
#include "../../../platform/x86/intel_ips.h"
#define BUSY_MAX_EI 20u /* ms */
@@ -1018,6 +1019,13 @@ void intel_rps_boost(struct i915_request *rq)
struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
if (rps_uses_slpc(rps)) {
+ const struct i915_gem_context *ctx;
+
+ ctx = i915_request_gem_context(rq);
+ if (ctx &&
+ test_bit(UCONTEXT_COMPUTE, &ctx->user_flags))
+ return;
+
I think request and intel_context do not own a strong reference to GEM
context. So at minimum you need a local one obtained under a RCU lock
with kref_get_unless_zero, as do some other places do.
However.. it may be simpler to just store the flag in
intel_context->flags. If you carry it over at the time GEM context is
assigned to intel_context, not only you simplify runtime rules, but you
get the ability to not set the compute flags for video etc.
It may e
✗ Fi.CI.CHECKPATCH: warning for IO and fast wake lines calculation and increase fw sync length
== Series Details == Series: IO and fast wake lines calculation and increase fw sync length URL : https://patchwork.freedesktop.org/series/130173/ State : warning == Summary == Error: dim checkpatch failed ec74338c41e4 drm/i915/display: Add aux function pointer for fast wake sync pulse count f2059a05bb86 drm/i915/psr: Improve fast and IO wake lines calculation -:38: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #38: FILE: drivers/gpu/drm/i915/display/intel_psr.c:1163: +static int get_io_wake_time(struct intel_dp *intel_dp, + struct intel_crtc_state *crtc_state) total: 0 errors, 0 warnings, 1 checks, 52 lines checked 854e6c44050d drm/i915/display: Increase number of fast wake precharge pulses
✗ Fi.CI.SPARSE: warning for IO and fast wake lines calculation and increase fw sync length
== Series Details == Series: IO and fast wake lines calculation and increase fw sync length URL : https://patchwork.freedesktop.org/series/130173/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
Re: [PATCH] drm/ttm: Fix an invalid freeing on already freed page in error path
Am 21.02.24 um 08:33 schrieb Thomas Hellström:
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-de...@lists.freedesktop.org
Cc: # v6.4+
You don't know how much time I've spend staring at this line to find the
bug in it and haven't seen it. Got bug reports about that for month as well.
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index b62f420a9f96..112438d965ff 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -387,7 +387,7 @@ static void ttm_pool_free_range(struct ttm_pool *pool,
struct ttm_tt *tt,
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = &tt->pages[start_page];
unsigned int order;
pgoff_t i, nr;
✓ Fi.CI.BAT: success for IO and fast wake lines calculation and increase fw sync length
== Series Details ==
Series: IO and fast wake lines calculation and increase fw sync length
URL : https://patchwork.freedesktop.org/series/130173/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14306 -> Patchwork_130173v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/index.html
Participating hosts (39 -> 37)
--
Additional (1): bat-arls-3
Missing(3): bat-mtlp-8 fi-glk-j4005 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_130173v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- bat-jsl-1: [PASS][1] -> [FAIL][2] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14306/bat-jsl-1/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/bat-jsl-1/boot.html
### IGT changes ###
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10026]: https://gitlab.freedesktop.org/drm/intel/issues/10026
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10196]: https://gitlab.freedesktop.org/drm/intel/issues/10196
[i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
[i915#10200]: https://gitlab.freedesktop.org/drm/intel/issues/10200
[i915#10202]: https://gitlab.freedesktop.org/drm/intel/issues/10202
[i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
[i915#10207]: https://gitlab.freedesktop.org/drm/intel/issues/10207
[i915#10208]: https://gitlab.freedesktop.org/drm/intel/issues/10208
[i915#10209]: https://gitlab.freedesktop.org/drm/intel/issues/10209
[i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
[i915#10212]: https://gitlab.freedesktop.org/drm/intel/issues/10212
[i915#10213]: https://gitlab.freedesktop.org/drm/intel/issues/10213
[i915#10214]: https://gitlab.freedesktop.org/drm/intel/issues/10214
[i915#10215]: https://gitlab.freedesktop.org/drm/intel/issues/10215
[i915#10216]: https://gitlab.freedesktop.org/drm/intel/issues/10216
[i915#10274]: https://gitlab.freedesktop.org/drm/intel/issues/10274
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
[i915#8809]: https://gitlab.freedesktop.org/drm/intel/issues/8809
[i915#9318]: https://gitlab.freedesktop.org/drm/intel/issues/9318
[i915#9732]: https://gitlab.freedesktop.org/drm/intel/issues/9732
[i915#9812]: https://gitlab.freedesktop.org/drm/intel/issues/9812
[i915#9886]: https://gitlab.freedesktop.org/drm/intel/issues/9886
Build changes
-
* Linux: CI_DRM_14306 -> Patchwork_130173v1
CI-20190529: 20190529
CI_DRM_14306: b895612a4da69e73804cd5fc2dedfa44fda1da99 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7718: 40e8b9122853f455c84afcfa56469a6bc9a0d564 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_130173v1: b895612a4da69e73804cd5fc2dedfa44fda1da99 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
835c1656b4c5 drm/i915/display: Increase number of fast wake precharge pulses
3d96e6b8f000 drm/i915/psr: Improve fast and IO wake lines calculation
bce9d2a58826 drm/i915/display: Add aux function pointer for fast wake sync
pulse count
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/index.html
[PATCH] drm/i915/display/debugfs: New entry "DRRS capable" to i915_drrs_status
If the connected panel supports both DRRS & PSR, driver gives preference
to PSR ("DRRS enabled: no"). Even though the hardware supports DRRS,
IGT treats ("DRRS enabled: yes") as not capable.
Introduce a new entry "DRRS capable" to debugfs i915_drrs_status, so
that IGT will read the DRRS capability as "DRRS capable: yes".
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/i915/display/intel_drrs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 6282ec0fc9b4..169ef38ff188 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -299,6 +299,7 @@ void intel_drrs_crtc_init(struct intel_crtc *crtc)
static int intel_drrs_debugfs_status_show(struct seq_file *m, void *unused)
{
struct intel_crtc *crtc = m->private;
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
const struct intel_crtc_state *crtc_state;
int ret;
@@ -310,6 +311,11 @@ static int intel_drrs_debugfs_status_show(struct seq_file
*m, void *unused)
mutex_lock(&crtc->drrs.mutex);
+ seq_printf(m, "DRRS capable: %s\n",
+ str_yes_no(crtc_state->has_drrs ||
+ HAS_DOUBLE_BUFFERED_M_N(i915) ||
+ intel_cpu_transcoder_has_m2_n2(i915,
crtc_state->cpu_transcoder)));
+
seq_printf(m, "DRRS enabled: %s\n",
str_yes_no(crtc_state->has_drrs));
--
2.43.0
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
Hi Tvrtko,
On Wed, Feb 21, 2024 at 08:19:34AM +, Tvrtko Ursulin wrote:
> On 21/02/2024 00:14, Andi Shyti wrote:
> > On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
> > > On 20/02/2024 14:35, Andi Shyti wrote:
> > > > Enable only one CCS engine by default with all the compute sices
> > >
> > > slices
> >
> > Thanks!
> >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > > index 833987015b8b..7041acc77810 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > > @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct
> > > > drm_i915_private *i915)
> > > > if (engine->uabi_class == I915_NO_UABI_CLASS)
> > > > continue;
> > > > + /*
> > > > +* Do not list and do not count CCS engines other than
> > > > the first
> > > > +*/
> > > > + if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> > > > + engine->uabi_instance > 0) {
> > > > +
> > > > i915->engine_uabi_class_count[engine->uabi_class]--;
> > > > + continue;
> > > > + }
> > >
> > > It's a bit ugly to decrement after increment, instead of somehow
> > > restructuring the loop to satisfy both cases more elegantly.
> >
> > yes, agree, indeed I had a hard time here to accept this change
> > myself.
> >
> > But moving the check above where the counter was incremented it
> > would have been much uglier.
> >
> > This check looks ugly everywhere you place it :-)
>
> One idea would be to introduce a separate local counter array for
> name_instance, so not use i915->engine_uabi_class_count[]. First one
> increments for every engine, second only for the exposed ones. That way
> feels wouldn't be too ugly.
Ah... you mean that whenever we change the CCS mode, we update
the indexes of the exposed engines from list of the real engines.
Will try.
My approach was to regenerate the list everytime the CCS mode was
changed, but your suggestion looks a bit simplier.
> > In any case, I'm working on a patch that is splitting this
> > function in two parts and there is some refactoring happening
> > here (for the first initialization and the dynamic update).
> >
> > Please let me know if it's OK with you or you want me to fix it
> > in this run.
> >
> > > And I wonder if
> > > internally (in dmesg when engine name is logged) we don't end up with ccs0
> > > ccs0 ccs0 ccs0.. for all instances.
> >
> > I don't see this. Even in sysfs we see only one ccs. Where is it?
>
> When you run this patch on something with two or more ccs-es, the "renamed
> ccs... to ccs.." debug logs do not all log the new name as ccs0?
it shouldn't, because the name_instance is anyway incremented
normally... anyway, I will test it.
Thanks a lot!
Andi
Re: [PATCH] drm/i915: check before removing mm notifier
Merged it to drm-intel-gt-next with s/check/Check
On 2/19/2024 1:50 PM, Nirmoy Das wrote:
Error in mmu_interval_notifier_insert() can leave a NULL
notifier.mm pointer. Catch that and return early.
Cc: Andi Shyti
Cc: Shawn Lee
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 0e21ce9d3e5a..61abfb505766 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -349,6 +349,9 @@ i915_gem_userptr_release(struct drm_i915_gem_object *obj)
{
GEM_WARN_ON(obj->userptr.page_ref);
+ if (!obj->userptr.notifier.mm)
+ return;
+
mmu_interval_notifier_remove(&obj->userptr.notifier);
obj->userptr.notifier.mm = NULL;
}
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
On 21/02/2024 11:19, Andi Shyti wrote:
Hi Tvrtko,
On Wed, Feb 21, 2024 at 08:19:34AM +, Tvrtko Ursulin wrote:
On 21/02/2024 00:14, Andi Shyti wrote:
On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
On 20/02/2024 14:35, Andi Shyti wrote:
Enable only one CCS engine by default with all the compute sices
slices
Thanks!
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 833987015b8b..7041acc77810 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -243,6 +243,15 @@ void intel_engines_driver_register(struct drm_i915_private
*i915)
if (engine->uabi_class == I915_NO_UABI_CLASS)
continue;
+ /*
+* Do not list and do not count CCS engines other than the first
+*/
+ if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
+ engine->uabi_instance > 0) {
+ i915->engine_uabi_class_count[engine->uabi_class]--;
+ continue;
+ }
It's a bit ugly to decrement after increment, instead of somehow
restructuring the loop to satisfy both cases more elegantly.
yes, agree, indeed I had a hard time here to accept this change
myself.
But moving the check above where the counter was incremented it
would have been much uglier.
This check looks ugly everywhere you place it :-)
One idea would be to introduce a separate local counter array for
name_instance, so not use i915->engine_uabi_class_count[]. First one
increments for every engine, second only for the exposed ones. That way
feels wouldn't be too ugly.
Ah... you mean that whenever we change the CCS mode, we update
the indexes of the exposed engines from list of the real engines.
Will try.
My approach was to regenerate the list everytime the CCS mode was
changed, but your suggestion looks a bit simplier.
No, I meant just for this first stage of permanently single engine. For
avoiding the decrement after increment. Something like this, but not compile
tested even:
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 833987015b8b..4c33f30612c4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -203,7 +203,8 @@ static void engine_rename(struct intel_engine_cs *engine,
const char *name, u16
void intel_engines_driver_register(struct drm_i915_private *i915)
{
- u16 name_instance, other_instance = 0;
+ u16 class_instance[I915_LAST_UABI_ENGINE_CLASS + 2] = { };
+ u16 uabi_class, other_instance = 0;
struct legacy_ring ring = {};
struct list_head *it, *next;
struct rb_node **p, *prev;
@@ -222,15 +223,14 @@ void intel_engines_driver_register(struct
drm_i915_private *i915)
GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));
engine->uabi_class = uabi_classes[engine->class];
+
if (engine->uabi_class == I915_NO_UABI_CLASS) {
- name_instance = other_instance++;
- } else {
- GEM_BUG_ON(engine->uabi_class >=
- ARRAY_SIZE(i915->engine_uabi_class_count));
- name_instance =
-
i915->engine_uabi_class_count[engine->uabi_class]++;
- }
- engine->uabi_instance = name_instance;
+ uabi_class = I915_LAST_UABI_ENGINE_CLASS + 1;
+ else
+ uabi_class = engine->uabi_class;
+
+ GEM_BUG_ON(uabi_class >= ARRAY_SIZE(class_instance));
+ engine->uabi_instance = class_instance[uabi_class]++;
/*
* Replace the internal name with the final user and log facing
@@ -238,11 +238,15 @@ void intel_engines_driver_register(struct
drm_i915_private *i915)
*/
engine_rename(engine,
intel_engine_class_repr(engine->class),
- name_instance);
+ engine->uabi_instance);
- if (engine->uabi_class == I915_NO_UABI_CLASS)
+ if (uabi_class == I915_NO_UABI_CLASS)
continue;
+ GEM_BUG_ON(uabi_class >=
+ ARRAY_SIZE(i915->engine_uabi_class_count));
+ i915->engine_uabi_class_count[uabi_class]++;
+
rb_link_node(&engine->uabi_node, prev, p);
rb_insert_color(&engine->uabi_node, &i915->uabi_engines);
In any case, I'm working on a patch that is splitting this
function in two parts and there is some refactoring happening
here (for the first initialization and the dynamic update).
Please let me know if it's OK with you or you want me to fix it
in this run.
And I
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
On 21/02/2024 12:08, Tvrtko Ursulin wrote:
On 21/02/2024 11:19, Andi Shyti wrote:
Hi Tvrtko,
On Wed, Feb 21, 2024 at 08:19:34AM +, Tvrtko Ursulin wrote:
On 21/02/2024 00:14, Andi Shyti wrote:
On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
On 20/02/2024 14:35, Andi Shyti wrote:
Enable only one CCS engine by default with all the compute sices
slices
Thanks!
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 833987015b8b..7041acc77810 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -243,6 +243,15 @@ void intel_engines_driver_register(struct
drm_i915_private *i915)
if (engine->uabi_class == I915_NO_UABI_CLASS)
continue;
+ /*
+ * Do not list and do not count CCS engines other than
the first
+ */
+ if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
+ engine->uabi_instance > 0) {
+ i915->engine_uabi_class_count[engine->uabi_class]--;
+ continue;
+ }
It's a bit ugly to decrement after increment, instead of somehow
restructuring the loop to satisfy both cases more elegantly.
yes, agree, indeed I had a hard time here to accept this change
myself.
But moving the check above where the counter was incremented it
would have been much uglier.
This check looks ugly everywhere you place it :-)
One idea would be to introduce a separate local counter array for
name_instance, so not use i915->engine_uabi_class_count[]. First one
increments for every engine, second only for the exposed ones. That way
feels wouldn't be too ugly.
Ah... you mean that whenever we change the CCS mode, we update
the indexes of the exposed engines from list of the real engines.
Will try.
My approach was to regenerate the list everytime the CCS mode was
changed, but your suggestion looks a bit simplier.
No, I meant just for this first stage of permanently single engine. For
avoiding the decrement after increment. Something like this, but not
compile tested even:
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 833987015b8b..4c33f30612c4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -203,7 +203,8 @@ static void engine_rename(struct intel_engine_cs
*engine, const char *name, u16
void intel_engines_driver_register(struct drm_i915_private *i915)
{
- u16 name_instance, other_instance = 0;
+ u16 class_instance[I915_LAST_UABI_ENGINE_CLASS + 2] = { };
+ u16 uabi_class, other_instance = 0;
struct legacy_ring ring = {};
struct list_head *it, *next;
struct rb_node **p, *prev;
@@ -222,15 +223,14 @@ void intel_engines_driver_register(struct
drm_i915_private *i915)
GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));
engine->uabi_class = uabi_classes[engine->class];
+
if (engine->uabi_class == I915_NO_UABI_CLASS) {
- name_instance = other_instance++;
- } else {
- GEM_BUG_ON(engine->uabi_class >=
-
ARRAY_SIZE(i915->engine_uabi_class_count));
- name_instance =
-
i915->engine_uabi_class_count[engine->uabi_class]++;
- }
- engine->uabi_instance = name_instance;
+ uabi_class = I915_LAST_UABI_ENGINE_CLASS + 1;
+ else
+ uabi_class = engine->uabi_class;
+
+ GEM_BUG_ON(uabi_class >= ARRAY_SIZE(class_instance));
+ engine->uabi_instance = class_instance[uabi_class]++;
/*
* Replace the internal name with the final user and
log facing
@@ -238,11 +238,15 @@ void intel_engines_driver_register(struct
drm_i915_private *i915)
*/
engine_rename(engine,
intel_engine_class_repr(engine->class),
- name_instance);
+ engine->uabi_instance);
- if (engine->uabi_class == I915_NO_UABI_CLASS)
+ if (uabi_class == I915_NO_UABI_CLASS)
continue;
Here you just add the ccs skip condition.
Anyway.. I rushed it a bit so see what you think.
Regards,
Tvrtko
+ GEM_BUG_ON(uabi_class >=
+ ARRAY_SIZE(i915->engine_uabi_class_count));
+ i915->engine_uabi_class_count[uabi_class]++;
+
rb_link_node(&engine->uabi_node, prev, p);
rb_insert_color(&engine->uabi_node, &i915->uabi_engines);
In any case, I'm working on a patch that is splitting this
function in two parts and there is some refactoring happening
here (for the first initialization and the
[PATCH v7 1/3] drm/buddy: Implement tracking clear page feature
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared memory
but fallback to uncleared if we can't find the cleared blocks.
when driver requests uncleared memory we try to use uncleared but
fallback to cleared memory if necessary.
- When a block gets freed we clear it and mark the freed block as cleared,
when there are buddies which are cleared as well we can merge them.
Otherwise, we prefer to keep the blocks as separated.
v1: (Christian)
- Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
cleared. Else, reset the clear flag for each block in the list.
- For merging the 2 cleared blocks compare as below,
drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)
v2: (Matthew)
- Add a wrapper drm_buddy_free_list_internal for the freeing of blocks
operation within drm buddy.
- Write a macro block_incompatible() to allocate the required blocks.
- Update the xe driver for the drm_buddy_free_list change in arguments.
v3: (Matthew)
- Keep DRM_BUDDY_HEADER_CLEAR define sorted.
Signed-off-by: Arunpravin Paneer Selvam
Signed-off-by: Matthew Auld
Suggested-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +-
drivers/gpu/drm/drm_buddy.c | 190 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 6 +-
drivers/gpu/drm/tests/drm_buddy_test.c| 10 +-
drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 4 +-
include/drm/drm_buddy.h | 19 +-
6 files changed, 186 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8db880244324..c0c851409241 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -571,7 +571,7 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
return 0;
error_free_blocks:
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
error_fini:
ttm_resource_fini(man, &vres->base);
@@ -604,7 +604,7 @@ static void amdgpu_vram_mgr_del(struct ttm_resource_manager
*man,
amdgpu_vram_mgr_do_reserve(man);
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
atomic64_sub(vis_usage, &mgr->vis_usage);
@@ -912,7 +912,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
kfree(rsv);
list_for_each_entry_safe(rsv, temp, &mgr->reserved_pages, blocks) {
- drm_buddy_free_list(&mgr->mm, &rsv->allocated);
+ drm_buddy_free_list(&mgr->mm, &rsv->allocated, 0);
kfree(rsv);
}
if (!adev->gmc.is_app_apu)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..18e004fa39d3 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -57,6 +57,16 @@ static void list_insert_sorted(struct drm_buddy *mm,
__list_add(&block->link, node->link.prev, &node->link);
}
+static void clear_reset(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_CLEAR;
+}
+
+static void mark_cleared(struct drm_buddy_block *block)
+{
+ block->header |= DRM_BUDDY_HEADER_CLEAR;
+}
+
static void mark_allocated(struct drm_buddy_block *block)
{
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -223,6 +233,12 @@ static int split_block(struct drm_buddy *mm,
mark_free(mm, block->left);
mark_free(mm, block->right);
+ if (drm_buddy_block_is_clear(block)) {
+ mark_cleared(block->left);
+ mark_cleared(block->right);
+ clear_reset(block);
+ }
+
mark_split(block);
return 0;
@@ -273,6 +289,13 @@ static void __drm_buddy_free(struct drm_buddy *mm,
if (!drm_buddy_block_is_free(buddy))
break;
+ if (drm_buddy_block_is_clear(block) !=
+ drm_buddy_block_is_clear(buddy))
+ break;
+
+ if (drm_buddy_block_is_clear(block))
+ mark_cleared(parent);
+
list_del(&buddy->link);
drm_block_free(mm, block);
@@ -295,26 +318,59 @@ void drm_buddy_free_block(struct drm_buddy *mm,
{
BUG_ON(!drm_buddy_block_is_allocated(block));
mm->avail += drm_buddy_block_size(mm, block);
+ if (drm_buddy_block_is_clear(block))
+ mm->clear_avail += drm_buddy_block_size(mm, block);
+
__drm_buddy_free(mm, block);
}
EXPORT_SYMBOL(drm_buddy_free_block);
-/**
- * drm_buddy_free_list - free blocks
- *
-
[PATCH v7 2/3] drm/amdgpu: Enable clear page functionality
Add clear page support in vram memory region.
v1(Christian):
- Dont handle clear page as TTM flag since when moving the BO back
in from GTT again we don't need that.
- Make a specialized version of amdgpu_fill_buffer() which only
clears the VRAM areas which are not already cleared
- Drop the TTM_PL_FLAG_WIPE_ON_RELEASE check in
amdgpu_object.c
v2:
- Modify the function name amdgpu_ttm_* (Alex)
- Drop the delayed parameter (Christian)
- handle amdgpu_res_cleared(&cursor) just above the size
calculation (Christian)
- Use AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE for clearing the buffers
in the free path to properly wait for fences etc.. (Christian)
v3(Christian):
- Remove buffer clear code in VRAM manager instead change the
AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE handling to set
the DRM_BUDDY_CLEARED flag.
- Remove ! from amdgpu_res_cleared(&cursor) check.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Christian König
Acked-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 22 ---
.../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 25
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 61 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 5 ++
6 files changed, 111 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 010b0cb7693c..904d71b3393f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -39,6 +39,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
#include "amdgpu_amdkfd.h"
+#include "amdgpu_vram_mgr.h"
/**
* DOC: amdgpu_object
@@ -595,8 +596,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
if (!amdgpu_bo_support_uswc(bo->flags))
bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
- if (adev->ras_enabled)
- bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE;
+ bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE;
bo->tbo.bdev = &adev->mman.bdev;
if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA |
@@ -626,15 +626,17 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.resource->mem_type == TTM_PL_VRAM) {
- struct dma_fence *fence;
+ struct dma_fence *fence = NULL;
- r = amdgpu_fill_buffer(bo, 0, bo->tbo.base.resv, &fence, true);
+ r = amdgpu_ttm_clear_buffer(bo, bo->tbo.base.resv, &fence);
if (unlikely(r))
goto fail_unreserve;
- dma_resv_add_fence(bo->tbo.base.resv, fence,
- DMA_RESV_USAGE_KERNEL);
- dma_fence_put(fence);
+ if (fence) {
+ dma_resv_add_fence(bo->tbo.base.resv, fence,
+ DMA_RESV_USAGE_KERNEL);
+ dma_fence_put(fence);
+ }
}
if (!bp->resv)
amdgpu_bo_unreserve(bo);
@@ -1359,8 +1361,12 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object
*bo)
if (WARN_ON_ONCE(!dma_resv_trylock(bo->base.resv)))
return;
- r = amdgpu_fill_buffer(abo, AMDGPU_POISON, bo->base.resv, &fence, true);
+ r = amdgpu_fill_buffer(abo, 0, bo->base.resv, &fence, true);
if (!WARN_ON(r)) {
+ struct amdgpu_vram_mgr_resource *vres;
+
+ vres = to_amdgpu_vram_mgr_resource(bo->resource);
+ vres->flags |= DRM_BUDDY_CLEARED;
amdgpu_bo_fence(abo, fence, false);
dma_fence_put(fence);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 381101d2bf05..50fcd86e1033 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -164,4 +164,29 @@ static inline void amdgpu_res_next(struct
amdgpu_res_cursor *cur, uint64_t size)
}
}
+/**
+ * amdgpu_res_cleared - check if blocks are cleared
+ *
+ * @cur: the cursor to extract the block
+ *
+ * Check if the @cur block is cleared
+ */
+static inline bool amdgpu_res_cleared(struct amdgpu_res_cursor *cur)
+{
+ struct drm_buddy_block *block;
+
+ switch (cur->mem_type) {
+ case TTM_PL_VRAM:
+ block = cur->node;
+
+ if (!amdgpu_vram_mgr_is_cleared(block))
+ return false;
+ break;
+ default:
+ return false;
+ }
+
+ return true;
+}
+
#endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8722beba494e..bcbffe909b47 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_tt
[PATCH v7 3/3] drm/buddy: Add defragmentation support
Add a function to support defragmentation.
v1:
- Defragment the memory beginning from min_order
till the required memory space is available.
v2(Matthew):
- add amdgpu user for defragmentation
- add a warning if the two blocks are incompatible on
defragmentation
- call full defragmentation in the fini() function
- place a condition to test if min_order is equal to 0
- replace the list with safe_reverse() variant as we might
remove the block from the list.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 +++-
drivers/gpu/drm/drm_buddy.c | 93 +---
include/drm/drm_buddy.h | 3 +
3 files changed, 97 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index e494f5bf136a..cff8a526c622 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -533,8 +533,21 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
min_block_size,
&vres->blocks,
vres->flags);
- if (unlikely(r))
- goto error_free_blocks;
+ if (unlikely(r)) {
+ if (r == -ENOSPC) {
+ drm_buddy_defrag(mm, min_block_size);
+ r = drm_buddy_alloc_blocks(mm, fpfn,
+ lpfn,
+ size,
+ min_block_size,
+ &vres->blocks,
+ vres->flags);
+ if (unlikely(r))
+ goto error_free_blocks;
+ } else {
+ goto error_free_blocks;
+ }
+ }
if (size > remaining_size)
remaining_size = 0;
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 18e004fa39d3..56bd1560fbcd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -203,6 +203,8 @@ void drm_buddy_fini(struct drm_buddy *mm)
drm_block_free(mm, mm->roots[i]);
}
+ drm_buddy_defrag(mm, mm->chunk_size << mm->max_order);
+
WARN_ON(mm->avail != mm->size);
kfree(mm->roots);
@@ -276,25 +278,39 @@ drm_get_buddy(struct drm_buddy_block *block)
}
EXPORT_SYMBOL(drm_get_buddy);
-static void __drm_buddy_free(struct drm_buddy *mm,
-struct drm_buddy_block *block)
+static unsigned int __drm_buddy_free(struct drm_buddy *mm,
+struct drm_buddy_block *block,
+bool defrag)
{
+ unsigned int order, block_order;
struct drm_buddy_block *parent;
+ block_order = drm_buddy_block_order(block);
+
while ((parent = block->parent)) {
- struct drm_buddy_block *buddy;
+ struct drm_buddy_block *buddy = NULL;
buddy = __get_buddy(block);
if (!drm_buddy_block_is_free(buddy))
break;
- if (drm_buddy_block_is_clear(block) !=
- drm_buddy_block_is_clear(buddy))
- break;
+ if (!defrag) {
+ /*
+* Check the block and its buddy clear state and exit
+* the loop if they both have the dissimilar state.
+*/
+ if (drm_buddy_block_is_clear(block) !=
+ drm_buddy_block_is_clear(buddy))
+ break;
- if (drm_buddy_block_is_clear(block))
- mark_cleared(parent);
+ if (drm_buddy_block_is_clear(block))
+ mark_cleared(parent);
+ }
+
+ WARN_ON(defrag &&
+ (drm_buddy_block_is_clear(block) ==
+drm_buddy_block_is_clear(buddy)));
list_del(&buddy->link);
@@ -304,8 +320,57 @@ static void __drm_buddy_free(struct drm_buddy *mm,
block = parent;
}
- mark_free(mm, block);
+ order = drm_buddy_block_order(block);
+ if (block_order != order)
+ mark_free(mm, block);
+
+ return order;
+}
+
+/**
+ * drm_buddy_defrag - Defragmentation routine
+ *
+ * @mm: DRM buddy manager
+ * @min_block_size: minimum size in bytes to begin
+ * the defragmentation process
+ *
+ * Driver calls the def
[PATCH 0/6] Enable Adaptive Sync SDP Support for DP
An Adaptive Sync SDP allows a DP protocol converter to forward Adaptive Sync video with minimal buffering overhead within the converter. An Adaptive-Sync-capable DP protocol converter indicates its support by setting the related bit in the DPCD register. Computes AS SDP values based on the display configuration, ensuring proper handling of Variable Refresh Rate (VRR) in the context of Adaptive Sync. --v2: - Update logging to Patch-1 - use as_sdp instead of async - Put definitions to correct placeholders from where it is defined. - Update member types of as_sdp for uniformity. - Correct use of REG_BIT and REG_GENMASK. - Remove unrelated comments and changes. - Correct code indents. - separate out patch changes for intel_read/write_dp_sdp. --v3: - Add VIDEO_DIP_ASYNC_DATA_SIZE definition and comment in as_sdp_pack function to patch 2 as originally used there. [Patch 2]. - Add VIDEO_DIP_ENABLE_AS_HSW flag to intel_dp_set_infoframes [Patch 3]. --v4: - Add check for HAS_VRR before writing AS SDP. [Patch 3]. --v5: - Add missing check for HAS_VRR before reading AS SDP as well [Patch 3]. --v6: - Rebase all patches. - Compute TRANS_VRR_VSYNC. -v7: - Move vrr_vsync_start/end to compute config. - Use correct function for drm_debug_printer. -v8: - Code refactoring. - Update, VSYNC_START/END macros to VRR_VSYNC_START/END.(Ankit) - Update bit fields of VRR_VSYNC_START/END.(Ankit) - Send patches to dri-devel.(Ankit) - Update definition names for AS SDP which are starting from HSW, as these defines are applicable for ADLP+.(Ankit) - Remove unused bitfield define, AS_SDP_ENABLE. - Add support in drm for Adaptive Sync sink status, which can be used later as a check for read/write sdp. (Ankit) -v9: - Add enum to operation mode to represent different AVT and FAVT modes. (Ankit) - Operation_mode, target_rr etc should be filled from as_sdp struct. (Ankit) - Fill as_sdp->*All Params* from compute config, read from the sdp. (Ankit) - Move configs to the appropriate patch where it used first.(Ankit) - There should be a check if as sdp is enable is set or not. (Ankit) - Add variables in crtc state->vrr for ad sdp enable and operation mode. (Ankit) - Use above variables for tracking AS SDP. (Ankit) - Revert unused changes. (Ankit) Mitul Golani (6): drm/dp: Add an support to indicate if sink supports AS SDP drm: Add Adaptive Sync SDP logging drm/i915/dp: Add Read/Write support for Adaptive Sync SDP drm/i915/display: Compute AS SDP parameters. drm/i915/display: Compute vrr_vsync params drm/i915/display: Read/Write AS sdp only when sink/source has enabled drivers/gpu/drm/display/drm_dp_helper.c | 37 ++ .../drm/i915/display/intel_crtc_state_dump.c | 12 ++ drivers/gpu/drm/i915/display/intel_ddi.c | 5 + drivers/gpu/drm/i915/display/intel_display.c | 1 + .../drm/i915/display/intel_display_device.h | 1 + .../drm/i915/display/intel_display_types.h| 4 + drivers/gpu/drm/i915/display/intel_dp.c | 122 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +- drivers/gpu/drm/i915/display/intel_vrr.c | 23 drivers/gpu/drm/i915/i915_reg.h | 15 +++ include/drm/display/drm_dp.h | 9 ++ include/drm/display/drm_dp_helper.h | 34 + 12 files changed, 271 insertions(+), 4 deletions(-) -- 2.25.1
[PATCH 1/6] drm/dp: Add an support to indicate if sink supports AS SDP
Add an API which indicates the sink support Adaptive Sync SDP,
which can be used by the rest of the DP programming.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/display/drm_dp_helper.c | 25 +
include/drm/display/drm_dp_helper.h | 2 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae..81c5507928f5 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,31 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const
struct drm_dp_vsc_sdp *vsc)
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+/**
+ * drm_dp_as_sdp_supported() - check if adaptive sync sdp is supported
+ * @aux: DisplayPort AUX channel
+ * @dpcd: DisplayPort configuration data
+ *
+ * Returns true if adaptive sync sdp is supported, else returns false
+ */
+bool drm_dp_as_sdp_supported(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 rx_feature;
+
+ if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_13)
+ return false;
+
+ if (drm_dp_dpcd_readb(aux, DP_DPRX_FEATURE_ENUMERATION_LIST_CONT_1,
+ &rx_feature) != 1) {
+ drm_dbg_dp(aux->drm_dev,
+ "failed to read
DP_DPRX_FEATURE_ENUMERATION_LIST_CONT_1\n");
+ return false;
+ }
+
+ return (rx_feature & DP_ADAPTIVE_SYNC_SDP_SUPPORTED);
+}
+EXPORT_SYMBOL(drm_dp_as_sdp_supported);
+
/**
* drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
* @dpcd: DisplayPort configuration data
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index d02014a87f12..a0356721de0f 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -100,6 +100,8 @@ struct drm_dp_vsc_sdp {
void drm_dp_vsc_sdp_log(struct drm_printer *p, const struct drm_dp_vsc_sdp
*vsc);
+bool drm_dp_as_sdp_supported(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE]);
+
int drm_dp_psr_setup_time(const u8 psr_cap[EDP_PSR_RECEIVER_CAP_SIZE]);
static inline int
--
2.25.1
[PATCH 2/6] drm: Add Adaptive Sync SDP logging
Add structure representing Adaptive Sync Secondary Data
Packet (AS SDP). Also, add Adaptive Sync SDP logging in
drm_dp_helper.c to facilitate debugging.
--v2:
- Update logging. [Jani, Ankit]
- use as_sdp instead of async [Ankit]
- Correct define placeholders to where it is being actually used. [Jani]
- Update members in as_sdp structure and make it uniform. [Jani]
--v3:
- Add changes dri-devel mail list. No code changes.
--v4:
- Instead of directly using operation mode, use enum to accommodate
all operation modes (Ankit).
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/display/drm_dp_helper.c | 12 +++
.../drm/i915/display/intel_crtc_state_dump.c | 12 +++
.../drm/i915/display/intel_display_types.h| 1 +
include/drm/display/drm_dp.h | 9 ++
include/drm/display/drm_dp_helper.h | 32 +++
5 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 81c5507928f5..a5804c9c245d 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,18 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const
struct drm_dp_vsc_sdp *vsc)
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+void drm_dp_as_sdp_log(struct drm_printer *p, const struct drm_dp_as_sdp
*as_sdp)
+{
+ drm_printf(p, "DP SDP: AS_SDP, revision %u, length %u\n",
+ as_sdp->revision, as_sdp->length);
+ drm_printf(p, " vtotal: %d\n", as_sdp->vtotal);
+ drm_printf(p, "target_rr: %d\n", as_sdp->target_rr);
+ drm_printf(p, "duration_incr_ms: %d\n", as_sdp->duration_incr_ms);
+ drm_printf(p, "duration_decr_ms: %d\n", as_sdp->duration_decr_ms);
+ drm_printf(p, "operation_mode: %d\n", as_sdp->mode);
+}
+EXPORT_SYMBOL(drm_dp_as_sdp_log);
+
/**
* drm_dp_as_sdp_supported() - check if adaptive sync sdp is supported
* @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index 4bcf446c75f4..26d77c2934e8 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -60,6 +60,15 @@ intel_dump_dp_vsc_sdp(struct drm_i915_private *i915,
drm_dp_vsc_sdp_log(&p, vsc);
}
+static void
+intel_dump_dp_as_sdp(struct drm_i915_private *i915,
+const struct drm_dp_as_sdp *as_sdp)
+{
+ struct drm_printer p = drm_dbg_printer(&i915->drm, DRM_UT_KMS,
"AS_SDP");
+
+ drm_dp_as_sdp_log(&p, as_sdp);
+}
+
static void
intel_dump_buffer(struct drm_i915_private *i915,
const char *prefix, const u8 *buf, size_t len)
@@ -299,6 +308,9 @@ void intel_crtc_state_dump(const struct intel_crtc_state
*pipe_config,
if (pipe_config->infoframes.enable &
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA))
intel_dump_infoframe(i915, &pipe_config->infoframes.drm);
+ if (pipe_config->infoframes.enable &
+ intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC))
+ intel_dump_dp_as_sdp(i915, &pipe_config->infoframes.as_sdp);
if (pipe_config->infoframes.enable &
intel_hdmi_infoframe_enable(DP_SDP_VSC))
intel_dump_dp_vsc_sdp(i915, &pipe_config->infoframes.vsc);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0d4012097db1..a6991bc3f07b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1332,6 +1332,7 @@ struct intel_crtc_state {
union hdmi_infoframe hdmi;
union hdmi_infoframe drm;
struct drm_dp_vsc_sdp vsc;
+ struct drm_dp_as_sdp as_sdp;
} infoframes;
u8 eld[MAX_ELD_BYTES];
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 281afff6ee4e..537d6b7148af 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1578,10 +1578,12 @@ enum drm_dp_phy {
#define DP_SDP_AUDIO_COPYMANAGEMENT0x05 /* DP 1.2 */
#define DP_SDP_ISRC0x06 /* DP 1.2 */
#define DP_SDP_VSC 0x07 /* DP 1.2 */
+#define DP_SDP_ADAPTIVE_SYNC0x22 /* DP 1.4 */
#define DP_SDP_CAMERA_GENERIC(i) (0x08 + (i)) /* 0-7, DP 1.3 */
#define DP_SDP_PPS 0x10 /* DP 1.4 */
#define DP_SDP_VSC_EXT_VESA0x20 /* DP 1.4 */
#define DP_SDP_VSC_EXT_CEA 0x21 /* DP 1.4 */
+
/* 0x80+ CEA-861 infoframe types */
#define DP_SDP_AUDIO_INFOFRAME_HB2 0x1b
@@ -1737,4 +1739,11 @@ enum dp_content_type {
DP_CONTENT_TYPE_GAME = 0x04,
};
+enum operation_mode {
+ DP_AS_SDP_AVT_DYNAMIC_VTOTAL = 0x00,
+ DP_AS_SDP_AVT_FIXED_VTOTAL = 0x01,
+ DP_AS_SDP_FAVT_TRR_NOT_REACHED = 0x02,
+ DP_AS_SDP_FAV
[PATCH 3/6] drm/i915/dp: Add Read/Write support for Adaptive Sync SDP
Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- Remove unrelated comments and changes. [Jani]
- Correct code indent. [Jani]
--v3:
- Update definition names for AS SDP which are starting from
HSW, as these defines are applicable for ADLP+.(Ankit)
Signed-off-by: Mitul Golani
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 89 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 12 ++-
drivers/gpu/drm/i915/display/intel_vrr.c | 5 ++
drivers/gpu/drm/i915/i915_reg.h | 8 ++
5 files changed, 111 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index a6991bc3f07b..2accfe41160d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1414,6 +1414,7 @@ struct intel_crtc_state {
bool enable, in_range;
u8 pipeline_full;
u16 flipline, vmin, vmax, guardband;
+ u8 as_sdp_mode;
} vrr;
/* Stream Splitter for eDP MSO */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 217196196e50..b370e1da4735 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -95,7 +95,6 @@
#define INTEL_DP_RESOLUTION_STANDARD (2 << INTEL_DP_RESOLUTION_SHIFT_MASK)
#define INTEL_DP_RESOLUTION_FAILSAFE (3 << INTEL_DP_RESOLUTION_SHIFT_MASK)
-
/* Constants for DP DSC configurations */
static const u8 valid_dsc_bpp[] = {6, 8, 10, 12, 15};
@@ -4089,6 +4088,32 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
*crtc_state,
return false;
}
+static ssize_t intel_dp_as_sdp_pack(const struct drm_dp_as_sdp *as_sdp,
+ struct dp_sdp *sdp, size_t size)
+{
+ size_t length = sizeof(struct dp_sdp);
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(sdp, 0, size);
+
+ /* Prepare AS (Adaptive Sync) SDP Header */
+ sdp->sdp_header.HB0 = 0;
+ sdp->sdp_header.HB1 = as_sdp->sdp_type;
+ sdp->sdp_header.HB2 = 0x02;
+ sdp->sdp_header.HB3 = as_sdp->length;
+
+ /* Fill AS (Adaptive Sync) SDP Payload */
+ sdp->db[0] = as_sdp->mode;
+ sdp->db[1] = as_sdp->vtotal & 0xFF;
+ sdp->db[2] = (as_sdp->vtotal >> 8) & 0xFF;
+ sdp->db[3] = as_sdp->target_rr;
+ sdp->db[4] = (as_sdp->target_rr >> 8) & 0x3;
+
+ return length;
+}
+
static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
struct dp_sdp *sdp, size_t size)
{
@@ -4256,6 +4281,10 @@ static void intel_write_dp_sdp(struct intel_encoder
*encoder,
&crtc_state->infoframes.drm.drm,
&sdp,
sizeof(sdp));
break;
+ case DP_SDP_ADAPTIVE_SYNC:
+ len = intel_dp_as_sdp_pack(&crtc_state->infoframes.as_sdp, &sdp,
+ sizeof(sdp));
+ break;
default:
MISSING_CASE(type);
return;
@@ -4276,7 +4305,8 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
u32 dip_enable = VIDEO_DIP_ENABLE_AVI_HSW | VIDEO_DIP_ENABLE_GCP_HSW |
VIDEO_DIP_ENABLE_VS_HSW | VIDEO_DIP_ENABLE_GMP_HSW |
-VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK;
+VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK |
+VIDEO_DIP_ENABLE_ADAPTIVE_SYNC;
u32 val = intel_de_read(dev_priv, reg) & ~dip_enable;
/* TODO: Sanitize DSC enabling wrt. intel_dsc_dp_pps_write(). */
@@ -4298,6 +4328,36 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
intel_write_dp_sdp(encoder, crtc_state,
HDMI_PACKET_TYPE_GAMUT_METADATA);
}
+static
+int intel_dp_as_sdp_unpack(struct drm_dp_as_sdp *as_sdp,
+ const void *buffer, size_t size)
+{
+ const struct dp_sdp *sdp = buffer;
+
+ if (size < sizeof(struct dp_sdp))
+ return -EINVAL;
+
+ memset(as_sdp, 0, sizeof(*as_sdp));
+
+ if (sdp->sdp_header.HB0 != 0)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB1 != DP_SDP_ADAPTIVE_SYNC)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB2 != 0x02)
+ return -EINVAL;
+
+ if ((sdp->sdp_header.HB3 & 0x3F) != 9)
+ return -EINVAL;
+
+ as_sdp->mode = sdp->db[0] & AS_SDP_
[PATCH 4/6] drm/i915/display: Compute AS SDP parameters.
Add necessary functions definitions to enable
and compute AS SDP data. The new `intel_dp_compute_as_sdp`
function computes AS SDP values based on the display
configuration, ensuring proper handling of Variable Refresh
Rate (VRR).
--v2:
- Add DP_SDP_ADAPTIVE_SYNC to infoframe_type_to_idx().[Ankit]
- separate patch for intel_read/write_dp_sdp [Ankit].
- _HSW_VIDEO_DIP_ASYNC_DATA_A should be from ADL onward [Ankit]
- To fix indentation [Ankit]
--v3:
- Add VIDEO_DIP_ENABLE_AS_HSW flag to intel_dp_set_infoframes.
--v4:
- Add HAS_VRR check before write as sdp.
--v5:
- Add missed HAS_VRR check before read as sdp.
--v6:
Use Adaptive Sync sink status, which can be
used as a check for read/write sdp. (Ankit)
Signed-off-by: Mitul Golani
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 28 +++
drivers/gpu/drm/i915/display/intel_vrr.c | 4 ++-
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 2accfe41160d..93b4b7dff1d0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1415,6 +1415,7 @@ struct intel_crtc_state {
u8 pipeline_full;
u16 flipline, vmin, vmax, guardband;
u8 as_sdp_mode;
+ bool as_sdp_enable;
} vrr;
/* Stream Splitter for eDP MSO */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b370e1da4735..5c1e2301dd52 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2617,6 +2617,33 @@ static void intel_dp_compute_vsc_colorimetry(const
struct intel_crtc_state *crtc
vsc->content_type = DP_CONTENT_TYPE_NOT_DEFINED;
}
+static void intel_dp_compute_as_sdp(struct intel_dp *intel_dp,
+ struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state
*conn_state)
+{
+ struct drm_dp_as_sdp *as_sdp = &crtc_state->infoframes.as_sdp;
+ struct intel_connector *connector = intel_dp->attached_connector;
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->hw.adjusted_mode;
+ int vrefresh = drm_mode_vrefresh(adjusted_mode);
+
+ if (!intel_vrr_is_in_range(connector, vrefresh) ||
!crtc_state->vrr.as_sdp_enable)
+ return;
+
+ as_sdp->sdp_type = DP_SDP_ADAPTIVE_SYNC;
+ as_sdp->length = 0x9;
+ as_sdp->mode = crtc_state->vrr.as_sdp_mode;
+ as_sdp->vtotal = adjusted_mode->vtotal;
+
+ if (as_sdp->mode == DP_AS_SDP_AVT_FIXED_VTOTAL) {
+ as_sdp->target_rr = 0;
+ as_sdp->duration_incr_ms = 0;
+ as_sdp->duration_incr_ms = 0;
+ }
+
+ crtc_state->infoframes.enable |=
intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC);
+}
+
static void intel_dp_compute_vsc_sdp(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
@@ -2942,6 +2969,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
g4x_dp_set_clock(encoder, pipe_config);
intel_vrr_compute_config(pipe_config, conn_state);
+ intel_dp_compute_as_sdp(intel_dp, pipe_config, conn_state);
intel_psr_compute_config(intel_dp, pipe_config, conn_state);
intel_dp_drrs_compute_config(connector, pipe_config, link_bpp_x16);
intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/display/intel_vrr.c
index d2ab7e571e62..08e3ba69bd30 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -167,9 +167,11 @@ intel_vrr_compute_config(struct intel_crtc_state
*crtc_state,
crtc_state->vrr.enable = true;
crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
- if (drm_dp_as_sdp_supported(&intel_dp->aux, intel_dp->dpcd))
+ if (drm_dp_as_sdp_supported(&intel_dp->aux, intel_dp->dpcd)) {
+ crtc_state->vrr.as_sdp_enable = true;
crtc_state->vrr.as_sdp_mode =
DP_AS_SDP_AVT_DYNAMIC_VTOTAL;
+ }
}
}
--
2.25.1
[PATCH 6/6] drm/i915/display: Read/Write AS sdp only when sink/source has enabled
Write/Read Adaptive sync SDP only when Sink and Source is enabled
for the same. Also along with write TRANS_VRR_VSYNC values.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_ddi.c| 5 +
drivers/gpu/drm/i915/display/intel_display_device.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
drivers/gpu/drm/i915/display/intel_vrr.c| 4
4 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bea441590204..a1f46e4a8fa1 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3926,6 +3926,7 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
/* XXX: DSI transcoder paranoia */
if (drm_WARN_ON(&dev_priv->drm, transcoder_is_dsi(cpu_transcoder)))
@@ -3972,6 +3973,10 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
intel_read_dp_sdp(encoder, pipe_config,
HDMI_PACKET_TYPE_GAMUT_METADATA);
intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
+ if (HAS_AS_SDP(dev_priv) &&
+ drm_dp_as_sdp_supported(&intel_dp->aux, intel_dp->dpcd))
+ intel_read_dp_sdp(encoder, pipe_config, DP_SDP_ADAPTIVE_SYNC);
+
intel_audio_codec_get_config(encoder, pipe_config);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
b/drivers/gpu/drm/i915/display/intel_display_device.h
index fe4268813786..6399fbc6c738 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.h
+++ b/drivers/gpu/drm/i915/display/intel_display_device.h
@@ -68,6 +68,7 @@ struct drm_printer;
#define HAS_TRANSCODER(i915, trans)
((DISPLAY_RUNTIME_INFO(i915)->cpu_transcoder_mask & \
BIT(trans)) != 0)
#define HAS_VRR(i915) (DISPLAY_VER(i915) >= 11)
+#define HAS_AS_SDP(i915) (DISPLAY_VER(i915) >= 13)
#define INTEL_NUM_PIPES(i915)
(hweight8(DISPLAY_RUNTIME_INFO(i915)->pipe_mask))
#define I915_HAS_HOTPLUG(i915) (DISPLAY_INFO(i915)->has_hotplug)
#define OVERLAY_NEEDS_PHYSICAL(i915)
(DISPLAY_INFO(i915)->overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c1e2301dd52..706878a361e7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4336,6 +4336,7 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK |
VIDEO_DIP_ENABLE_ADAPTIVE_SYNC;
u32 val = intel_de_read(dev_priv, reg) & ~dip_enable;
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
/* TODO: Sanitize DSC enabling wrt. intel_dsc_dp_pps_write(). */
if (!enable && HAS_DSC(dev_priv))
@@ -4353,6 +4354,10 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
intel_write_dp_sdp(encoder, crtc_state, DP_SDP_VSC);
+ if (HAS_AS_SDP(dev_priv) &&
+ drm_dp_as_sdp_supported(&intel_dp->aux, intel_dp->dpcd))
+ intel_write_dp_sdp(encoder, crtc_state, DP_SDP_ADAPTIVE_SYNC);
+
intel_write_dp_sdp(encoder, crtc_state,
HDMI_PACKET_TYPE_GAMUT_METADATA);
}
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 29ddf504d94b..f4bf0518a816 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -217,6 +217,10 @@ void intel_vrr_set_transcoder_timings(const struct
intel_crtc_state *crtc_state)
intel_de_write(dev_priv, TRANS_VRR_VMAX(cpu_transcoder),
crtc_state->vrr.vmax - 1);
intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder),
trans_vrr_ctl(crtc_state));
intel_de_write(dev_priv, TRANS_VRR_FLIPLINE(cpu_transcoder),
crtc_state->vrr.flipline - 1);
+
+ if (crtc_state->vrr.as_sdp_enable)
+ intel_de_write(dev_priv, TRANS_VRR_VSYNC(cpu_transcoder),
+ crtc_state->vrr.vsync_end << 16 |
crtc_state->vrr.vsync_start);
}
void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
--
2.25.1
[PATCH 5/6] drm/i915/display: Compute vrr_vsync params
Compute vrr_vsync_start/end which sets the position
for hardware to send the Vsync at a fixed position
relative to the end of the Vblank.
--v2:
- Update, VSYNC_START/END macros to VRR_VSYNC_START/END.(Ankit)
- Update bit fields of VRR_VSYNC_START/END.(Ankit)
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_vrr.c | 12
drivers/gpu/drm/i915/i915_reg.h| 7 +++
4 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 00ac65a14029..5994f7fcbb6a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5321,6 +5321,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_I(vrr.flipline);
PIPE_CONF_CHECK_I(vrr.pipeline_full);
PIPE_CONF_CHECK_I(vrr.guardband);
+ PIPE_CONF_CHECK_BOOL(vrr.as_sdp_enable);
}
#undef PIPE_CONF_CHECK_X
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 93b4b7dff1d0..7859e4baad4b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1416,6 +1416,7 @@ struct intel_crtc_state {
u16 flipline, vmin, vmax, guardband;
u8 as_sdp_mode;
bool as_sdp_enable;
+ u32 vsync_end, vsync_start;
} vrr;
/* Stream Splitter for eDP MSO */
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 08e3ba69bd30..29ddf504d94b 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -150,6 +150,13 @@ intel_vrr_compute_config(struct intel_crtc_state
*crtc_state,
crtc_state->vrr.flipline = crtc_state->vrr.vmin + 1;
+ crtc_state->vrr.vsync_start =
+ (crtc_state->hw.adjusted_mode.crtc_vtotal -
+
VRR_VSYNC_START(crtc_state->hw.adjusted_mode.vsync_start));
+ crtc_state->vrr.vsync_end =
+ (crtc_state->hw.adjusted_mode.crtc_vtotal -
+ (VRR_VSYNC_END(crtc_state->hw.adjusted_mode.vsync_end)
>> 16));
+
/*
* For XE_LPD+, we use guardband and pipeline override
* is deprecated.
@@ -273,8 +280,13 @@ void intel_vrr_get_config(struct intel_crtc_state
*crtc_state)
u32 trans_vrr_ctl;
trans_vrr_ctl = intel_de_read(dev_priv, TRANS_VRR_CTL(cpu_transcoder));
+ bool as_sdp_enabled =
+ intel_de_read(dev_priv,
+ HSW_TVIDEO_DIP_CTL(cpu_transcoder));
crtc_state->vrr.enable = trans_vrr_ctl & VRR_CTL_VRR_ENABLE;
+ crtc_state->vrr.as_sdp_enable =
+ as_sdp_enabled & VIDEO_DIP_ENABLE_ADAPTIVE_SYNC;
if (DISPLAY_VER(dev_priv) >= 13)
crtc_state->vrr.guardband =
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c02ea07af4c2..3e0853458ef4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2007,7 +2007,9 @@
#define _TRANS_VRR_CTL_B 0x61420
#define _TRANS_VRR_CTL_C 0x62420
#define _TRANS_VRR_CTL_D 0x63420
+#define _TRANS_VRR_VSYNC_A 0x60078
#define TRANS_VRR_CTL(trans) _MMIO_TRANS2(trans,
_TRANS_VRR_CTL_A)
+#define TRANS_VRR_VSYNC(trans) _MMIO_TRANS2(trans,
_TRANS_VRR_VSYNC_A)
#define VRR_CTL_VRR_ENABLE REG_BIT(31)
#define VRR_CTL_IGN_MAX_SHIFTREG_BIT(30)
#define VRR_CTL_FLIP_LINE_EN REG_BIT(29)
@@ -2087,6 +2089,11 @@
#define TRANS_VRR_STATUS2(trans) _MMIO_TRANS2(trans,
_TRANS_VRR_STATUS2_A)
#define VRR_STATUS2_VERT_LN_CNT_MASK REG_GENMASK(19, 0)
+#define VRR_VSYNC_END_MASK REG_GENMASK(28, 16)
+#define VRR_VSYNC_END(vsync_end) REG_FIELD_PREP(VSYNC_END_MASK,
(vsync_end))
+#define VRR_VSYNC_START_MASK REG_GENMASK(12, 0)
+#define VRR_VSYNC_START(vsync_start) REG_FIELD_PREP(VSYNC_START_MASK,
(vsync_start))
+
#define _TRANS_PUSH_A 0x60A70
#define _TRANS_PUSH_B 0x61A70
#define _TRANS_PUSH_C 0x62A70
--
2.25.1
✗ Fi.CI.IGT: failure for IO and fast wake lines calculation and increase fw sync length
== Series Details == Series: IO and fast wake lines calculation and increase fw sync length URL : https://patchwork.freedesktop.org/series/130173/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14306_full -> Patchwork_130173v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_130173v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_130173v1_full, please notify your bug team (i915-ci-in...@lists.freedesktop.org) to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (8 -> 9) -- Additional (1): shard-snb-0 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_130173v1_full: ### IGT changes ### Possible regressions * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-glk: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-glk1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_flip@flip-vs-expired-vblank@b-vga1: - shard-snb: NOTRUN -> [ABORT][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-snb6/igt@kms_flip@flip-vs-expired-vbl...@b-vga1.html Known issues Here are the changes found in Patchwork_130173v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@crc32: - shard-rkl: NOTRUN -> [SKIP][3] ([i915#6230]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-rkl-7/igt@api_intel...@crc32.html * igt@api_intel_bb@object-reloc-keep-cache: - shard-rkl: NOTRUN -> [SKIP][4] ([i915#8411]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-rkl-7/igt@api_intel...@object-reloc-keep-cache.html - shard-dg2: NOTRUN -> [SKIP][5] ([i915#8411]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-dg2-2/igt@api_intel...@object-reloc-keep-cache.html * igt@device_reset@unbind-cold-reset-rebind: - shard-tglu: NOTRUN -> [SKIP][6] ([i915#7701]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-tglu-8/igt@device_re...@unbind-cold-reset-rebind.html * igt@drm_fdinfo@busy-check-all@ccs3: - shard-dg2: NOTRUN -> [SKIP][7] ([i915#8414]) +20 other tests skip [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-dg2-2/igt@drm_fdinfo@busy-check-...@ccs3.html * igt@drm_fdinfo@most-busy-check-all@rcs0: - shard-rkl: [PASS][8] -> [FAIL][9] ([i915#7742]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14306/shard-rkl-2/igt@drm_fdinfo@most-busy-check-...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-rkl-7/igt@drm_fdinfo@most-busy-check-...@rcs0.html * igt@gem_basic@multigpu-create-close: - shard-dg2: NOTRUN -> [SKIP][10] ([i915#7697]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-dg2-2/igt@gem_ba...@multigpu-create-close.html * igt@gem_create@create-ext-cpu-access-big: - shard-dg2: NOTRUN -> [ABORT][11] ([i915#10183]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-dg2-2/igt@gem_cre...@create-ext-cpu-access-big.html * igt@gem_create@create-ext-set-pat: - shard-rkl: NOTRUN -> [SKIP][12] ([i915#8562]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-rkl-1/igt@gem_cre...@create-ext-set-pat.html * igt@gem_ctx_persistence@heartbeat-many: - shard-dg2: NOTRUN -> [SKIP][13] ([i915#8555]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-dg2-5/igt@gem_ctx_persiste...@heartbeat-many.html * igt@gem_exec_balancer@bonded-false-hang: - shard-dg2: NOTRUN -> [SKIP][14] ([i915#4812]) +3 other tests skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-dg2-2/igt@gem_exec_balan...@bonded-false-hang.html * igt@gem_exec_capture@capture-invisible@smem0: - shard-rkl: NOTRUN -> [SKIP][15] ([i915#6334]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-rkl-1/igt@gem_exec_capture@capture-invisi...@smem0.html * igt@gem_exec_capture@many-4k-zero: - shard-tglu: NOTRUN -> [FAIL][16] ([i915#9606]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-tglu-8/igt@gem_exec_capt...@many-4k-zero.html * igt@gem_exec_flush@basic-wb-ro-before-default: - shard-dg2: NOTRUN -> [SKIP][17] ([i915#3539] / [i915#4852]) +2 other tests skip [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130173v1/shard-dg2-2/igt@gem_exec_fl...@basic-wb-ro-before-default.htm
Re: [PATCH v6 1/3] drm/buddy: Implement tracking clear page feature
On 2/16/2024 5:33 PM, Matthew Auld wrote:
On 08/02/2024 15:49, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared memory
but fallback to uncleared if we can't find the cleared blocks.
when driver requests uncleared memory we try to use uncleared but
fallback to cleared memory if necessary.
- When a block gets freed we clear it and mark the freed block as
cleared,
when there are buddies which are cleared as well we can merge them.
Otherwise, we prefer to keep the blocks as separated.
v1: (Christian)
- Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
cleared. Else, reset the clear flag for each block in the list.
- For merging the 2 cleared blocks compare as below,
drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)
v2: (Matthew)
- Add a wrapper drm_buddy_free_list_internal for the freeing of
blocks
operation within drm buddy.
- Write a macro block_incompatible() to allocate the required blocks.
- Update the xe driver for the drm_buddy_free_list change in
arguments.
Signed-off-by: Arunpravin Paneer Selvam
Signed-off-by: Matthew Auld
Suggested-by: Christian König
Probably needs a new unit test.
Sure, I am working on it. I will send in a separate patch.
I think we are missing something to forcefully re-merge everything at
fini()? In theory we can just call the defrag routine. Otherwise we
might trigger various warnings since the root(s) might still be split.
I have added the full defrag in the fini() function. Please review the
patch number 3.
Thanks,
Arun.
Also one nit below. Otherwise I think looks good.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +-
drivers/gpu/drm/drm_buddy.c | 192 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 6 +-
drivers/gpu/drm/tests/drm_buddy_test.c | 10 +-
drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 4 +-
include/drm/drm_buddy.h | 18 +-
6 files changed, 187 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8db880244324..c0c851409241 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -571,7 +571,7 @@ static int amdgpu_vram_mgr_new(struct
ttm_resource_manager *man,
return 0;
error_free_blocks:
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
error_fini:
ttm_resource_fini(man, &vres->base);
@@ -604,7 +604,7 @@ static void amdgpu_vram_mgr_del(struct
ttm_resource_manager *man,
amdgpu_vram_mgr_do_reserve(man);
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
atomic64_sub(vis_usage, &mgr->vis_usage);
@@ -912,7 +912,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device
*adev)
kfree(rsv);
list_for_each_entry_safe(rsv, temp, &mgr->reserved_pages,
blocks) {
- drm_buddy_free_list(&mgr->mm, &rsv->allocated);
+ drm_buddy_free_list(&mgr->mm, &rsv->allocated, 0);
kfree(rsv);
}
if (!adev->gmc.is_app_apu)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..33ad0cfbd54c 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -57,6 +57,16 @@ static void list_insert_sorted(struct drm_buddy *mm,
__list_add(&block->link, node->link.prev, &node->link);
}
+static void clear_reset(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_CLEAR;
+}
+
+static void mark_cleared(struct drm_buddy_block *block)
+{
+ block->header |= DRM_BUDDY_HEADER_CLEAR;
+}
+
static void mark_allocated(struct drm_buddy_block *block)
{
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -223,6 +233,12 @@ static int split_block(struct drm_buddy *mm,
mark_free(mm, block->left);
mark_free(mm, block->right);
+ if (drm_buddy_block_is_clear(block)) {
+ mark_cleared(block->left);
+ mark_cleared(block->right);
+ clear_reset(block);
+ }
+
mark_split(block);
return 0;
@@ -273,6 +289,13 @@ static void __drm_buddy_free(struct drm_buddy *mm,
if (!drm_buddy_block_is_free(buddy))
break;
+ if (drm_buddy_block_is_clear(block) !=
+ drm_buddy_block_is_clear(buddy))
+ break;
+
+ if (drm_buddy_block_is_clear(block))
+ mark_cleared(parent);
+
list_del(&buddy->link);
drm_block_free(mm, block);
@@ -295,26 +318,61 @@ void drm_buddy_free_block(
Re: [PATCH v6 1/3] drm/buddy: Implement tracking clear page feature
On 2/16/2024 5:33 PM, Matthew Auld wrote:
On 08/02/2024 15:49, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared memory
but fallback to uncleared if we can't find the cleared blocks.
when driver requests uncleared memory we try to use uncleared but
fallback to cleared memory if necessary.
- When a block gets freed we clear it and mark the freed block as
cleared,
when there are buddies which are cleared as well we can merge them.
Otherwise, we prefer to keep the blocks as separated.
v1: (Christian)
- Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
cleared. Else, reset the clear flag for each block in the list.
- For merging the 2 cleared blocks compare as below,
drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)
v2: (Matthew)
- Add a wrapper drm_buddy_free_list_internal for the freeing of
blocks
operation within drm buddy.
- Write a macro block_incompatible() to allocate the required blocks.
- Update the xe driver for the drm_buddy_free_list change in
arguments.
Signed-off-by: Arunpravin Paneer Selvam
Signed-off-by: Matthew Auld
Suggested-by: Christian König
Probably needs a new unit test.
I think we are missing something to forcefully re-merge everything at
fini()? In theory we can just call the defrag routine. Otherwise we
might trigger various warnings since the root(s) might still be split.
Also one nit below. Otherwise I think looks good.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +-
drivers/gpu/drm/drm_buddy.c | 192 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 6 +-
drivers/gpu/drm/tests/drm_buddy_test.c | 10 +-
drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 4 +-
include/drm/drm_buddy.h | 18 +-
6 files changed, 187 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8db880244324..c0c851409241 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -571,7 +571,7 @@ static int amdgpu_vram_mgr_new(struct
ttm_resource_manager *man,
return 0;
error_free_blocks:
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
error_fini:
ttm_resource_fini(man, &vres->base);
@@ -604,7 +604,7 @@ static void amdgpu_vram_mgr_del(struct
ttm_resource_manager *man,
amdgpu_vram_mgr_do_reserve(man);
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
atomic64_sub(vis_usage, &mgr->vis_usage);
@@ -912,7 +912,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device
*adev)
kfree(rsv);
list_for_each_entry_safe(rsv, temp, &mgr->reserved_pages,
blocks) {
- drm_buddy_free_list(&mgr->mm, &rsv->allocated);
+ drm_buddy_free_list(&mgr->mm, &rsv->allocated, 0);
kfree(rsv);
}
if (!adev->gmc.is_app_apu)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..33ad0cfbd54c 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -57,6 +57,16 @@ static void list_insert_sorted(struct drm_buddy *mm,
__list_add(&block->link, node->link.prev, &node->link);
}
+static void clear_reset(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_CLEAR;
+}
+
+static void mark_cleared(struct drm_buddy_block *block)
+{
+ block->header |= DRM_BUDDY_HEADER_CLEAR;
+}
+
static void mark_allocated(struct drm_buddy_block *block)
{
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -223,6 +233,12 @@ static int split_block(struct drm_buddy *mm,
mark_free(mm, block->left);
mark_free(mm, block->right);
+ if (drm_buddy_block_is_clear(block)) {
+ mark_cleared(block->left);
+ mark_cleared(block->right);
+ clear_reset(block);
+ }
+
mark_split(block);
return 0;
@@ -273,6 +289,13 @@ static void __drm_buddy_free(struct drm_buddy *mm,
if (!drm_buddy_block_is_free(buddy))
break;
+ if (drm_buddy_block_is_clear(block) !=
+ drm_buddy_block_is_clear(buddy))
+ break;
+
+ if (drm_buddy_block_is_clear(block))
+ mark_cleared(parent);
+
list_del(&buddy->link);
drm_block_free(mm, block);
@@ -295,26 +318,61 @@ void drm_buddy_free_block(struct drm_buddy *mm,
{
BUG_ON(!drm_buddy_block_is_allocated(block));
mm->avail += drm_buddy_block_size(mm, block);
+ if (drm_buddy_block_is_clear(block
Re: [PATCH] drm/i915: Fix doc build issue on intel_cdclk.c
Quoting Rodrigo Vivi (2024-02-20 19:30:30-03:00)
>Fixing some doc build issues:
>
>Documentation/gpu/i915:222: drivers/gpu/drm/i915/display/intel_cdclk.c:69:
>ERROR: Unexpected indentation.
>Documentation/gpu/i915:222: ./drivers/gpu/drm/i915/display/intel_cdclk.c:70:
>WARNING: Block quote ends without a blank line; unexpected unindent.
Ugh... I wonder if our CI could do something like:
make SPHINXDIRS=gpu htmldocs
to capture those little mistakes we make...
>
>Closes: https://lore.kernel.org/all/20240219161747.0e867...@canb.auug.org.au/
>Fixes: 79e2ea2eaaa6 ("drm/i915/cdclk: Document CDCLK update methods")
>Cc: Ville Syrjälä
>Cc: Gustavo Sousa
>Reported-by: Stephen Rothwell
>Signed-off-by: Rodrigo Vivi
>---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 6 ++
> 1 file changed, 6 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
>b/drivers/gpu/drm/i915/display/intel_cdclk.c
>index 30dae4fef6cb..42cbc3203d2c 100644
>--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>@@ -65,13 +65,19 @@
> *
> * Several methods exist to change the CDCLK frequency, which ones are
> * supported depends on the platform:
>+ *
Looks like this blank line should be enough to fix the warning and the
blank lines between the list items are not strictly necessary.
With or without the blank lines between list items,
Reviewed-by: Gustavo Sousa
Thanks for the fix!
And it seems I have some homework to do on [1] before gets applied :-)
[1] https://patchwork.freedesktop.org/series/130016/
> * - Full PLL disable + re-enable with new VCO frequency. Pipes must be
> inactive.
>+ *
> * - CD2X divider update. Single pipe can be active as the divider update
> * can be synchronized with the pipe's start of vblank.
>+ *
> * - Crawl the PLL smoothly to the new VCO frequency. Pipes can be active.
>+ *
> * - Squash waveform update. Pipes can be active.
>+ *
> * - Crawl and squash can also be done back to back. Pipes can be active.
> *
>+ *
This extra blank line could be removed.
--
Gustavo Sousa
> * RAWCLK is a fixed frequency clock, often used by various auxiliary
> * blocks such as AUX CH or backlight PWM. Hence the only thing we
> * really need to know about RAWCLK is its frequency so that various
>--
>2.43.2
>
Re: [PATCH] drm/i915/cdclk: Document CDCLK components
Quoting Ville Syrjälä (2024-02-19 17:12:17-03:00) >On Fri, Feb 16, 2024 at 01:45:25PM -0300, Gustavo Sousa wrote: >> Improve documentation by giving an overview of the components involved >> in the generation of the CDCLK. >> >> Signed-off-by: Gustavo Sousa > >Reviewed-by: Ville Syrjälä > >> --- >> drivers/gpu/drm/i915/display/intel_cdclk.c | 25 ++ >> 1 file changed, 25 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c >> b/drivers/gpu/drm/i915/display/intel_cdclk.c >> index 30dae4fef6cb..ef1660f94e46 100644 >> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c >> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c >> @@ -63,6 +63,31 @@ >> * DMC will not change the active CDCLK frequency however, so that part >> * will still be performed by the driver directly. >> * >> + * There are multiple components involved in the generation of the CDCLK >> + * frequency: Looks like we need a blank line here to get `make htmldocs` to parse this without warnings. There is a similar fix[1] that's currently in-flight, which also adds blank lines between list items, but that doesn't seem to be strictly necessary. Let's wait to see how that series gets applied so that we make a fix that is consistent with that one. [1]: https://patchwork.freedesktop.org/series/130159/ -- Gustavo Sousa >> + * - We have the CDCLK PLL, which generates an output clock based on a >> + * reference clock and a ratio parameter. >> + * - The CD2X Divider, which divides the output of the PLL based on a >> + * divisor selected from a set of pre-defined choices. >> + * - The CD2X Squasher, which further divides the output based on a >> + * waveform represented as a sequence of bits where each zero >> + * "squashes out" a clock cycle. >> + * - And, finally, a fixed divider that divides the output frequency by 2. >> + * >> + * As such, the resulting CDCLK frequency can be calculated with the >> + * following formula: >> + * >> + * cdclk = vco / cd2x_div / (sq_len / sq_div) / 2 >> + * >> + * , where vco is the frequency generated by the PLL; cd2x_div >> + * represents the CD2X Divider; sq_len and sq_div are the bit length >> + * and the number of high bits for the CD2X Squasher waveform, respectively; >> + * and 2 represents the fixed divider. >> + * >> + * Note that some older platforms do not contain the CD2X Divider >> + * and/or CD2X Squasher, in which case we can ignore their respective >> + * factors in the formula above. >> + * >> * Several methods exist to change the CDCLK frequency, which ones are >> * supported depends on the platform: >> * - Full PLL disable + re-enable with new VCO frequency. Pipes must be >> inactive. >> -- >> 2.43.0 > >-- >Ville Syrjälä >Intel
[PATCH 1/2] drm/i915: Shadow default engine context image in the context
From: Tvrtko Ursulin
To enable adding override of the default engine context image let us start
shadowing the per engine state in the context.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc: Carlos Santa
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ---
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 7 ---
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 7eccbd70d89f..b179178680a5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -99,6 +99,8 @@ struct intel_context {
struct i915_address_space *vm;
struct i915_gem_context __rcu *gem_context;
+ struct file *default_state;
+
/*
* @signal_lock protects the list of requests that need signaling,
* @signals. While there are any requests that need signaling,
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 7c367ba8d9dc..d4eb822d20ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1060,9 +1060,8 @@ void lrc_init_state(struct intel_context *ce,
set_redzone(state, engine);
- if (engine->default_state) {
- shmem_read(engine->default_state, 0,
- state, engine->context_size);
+ if (ce->default_state) {
+ shmem_read(ce->default_state, 0, state, engine->context_size);
__set_bit(CONTEXT_VALID_BIT, &ce->flags);
inhibit = false;
}
@@ -1174,6 +1173,8 @@ int lrc_alloc(struct intel_context *ce, struct
intel_engine_cs *engine)
GEM_BUG_ON(ce->state);
+ ce->default_state = engine->default_state;
+
vma = __lrc_alloc_state(ce, engine);
if (IS_ERR(vma))
return PTR_ERR(vma);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 92085ffd23de..8625e88e785f 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -474,8 +474,7 @@ static int ring_context_init_default_state(struct
intel_context *ce,
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
- shmem_read(ce->engine->default_state, 0,
- vaddr, ce->engine->context_size);
+ shmem_read(ce->default_state, 0, vaddr, ce->engine->context_size);
i915_gem_object_flush_map(obj);
__i915_gem_object_release_map(obj);
@@ -491,7 +490,7 @@ static int ring_context_pre_pin(struct intel_context *ce,
struct i915_address_space *vm;
int err = 0;
- if (ce->engine->default_state &&
+ if (ce->default_state &&
!test_bit(CONTEXT_VALID_BIT, &ce->flags)) {
err = ring_context_init_default_state(ce, ww);
if (err)
@@ -570,6 +569,8 @@ static int ring_context_alloc(struct intel_context *ce)
{
struct intel_engine_cs *engine = ce->engine;
+ ce->default_state = engine->default_state;
+
/* One ringbuffer to rule them all */
GEM_BUG_ON(!engine->legacy.ring);
ce->ring = engine->legacy.ring;
--
2.40.1
[PATCH v2 0/2] GPU hang replay
From: Tvrtko Ursulin Please see 2/2 for explanation and rationale. v2: * Extracted shadowing of default state into a leading patch. Tvrtko Ursulin (2): drm/i915: Shadow default engine context image in the context drm/i915: Support replaying GPU hangs with captured context image drivers/gpu/drm/i915/Kconfig.debug| 17 +++ drivers/gpu/drm/i915/gem/i915_gem_context.c | 113 ++ drivers/gpu/drm/i915/gt/intel_context.c | 2 + drivers/gpu/drm/i915/gt/intel_context.h | 22 drivers/gpu/drm/i915/gt/intel_context_types.h | 3 + drivers/gpu/drm/i915/gt/intel_lrc.c | 8 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 8 +- drivers/gpu/drm/i915/i915_params.c| 5 + drivers/gpu/drm/i915/i915_params.h| 3 +- include/uapi/drm/i915_drm.h | 27 + 10 files changed, 201 insertions(+), 7 deletions(-) -- 2.40.1
[PATCH 2/2] drm/i915: Support replaying GPU hangs with captured context image
From: Tvrtko Ursulin
When debugging GPU hangs Mesa developers are finding it useful to replay
the captured error state against the simulator. But due various simulator
limitations which prevent replicating all hangs, one step further is being
able to replay against a real GPU.
This is almost doable today with the missing part being able to upload the
captured context image into the driver state prior to executing the
uploaded hanging batch and all the buffers.
To enable this last part we add a new context parameter called
I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU
configuration pattern of being able to select which context to apply
against, paired with the actual image and its size.
Since this is adding a new concept of debug only uapi, we hide it behind
a new kconfig option and also require activation with a module parameter.
Together with a warning banner printed at driver load, all those combined
should be sufficient to guard against inadvertently enabling the feature.
In terms of implementation we allow the legacy context set param to be
used since that removes the need to record the per context data in the
proto context, while still allowing flexibility of specifying context
images for any context.
Mesa MR using the uapi can be seen at:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594
v2:
* Fix whitespace alignment as per checkpatch.
* Added warning on userspace misuse.
* Rebase for extracting ce->default_state shadowing.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc: Carlos Santa
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi # v1
---
drivers/gpu/drm/i915/Kconfig.debug| 17 +++
drivers/gpu/drm/i915/gem/i915_gem_context.c | 113 ++
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
drivers/gpu/drm/i915/gt/intel_context.h | 22
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
drivers/gpu/drm/i915/i915_params.c| 5 +
drivers/gpu/drm/i915/i915_params.h| 3 +-
include/uapi/drm/i915_drm.h | 27 +
10 files changed, 193 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 5b7162076850..32e9f70e91ed 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -16,6 +16,23 @@ config DRM_I915_WERROR
If in doubt, say "N".
+config DRM_I915_REPLAY_GPU_HANGS_API
+ bool "Enable GPU hang replay userspace API"
+ depends on DRM_I915
+ depends on EXPERT
+ default n
+ help
+ Choose this option if you want to enable special and unstable
+ userspace API used for replaying GPU hangs on a running system.
+
+ This API is intended to be used by userspace graphics stack developers
+ and provides no stability guarantees.
+
+ The API needs to be activated at boot time using the
+ enable_debug_only_api module parameter.
+
+ If in doubt, say "N".
+
config DRM_I915_DEBUG
bool "Enable additional driver debugging"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..481aacbc1772 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -78,6 +78,7 @@
#include "gt/intel_engine_user.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_ring.h"
+#include "gt/shmem_utils.h"
#include "pxp/intel_pxp.h"
@@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct drm_i915_file_private
*fpriv,
case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
+ case I915_CONTEXT_PARAM_CONTEXT_IMAGE:
default:
ret = -EINVAL;
break;
@@ -2092,6 +2094,95 @@ static int get_protected(struct i915_gem_context *ctx,
return 0;
}
+static int set_context_image(struct i915_gem_context *ctx,
+struct drm_i915_gem_context_param *args)
+{
+ struct i915_gem_context_param_context_image user;
+ struct intel_context *ce;
+ struct file *shmem_state;
+ unsigned long lookup;
+ void *state;
+ int ret = 0;
+
+ if (!IS_ENABLED(CONFIG_DRM_I915_REPLAY_GPU_HANGS_API))
+ return -EINVAL;
+
+ if (!ctx->i915->params.enable_debug_only_api)
+ return -EINVAL;
+
+ if (args->size < sizeof(user))
+ return -EINVAL;
+
+ if (copy_from_user(&user, u64_to_user_ptr(args->value), sizeof(user)))
+ return -EFAULT;
+
+ if (user.mbz)
+ return -EINVAL;
+
+ if (user.flags & ~(I915_CONTEXT_IMAGE_FLAG_ENGINE_INDEX))
+ return -EINVAL;
+
+ lookup = 0;
+ if
Re: [PATCH v7 3/3] drm/buddy: Add defragmentation support
Am 21.02.24 um 13:18 schrieb Arunpravin Paneer Selvam:
Add a function to support defragmentation.
Thinking more about it maybe you want to call this function differently.
Essentially we are force merging pages even if their cleared flag
doesn't match, that is something different than defragmentation I think.
Maybe rename it for force_merge or something similar. Not mandatory,
just an idea how to improve the readability of the code.
Apart from that just let me know when I can push it to drm-misc-next.
Christian.
v1:
- Defragment the memory beginning from min_order
till the required memory space is available.
v2(Matthew):
- add amdgpu user for defragmentation
- add a warning if the two blocks are incompatible on
defragmentation
- call full defragmentation in the fini() function
- place a condition to test if min_order is equal to 0
- replace the list with safe_reverse() variant as we might
remove the block from the list.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 +++-
drivers/gpu/drm/drm_buddy.c | 93 +---
include/drm/drm_buddy.h | 3 +
3 files changed, 97 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index e494f5bf136a..cff8a526c622 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -533,8 +533,21 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
min_block_size,
&vres->blocks,
vres->flags);
- if (unlikely(r))
- goto error_free_blocks;
+ if (unlikely(r)) {
+ if (r == -ENOSPC) {
+ drm_buddy_defrag(mm, min_block_size);
+ r = drm_buddy_alloc_blocks(mm, fpfn,
+ lpfn,
+ size,
+ min_block_size,
+ &vres->blocks,
+ vres->flags);
+ if (unlikely(r))
+ goto error_free_blocks;
+ } else {
+ goto error_free_blocks;
+ }
+ }
if (size > remaining_size)
remaining_size = 0;
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 18e004fa39d3..56bd1560fbcd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -203,6 +203,8 @@ void drm_buddy_fini(struct drm_buddy *mm)
drm_block_free(mm, mm->roots[i]);
}
+ drm_buddy_defrag(mm, mm->chunk_size << mm->max_order);
+
WARN_ON(mm->avail != mm->size);
kfree(mm->roots);
@@ -276,25 +278,39 @@ drm_get_buddy(struct drm_buddy_block *block)
}
EXPORT_SYMBOL(drm_get_buddy);
-static void __drm_buddy_free(struct drm_buddy *mm,
-struct drm_buddy_block *block)
+static unsigned int __drm_buddy_free(struct drm_buddy *mm,
+struct drm_buddy_block *block,
+bool defrag)
{
+ unsigned int order, block_order;
struct drm_buddy_block *parent;
+ block_order = drm_buddy_block_order(block);
+
while ((parent = block->parent)) {
- struct drm_buddy_block *buddy;
+ struct drm_buddy_block *buddy = NULL;
buddy = __get_buddy(block);
if (!drm_buddy_block_is_free(buddy))
break;
- if (drm_buddy_block_is_clear(block) !=
- drm_buddy_block_is_clear(buddy))
- break;
+ if (!defrag) {
+ /*
+* Check the block and its buddy clear state and exit
+* the loop if they both have the dissimilar state.
+*/
+ if (drm_buddy_block_is_clear(block) !=
+ drm_buddy_block_is_clear(buddy))
+ break;
- if (drm_buddy_block_is_clear(block))
- mark_cleared(parent);
+ if (drm_buddy_block_is_clear(block))
+ mark_cleared(parent);
+ }
+
+ WARN_ON(defrag &&
+ (drm_buddy_block_is_clear(block) ==
+drm_buddy_block_is_clear(buddy)));
list_del(&buddy->link);
@@ -304,8 +320,57 @@ static void __drm_buddy_free(struct
[PATCH] drm/i915: Fix doc build issue on intel_cdclk.c
Fixing some doc build issues:
Documentation/gpu/i915:222: drivers/gpu/drm/i915/display/intel_cdclk.c:69:
ERROR: Unexpected indentation.
Documentation/gpu/i915:222: ./drivers/gpu/drm/i915/display/intel_cdclk.c:70:
WARNING: Block quote ends without a blank line; unexpected unindent.
v2: Minimize the empty lines (Gustavo)
Closes: https://lore.kernel.org/all/20240219161747.0e867...@canb.auug.org.au/
Fixes: 79e2ea2eaaa6 ("drm/i915/cdclk: Document CDCLK update methods")
Cc: Ville Syrjälä
Cc: Gustavo Sousa
Reported-by: Stephen Rothwell
Signed-off-by: Rodrigo Vivi
Reviewed-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 30dae4fef6cb..ed89b86ea625 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -65,6 +65,7 @@
*
* Several methods exist to change the CDCLK frequency, which ones are
* supported depends on the platform:
+ *
* - Full PLL disable + re-enable with new VCO frequency. Pipes must be
inactive.
* - CD2X divider update. Single pipe can be active as the divider update
* can be synchronized with the pipe's start of vblank.
--
2.43.2
[PATCH 0/1] [CI] Test MTL DMC v2.21
The following changes since commit 88364c11402c5a0cdb3a07530b76eef32882a54b: [CI] xe: Add xe directory (2023-11-16 17:28:49 -0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware b407637671a914a401bb818d7691ba45b6b04d10 for you to fetch changes up to b407637671a914a401bb818d7691ba45b6b04d10: [CI] i915: Add MTL DMC v2.21 (2024-02-21 12:59:11 -0300) Gustavo Sousa (1): [CI] i915: Add MTL DMC v2.21 i915/mtl_dmc_ver2_21.bin | Bin 0 -> 52476 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 i915/mtl_dmc_ver2_21.bin
[PATCH 1/1] [CI] drm/i915/dmc: Hardcode path to MTL DMC v2.21
NOT TO BE REVIEWED/MERGED Hardcode path to DMC firmware for CI purposes only. Signed-off-by: Gustavo Sousa --- drivers/gpu/drm/i915/display/intel_dmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c index 835781624482..32cee5cd68e5 100644 --- a/drivers/gpu/drm/i915/display/intel_dmc.c +++ b/drivers/gpu/drm/i915/display/intel_dmc.c @@ -93,7 +93,7 @@ static struct intel_dmc *i915_to_dmc(struct drm_i915_private *i915) #define DISPLAY_VER13_DMC_MAX_FW_SIZE 0x2 #define DISPLAY_VER12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE -#define MTL_DMC_PATH DMC_PATH(mtl) +#define MTL_DMC_PATH "i915/mtl_dmc_ver2_21.bin" MODULE_FIRMWARE(MTL_DMC_PATH); #define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08) -- 2.43.0
Re: [PATCH v6 1/3] drm/buddy: Implement tracking clear page feature
On 21/02/2024 12:40, Paneer Selvam, Arunpravin wrote:
On 2/16/2024 5:33 PM, Matthew Auld wrote:
On 08/02/2024 15:49, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared memory
but fallback to uncleared if we can't find the cleared blocks.
when driver requests uncleared memory we try to use uncleared but
fallback to cleared memory if necessary.
- When a block gets freed we clear it and mark the freed block as
cleared,
when there are buddies which are cleared as well we can merge them.
Otherwise, we prefer to keep the blocks as separated.
v1: (Christian)
- Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
cleared. Else, reset the clear flag for each block in the list.
- For merging the 2 cleared blocks compare as below,
drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)
v2: (Matthew)
- Add a wrapper drm_buddy_free_list_internal for the freeing of
blocks
operation within drm buddy.
- Write a macro block_incompatible() to allocate the required blocks.
- Update the xe driver for the drm_buddy_free_list change in
arguments.
Signed-off-by: Arunpravin Paneer Selvam
Signed-off-by: Matthew Auld
Suggested-by: Christian König
Probably needs a new unit test.
I think we are missing something to forcefully re-merge everything at
fini()? In theory we can just call the defrag routine. Otherwise we
might trigger various warnings since the root(s) might still be split.
Also one nit below. Otherwise I think looks good.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +-
drivers/gpu/drm/drm_buddy.c | 192 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 6 +-
drivers/gpu/drm/tests/drm_buddy_test.c | 10 +-
drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 4 +-
include/drm/drm_buddy.h | 18 +-
6 files changed, 187 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8db880244324..c0c851409241 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -571,7 +571,7 @@ static int amdgpu_vram_mgr_new(struct
ttm_resource_manager *man,
return 0;
error_free_blocks:
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
error_fini:
ttm_resource_fini(man, &vres->base);
@@ -604,7 +604,7 @@ static void amdgpu_vram_mgr_del(struct
ttm_resource_manager *man,
amdgpu_vram_mgr_do_reserve(man);
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
atomic64_sub(vis_usage, &mgr->vis_usage);
@@ -912,7 +912,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device
*adev)
kfree(rsv);
list_for_each_entry_safe(rsv, temp, &mgr->reserved_pages,
blocks) {
- drm_buddy_free_list(&mgr->mm, &rsv->allocated);
+ drm_buddy_free_list(&mgr->mm, &rsv->allocated, 0);
kfree(rsv);
}
if (!adev->gmc.is_app_apu)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..33ad0cfbd54c 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -57,6 +57,16 @@ static void list_insert_sorted(struct drm_buddy *mm,
__list_add(&block->link, node->link.prev, &node->link);
}
+static void clear_reset(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_CLEAR;
+}
+
+static void mark_cleared(struct drm_buddy_block *block)
+{
+ block->header |= DRM_BUDDY_HEADER_CLEAR;
+}
+
static void mark_allocated(struct drm_buddy_block *block)
{
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -223,6 +233,12 @@ static int split_block(struct drm_buddy *mm,
mark_free(mm, block->left);
mark_free(mm, block->right);
+ if (drm_buddy_block_is_clear(block)) {
+ mark_cleared(block->left);
+ mark_cleared(block->right);
+ clear_reset(block);
+ }
+
mark_split(block);
return 0;
@@ -273,6 +289,13 @@ static void __drm_buddy_free(struct drm_buddy *mm,
if (!drm_buddy_block_is_free(buddy))
break;
+ if (drm_buddy_block_is_clear(block) !=
+ drm_buddy_block_is_clear(buddy))
+ break;
+
+ if (drm_buddy_block_is_clear(block))
+ mark_cleared(parent);
+
list_del(&buddy->link);
drm_block_free(mm, block);
@@ -295,26 +318,61 @@ void drm_buddy_free_block(struct drm_buddy *mm,
{
BUG_ON(!drm_buddy_block_is_allocated(block));
mm->avail += drm_buddy_block_si
✗ Fi.CI.BUILD: failure for drm/i915: Add support for XRandR Border property
== Series Details == Series: drm/i915: Add support for XRandR Border property URL : https://patchwork.freedesktop.org/series/130183/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers LD [M] drivers/gpu/drm/i915/i915.o LD [M] drivers/gpu/drm/i915/kvmgt.o HDRTEST drivers/gpu/drm/i915/display/intel_connector.h In file included from : ./drivers/gpu/drm/i915/display/intel_connector.h:29:41: error: ‘struct intel_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 29 | int intel_connector_apply_border(struct intel_crtc_state *crtc_state, | ^~~~ cc1: all warnings being treated as errors make[6]: *** [drivers/gpu/drm/i915/Makefile:440: drivers/gpu/drm/i915/display/intel_connector.hdrtest] Error 1 make[5]: *** [scripts/Makefile.build:481: drivers/gpu/drm/i915] Error 2 make[4]: *** [scripts/Makefile.build:481: drivers/gpu/drm] Error 2 make[3]: *** [scripts/Makefile.build:481: drivers/gpu] Error 2 make[2]: *** [scripts/Makefile.build:481: drivers] Error 2 make[1]: *** [/home/kbuild/kernel/Makefile:1921: .] Error 2 make: *** [Makefile:240: __sub-make] Error 2 Build failed, no error log produced
Re: [PATCH v1] drivers/i915/intel_bios: Fix parsing backlight BDB data
On Tue, Feb 20, 2024 at 02:12:57PM -0700, Karthikeyan Ramasubramanian wrote:
> Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to
> backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB
> contents") updated the backlight BDB data accordingly. This broke the
> parsing of backlight BDB data in VBT for versions 236 - 238 (both
> inclusive) and hence the backlight controls are not responding on units
> with the concerned BDB version.
>
> backlight_control information has been present in backlight BDB data
> from at least BDB version 191 onwards, if not before. Hence this patch
> extracts the backlight_control information if the block size of
> backlight BDB is >= version 191 backlight BDB block size.
> Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236).
> Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251).
>
> Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents")
> Cc: sta...@vger.kernel.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Karthikeyan Ramasubramanian
> ---
>
> drivers/gpu/drm/i915/display/intel_bios.c | 22 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 --
> 2 files changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index aa169b0055e97..4ec50903b9e64 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1041,23 +1041,13 @@ parse_lfp_backlight(struct drm_i915_private *i915,
>
> panel->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> panel->vbt.backlight.controller = 0;
> - if (i915->display.vbt.version >= 191) {
> - size_t exp_size;
> + if (i915->display.vbt.version >= 191 &&
> + get_blocksize(backlight_data) >= EXP_BDB_LFP_BL_DATA_SIZE_REV_191) {
The size checks looks like nonsense to me. I guess maybe
we needed it before we were guaranteed to have the full
struct's worth of memory. But there should be no need for
this anymore.
> + const struct lfp_backlight_control_method *method;
>
> - if (i915->display.vbt.version >= 236)
> - exp_size = sizeof(struct bdb_lfp_backlight_data);
> - else if (i915->display.vbt.version >= 234)
> - exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
> - else
> - exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_191;
> -
> - if (get_blocksize(backlight_data) >= exp_size) {
> - const struct lfp_backlight_control_method *method;
> -
> - method = &backlight_data->backlight_control[panel_type];
> - panel->vbt.backlight.type = method->type;
> - panel->vbt.backlight.controller = method->controller;
> - }
> + method = &backlight_data->backlight_control[panel_type];
> + panel->vbt.backlight.type = method->type;
> + panel->vbt.backlight.controller = method->controller;
> }
>
> panel->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index a9f44abfc9fc2..aeea5635a37ff 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -899,8 +899,6 @@ struct lfp_brightness_level {
>
> #define EXP_BDB_LFP_BL_DATA_SIZE_REV_191 \
> offsetof(struct bdb_lfp_backlight_data, brightness_level)
> -#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
> - offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
>
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> --
> 2.44.0.rc0.258.g7320e95886-goog
--
Ville Syrjälä
Intel
✗ Fi.CI.BUILD: failure for series starting with [v7,1/3] drm/buddy: Implement tracking clear page feature
== Series Details == Series: series starting with [v7,1/3] drm/buddy: Implement tracking clear page feature URL : https://patchwork.freedesktop.org/series/130200/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers AR drivers/gpu/drm/display/built-in.a CC [M] drivers/gpu/drm/display/drm_display_helper_mod.o CC [M] drivers/gpu/drm/display/drm_dp_dual_mode_helper.o CC [M] drivers/gpu/drm/display/drm_dp_helper.o CC [M] drivers/gpu/drm/display/drm_dp_mst_topology.o CC [M] drivers/gpu/drm/display/drm_dsc_helper.o CC [M] drivers/gpu/drm/display/drm_hdcp_helper.o CC [M] drivers/gpu/drm/display/drm_hdmi_helper.o CC [M] drivers/gpu/drm/display/drm_scdc_helper.o CC [M] drivers/gpu/drm/display/drm_dp_aux_dev.o LD [M] drivers/gpu/drm/display/drm_display_helper.o AR drivers/gpu/drm/renesas/rcar-du/built-in.a AR drivers/gpu/drm/renesas/rz-du/built-in.a AR drivers/gpu/drm/renesas/built-in.a AR drivers/gpu/drm/omapdrm/built-in.a AR drivers/gpu/drm/tilcdc/built-in.a AR drivers/gpu/drm/imx/built-in.a AR drivers/gpu/drm/i2c/built-in.a AR drivers/gpu/drm/panel/built-in.a AR drivers/gpu/drm/bridge/analogix/built-in.a AR drivers/gpu/drm/bridge/cadence/built-in.a AR drivers/gpu/drm/bridge/imx/built-in.a AR drivers/gpu/drm/bridge/synopsys/built-in.a AR drivers/gpu/drm/bridge/built-in.a AR drivers/gpu/drm/hisilicon/built-in.a AR drivers/gpu/drm/mxsfb/built-in.a AR drivers/gpu/drm/tiny/built-in.a AR drivers/gpu/drm/xlnx/built-in.a AR drivers/gpu/drm/gud/built-in.a AR drivers/gpu/drm/solomon/built-in.a CC [M] drivers/gpu/drm/tests/drm_buddy_test.o drivers/gpu/drm/tests/drm_buddy_test.c: In function ‘drm_test_buddy_alloc_contiguous’: drivers/gpu/drm/tests/drm_buddy_test.c:68:2: error: too few arguments to function ‘drm_buddy_free_list’ 68 | drm_buddy_free_list(&mm, &middle); | ^~~ In file included from drivers/gpu/drm/tests/drm_buddy_test.c:13: ./include/drm/drm_buddy.h:166:6: note: declared here 166 | void drm_buddy_free_list(struct drm_buddy *mm, | ^~~ drivers/gpu/drm/tests/drm_buddy_test.c:78:2: error: too few arguments to function ‘drm_buddy_free_list’ 78 | drm_buddy_free_list(&mm, &right); | ^~~ In file included from drivers/gpu/drm/tests/drm_buddy_test.c:13: ./include/drm/drm_buddy.h:166:6: note: declared here 166 | void drm_buddy_free_list(struct drm_buddy *mm, | ^~~ drivers/gpu/drm/tests/drm_buddy_test.c:93:2: error: too few arguments to function ‘drm_buddy_free_list’ 93 | drm_buddy_free_list(&mm, &left); | ^~~ In file included from drivers/gpu/drm/tests/drm_buddy_test.c:13: ./include/drm/drm_buddy.h:166:6: note: declared here 166 | void drm_buddy_free_list(struct drm_buddy *mm, | ^~~ drivers/gpu/drm/tests/drm_buddy_test.c:105:2: error: too few arguments to function ‘drm_buddy_free_list’ 105 | drm_buddy_free_list(&mm, &allocated); | ^~~ In file included from drivers/gpu/drm/tests/drm_buddy_test.c:13: ./include/drm/drm_buddy.h:166:6: note: declared here 166 | void drm_buddy_free_list(struct drm_buddy *mm, | ^~~ make[6]: *** [scripts/Makefile.build:243: drivers/gpu/drm/tests/drm_buddy_test.o] Error 1 make[5]: *** [scripts/Makefile.build:481: drivers/gpu/drm/tests] Error 2 make[4]: *** [scripts/Makefile.build:481: drivers/gpu/drm] Error 2 make[3]: *** [scripts/Makefile.build:481: drivers/gpu] Error 2 make[2]: *** [scripts/Makefile.build:481: drivers] Error 2 make[1]: *** [/home/kbuild2/kernel/Makefile:1921: .] Error 2 make: *** [Makefile:240: __sub-make] Error 2 Build failed, no error log produced
Re: [PATCH v2 5/6] drm/i915/psr: Enable ALPM for eDP Panel replay
Hi Jouni,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm/drm-next next-20240221]
[cannot apply to drm-intel/for-linux-next-fixes linus/master v6.8-rc5]
[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#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Jouni-H-gander/drm-display-Add-missing-aux-less-alpm-wake-related-bits/20240220-201356
base: git://anongit.freedesktop.org/drm-intel for-linux-next
patch link:
https://lore.kernel.org/r/20240220121045.2156004-6-jouni.hogander%40intel.com
patch subject: [PATCH v2 5/6] drm/i915/psr: Enable ALPM for eDP Panel replay
config: riscv-allmodconfig
(https://download.01.org/0day-ci/archive/20240222/202402220225.2evin531-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
36adfec155de366d722f2bac8ff9162289dcf06c)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240222/202402220225.2evin531-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202402220225.2evin531-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_psr.c:1705:3: warning: variable
>> 'alpm_ctl' is uninitialized when used here [-Wuninitialized]
1705 | alpm_ctl |= ALPM_CTL_ALPM_ENABLE |
| ^~~~
drivers/gpu/drm/i915/display/intel_psr.c:1699:14: note: initialize the
variable 'alpm_ctl' to silence this warning
1699 | u32 alpm_ctl;
| ^
| = 0
1 warning generated.
vim +/alpm_ctl +1705 drivers/gpu/drm/i915/display/intel_psr.c
1693
1694 static void lnl_alpm_configure(struct intel_dp *intel_dp)
1695 {
1696 struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
1697 enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
1698 struct intel_psr *psr = &intel_dp->psr;
1699 u32 alpm_ctl;
1700
1701 if (DISPLAY_VER(dev_priv) < 20)
1702 return;
1703
1704 if (intel_dp->psr.panel_replay_enabled &&
intel_dp_is_edp(intel_dp)) {
> 1705 alpm_ctl |= ALPM_CTL_ALPM_ENABLE |
1706 ALPM_CTL_ALPM_AUX_LESS_ENABLE |
1707 ALPM_CTL_AUX_LESS_SLEEP_HOLD_TIME_50_SYMBOLS;
1708
1709 intel_de_write(dev_priv, PORT_ALPM_CTL(cpu_transcoder),
1710 PORT_ALPM_CTL_ALPM_AUX_LESS_ENABLE |
1711 PORT_ALPM_CTL_MAX_PHY_SWING_SETUP(15) |
1712 PORT_ALPM_CTL_MAX_PHY_SWING_HOLD(0) |
1713 PORT_ALPM_CTL_SILENCE_PERIOD(
1714
psr->alpm_parameters.silence_period_sym_clocks));
1715
1716 intel_de_write(dev_priv,
PORT_ALPM_LFPS_CTL(cpu_transcoder),
1717 PORT_ALPM_LFPS_CTL_LFPS_CYCLE_COUNT(10) |
1718
PORT_ALPM_LFPS_CTL_LFPS_HALF_CYCLE_DURATION(
1719
psr->alpm_parameters.lfps_half_cycle_num_of_syms) |
1720
PORT_ALPM_LFPS_CTL_FIRST_LFPS_HALF_CYCLE_DURATION(
1721
psr->alpm_parameters.lfps_half_cycle_num_of_syms) |
1722
PORT_ALPM_LFPS_CTL_LAST_LFPS_HALF_CYCLE_DURATION(
1723
psr->alpm_parameters.lfps_half_cycle_num_of_syms));
1724 } else {
1725 alpm_ctl = ALPM_CTL_EXTENDED_FAST_WAKE_ENABLE |
1726
ALPM_CTL_EXTENDED_FAST_WAKE_TIME(psr->alpm_parameters.fast_wake_lines);
1727 }
1728
1729 alpm_ctl |=
ALPM_CTL_ALPM_ENTRY_CHECK(psr->alpm_parameters.check_entry_lines);
1730
1731 intel_de_write(dev_priv, ALPM_CTL(cpu_transcoder), alpm_ctl);
1732 }
1733
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
✓ Fi.CI.BAT: success for drm/i915/display/debugfs: New entry "DRRS capable" to i915_drrs_status
== Series Details ==
Series: drm/i915/display/debugfs: New entry "DRRS capable" to i915_drrs_status
URL : https://patchwork.freedesktop.org/series/130197/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14310 -> Patchwork_130197v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/index.html
Participating hosts (37 -> 35)
--
Missing(2): bat-arls-1 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_130197v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_create@basic-files:
- {bat-arls-2}: [PASS][1] -> [TIMEOUT][2] +1 other test timeout
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/bat-arls-2/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/bat-arls-2/igt@gem_ctx_cre...@basic-files.html
* igt@gem_exec_fence@basic-busy:
- {bat-arls-2}: NOTRUN -> [TIMEOUT][3] +4 other tests timeout
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/bat-arls-2/igt@gem_exec_fe...@basic-busy.html
Known issues
Here are the changes found in Patchwork_130197v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- bat-jsl-1: [PASS][4] -> [FAIL][5] ([i915#8293])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/bat-jsl-1/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/bat-jsl-1/boot.html
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[ABORT][6] ([i915#7911]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
Build changes
-
* Linux: CI_DRM_14310 -> Patchwork_130197v1
CI-20190529: 20190529
CI_DRM_14310: 53c127ff2eda902ff59370f44526e5e8ae49dec0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7719: 7719
Patchwork_130197v1: 53c127ff2eda902ff59370f44526e5e8ae49dec0 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
f7610b612b4a drm/i915/display/debugfs: New entry "DRRS capable" to
i915_drrs_status
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/index.html
Re: [PATCH v7 3/3] drm/buddy: Add defragmentation support
On 21/02/2024 12:18, Arunpravin Paneer Selvam wrote:
Add a function to support defragmentation.
v1:
- Defragment the memory beginning from min_order
till the required memory space is available.
v2(Matthew):
- add amdgpu user for defragmentation
- add a warning if the two blocks are incompatible on
defragmentation
- call full defragmentation in the fini() function
- place a condition to test if min_order is equal to 0
- replace the list with safe_reverse() variant as we might
remove the block from the list.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 +++-
drivers/gpu/drm/drm_buddy.c | 93 +---
include/drm/drm_buddy.h | 3 +
3 files changed, 97 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index e494f5bf136a..cff8a526c622 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -533,8 +533,21 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
min_block_size,
&vres->blocks,
vres->flags);
- if (unlikely(r))
- goto error_free_blocks;
+ if (unlikely(r)) {
+ if (r == -ENOSPC) {
+ drm_buddy_defrag(mm, min_block_size);
+ r = drm_buddy_alloc_blocks(mm, fpfn,
+ lpfn,
+ size,
+ min_block_size,
+ &vres->blocks,
+ vres->flags);
+ if (unlikely(r))
+ goto error_free_blocks;
+ } else {
+ goto error_free_blocks;
+ }
+ }
if (size > remaining_size)
remaining_size = 0;
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 18e004fa39d3..56bd1560fbcd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -203,6 +203,8 @@ void drm_buddy_fini(struct drm_buddy *mm)
drm_block_free(mm, mm->roots[i]);
}
+ drm_buddy_defrag(mm, mm->chunk_size << mm->max_order);
I think this needs to be called higher up, otherwise we blow up with the
WARN, plus we just freed the root(s). There is also the case with
non-power-of-two VRAM size, in which case you get multiple roots and
max_order is just the largest root and not entire address space. I guess
do this in the loop above and use the root order instead?
Also this should be done as part of the first patch and then in this
patch it is just a case of exporting it. Every commit should ideally be
functional by itself.
+
WARN_ON(mm->avail != mm->size);
kfree(mm->roots);
@@ -276,25 +278,39 @@ drm_get_buddy(struct drm_buddy_block *block)
}
EXPORT_SYMBOL(drm_get_buddy);
-static void __drm_buddy_free(struct drm_buddy *mm,
-struct drm_buddy_block *block)
+static unsigned int __drm_buddy_free(struct drm_buddy *mm,
+struct drm_buddy_block *block,
+bool defrag)
{
+ unsigned int order, block_order;
struct drm_buddy_block *parent;
+ block_order = drm_buddy_block_order(block);
+
while ((parent = block->parent)) {
- struct drm_buddy_block *buddy;
+ struct drm_buddy_block *buddy = NULL;
buddy = __get_buddy(block);
if (!drm_buddy_block_is_free(buddy))
break;
- if (drm_buddy_block_is_clear(block) !=
- drm_buddy_block_is_clear(buddy))
- break;
+ if (!defrag) {
+ /*
+* Check the block and its buddy clear state and exit
+* the loop if they both have the dissimilar state.
+*/
+ if (drm_buddy_block_is_clear(block) !=
+ drm_buddy_block_is_clear(buddy))
+ break;
- if (drm_buddy_block_is_clear(block))
- mark_cleared(parent);
+ if (drm_buddy_block_is_clear(block))
+ mark_cleared(parent);
+ }
+
+ WARN_ON(defrag &&
+ (drm_buddy_block_is_clear(block) ==
+drm_buddy_block_is_clear(buddy)));
li
[PATCH v2] drm/i915/cdclk: Document CDCLK components
Improve documentation by giving an overview of the components involved in the generation of the CDCLK. v2: Fix htmldoc error because of missing blank line at the start of bulleted list. Reviewed-by: Ville Syrjälä Signed-off-by: Gustavo Sousa --- drivers/gpu/drm/i915/display/intel_cdclk.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index 30dae4fef6cb..7330131ed6a8 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.c +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c @@ -63,6 +63,32 @@ * DMC will not change the active CDCLK frequency however, so that part * will still be performed by the driver directly. * + * There are multiple components involved in the generation of the CDCLK + * frequency: + * + * - We have the CDCLK PLL, which generates an output clock based on a + * reference clock and a ratio parameter. + * - The CD2X Divider, which divides the output of the PLL based on a + * divisor selected from a set of pre-defined choices. + * - The CD2X Squasher, which further divides the output based on a + * waveform represented as a sequence of bits where each zero + * "squashes out" a clock cycle. + * - And, finally, a fixed divider that divides the output frequency by 2. + * + * As such, the resulting CDCLK frequency can be calculated with the + * following formula: + * + * cdclk = vco / cd2x_div / (sq_len / sq_div) / 2 + * + * , where vco is the frequency generated by the PLL; cd2x_div + * represents the CD2X Divider; sq_len and sq_div are the bit length + * and the number of high bits for the CD2X Squasher waveform, respectively; + * and 2 represents the fixed divider. + * + * Note that some older platforms do not contain the CD2X Divider + * and/or CD2X Squasher, in which case we can ignore their respective + * factors in the formula above. + * * Several methods exist to change the CDCLK frequency, which ones are * supported depends on the platform: * - Full PLL disable + re-enable with new VCO frequency. Pipes must be inactive. -- 2.43.0
[PATCH v2 1/6] sna: stop using obsolete type aliases
The Xserver has been moved to using pixman for all matrix operations, back in
2008, but left some #define's so drivers still compile. Since 1.5 decades have
passed now, it's time to fix remaining drivers still using the old name, so
we can drop these #define's from the Xserver includes.
Signed-off-by: Enrico Weigelt, metux IT consult
---
src/sna/sna_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 15df51f6..3ff3d2fe 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -208,7 +208,7 @@ struct sna_crtc {
bool hwcursor;
bool flip_pending;
- struct pict_f_transform cursor_to_fb, fb_to_cursor;
+ struct pixman_f_transform cursor_to_fb, fb_to_cursor;
RegionRec crtc_damage;
uint16_t shadow_bo_width, shadow_bo_height;
@@ -2376,7 +2376,7 @@ static bool use_shadow(struct sna *sna, xf86CrtcPtr crtc)
{
RRTransformPtr transform;
PictTransform crtc_to_fb;
- struct pict_f_transform f_crtc_to_fb, f_fb_to_crtc;
+ struct pixman_f_transform f_crtc_to_fb, f_fb_to_crtc;
unsigned pitch_limit;
BoxRec b;
@@ -2846,7 +2846,7 @@ affine_is_pixel_exact(const struct pixman_f_transform *t)
static void sna_crtc_randr(xf86CrtcPtr crtc)
{
struct sna_crtc *sna_crtc = to_sna_crtc(crtc);
- struct pict_f_transform f_crtc_to_fb, f_fb_to_crtc;
+ struct pixman_f_transform f_crtc_to_fb, f_fb_to_crtc;
PictTransform crtc_to_fb;
PictFilterPtr filter;
xFixed *params;
@@ -,7 +,7 @@ sna_set_cursor_position(ScrnInfoPtr scrn, int x, int y)
if (crtc->transform_in_use) {
int xhot = sna->cursor.ref->bits->xhot;
int yhot = sna->cursor.ref->bits->yhot;
- struct pict_f_vector v, hot;
+ struct pixman_f_vector v, hot;
v.v[0] = x + xhot + .5;
v.v[1] = y + yhot + .5;
--
2.39.2
[PATCH v2 3/6] backlight: use system() instead of System()
The Xserver's System() function is a special wrapper for calling a program
(xkbcomp) as an unprivileged user, when the Xserver is running as suid-root.
(which today only needed on a few platforms, eg. Solaris). Therefore it's
not suited for being called by arbitrary drivers.
In this specific context it doesn't even much sense, since it's just used
for checking whether pkexec command is present at all (and just should be
used), while the actual exec'ing of the helper is done directly by fork()
and exec() syscalls.
Thus we can safely use standard system() call instead - clearing the road
for dropping System() from Xserver's public/driver API.
Signed-off-by: Enrico Weigelt, metux IT consult
---
src/backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backlight.c b/src/backlight.c
index fcbb279f..f416f2a4 100644
--- a/src/backlight.c
+++ b/src/backlight.c
@@ -366,7 +366,7 @@ static int __backlight_helper_init(struct backlight *b,
char *iface)
return 0;
if ((st.st_mode & (S_IFREG | S_ISUID | S_IXUSR)) != (S_IFREG | S_ISUID
| S_IXUSR)) {
- if (System("pkexec --version"))
+ if (system("pkexec --version"))
return 0;
use_pkexec = 1;
--
2.39.2
[PATCH v2 4/6] intel_device: fix warning on possible buffer overlflow on sprintf() calls
Signed-off-by: Enrico Weigelt, metux IT consult
---
src/intel_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel_device.c b/src/intel_device.c
index f28d3be1..06108ec3 100644
--- a/src/intel_device.c
+++ b/src/intel_device.c
@@ -335,7 +335,7 @@ static int __intel_open_device__major_minor(int _major, int
_minor)
static int __intel_open_device__pci(const struct pci_device *pci)
{
struct stat st;
- char path[256];
+ char path[PATH_MAX];
DIR *dir;
struct dirent *de;
int base;
--
2.39.2
[PATCH v2 6/6] uxa: stop calling deprecated xf86_reload_cursors()
the function has become a no-op, it's former duties are done automatically. Signed-off-by: Enrico Weigelt, metux IT consult --- src/uxa/intel_display.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c index ba4b8d87..ef5962eb 100644 --- a/src/uxa/intel_display.c +++ b/src/uxa/intel_display.c @@ -393,9 +393,6 @@ intel_crtc_apply(xf86CrtcPtr crtc) } } - if (scrn->pScreen) - xf86_reload_cursors(scrn->pScreen); - done: free(output_ids); return ret; -- 2.39.2
[PATCH v2 5/6] stop using obsolete xf86BlockSIGIO() and xf86UnblockSIGIO()
These are just wrappers for calling input_lock()/input_unlock() and marked
deprecated for quite a while now.
Signed-off-by: Enrico Weigelt, metux IT consult
---
src/sna/sna_display.c | 5 +++--
src/uxa/intel_driver.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 3ff3d2fe..460fb1ca 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -1156,11 +1156,12 @@ static inline void sigio_unblock(int was_blocked)
#include
static inline int sigio_block(void)
{
- return xf86BlockSIGIO();
+ input_lock();
+ return 0;
}
static inline void sigio_unblock(int was_blocked)
{
- xf86UnblockSIGIO(was_blocked);
+ input_unlock();
}
#endif
diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
index 9c3fe85f..79105b89 100644
--- a/src/uxa/intel_driver.c
+++ b/src/uxa/intel_driver.c
@@ -641,10 +641,10 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr
dirty)
intel_flush(intel);
if (!intel->has_prime_vmap_flush) {
drm_intel_bo *bo =
intel_uxa_get_pixmap_bo(PixmapDirtyPrimary(dirty));
- was_blocked = xf86BlockSIGIO();
+ input_lock();
drm_intel_bo_map(bo, FALSE);
drm_intel_bo_unmap(bo);
- xf86UnblockSIGIO(was_blocked);
+ input_unlock();
}
DamageRegionProcessPending(&PixmapDirtyDst(dirty)->drawable);
--
2.39.2
[PATCH v2 2/6] sna: use GCPtr instead of GC *
Xserver includes have explicit pointer types for quite all kind of structs
(at least those used by drivers), which are used all over the Xserver.
Thus it's much cleaner to use those everywhere.
This commit also clears the road to fix a horrible nightmare of hacks just
needed to circumvent naming clashes between Xserver and Xlib (affecting all
DDXes that are painting on another Xserver): we can simply rename Xserver's
own "GC" type to "GCRec" (the usual naming convention here) and so no trouble
with Xlib's "GC" type anymore. Once this has landed, we're free to do that
without breaking this driver.
Signed-off-by: Enrico Weigelt, metux IT consult
---
src/sna/sna_accel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 89b82afa..90a61ab3 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -14300,7 +14300,7 @@ static void
sna_poly_fill_rect_stippled_n_box__imm(struct sna *sna,
struct kgem_bo *bo,
uint32_t br00, uint32_t br13,
- const GC *gc,
+ const GCPtr gc,
const BoxRec *box,
const DDXPointRec *origin)
{
@@ -14412,7 +14412,7 @@ sna_poly_fill_rect_stippled_n_box(struct sna *sna,
struct kgem_bo *bo,
struct kgem_bo **tile,
uint32_t br00, uint32_t br13,
- const GC *gc,
+ const GCPtr gc,
const BoxRec *box,
const DDXPointRec *origin)
{
--
2.39.2
✗ Fi.CI.SPARSE: warning for Enable Adaptive Sync SDP Support for DP (rev9)
== Series Details == Series: Enable Adaptive Sync SDP Support for DP (rev9) URL : https://patchwork.freedesktop.org/series/126829/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [PATCH 1/3] drm/i915/display: Add aux function pointer for fast wake sync pulse count
On Wed, Feb 21, 2024 at 09:53:20AM +0200, Jouni Högander wrote:
> ALPM AUX-Wake fast wake sync pulse count is needed by PSR to calculate IO
> wake and fast wake lines.
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 6 ++
> drivers/gpu/drm/i915/display/intel_dp_aux.c| 12 +++-
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 0d4012097db1..1231d374aeec 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1798,6 +1798,12 @@ struct intel_dp {
> u32 (*get_aux_send_ctl)(struct intel_dp *dp, int send_bytes,
> u32 aux_clock_divider);
>
> + /*
> + * This function returns the number of fast wake sync pulses. It is
> + * needed by PSR code to calculate needed fast wake and io wake lines.
> + */
> + u8 (*get_aux_fw_sync_len)(void);
We have just the one function so I don't really see the
point of having this function pointer.
> +
> i915_reg_t (*aux_ch_ctl_reg)(struct intel_dp *dp);
> i915_reg_t (*aux_ch_data_reg)(struct intel_dp *dp, int index);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index 4f4a0e3b3114..fad39b2e3022 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -143,10 +143,10 @@ static int intel_dp_aux_sync_len(void)
> return precharge + preamble;
> }
>
> -static int intel_dp_aux_fw_sync_len(void)
> +static u8 intel_dp_aux_fw_sync_len(void)
> {
> - int precharge = 10; /* 10-16 */
> - int preamble = 8;
> + u8 precharge = 10; /* 10-16 */
> + u8 preamble = 8;
>
> return precharge + preamble;
> }
> @@ -793,10 +793,12 @@ void intel_dp_aux_init(struct intel_dp *intel_dp)
> else
> intel_dp->get_aux_clock_divider = g4x_get_aux_clock_divider;
>
> - if (DISPLAY_VER(i915) >= 9)
> + if (DISPLAY_VER(i915) >= 9) {
> intel_dp->get_aux_send_ctl = skl_get_aux_send_ctl;
> - else
> + intel_dp->get_aux_fw_sync_len = intel_dp_aux_fw_sync_len;
> + } else {
> intel_dp->get_aux_send_ctl = g4x_get_aux_send_ctl;
> + }
>
> intel_dp->aux.drm_dev = &i915->drm;
> drm_dp_aux_init(&intel_dp->aux);
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [PATCH 2/3] drm/i915/psr: Improve fast and IO wake lines calculation
On Wed, Feb 21, 2024 at 09:53:21AM +0200, Jouni Högander wrote:
> Current fast and IO wake lines calculation is assuming fast wake sync
> length is 18 pulses. Let's improve this by checking the actual length.
>
> Also 10 us IO buffer wake time is currently assumed. This is not the case
> with LunarLake and beyond. Fix this by adding getter for IO wake time and
> return values there according to Bspec.
>
> Bspec: 65450
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 40 +++-
> 1 file changed, 33 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 72cadad09db5..4a1e07411716 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1150,6 +1150,28 @@ static bool _lnl_compute_alpm_params(struct intel_dp
> *intel_dp,
> return true;
> }
>
> +/*
> + * From Bspec:
> + *
> + * For Xe2 and beyond
> + * RBR 15us, HBR1 11us, higher rates 10us
> + *
> + * For pre-Xe2
> + * 10 us
> + */
> +static int get_io_wake_time(struct intel_dp *intel_dp,
No point in passing that. You can dig out the i915 from the crtc state.
> + struct intel_crtc_state *crtc_state)
const
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (DISPLAY_VER(i915) < 20 || crtc_state->port_clock > 27)
> + return 10;
> + else if (crtc_state->port_clock > 162000)
> + return 11;
> + else
> + return 15;
The new rate dependent stuff should be a separate patch.
And looks like the 10 usec will give us 44 usec io wake time, so
that should probably be a separate patch as well, to avoid
any functional changes when we introduce the formula.
> +}
> +
> static bool _compute_alpm_params(struct intel_dp *intel_dp,
>struct intel_crtc_state *crtc_state)
> {
> @@ -1157,13 +1179,17 @@ static bool _compute_alpm_params(struct intel_dp
> *intel_dp,
> int io_wake_lines, io_wake_time, fast_wake_lines, fast_wake_time;
> u8 max_wake_lines;
>
> - if (DISPLAY_VER(i915) >= 12) {
> - io_wake_time = 42;
> - /*
> - * According to Bspec it's 42us, but based on testing
> - * it is not enough -> use 45 us.
> - */
> - fast_wake_time = 45;
> + if (intel_dp->get_aux_fw_sync_len) {
> + int io_wake_time = get_io_wake_time(intel_dp, crtc_state);
Looks like this will shadow the variable you're trying to change.
Does the compiler not complain about this?
> + int tfw_exit_latency = 20; /* eDP spec */
> + int phy_wake = 4; /* eDP spec */
> + int preamble = 8; /* eDP spec */
> + int precharge = intel_dp->get_aux_fw_sync_len() - preamble;
> +
> + io_wake_time = max(precharge, io_wake_time) + preamble +
> + phy_wake + tfw_exit_latency;
> + fast_wake_time = precharge + preamble + phy_wake +
> + tfw_exit_latency;
>
> /* TODO: Check how we can use ALPM_CTL fast wake extended field
> */
> max_wake_lines = 12;
I would also convert the older platforms to use the formula.
We do need to reverse calculate the io buffer on latency since
AFAICS it's not directly specified in bspec. But I think
that's better than not converting it since with the formula we
can't totally screw things up when eg. changing the precharge
length.
--
Ville Syrjälä
Intel
Re: [PATCH 3/3] drm/i915/display: Increase number of fast wake precharge pulses
On Wed, Feb 21, 2024 at 09:53:22AM +0200, Jouni Högander wrote:
> Increasing number of fast wake sync pulses seem to fix problems with
> certain PSR panels. This should be ok for other panels as well as the eDP
> specification allows 10...16 precharge pulses and we are still within that
> range.
Hmm. Didn't we have some other panel that didn't like the original 16
precharge pulses? Or maybe that was just because we weren't using the
formula and thus we had a mismatch wrt. the fast wake stuff?
And are we sure this is definitely due to the precharge length
and not because eg. our idea of the io buffer on latency is too
short?
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9739
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index fad39b2e3022..4641c5bb8fb9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -145,7 +145,7 @@ static int intel_dp_aux_sync_len(void)
>
> static u8 intel_dp_aux_fw_sync_len(void)
> {
> - u8 precharge = 10; /* 10-16 */
> + u8 precharge = 12; /* 10-16 */
I think we need a comment to remind people why we are using a specific
value.
> u8 preamble = 8;
>
> return precharge + preamble;
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [PATCH 2/3] drm/i915/psr: Improve fast and IO wake lines calculation
On Wed, Feb 21, 2024 at 09:05:43PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 21, 2024 at 09:53:21AM +0200, Jouni Högander wrote:
> > Current fast and IO wake lines calculation is assuming fast wake sync
> > length is 18 pulses. Let's improve this by checking the actual length.
> >
> > Also 10 us IO buffer wake time is currently assumed. This is not the case
> > with LunarLake and beyond. Fix this by adding getter for IO wake time and
> > return values there according to Bspec.
> >
> > Bspec: 65450
> >
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 40 +++-
> > 1 file changed, 33 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 72cadad09db5..4a1e07411716 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1150,6 +1150,28 @@ static bool _lnl_compute_alpm_params(struct intel_dp
> > *intel_dp,
> > return true;
> > }
> >
> > +/*
> > + * From Bspec:
> > + *
> > + * For Xe2 and beyond
> > + * RBR 15us, HBR1 11us, higher rates 10us
> > + *
> > + * For pre-Xe2
> > + * 10 us
> > + */
> > +static int get_io_wake_time(struct intel_dp *intel_dp,
>
> No point in passing that. You can dig out the i915 from the crtc state.
>
> > + struct intel_crtc_state *crtc_state)
>
> const
>
> > +{
> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +
> > + if (DISPLAY_VER(i915) < 20 || crtc_state->port_clock > 27)
> > + return 10;
> > + else if (crtc_state->port_clock > 162000)
> > + return 11;
> > + else
> > + return 15;
>
> The new rate dependent stuff should be a separate patch.
>
> And looks like the 10 usec will give us 44 usec io wake time, so
> that should probably be a separate patch as well, to avoid
> any functional changes when we introduce the formula.
>
> > +}
> > +
> > static bool _compute_alpm_params(struct intel_dp *intel_dp,
> > struct intel_crtc_state *crtc_state)
> > {
> > @@ -1157,13 +1179,17 @@ static bool _compute_alpm_params(struct intel_dp
> > *intel_dp,
> > int io_wake_lines, io_wake_time, fast_wake_lines, fast_wake_time;
> > u8 max_wake_lines;
> >
> > - if (DISPLAY_VER(i915) >= 12) {
> > - io_wake_time = 42;
> > - /*
> > -* According to Bspec it's 42us, but based on testing
> > -* it is not enough -> use 45 us.
> > -*/
> > - fast_wake_time = 45;
> > + if (intel_dp->get_aux_fw_sync_len) {
> > + int io_wake_time = get_io_wake_time(intel_dp, crtc_state);
>
> Looks like this will shadow the variable you're trying to change.
> Does the compiler not complain about this?
>
> > + int tfw_exit_latency = 20; /* eDP spec */
> > + int phy_wake = 4; /* eDP spec */
> > + int preamble = 8; /* eDP spec */
> > + int precharge = intel_dp->get_aux_fw_sync_len() - preamble;
> > +
> > + io_wake_time = max(precharge, io_wake_time) + preamble +
> > + phy_wake + tfw_exit_latency;
> > + fast_wake_time = precharge + preamble + phy_wake +
> > + tfw_exit_latency;
> >
> > /* TODO: Check how we can use ALPM_CTL fast wake extended field
> > */
> > max_wake_lines = 12;
>
> I would also convert the older platforms to use the formula.
> We do need to reverse calculate the io buffer on latency since
> AFAICS it's not directly specified in bspec. But I think
> that's better than not converting it since with the formula we
> can't totally screw things up when eg. changing the precharge
> length.
Hmm. The older platforms are apparently using fast_wake=32
which implies zero precharge pulses. That definitely does
not match what we program into the AUX control register...
--
Ville Syrjälä
Intel
[PATCH 0/3] Bigjoiner refactoring
There are few things we need to do for bigjoiner, in order to improve code maintenance and also make testing for Bigjoiner easier. Those series contain addition of bigjoiner force debugfs option, in order to be able to force bigjoiner even if there is no display support, also we refactor pipe vs transcoder logic, as currently it is a bit scattered between *_commit_modeset_enables/disables and *_crtc_enable/disable functions. Same applies to encoders. We made a decision to handle all the slaves in correspondent master hook, so slaves and slave checks no longer would be in modesetting level logic. Stanislav Lisovskiy (3): drm/i915/bigjoiner: Refactor bigjoiner state readout Start separating pipe vs transcoder set logic for bigjoiner during modeset drm/i915: Fix bigjoiner case for DP2.0 drivers/gpu/drm/i915/display/intel_ddi.c | 21 +- drivers/gpu/drm/i915/display/intel_display.c | 205 +++ drivers/gpu/drm/i915/display/intel_display.h | 6 + drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 +- 4 files changed, 144 insertions(+), 107 deletions(-) -- 2.37.3
[PATCH 1/3] drm/i915/bigjoiner: Refactor bigjoiner state readout
Don't call enabled_bigjoiner_pipes twice, lets just move
intel_get_bigjoiner_config earlier, because it is anyway
calling same function.
Also cleanup hsw_enabled_transcoders from irrelevant bigjoiner code.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_display.c | 22 ++--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 00ac65a140298..916c13a149fd5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3535,7 +3535,6 @@ 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;
/*
@@ -3586,15 +3585,6 @@ static u8 hsw_enabled_transcoders(struct intel_crtc
*crtc)
if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
enabled_transcoders |= BIT(cpu_transcoder);
- /* bigjoiner slave -> consider the master pipe's transcoder as well */
- enabled_bigjoiner_pipes(dev_priv, &master_pipes, &slave_pipes);
- if (slave_pipes & BIT(crtc->pipe)) {
- cpu_transcoder = (enum transcoder)
- get_bigjoiner_master_pipe(crtc->pipe, master_pipes,
slave_pipes);
- if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
- enabled_transcoders |= BIT(cpu_transcoder);
- }
-
return enabled_transcoders;
}
@@ -3641,6 +3631,15 @@ static bool hsw_get_transcoder_state(struct intel_crtc
*crtc,
u32 tmp;
enabled_transcoders = hsw_enabled_transcoders(crtc);
+
+ /* bigjoiner slave -> consider the master pipe's transcoder as well */
+ if (intel_crtc_is_bigjoiner_slave(pipe_config)) {
+ unsigned long cpu_transcoder = (enum transcoder)
+ bigjoiner_master_pipe(pipe_config);
+ if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
+ enabled_transcoders |= BIT(cpu_transcoder);
+ }
+
if (!enabled_transcoders)
return false;
@@ -3745,6 +3744,8 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
pipe_config->shared_dpll = NULL;
+ intel_bigjoiner_get_config(pipe_config);
+
active = hsw_get_transcoder_state(crtc, pipe_config,
&crtc->hw_readout_power_domains);
if ((IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) &&
@@ -3756,7 +3757,6 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
if (!active)
goto out;
- intel_bigjoiner_get_config(pipe_config);
intel_dsc_get_config(pipe_config);
if (!transcoder_is_dsi(pipe_config->cpu_transcoder) ||
--
2.37.3
[PATCH 2/3] Start separating pipe vs transcoder set logic for bigjoiner during modeset
Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
slave crtcs should be handled by master hooks. Same for encoders.
That way we can also remove a bunch of checks like
intel_crtc_is_bigjoiner_slave.
v2: Get rid of master vs slave checks and separation in crtc enable/disable
hooks.
Use unified iteration cycle for all of those, while enabling/disabling
transcoder only for those pipes where its needed(Ville Syrjälä)
v3: Move all the intel_encoder_* calls under transcoder code path(Ville Syrjälä)
v4: - Call intel_crtc_vblank_on from hsw_crtc_enable only for non-transcoder
path
(for master pipe that will be called from
intel_encoders_enable/intel_enable_ddi)
- Fix stupid mistake with using crtc->pipe for the mask, instead of
BIT(crtc->pipe)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_ddi.c | 21 +--
drivers/gpu/drm/i915/display/intel_display.c | 183 ---
drivers/gpu/drm/i915/display/intel_display.h | 6 +
3 files changed, 121 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bea4415902044..6071e9f500871 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3100,7 +3100,6 @@ static void intel_ddi_post_disable(struct
intel_atomic_state *state,
const struct drm_connector_state
*old_conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- struct intel_crtc *slave_crtc;
if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
intel_crtc_vblank_off(old_crtc_state);
@@ -3117,17 +3116,6 @@ static void intel_ddi_post_disable(struct
intel_atomic_state *state,
ilk_pfit_disable(old_crtc_state);
}
- for_each_intel_crtc_in_pipe_mask(&dev_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);
-
- intel_crtc_vblank_off(old_slave_crtc_state);
-
- intel_dsc_disable(old_slave_crtc_state);
- skl_scaler_disable(old_slave_crtc_state);
- }
-
/*
* When called from DP MST code:
* - old_conn_state will be NULL
@@ -3363,8 +3351,7 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
{
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
- if (!intel_crtc_is_bigjoiner_slave(crtc_state))
- intel_ddi_enable_transcoder_func(encoder, crtc_state);
+ intel_ddi_enable_transcoder_func(encoder, crtc_state);
/* Enable/Disable DP2.0 SDP split config before transcoder */
intel_audio_sdp_split_update(crtc_state);
@@ -3469,9 +3456,6 @@ void intel_ddi_update_active_dpll(struct
intel_atomic_state *state,
struct intel_crtc *crtc)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
- struct intel_crtc_state *crtc_state =
- intel_atomic_get_new_crtc_state(state, crtc);
- struct intel_crtc *slave_crtc;
enum phy phy = intel_port_to_phy(i915, encoder->port);
/* FIXME: Add MTL pll_mgr */
@@ -3479,9 +3463,6 @@ void intel_ddi_update_active_dpll(struct
intel_atomic_state *state,
return;
intel_update_active_dpll(state, crtc, encoder);
- for_each_intel_crtc_in_pipe_mask(&i915->drm, slave_crtc,
-
intel_crtc_bigjoiner_slave_pipes(crtc_state))
- intel_update_active_dpll(state, slave_crtc, encoder);
}
static void
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 916c13a149fd5..e1ea53fd6a288 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1631,31 +1631,12 @@ static void hsw_configure_cpu_transcoder(const struct
intel_crtc_state *crtc_sta
hsw_set_transconf(crtc_state);
}
-static void hsw_crtc_enable(struct intel_atomic_state *state,
- struct intel_crtc *crtc)
+static void hsw_crtc_enable_pre_transcoder(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
- enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
- bool psl_clkgate_wa;
-
- if (drm_WARN_ON(&dev_priv->drm, crtc->active))
- return;
-
- intel_dmc_enable_pipe(dev_priv, crtc->pipe);
-
- if
[PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0
Patch calculates bigjoiner pipes in mst compute.
Patch also passes bigjoiner bool to validate plane
max size.
Signed-off-by: vsrini4
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 5307ddd4edcf5..fd27d9976c050 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -523,6 +523,7 @@ static int intel_dp_mst_compute_config(struct intel_encoder
*encoder,
struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
struct intel_dp *intel_dp = &intel_mst->primary->dp;
const struct intel_connector *connector =
@@ -540,6 +541,10 @@ static int intel_dp_mst_compute_config(struct
intel_encoder *encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
return -EINVAL;
+ if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode->crtc_hdisplay,
+ adjusted_mode->crtc_clock))
+ pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1,
crtc->pipe);
+
pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
pipe_config->has_pch_encoder = false;
@@ -1318,12 +1323,6 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
*connector,
* corresponding link capabilities of the sink) in case the
* stream is uncompressed for it by the last branch device.
*/
- if (mode_rate > max_rate || mode->clock > max_dotclk ||
- drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port->full_pbn) {
- *status = MODE_CLOCK_HIGH;
- return 0;
- }
-
if (mode->clock < 1) {
*status = MODE_CLOCK_LOW;
return 0;
@@ -1343,6 +1342,12 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
*connector,
return 0;
}
+ if (mode_rate > max_rate || mode->clock > max_dotclk ||
+ drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port->full_pbn) {
+ *status = MODE_CLOCK_HIGH;
+ return 0;
+ }
+
if (DISPLAY_VER(dev_priv) >= 10 &&
drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
/*
@@ -1385,7 +1390,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
*connector,
return 0;
}
- *status = intel_mode_valid_max_plane_size(dev_priv, mode, false);
+ *status = intel_mode_valid_max_plane_size(dev_priv, mode, bigjoiner);
return 0;
}
--
2.37.3
✗ Fi.CI.BAT: failure for Enable Adaptive Sync SDP Support for DP (rev9)
== Series Details ==
Series: Enable Adaptive Sync SDP Support for DP (rev9)
URL : https://patchwork.freedesktop.org/series/126829/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14310 -> Patchwork_126829v9
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_126829v9 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_126829v9, please notify your bug team
(i915-ci-in...@lists.freedesktop.org) 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_126829v9/index.html
Participating hosts (37 -> 36)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_126829v9:
### IGT changes ###
Possible regressions
* igt@i915_module_load@load:
- fi-elk-e7500: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/fi-elk-e7500/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v9/fi-elk-e7500/igt@i915_module_l...@load.html
- fi-bsw-nick:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/fi-bsw-nick/igt@i915_module_l...@load.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v9/fi-bsw-nick/igt@i915_module_l...@load.html
* igt@kms_hdmi_inject@inject-audio:
- fi-ilk-650: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/fi-ilk-650/igt@kms_hdmi_inj...@inject-audio.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v9/fi-ilk-650/igt@kms_hdmi_inj...@inject-audio.html
Known issues
Here are the changes found in Patchwork_126829v9 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-cfl-8109u: [PASS][7] -> [FAIL][8] ([i915#8293])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/fi-cfl-8109u/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v9/fi-cfl-8109u/boot.html
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-kbl-7567u: [PASS][9] -> [CRASH][10] ([i915#9947])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v9/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-connector-state:
- bat-adlm-1: [PASS][11] -> [ABORT][12] ([i915#9991])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/bat-adlm-1/igt@kms_force_connector_ba...@force-connector-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v9/bat-adlm-1/igt@kms_force_connector_ba...@force-connector-state.html
Possible fixes
* igt@gem_exec_create@basic@smem:
- {bat-arls-1}: [DMESG-WARN][13] ([i915#10194]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/bat-arls-1/igt@gem_exec_create@ba...@smem.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v9/bat-arls-1/igt@gem_exec_create@ba...@smem.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
[i915#9947]: https://gitlab.freedesktop.org/drm/intel/issues/9947
[i915#9991]: https://gitlab.freedesktop.org/drm/intel/issues/9991
Build changes
-
* Linux: CI_DRM_14310 -> Patchwork_126829v9
CI-20190529: 20190529
CI_DRM_14310: 53c127ff2eda902ff59370f44526e5e8ae49dec0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7719: 7719
Patchwork_126829v9: 53c127ff2eda902ff59370f44526e5e8ae49dec0 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
51349d60491c drm/i915/display: Read/Write AS sdp only when sink/source has
enabled
5dfb5e8f4208 drm/i915/display: Compute vrr_vsync params
90850fc75b90 drm/i915/display: Compute AS SDP parameters.
b5e3ed41a719 drm/i915/dp: Add Read/Write support for Adaptive Sync SDP
0c23205cf25d drm: Add Adaptive Sync SDP logging
a84666012cc8 drm/dp: Add an support to indicate if sink supports AS SDP
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v9/index.html
Re: [RFC v1 0/3] drm/i915: Add support for XRandR Border property
On Wed, Feb 21, 2024 at 12:47:53AM -0800, Vivek Kasireddy wrote: > Some customers and users have expressed interest in adding borders > (or margins) to certain displays in their multi-display configurations. > To address this need, this patchset implements the XRandR Border > property as defined here: > https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n2032 > > --- > > Patchset overview: > > Patch 1: Create skl_program_crtc_scaler() to program scaler for crtc > Patch 2: Create and attach the Border property to DP and HDMI > Patch 3: Implement Border property by enabling crtc scalar > > This series is tested using following method: > - Run the following xrandr command with different parameters: > xrandr --output HDMI-3 --pos 1920x0 --mode 1280x1024 --fb 3840x2160 --scale > 2.11x2.11 --set "Border" 150,0,150,0 > > The following patch was also added to the modesetting driver to > implement the Border property: > https://gitlab.freedesktop.org/Vivek/xserver/-/commit/62abfc438f0d17fe7f88bf2826c9784c2b36443b I have an old branch implementing the margin properties: https://github.com/vsyrjala/linux.git hdmi_margins_3 but it got stalled due to the scaler code being in a very poor state. I started sketching some reworks there, but that got put on the backburner due to other stuff: https://github.com/vsyrjala/linux.git scaler_rework_2 I might have somehting more recent than that locally, but I'd have to trawl through my branches to check what's the latest state. > > Cc: Ville Syrjälä > Cc: Matt Roper > Cc: Dongwon Kim > > Vivek Kasireddy (3): > drm/i915: Rename skl_pfit_enable() to skl_program_crtc_scaler() > drm/i915: Attach the Border property to DP and HDMI connectors > drm/i915: Apply border adjustments and enable scaler on the crtc > > drivers/gpu/drm/i915/display/intel_atomic.c | 29 ++- > .../gpu/drm/i915/display/intel_connector.c| 49 +++ > .../gpu/drm/i915/display/intel_connector.h| 3 ++ > drivers/gpu/drm/i915/display/intel_display.c | 25 -- > .../gpu/drm/i915/display/intel_display_core.h | 1 + > .../drm/i915/display/intel_display_types.h| 6 +++ > drivers/gpu/drm/i915/display/intel_dp.c | 11 + > drivers/gpu/drm/i915/display/intel_hdmi.c | 11 + > drivers/gpu/drm/i915/display/skl_scaler.c | 27 ++ > drivers/gpu/drm/i915/display/skl_scaler.h | 3 +- > 10 files changed, 149 insertions(+), 16 deletions(-) > > -- > 2.43.0 -- Ville Syrjälä Intel
RE: [PATCH v3] drm/i915/panelreplay: Panel replay workaround with VRR
> -Original Message- > From: Vivi, Rodrigo > Sent: Tuesday, February 20, 2024 11:12 PM > To: Manna, Animesh > Cc: intel-gfx@lists.freedesktop.org; ville.syrj...@linux.intel.com; Hogander, > Jouni ; Murthy, Arun R > > Subject: Re: [PATCH v3] drm/i915/panelreplay: Panel replay workaround with > VRR > > On Tue, Feb 20, 2024 at 07:49:19PM +0530, Animesh Manna wrote: > > Panel Replay VSC SDP not getting sent when VRR is enabled and W1 and > > W2 are 0. So Program Set Context Latency in > TRANS_SET_CONTEXT_LATENCY > > register to at least a value of 1. > > > > HSD: 14015406119 > > Unnecessary mark since the wa_name already is a pointer to the HSD. > > > > > v1: Initial version. > > v2: Update timings stored in adjusted_mode struct. [Ville] > > v3: Add WA in compute_config(). [Ville] > > > > Signed-off-by: Animesh Manna > > --- > > drivers/gpu/drm/i915/display/intel_dp.c | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > b/drivers/gpu/drm/i915/display/intel_dp.c > > index 217196196e50..eb0fa513cd0f 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > @@ -2948,6 +2948,18 @@ intel_dp_compute_config(struct intel_encoder > *encoder, > > intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state); > > intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, > pipe_config, > > conn_state); > > > > + /* > > +* WA: HSD-14015406119 > > this is not the right one. You should use the lineage one and then mark the > platforms. > > /* wa_14015401596: xe_lpd, xe_hpd */ > > or perhaps > > /* wa_14015401596: display versions: 13, 14 */ > > and also add a check for the display version with it. Sure. > > > +* Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY > register > > +* to at least a value of 1 when Panel Replay is enabled with VRR. > > +* Value for TRANS_SET_CONTEXT_LATENCY is calculated by > substracting > > +* crtc_vdisplay from crtc_vblank_start, so incrementing > crtc_vblank_start > > +* by 1 if both are equal. > > +*/ > > + if (pipe_config->vrr.enable && pipe_config->has_panel_replay && > > + adjusted_mode->crtc_vblank_start == adjusted_mode- > >crtc_vdisplay) > > + adjusted_mode->crtc_vblank_start += 1; > > why to mess with the vblank start instead of going to > intel_set_transcoder_timings() and change directly what is getting written to > the register when the register gets written? I have done in previous version of this patch. But as per review feedback, added now here. https://patchwork.freedesktop.org/series/129632/#rev1 https://patchwork.freedesktop.org/series/129632/#rev2 > > In case the answer is becasue by then we don't have the vrr.enable or > something like that, then we should consider move around when we set that > register? This was not acceptable in earlier versions. As per feedback instead of atomic-commit need to add in compute-config phase. > > or perhaps create a specific flag? one extra variable, 3 less comment lines... The above comment is not clear to me, can you please elaborate more here. Regards, Animesh > > > + > > return 0; > > } > > > > -- > > 2.29.0 > >
Re: [PATCH v3 1/3] bits: introduce fixed-type genmasks
On Thu, 8 Feb 2024 at 09:45, Lucas De Marchi wrote: > > From: Yury Norov > > Generalize __GENMASK() to support different types, and implement > fixed-types versions of GENMASK() based on it. The fixed-type version > allows more strict checks to the min/max values accepted, which is > useful for defining registers like implemented by i915 and xe drivers > with their REG_GENMASK*() macros. > > The strict checks rely on shift-count-overflow compiler check to > fail the build if a number outside of the range allowed is passed. > Example: > > #define FOO_MASK GENMASK_U32(33, 4) > > will generate a warning like: > > ../include/linux/bits.h:41:31: error: left shift count >= width of > type [-Werror=shift-count-overflow] >41 | (((t)~0ULL - ((t)(1) << (l)) + 1) & \ > | ^~ > > Signed-off-by: Yury Norov > Signed-off-by: Lucas De Marchi > Acked-by: Jani Nikula > --- > include/linux/bitops.h | 1 - > include/linux/bits.h | 32 ++-- > 2 files changed, 22 insertions(+), 11 deletions(-) > > diff --git a/include/linux/bitops.h b/include/linux/bitops.h > index 2ba557e067fe..1db50c69cfdb 100644 > --- a/include/linux/bitops.h > +++ b/include/linux/bitops.h > @@ -15,7 +15,6 @@ > # define aligned_byte_mask(n) (~0xffUL << (BITS_PER_LONG - 8 - 8*(n))) > #endif > > -#define BITS_PER_TYPE(type)(sizeof(type) * BITS_PER_BYTE) > #define BITS_TO_LONGS(nr) __KERNEL_DIV_ROUND_UP(nr, BITS_PER_TYPE(long)) > #define BITS_TO_U64(nr)__KERNEL_DIV_ROUND_UP(nr, > BITS_PER_TYPE(u64)) > #define BITS_TO_U32(nr)__KERNEL_DIV_ROUND_UP(nr, > BITS_PER_TYPE(u32)) > diff --git a/include/linux/bits.h b/include/linux/bits.h > index 7c0cf5031abe..bd56f32de44e 100644 > --- a/include/linux/bits.h > +++ b/include/linux/bits.h > @@ -6,6 +6,8 @@ > #include > #include > > +#define BITS_PER_TYPE(type)(sizeof(type) * BITS_PER_BYTE) > + > #define BIT_MASK(nr) (UL(1) << ((nr) % BITS_PER_LONG)) > #define BIT_WORD(nr) ((nr) / BITS_PER_LONG) > #define BIT_ULL_MASK(nr) (ULL(1) << ((nr) % BITS_PER_LONG_LONG)) > @@ -30,16 +32,26 @@ > #define GENMASK_INPUT_CHECK(h, l) 0 > #endif > > -#define __GENMASK(h, l) \ > - (((~UL(0)) - (UL(1) << (l)) + 1) & \ > -(~UL(0) >> (BITS_PER_LONG - 1 - (h > -#define GENMASK(h, l) \ > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) > +/* > + * Generate a mask for the specified type @t. Additional checks are made to > + * guarantee the value returned fits in that type, relying on > + * shift-count-overflow compiler check to detect incompatible arguments. > + * For example, all these create build errors or warnings: > + * > + * - GENMASK(15, 20): wrong argument order > + * - GENMASK(72, 15): doesn't fit unsigned long > + * - GENMASK_U32(33, 15): doesn't fit in a u32 > + */ > +#define __GENMASK(t, h, l) \ > + (GENMASK_INPUT_CHECK(h, l) + \ > +(((t)~0ULL - ((t)(1) << (l)) + 1) & \ > +((t)~0ULL >> (BITS_PER_TYPE(t) - 1 - (h) > > -#define __GENMASK_ULL(h, l) \ > - (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ > -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h > -#define GENMASK_ULL(h, l) \ > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l)) > +#define GENMASK(h, l) __GENMASK(unsigned long, h, l) > +#define GENMASK_ULL(h, l) __GENMASK(unsigned long long, h, l) > +#define GENMASK_U8(h, l) __GENMASK(u8, h, l) > +#define GENMASK_U16(h, l) __GENMASK(u16, h, l) > +#define GENMASK_U32(h, l) __GENMASK(u32, h, l) > +#define GENMASK_U64(h, l) __GENMASK(u64, h, l) This breaks drm-tip on arm64 architecture: arch/arm64/kernel/entry-fpsimd.S: Assembler messages: 465arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' 466arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 467arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' 468arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 469arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' 470arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 471arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' 472arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 473arch/arm64/kernel/entry-fpsimd.S:271: Error: unexpected characters following instruction at operand 3 -- `bic x2,x1,(0+(((unsigned long)~0ULL-((unsigned long)(1)<<(0))+1)&((unsigned long)~0ULL>>((sizeof(unsigned long)*8)-1-(3)' 474arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 475arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' 476arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here 477arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' 478arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here 479arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', e
Re: [PATCH v3 1/3] bits: introduce fixed-type genmasks
On Wed, 21 Feb 2024 at 22:30, Dmitry Baryshkov wrote: > > On Thu, 8 Feb 2024 at 09:45, Lucas De Marchi wrote: > > > > From: Yury Norov > > > > Generalize __GENMASK() to support different types, and implement > > fixed-types versions of GENMASK() based on it. The fixed-type version > > allows more strict checks to the min/max values accepted, which is > > useful for defining registers like implemented by i915 and xe drivers > > with their REG_GENMASK*() macros. > > > > The strict checks rely on shift-count-overflow compiler check to > > fail the build if a number outside of the range allowed is passed. > > Example: > > > > #define FOO_MASK GENMASK_U32(33, 4) > > > > will generate a warning like: > > > > ../include/linux/bits.h:41:31: error: left shift count >= width of > > type [-Werror=shift-count-overflow] > >41 | (((t)~0ULL - ((t)(1) << (l)) + 1) & \ > > | ^~ > > > > Signed-off-by: Yury Norov > > Signed-off-by: Lucas De Marchi > > Acked-by: Jani Nikula > > --- > > include/linux/bitops.h | 1 - > > include/linux/bits.h | 32 ++-- > > 2 files changed, 22 insertions(+), 11 deletions(-) > > > > diff --git a/include/linux/bitops.h b/include/linux/bitops.h > > index 2ba557e067fe..1db50c69cfdb 100644 > > --- a/include/linux/bitops.h > > +++ b/include/linux/bitops.h > > @@ -15,7 +15,6 @@ > > # define aligned_byte_mask(n) (~0xffUL << (BITS_PER_LONG - 8 - 8*(n))) > > #endif > > > > -#define BITS_PER_TYPE(type)(sizeof(type) * BITS_PER_BYTE) > > #define BITS_TO_LONGS(nr) __KERNEL_DIV_ROUND_UP(nr, > > BITS_PER_TYPE(long)) > > #define BITS_TO_U64(nr)__KERNEL_DIV_ROUND_UP(nr, > > BITS_PER_TYPE(u64)) > > #define BITS_TO_U32(nr)__KERNEL_DIV_ROUND_UP(nr, > > BITS_PER_TYPE(u32)) > > diff --git a/include/linux/bits.h b/include/linux/bits.h > > index 7c0cf5031abe..bd56f32de44e 100644 > > --- a/include/linux/bits.h > > +++ b/include/linux/bits.h > > @@ -6,6 +6,8 @@ > > #include > > #include > > > > +#define BITS_PER_TYPE(type)(sizeof(type) * BITS_PER_BYTE) > > + > > #define BIT_MASK(nr) (UL(1) << ((nr) % BITS_PER_LONG)) > > #define BIT_WORD(nr) ((nr) / BITS_PER_LONG) > > #define BIT_ULL_MASK(nr) (ULL(1) << ((nr) % BITS_PER_LONG_LONG)) > > @@ -30,16 +32,26 @@ > > #define GENMASK_INPUT_CHECK(h, l) 0 > > #endif > > > > -#define __GENMASK(h, l) \ > > - (((~UL(0)) - (UL(1) << (l)) + 1) & \ > > -(~UL(0) >> (BITS_PER_LONG - 1 - (h > > -#define GENMASK(h, l) \ > > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) > > +/* > > + * Generate a mask for the specified type @t. Additional checks are made to > > + * guarantee the value returned fits in that type, relying on > > + * shift-count-overflow compiler check to detect incompatible arguments. > > + * For example, all these create build errors or warnings: > > + * > > + * - GENMASK(15, 20): wrong argument order > > + * - GENMASK(72, 15): doesn't fit unsigned long > > + * - GENMASK_U32(33, 15): doesn't fit in a u32 > > + */ > > +#define __GENMASK(t, h, l) \ > > + (GENMASK_INPUT_CHECK(h, l) + \ > > +(((t)~0ULL - ((t)(1) << (l)) + 1) & \ > > +((t)~0ULL >> (BITS_PER_TYPE(t) - 1 - (h) > > > > -#define __GENMASK_ULL(h, l) \ > > - (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ > > -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h > > -#define GENMASK_ULL(h, l) \ > > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l)) > > +#define GENMASK(h, l) __GENMASK(unsigned long, h, l) > > +#define GENMASK_ULL(h, l) __GENMASK(unsigned long long, h, l) > > +#define GENMASK_U8(h, l) __GENMASK(u8, h, l) > > +#define GENMASK_U16(h, l) __GENMASK(u16, h, l) > > +#define GENMASK_U32(h, l) __GENMASK(u32, h, l) > > +#define GENMASK_U64(h, l) __GENMASK(u64, h, l) > > This breaks drm-tip on arm64 architecture: > Excuse me, it seems a c&p from gitlab didn't work as expected. arch/arm64/kernel/entry-fpsimd.S: Assembler messages: arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here arch/arm64/kernel/entry-fpsimd.S:271: Error: unexpected characters following instruction at operand 3 -- `bic x2,x1,(0+(((unsigned long)~0ULL-((unsigned long)(1)<<(0))+1)&((unsigned long)~0ULL>>((sizeof(unsigned long)*8)-1-(3)' arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l'
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
On Wed, Feb 21, 2024 at 01:12:18AM +0100, Andi Shyti wrote:
> Hi Matt,
>
> thanks a lot for looking into this.
>
> On Tue, Feb 20, 2024 at 03:39:18PM -0800, Matt Roper wrote:
> > On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
>
> [...]
>
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > index 833987015b8b..7041acc77810 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct
> > > drm_i915_private *i915)
> > > if (engine->uabi_class == I915_NO_UABI_CLASS)
> > > continue;
> > >
> > > + /*
> > > + * Do not list and do not count CCS engines other than the first
> > > + */
> > > + if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> > > + engine->uabi_instance > 0) {
> > > + i915->engine_uabi_class_count[engine->uabi_class]--;
> > > + continue;
> > > + }
> >
> > Wouldn't it be simpler to just add a workaround to the end of
> > engine_mask_apply_compute_fuses() if we want to ensure only a single
> > compute engine gets exposed? Then both the driver internals and uapi
> > will agree that's there's just one CCS (and on which one there is).
> >
> > If we want to do something fancy with "hotplugging" a new engine later
> > on or whatever, that can be handled in the future series (although as
> > noted on the previous patch, it sounds like these changes might not
> > actually be aligned with the workaround we were trying to address).
>
> The hotplugging capability is one of the features I was looking
> for, actually.
>
> I have done some more refactoring in this piece of code in
> upcoming patches.
>
> Will check, though, if I can do something with compute_fuses(),
> even though, the other cslices are not really fused off (read
> below).
>
> > > +
> > > rb_link_node(&engine->uabi_node, prev, p);
> > > rb_insert_color(&engine->uabi_node, &i915->uabi_engines);
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > index a425db5ed3a2..e19df4ef47f6 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > @@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
> > > }
> > > }
> > >
> > > +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> > > +{
> > > + if (!IS_DG2(gt->i915))
> > > + return;
> > > +
> > > + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
> >
> > This doesn't look right to me. A value of 0 means every cslice gets
> > associated with CCS0.
>
> Yes, that's what I'm trying to do. The behavior I'm looking for
> is this one:
>
>/*
> ...
> * With 1 engine (ccs0):
> * slice 0, 1, 2, 3: ccs0
> *
> * With 2 engines (ccs0, ccs1):
> * slice 0, 2: ccs0
> * slice 1, 3: ccs1
> *
> * With 4 engines (ccs0, ccs1, ccs2, ccs3):
> * slice 0: ccs0
> * slice 1: ccs1
> * slice 2: ccs2
> * slice 3: ccs3
> ...
> */
>
> where the user can configure runtime the mode, making sure that
> no client is connected to i915.
>
> But, this needs to be written
>
> As we are now forcing mode '1', then all cslices are connected
> with ccs0.
Right --- and that's what I'm pointing out as illegal. I think that
code comment above was taken out of context from a different RFC series;
that's not an accurate description of the behavior we want here.
First, the above comment is using ccs# to refer to userspace engines,
not hardware engines. As a simple example, DG2-G11 only ever has a
single CCS which userspace sees as "instance 0" but which is actually
CCS1 at the hardware level. If you try to follow the comment above when
programming CCS_MODE, you've assigned all of the cslices to a
non-existent engine and assigned no cslices to the CCS engine that
actually exists. For DG2-G10 (and I think DG2-G12), there are different
combinations of fused-off / not-fused-off engines that will always show
up in userspace as CCS0-CCSn, even if those don't match the hardware
IDs.
Second, the above comment is assuming that you have a part with a
maximum fusing config (i.e., all cslices present). Using DG2-G11 again
as an example, there's also only a single cslice (cslice1), so if you
tell CCS1 that it's allowed to use EUs from non-existent cslice0,
cslice2, and cslice3, you might not get the behavior you were hoping
for.
>
> > On a DG2-G11 platform, that will flat out break
> > compute since CCS0 is never present (G11 only has a single CCS and it's
> > always the hardware's CCS1). Even on a G10 or G12 this could also break
> > things depending on the fusing of your card if the hardw
Re: [PATCH v3] drm/i915/panelreplay: Panel replay workaround with VRR
On Wed, Feb 21, 2024 at 08:19:35PM +, Manna, Animesh wrote: > > > > -Original Message- > > From: Vivi, Rodrigo > > Sent: Tuesday, February 20, 2024 11:12 PM > > To: Manna, Animesh > > Cc: intel-gfx@lists.freedesktop.org; ville.syrj...@linux.intel.com; > > Hogander, > > Jouni ; Murthy, Arun R > > > > Subject: Re: [PATCH v3] drm/i915/panelreplay: Panel replay workaround with > > VRR > > > > On Tue, Feb 20, 2024 at 07:49:19PM +0530, Animesh Manna wrote: > > > Panel Replay VSC SDP not getting sent when VRR is enabled and W1 and > > > W2 are 0. So Program Set Context Latency in > > TRANS_SET_CONTEXT_LATENCY > > > register to at least a value of 1. > > > > > > HSD: 14015406119 > > > > Unnecessary mark since the wa_name already is a pointer to the HSD. > > > > > > > > v1: Initial version. > > > v2: Update timings stored in adjusted_mode struct. [Ville] > > > v3: Add WA in compute_config(). [Ville] > > > > > > Signed-off-by: Animesh Manna > > > --- > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 > > > 1 file changed, 12 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > > b/drivers/gpu/drm/i915/display/intel_dp.c > > > index 217196196e50..eb0fa513cd0f 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > > @@ -2948,6 +2948,18 @@ intel_dp_compute_config(struct intel_encoder > > *encoder, > > > intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state); > > > intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, > > pipe_config, > > > conn_state); > > > > > > + /* > > > + * WA: HSD-14015406119 > > > > this is not the right one. You should use the lineage one and then mark the > > platforms. > > > > /* wa_14015401596: xe_lpd, xe_hpd */ > > > > or perhaps > > > > /* wa_14015401596: display versions: 13, 14 */ > > > > and also add a check for the display version with it. > > Sure. > > > > > > + * Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY > > register > > > + * to at least a value of 1 when Panel Replay is enabled with VRR. > > > + * Value for TRANS_SET_CONTEXT_LATENCY is calculated by > > substracting > > > + * crtc_vdisplay from crtc_vblank_start, so incrementing > > crtc_vblank_start > > > + * by 1 if both are equal. > > > + */ > > > + if (pipe_config->vrr.enable && pipe_config->has_panel_replay && > > > + adjusted_mode->crtc_vblank_start == adjusted_mode- > > >crtc_vdisplay) > > > + adjusted_mode->crtc_vblank_start += 1; > > > > why to mess with the vblank start instead of going to > > intel_set_transcoder_timings() and change directly what is getting written > > to > > the register when the register gets written? > > I have done in previous version of this patch. But as per review feedback, > added now here. > https://patchwork.freedesktop.org/series/129632/#rev1 > https://patchwork.freedesktop.org/series/129632/#rev2 > > > > > In case the answer is becasue by then we don't have the vrr.enable or > > something like that, then we should consider move around when we set that > > register? > > This was not acceptable in earlier versions. As per feedback instead of > atomic-commit need to add in compute-config phase. > > > > > or perhaps create a specific flag? one extra variable, 3 less comment > > lines... > > The above comment is not clear to me, can you please elaborate more here. something like: @intel_dp_compute_config() +if (pipe_config->vrr.enable && pipe_config->has_panel_replay && + adjusted_mode->crtc_vblank_start == adjusted_mode-crtc_vdisplay) + pipe_config->mode_flags = I915_MODE_FLAG_MIN_TRANS_CONTEXT_LATENCY_1 then @intel_set_transcoder_timings() +u32 context_latency; +if (crtc_state->mode_flags & I915_MODE_FLAG_MIN_TRANS_CONTEXT_LATENCY_1) + context_latency = 1; +else + crtc_vblank_start - crtc_vdisplay; -crtc_vblank_start - crtc_vdisplay); +context_latency); Ville, thoughts? > > Regards, > Animesh > > > > > > + > > > return 0; > > > } > > > > > > -- > > > 2.29.0 > > >
✗ Fi.CI.CHECKPATCH: warning for GPU hang replay
== Series Details == Series: GPU hang replay URL : https://patchwork.freedesktop.org/series/130208/ State : warning == Summary == Error: dim checkpatch failed dd9bcf4e2133 drm/i915: Shadow default engine context image in the context b29511c8b0ab drm/i915: Support replaying GPU hangs with captured context image -:343: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #343: FILE: drivers/gpu/drm/i915/i915_params.h:68: + param(bool, enable_debug_only_api, false, IS_ENABLED(CONFIG_DRM_I915_REPLAY_GPU_HANGS_API) ? 0400 : 0) total: 0 errors, 1 warnings, 0 checks, 291 lines checked
✗ Fi.CI.SPARSE: warning for GPU hang replay
== Series Details == Series: GPU hang replay URL : https://patchwork.freedesktop.org/series/130208/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [PATCH v3 1/3] bits: introduce fixed-type genmasks
On Wed, Feb 21, 2024 at 10:30:02PM +0200, Dmitry Baryshkov wrote: > On Thu, 8 Feb 2024 at 09:45, Lucas De Marchi wrote: ... > > +#define BITS_PER_TYPE(type)(sizeof(type) * BITS_PER_BYTE) Can sizeof() be used in assembly? ... > > -#define __GENMASK(h, l) \ > > - (((~UL(0)) - (UL(1) << (l)) + 1) & \ > > -(~UL(0) >> (BITS_PER_LONG - 1 - (h > > -#define GENMASK(h, l) \ > > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) > > +#define __GENMASK(t, h, l) \ > > + (GENMASK_INPUT_CHECK(h, l) + \ > > +(((t)~0ULL - ((t)(1) << (l)) + 1) & \ > > +((t)~0ULL >> (BITS_PER_TYPE(t) - 1 - (h) Nevertheless, the use ~0ULL is not proper assembly, this broke initial implementation using UL() / ULL(). > > -#define __GENMASK_ULL(h, l) \ > > - (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ > > -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h > > -#define GENMASK_ULL(h, l) \ > > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l)) Ditto. > > +#define GENMASK(h, l) __GENMASK(unsigned long, h, l) > > +#define GENMASK_ULL(h, l) __GENMASK(unsigned long long, h, l) > > +#define GENMASK_U8(h, l) __GENMASK(u8, h, l) > > +#define GENMASK_U16(h, l) __GENMASK(u16, h, l) > > +#define GENMASK_U32(h, l) __GENMASK(u32, h, l) > > +#define GENMASK_U64(h, l) __GENMASK(u64, h, l) > > This breaks drm-tip on arm64 architecture: > > arch/arm64/kernel/entry-fpsimd.S: Assembler messages: > 465arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' > 466arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here > 467arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' > 468arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here > 469arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' > 470arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here > 471arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' > 472arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here > 473arch/arm64/kernel/entry-fpsimd.S:271: Error: unexpected characters > following instruction at operand 3 -- `bic x2,x1,(0+(((unsigned > long)~0ULL-((unsigned long)(1)<<(0))+1)&((unsigned > long)~0ULL>>((sizeof(unsigned long)*8)-1-(3)' > 474arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here > 475arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' > 476arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here > 477arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' > 478arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here > 479arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' > 480arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here > 481arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' > 482arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here > 483arch/arm64/kernel/entry-fpsimd.S:282: Error: unexpected characters > following instruction at operand 3 -- `bic x2,x1,(0+(((unsigned > long)~0ULL-((unsigned long)(1)<<(0))+1)&((unsigned > long)~0ULL>>((sizeof(unsigned long)*8)-1-(3)' > 484arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 1/3] bits: introduce fixed-type genmasks
On Wed, Feb 21, 2024 at 10:37:30PM +0200, Dmitry Baryshkov wrote: > On Wed, 21 Feb 2024 at 22:30, Dmitry Baryshkov > wrote: ... > Excuse me, it seems a c&p from gitlab didn't work as expected. No problem, it's clear that the patch has not been properly tested and obviously wrong. Has to be dropped. If somebody wants that, it will be material for v6.10 cycle. -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 1/3] bits: introduce fixed-type genmasks
On Wed, Feb 21, 2024 at 11:06:10PM +0200, Andy Shevchenko wrote: > On Wed, Feb 21, 2024 at 10:37:30PM +0200, Dmitry Baryshkov wrote: > > On Wed, 21 Feb 2024 at 22:30, Dmitry Baryshkov > > wrote: ... > > Excuse me, it seems a c&p from gitlab didn't work as expected. > > No problem, it's clear that the patch has not been properly tested and > obviously wrong. Has to be dropped. If somebody wants that, it will > be material for v6.10 cycle. ...which makes me think that bitmap(bitops) lack of assembly test case(s). -- With Best Regards, Andy Shevchenko
Re: [PATCH v3] drm/i915/panelreplay: Panel replay workaround with VRR
On Wed, Feb 21, 2024 at 03:58:48PM -0500, Rodrigo Vivi wrote: > On Wed, Feb 21, 2024 at 08:19:35PM +, Manna, Animesh wrote: > > > > > > > -Original Message- > > > From: Vivi, Rodrigo > > > Sent: Tuesday, February 20, 2024 11:12 PM > > > To: Manna, Animesh > > > Cc: intel-gfx@lists.freedesktop.org; ville.syrj...@linux.intel.com; > > > Hogander, > > > Jouni ; Murthy, Arun R > > > > > > Subject: Re: [PATCH v3] drm/i915/panelreplay: Panel replay workaround with > > > VRR > > > > > > On Tue, Feb 20, 2024 at 07:49:19PM +0530, Animesh Manna wrote: > > > > Panel Replay VSC SDP not getting sent when VRR is enabled and W1 and > > > > W2 are 0. So Program Set Context Latency in > > > TRANS_SET_CONTEXT_LATENCY > > > > register to at least a value of 1. > > > > > > > > HSD: 14015406119 > > > > > > Unnecessary mark since the wa_name already is a pointer to the HSD. > > > > > > > > > > > v1: Initial version. > > > > v2: Update timings stored in adjusted_mode struct. [Ville] > > > > v3: Add WA in compute_config(). [Ville] > > > > > > > > Signed-off-by: Animesh Manna > > > > --- > > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 > > > > 1 file changed, 12 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > > > b/drivers/gpu/drm/i915/display/intel_dp.c > > > > index 217196196e50..eb0fa513cd0f 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > > > @@ -2948,6 +2948,18 @@ intel_dp_compute_config(struct intel_encoder > > > *encoder, > > > > intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state); > > > > intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, > > > pipe_config, > > > > conn_state); > > > > > > > > + /* > > > > +* WA: HSD-14015406119 > > > > > > this is not the right one. You should use the lineage one and then mark > > > the > > > platforms. > > > > > > /* wa_14015401596: xe_lpd, xe_hpd */ > > > > > > or perhaps > > > > > > /* wa_14015401596: display versions: 13, 14 */ > > > > > > and also add a check for the display version with it. > > > > Sure. > > > > > > > > > +* Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY > > > register > > > > +* to at least a value of 1 when Panel Replay is enabled with > > > > VRR. > > > > +* Value for TRANS_SET_CONTEXT_LATENCY is calculated by > > > substracting > > > > +* crtc_vdisplay from crtc_vblank_start, so incrementing > > > crtc_vblank_start > > > > +* by 1 if both are equal. > > > > +*/ > > > > + if (pipe_config->vrr.enable && pipe_config->has_panel_replay && > > > > + adjusted_mode->crtc_vblank_start == adjusted_mode- > > > >crtc_vdisplay) > > > > + adjusted_mode->crtc_vblank_start += 1; > > > > > > why to mess with the vblank start instead of going to > > > intel_set_transcoder_timings() and change directly what is getting > > > written to > > > the register when the register gets written? > > > > I have done in previous version of this patch. But as per review feedback, > > added now here. > > https://patchwork.freedesktop.org/series/129632/#rev1 > > https://patchwork.freedesktop.org/series/129632/#rev2 > > > > > > > > In case the answer is becasue by then we don't have the vrr.enable or > > > something like that, then we should consider move around when we set that > > > register? > > > > This was not acceptable in earlier versions. As per feedback instead of > > atomic-commit need to add in compute-config phase. > > > > > > > > or perhaps create a specific flag? one extra variable, 3 less comment > > > lines... > > > > The above comment is not clear to me, can you please elaborate more here. > > something like: > > @intel_dp_compute_config() > > +if (pipe_config->vrr.enable && pipe_config->has_panel_replay && > + adjusted_mode->crtc_vblank_start == adjusted_mode-crtc_vdisplay) > + pipe_config->mode_flags = I915_MODE_FLAG_MIN_TRANS_CONTEXT_LATENCY_1 > > then > @intel_set_transcoder_timings() > +u32 context_latency; > > +if (crtc_state->mode_flags & I915_MODE_FLAG_MIN_TRANS_CONTEXT_LATENCY_1) > + context_latency = 1; > +else > + crtc_vblank_start - crtc_vdisplay; > > -crtc_vblank_start - crtc_vdisplay); > +context_latency); > > Ville, thoughts? I think what we need is a intel_crtc_vblank_delay() or somesuch thing that accounts for all the things (eg. this w/a, dsb execution latency when we start to use dsb for double buffered registers, etc). And it should probably be called from some central place so that it works for all output types. intel_crtc_compute_config() comes to mind, but I guess we need to first ponder whether there are bits of code being executed prior to that that would need to know the actual vblank_start... -- Ville Syrjälä Intel
✓ Fi.CI.BAT: success for GPU hang replay
== Series Details ==
Series: GPU hang replay
URL : https://patchwork.freedesktop.org/series/130208/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14311 -> Patchwork_130208v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130208v1/index.html
Participating hosts (38 -> 35)
--
Missing(3): bat-kbl-2 fi-snb-2520m bat-arls-3
Known issues
Here are the changes found in Patchwork_130208v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-cfl-8109u: [PASS][1] -> [FAIL][2] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-cfl-8109u/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130208v1/fi-cfl-8109u/boot.html
### IGT changes ###
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-kbl-7567u: [CRASH][3] ([i915#9947]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130208v1/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[ABORT][5] ([i915#7911]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130208v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
[i915#9947]: https://gitlab.freedesktop.org/drm/intel/issues/9947
Build changes
-
* Linux: CI_DRM_14311 -> Patchwork_130208v1
CI-20190529: 20190529
CI_DRM_14311: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7720: 7720
Patchwork_130208v1: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
5e8021aae34b drm/i915: Support replaying GPU hangs with captured context image
02cc3b0a4a0d drm/i915: Shadow default engine context image in the context
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130208v1/index.html
Re: [PATCH v3] drm/i915/panelreplay: Panel replay workaround with VRR
On Wed, Feb 21, 2024 at 11:08:18PM +0200, Ville Syrjälä wrote: > On Wed, Feb 21, 2024 at 03:58:48PM -0500, Rodrigo Vivi wrote: > > On Wed, Feb 21, 2024 at 08:19:35PM +, Manna, Animesh wrote: > > > > > > > > > > -Original Message- > > > > From: Vivi, Rodrigo > > > > Sent: Tuesday, February 20, 2024 11:12 PM > > > > To: Manna, Animesh > > > > Cc: intel-gfx@lists.freedesktop.org; ville.syrj...@linux.intel.com; > > > > Hogander, > > > > Jouni ; Murthy, Arun R > > > > > > > > Subject: Re: [PATCH v3] drm/i915/panelreplay: Panel replay workaround > > > > with > > > > VRR > > > > > > > > On Tue, Feb 20, 2024 at 07:49:19PM +0530, Animesh Manna wrote: > > > > > Panel Replay VSC SDP not getting sent when VRR is enabled and W1 and > > > > > W2 are 0. So Program Set Context Latency in > > > > TRANS_SET_CONTEXT_LATENCY > > > > > register to at least a value of 1. > > > > > > > > > > HSD: 14015406119 > > > > > > > > Unnecessary mark since the wa_name already is a pointer to the HSD. > > > > > > > > > > > > > > v1: Initial version. > > > > > v2: Update timings stored in adjusted_mode struct. [Ville] > > > > > v3: Add WA in compute_config(). [Ville] > > > > > > > > > > Signed-off-by: Animesh Manna > > > > > --- > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 > > > > > 1 file changed, 12 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > > > > b/drivers/gpu/drm/i915/display/intel_dp.c > > > > > index 217196196e50..eb0fa513cd0f 100644 > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > > > > @@ -2948,6 +2948,18 @@ intel_dp_compute_config(struct intel_encoder > > > > *encoder, > > > > > intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state); > > > > > intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, > > > > pipe_config, > > > > > conn_state); > > > > > > > > > > + /* > > > > > + * WA: HSD-14015406119 > > > > > > > > this is not the right one. You should use the lineage one and then mark > > > > the > > > > platforms. > > > > > > > > /* wa_14015401596: xe_lpd, xe_hpd */ > > > > > > > > or perhaps > > > > > > > > /* wa_14015401596: display versions: 13, 14 */ > > > > > > > > and also add a check for the display version with it. > > > > > > Sure. > > > > > > > > > > > > + * Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY > > > > register > > > > > + * to at least a value of 1 when Panel Replay is enabled with > > > > > VRR. > > > > > + * Value for TRANS_SET_CONTEXT_LATENCY is calculated by > > > > substracting > > > > > + * crtc_vdisplay from crtc_vblank_start, so incrementing > > > > crtc_vblank_start > > > > > + * by 1 if both are equal. > > > > > + */ > > > > > + if (pipe_config->vrr.enable && pipe_config->has_panel_replay && > > > > > + adjusted_mode->crtc_vblank_start == adjusted_mode- > > > > >crtc_vdisplay) > > > > > + adjusted_mode->crtc_vblank_start += 1; > > > > > > > > why to mess with the vblank start instead of going to > > > > intel_set_transcoder_timings() and change directly what is getting > > > > written to > > > > the register when the register gets written? > > > > > > I have done in previous version of this patch. But as per review > > > feedback, added now here. > > > https://patchwork.freedesktop.org/series/129632/#rev1 > > > https://patchwork.freedesktop.org/series/129632/#rev2 > > > > > > > > > > > In case the answer is becasue by then we don't have the vrr.enable or > > > > something like that, then we should consider move around when we set > > > > that > > > > register? > > > > > > This was not acceptable in earlier versions. As per feedback instead of > > > atomic-commit need to add in compute-config phase. > > > > > > > > > > > or perhaps create a specific flag? one extra variable, 3 less comment > > > > lines... > > > > > > The above comment is not clear to me, can you please elaborate more here. > > > > something like: > > > > @intel_dp_compute_config() > > > > +if (pipe_config->vrr.enable && pipe_config->has_panel_replay && > > + adjusted_mode->crtc_vblank_start == adjusted_mode-crtc_vdisplay) > > + pipe_config->mode_flags = I915_MODE_FLAG_MIN_TRANS_CONTEXT_LATENCY_1 > > > > then > > @intel_set_transcoder_timings() > > +u32 context_latency; > > > > +if (crtc_state->mode_flags & I915_MODE_FLAG_MIN_TRANS_CONTEXT_LATENCY_1) > > + context_latency = 1; > > +else > > + crtc_vblank_start - crtc_vdisplay; > > > > -crtc_vblank_start - crtc_vdisplay); > > +context_latency); > > > > Ville, thoughts? > > I think what we need is a intel_crtc_vblank_delay() or somesuch thing > that accounts for all the things (eg. this w/a, dsb execution latency > when we start to use dsb for double buffered registers, etc). > And it should probably be called from some central place so that > it works for all output types. intel_crtc_compute_conf
Re: [PATCH] drm/i915/guc: Add Compute context hint
On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote:
>
> On 21/02/2024 00:14, Vinay Belgaumkar wrote:
> > Allow user to provide a context hint. When this is set, KMD will
> > send a hint to GuC which results in special handling for this
> > context. SLPC will ramp the GT frequency aggressively every time
> > it switches to this context. The down freq threshold will also be
> > lower so GuC will ramp down the GT freq for this context more slowly.
> > We also disable waitboost for this context as that will interfere with
> > the strategy.
> >
> > We need to enable the use of Compute strategy during SLPC init, but
> > it will apply only to contexts that set this bit during context
> > creation.
> >
> > Userland can check whether this feature is supported using a new param-
> > I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true for all guc submission
> > enabled platforms since they use SLPC for freq management.
> >
> > The Mesa usage model for this flag is here -
> > https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
>
> This allows for setting it for the whole application, correct? Upsides,
> downsides? Are there any plans for per context?
Currently there's no extension on a high level API (Vulkan/OpenGL/OpenCL/etc)
that would allow the application to hint for power/freq/latency. So Mesa cannot
decide when to hint. So their solution was to use .drirc and make
per-application
decision.
I would prefer a high level extension for a more granular and informative
decision. We need to work with that goal, but for now I don't see any
cons on this approach.
>
> > Cc: Rodrigo Vivi
> > Signed-off-by: Vinay Belgaumkar
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++
> > .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++
> > drivers/gpu/drm/i915/i915_getparam.c | 11 ++
> > include/uapi/drm/i915_drm.h | 15 +
> > 9 files changed, 89 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index dcbfe32fd30c..ceab7dbe9b47 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct
> > drm_i915_file_private *fpriv,
> >struct i915_gem_proto_context *pc,
> >struct drm_i915_gem_context_param *args)
> > {
> > + struct drm_i915_private *i915 = fpriv->i915;
> > int ret = 0;
> > switch (args->param) {
> > @@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
> > drm_i915_file_private *fpriv,
> > pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
> > break;
> > + case I915_CONTEXT_PARAM_IS_COMPUTE:
> > + if (!intel_uc_uses_guc_submission(&to_gt(i915)->uc))
> > + ret = -EINVAL;
> > + else
> > + pc->user_flags |= BIT(UCONTEXT_COMPUTE);
> > + break;
> > +
> > case I915_CONTEXT_PARAM_RECOVERABLE:
> > if (args->size)
> > ret = -EINVAL;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > index 03bc7f9d191b..db86d6f6245f 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > @@ -338,6 +338,7 @@ struct i915_gem_context {
> > #define UCONTEXT_BANNABLE 2
> > #define UCONTEXT_RECOVERABLE 3
> > #define UCONTEXT_PERSISTENCE 4
> > +#define UCONTEXT_COMPUTE 5
>
> What is the GuC behaviour when SLPC_CTX_FREQ_REQ_IS_COMPUTE is set for
> non-compute engines? Wondering if per intel_context is what we want instead.
> (Which could then be the i915_context_param_engines extension to mark
> individual contexts as compute strategy.)
Perhaps we should rename this? This is a freq-decision-strategy inside
GuC that is there mostly targeting compute workloads that needs lower
latency with short burst execution. But the engine itself doesn't matter.
It can be applied to any engine.
>
> > /**
> > * @flags: small set of booleans
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> > b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index 4feef874e6d6..1ed40cd61b70 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -24,6 +24,7 @@
> > #include "intel_pcode.h"
> > #include "intel_rps.h"
> > #include "vlv_sideband.h"
> > +#include "../gem/i915_gem_context.h"
> >
✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix doc build issue on intel_cdclk.c (rev2)
== Series Details == Series: drm/i915: Fix doc build issue on intel_cdclk.c (rev2) URL : https://patchwork.freedesktop.org/series/130159/ State : warning == Summary == Error: dim checkpatch failed 2e04356d3b31 drm/i915: Fix doc build issue on intel_cdclk.c -:20: WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately followed by Closes: with a URL to the report #20: Reported-by: Stephen Rothwell Signed-off-by: Rodrigo Vivi total: 0 errors, 1 warnings, 0 checks, 7 lines checked
Re: [PATCH 2/3] drm/i915/psr: Improve fast and IO wake lines calculation
On Wed, Feb 21, 2024 at 09:16:22PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 21, 2024 at 09:05:43PM +0200, Ville Syrjälä wrote:
> > On Wed, Feb 21, 2024 at 09:53:21AM +0200, Jouni Högander wrote:
> > > Current fast and IO wake lines calculation is assuming fast wake sync
> > > length is 18 pulses. Let's improve this by checking the actual length.
> > >
> > > Also 10 us IO buffer wake time is currently assumed. This is not the case
> > > with LunarLake and beyond. Fix this by adding getter for IO wake time and
> > > return values there according to Bspec.
> > >
> > > Bspec: 65450
> > >
> > > Signed-off-by: Jouni Högander
> > > ---
> > > drivers/gpu/drm/i915/display/intel_psr.c | 40 +++-
> > > 1 file changed, 33 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 72cadad09db5..4a1e07411716 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1150,6 +1150,28 @@ static bool _lnl_compute_alpm_params(struct
> > > intel_dp *intel_dp,
> > > return true;
> > > }
> > >
> > > +/*
> > > + * From Bspec:
> > > + *
> > > + * For Xe2 and beyond
> > > + * RBR 15us, HBR1 11us, higher rates 10us
> > > + *
> > > + * For pre-Xe2
> > > + * 10 us
> > > + */
> > > +static int get_io_wake_time(struct intel_dp *intel_dp,
> >
> > No point in passing that. You can dig out the i915 from the crtc state.
> >
> > > + struct intel_crtc_state *crtc_state)
> >
> > const
> >
> > > +{
> > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > +
> > > + if (DISPLAY_VER(i915) < 20 || crtc_state->port_clock > 27)
> > > + return 10;
> > > + else if (crtc_state->port_clock > 162000)
> > > + return 11;
> > > + else
> > > + return 15;
> >
> > The new rate dependent stuff should be a separate patch.
> >
> > And looks like the 10 usec will give us 44 usec io wake time, so
> > that should probably be a separate patch as well, to avoid
> > any functional changes when we introduce the formula.
> >
> > > +}
> > > +
> > > static bool _compute_alpm_params(struct intel_dp *intel_dp,
> > >struct intel_crtc_state *crtc_state)
> > > {
> > > @@ -1157,13 +1179,17 @@ static bool _compute_alpm_params(struct intel_dp
> > > *intel_dp,
> > > int io_wake_lines, io_wake_time, fast_wake_lines, fast_wake_time;
> > > u8 max_wake_lines;
> > >
> > > - if (DISPLAY_VER(i915) >= 12) {
> > > - io_wake_time = 42;
> > > - /*
> > > - * According to Bspec it's 42us, but based on testing
> > > - * it is not enough -> use 45 us.
> > > - */
> > > - fast_wake_time = 45;
> > > + if (intel_dp->get_aux_fw_sync_len) {
> > > + int io_wake_time = get_io_wake_time(intel_dp, crtc_state);
> >
> > Looks like this will shadow the variable you're trying to change.
> > Does the compiler not complain about this?
> >
> > > + int tfw_exit_latency = 20; /* eDP spec */
> > > + int phy_wake = 4; /* eDP spec */
> > > + int preamble = 8; /* eDP spec */
> > > + int precharge = intel_dp->get_aux_fw_sync_len() - preamble;
> > > +
> > > + io_wake_time = max(precharge, io_wake_time) + preamble +
> > > + phy_wake + tfw_exit_latency;
> > > + fast_wake_time = precharge + preamble + phy_wake +
> > > + tfw_exit_latency;
> > >
> > > /* TODO: Check how we can use ALPM_CTL fast wake extended field
> > > */
> > > max_wake_lines = 12;
> >
> > I would also convert the older platforms to use the formula.
> > We do need to reverse calculate the io buffer on latency since
> > AFAICS it's not directly specified in bspec. But I think
> > that's better than not converting it since with the formula we
> > can't totally screw things up when eg. changing the precharge
> > length.
>
> Hmm. The older platforms are apparently using fast_wake=32
> which implies zero precharge pulses. That definitely does
> not match what we program into the AUX control register...
Looks like Windows just uses:
pre-tgl:
fast_wake=50
io_fast_wake=50
tgl-mtl:
fast_wake=42
io_fast_wake=42
Also for pre-tgl they clamp these to 5-8 instead of using
the min=7 we have. For tgl+ they do clamp to 7-12.
And if the values exceed those limits they just proceed
blindly with the clamped values, which is pretty dodgy.
--
Ville Syrjälä
Intel
✗ Fi.CI.BAT: failure for drm/i915: Fix doc build issue on intel_cdclk.c (rev2)
== Series Details ==
Series: drm/i915: Fix doc build issue on intel_cdclk.c (rev2)
URL : https://patchwork.freedesktop.org/series/130159/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14311 -> Patchwork_130159v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_130159v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_130159v2, please notify your bug team
(i915-ci-in...@lists.freedesktop.org) 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_130159v2/index.html
Participating hosts (38 -> 36)
--
Missing(2): bat-kbl-2 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_130159v2:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_mocs:
- bat-dg2-11: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/bat-dg2-11/igt@i915_selftest@live@gt_mocs.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130159v2/bat-dg2-11/igt@i915_selftest@live@gt_mocs.html
Known issues
Here are the changes found in Patchwork_130159v2 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-kbl-7567u: [CRASH][3] ([i915#9947]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130159v2/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[ABORT][5] ([i915#7911]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130159v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#9947]: https://gitlab.freedesktop.org/drm/intel/issues/9947
Build changes
-
* Linux: CI_DRM_14311 -> Patchwork_130159v2
CI-20190529: 20190529
CI_DRM_14311: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7720: 7720
Patchwork_130159v2: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
7bfd299156e1 drm/i915: Fix doc build issue on intel_cdclk.c
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130159v2/index.html
Re: Re: [PATCH v3 1/3] bits: introduce fixed-type genmasks
On Wed, Feb 21, 2024 at 11:04:22PM +0200, Andy Shevchenko wrote: On Wed, Feb 21, 2024 at 10:30:02PM +0200, Dmitry Baryshkov wrote: On Thu, 8 Feb 2024 at 09:45, Lucas De Marchi wrote: ... > +#define BITS_PER_TYPE(type)(sizeof(type) * BITS_PER_BYTE) Can sizeof() be used in assembly? ... > -#define __GENMASK(h, l) \ > - (((~UL(0)) - (UL(1) << (l)) + 1) & \ > -(~UL(0) >> (BITS_PER_LONG - 1 - (h > -#define GENMASK(h, l) \ > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) > +#define __GENMASK(t, h, l) \ > + (GENMASK_INPUT_CHECK(h, l) + \ > +(((t)~0ULL - ((t)(1) << (l)) + 1) & \ > +((t)~0ULL >> (BITS_PER_TYPE(t) - 1 - (h) Nevertheless, the use ~0ULL is not proper assembly, this broke initial implementation using UL() / ULL(). indeed. > -#define __GENMASK_ULL(h, l) \ > - (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ > -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h > -#define GENMASK_ULL(h, l) \ > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l)) Ditto. problem here seems actually because of the cast to the final type. My previous impl was avoiding that, but was too verbose compared to this. I will look at reverting this. Lucas De Marchi > +#define GENMASK(h, l) __GENMASK(unsigned long, h, l) > +#define GENMASK_ULL(h, l) __GENMASK(unsigned long long, h, l) > +#define GENMASK_U8(h, l) __GENMASK(u8, h, l) > +#define GENMASK_U16(h, l) __GENMASK(u16, h, l) > +#define GENMASK_U32(h, l) __GENMASK(u32, h, l) > +#define GENMASK_U64(h, l) __GENMASK(u64, h, l) This breaks drm-tip on arm64 architecture: arch/arm64/kernel/entry-fpsimd.S: Assembler messages: 465arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' 466arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 467arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' 468arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 469arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' 470arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 471arch/arm64/kernel/entry-fpsimd.S:271: Error: found 'l', expected: ')' 472arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 473arch/arm64/kernel/entry-fpsimd.S:271: Error: unexpected characters following instruction at operand 3 -- `bic x2,x1,(0+(((unsigned long)~0ULL-((unsigned long)(1)<<(0))+1)&((unsigned long)~0ULL>>((sizeof(unsigned long)*8)-1-(3)' 474arch/arm64/kernel/entry-fpsimd.S:66: Info: macro invoked from here 475arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' 476arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here 477arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' 478arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here 479arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' 480arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here 481arch/arm64/kernel/entry-fpsimd.S:282: Error: found 'l', expected: ')' 482arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here 483arch/arm64/kernel/entry-fpsimd.S:282: Error: unexpected characters following instruction at operand 3 -- `bic x2,x1,(0+(((unsigned long)~0ULL-((unsigned long)(1)<<(0))+1)&((unsigned long)~0ULL>>((sizeof(unsigned long)*8)-1-(3)' 484arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here -- With Best Regards, Andy Shevchenko
✓ Fi.CI.BAT: success for Test MTL DMC v2.21 (rev2)
== Series Details ==
Series: Test MTL DMC v2.21 (rev2)
URL : https://patchwork.freedesktop.org/series/130213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14311 -> Patchwork_130213v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130213v2/index.html
Participating hosts (38 -> 36)
--
Missing(2): fi-snb-2520m bat-arls-3
Known issues
Here are the changes found in Patchwork_130213v2 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-cfl-8109u: [PASS][1] -> [FAIL][2] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-cfl-8109u/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130213v2/fi-cfl-8109u/boot.html
### IGT changes ###
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-kbl-7567u: [CRASH][3] ([i915#9947]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130213v2/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[ABORT][5] ([i915#7911]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130213v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
[i915#9947]: https://gitlab.freedesktop.org/drm/intel/issues/9947
Build changes
-
* Linux: CI_DRM_14311 -> Patchwork_130213v2
CI-20190529: 20190529
CI_DRM_14311: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7720: 7720
Patchwork_130213v2: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
9361b60d6ba7 drm/i915/dmc: Hardcode path to MTL DMC v2.21
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130213v2/index.html
Re: [PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0
Thanks Stan and Vidya for this patch.
ACK for the bigjoiner pipes calc and plane max size validation changes.
@Ville Syrjälä : Do you see any gaps now with MST bigjoiner enabling
in crtc_enable hooks () ? Or just these changes would suffice?
Regards
Manasi
On Wed, Feb 21, 2024 at 11:20 AM Stanislav Lisovskiy
wrote:
>
> Patch calculates bigjoiner pipes in mst compute.
> Patch also passes bigjoiner bool to validate plane
> max size.
>
> Signed-off-by: vsrini4
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 5307ddd4edcf5..fd27d9976c050 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -523,6 +523,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>struct drm_connector_state *conn_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> struct intel_dp *intel_dp = &intel_mst->primary->dp;
> const struct intel_connector *connector =
> @@ -540,6 +541,10 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> return -EINVAL;
>
> + if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode->crtc_hdisplay,
> + adjusted_mode->crtc_clock))
> + pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1,
> crtc->pipe);
> +
> pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> pipe_config->has_pch_encoder = false;
> @@ -1318,12 +1323,6 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
> * corresponding link capabilities of the sink) in case the
> * stream is uncompressed for it by the last branch device.
> */
> - if (mode_rate > max_rate || mode->clock > max_dotclk ||
> - drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port->full_pbn)
> {
> - *status = MODE_CLOCK_HIGH;
> - return 0;
> - }
> -
> if (mode->clock < 1) {
> *status = MODE_CLOCK_LOW;
> return 0;
> @@ -1343,6 +1342,12 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
> return 0;
> }
>
> + if (mode_rate > max_rate || mode->clock > max_dotclk ||
> + drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port->full_pbn)
> {
> + *status = MODE_CLOCK_HIGH;
> + return 0;
> + }
> +
> if (DISPLAY_VER(dev_priv) >= 10 &&
> drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
> /*
> @@ -1385,7 +1390,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
> return 0;
> }
>
> - *status = intel_mode_valid_max_plane_size(dev_priv, mode, false);
> + *status = intel_mode_valid_max_plane_size(dev_priv, mode, bigjoiner);
> return 0;
> }
>
> --
> 2.37.3
>
✗ Fi.CI.BUILD: failure for series starting with [v2,1/6] sna: stop using obsolete type aliases
== Series Details == Series: series starting with [v2,1/6] sna: stop using obsolete type aliases URL : https://patchwork.freedesktop.org/series/130225/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/130225/revisions/1/mbox/ not applied Applying: sna: stop using obsolete type aliases error: sha1 information is lacking or useless (src/sna/sna_display.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 sna: stop using obsolete type aliases 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". Build failed, no error log produced
✓ Fi.CI.BAT: success for drm/i915/cdclk: Document CDCLK components (rev2)
== Series Details ==
Series: drm/i915/cdclk: Document CDCLK components (rev2)
URL : https://patchwork.freedesktop.org/series/130016/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14311 -> Patchwork_130016v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/index.html
Participating hosts (38 -> 35)
--
Missing(3): bat-kbl-2 fi-snb-2520m bat-arls-3
Known issues
Here are the changes found in Patchwork_130016v2 that come from known issues:
### CI changes ###
### IGT changes ###
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-kbl-7567u: [CRASH][1] ([i915#9947]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[ABORT][3] ([i915#7911]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10234]: https://gitlab.freedesktop.org/drm/intel/issues/10234
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#9947]: https://gitlab.freedesktop.org/drm/intel/issues/9947
Build changes
-
* Linux: CI_DRM_14311 -> Patchwork_130016v2
CI-20190529: 20190529
CI_DRM_14311: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7720: 7720
Patchwork_130016v2: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
2f46fe152334 drm/i915/cdclk: Document CDCLK components
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/index.html
✗ Fi.CI.CHECKPATCH: warning for Bigjoiner refactoring (rev8)
== Series Details == Series: Bigjoiner refactoring (rev8) URL : https://patchwork.freedesktop.org/series/128311/ State : warning == Summary == Error: dim checkpatch failed 99388805e7fa drm/i915/bigjoiner: Refactor bigjoiner state readout 1b4a23d5e363 Start separating pipe vs transcoder set logic for bigjoiner during modeset -:12: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?) #12: That way we can also remove a bunch of checks like intel_crtc_is_bigjoiner_slave. -:235: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #235: FILE: drivers/gpu/drm/i915/display/intel_display.c:1750: +* to change the workaround. */ -:361: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #361: FILE: drivers/gpu/drm/i915/display/intel_display.h:283: +#define for_each_intel_crtc_in_pipe_mask_reverse(dev, intel_crtc, pipe_mask) \ + list_for_each_entry_reverse(intel_crtc, \ + &(dev)->mode_config.crtc_list, \ + base.head) \ + for_each_if((pipe_mask) & BIT(intel_crtc->pipe)) -:361: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_crtc' - possible side-effects? #361: FILE: drivers/gpu/drm/i915/display/intel_display.h:283: +#define for_each_intel_crtc_in_pipe_mask_reverse(dev, intel_crtc, pipe_mask) \ + list_for_each_entry_reverse(intel_crtc, \ + &(dev)->mode_config.crtc_list, \ + base.head) \ + for_each_if((pipe_mask) & BIT(intel_crtc->pipe)) total: 1 errors, 2 warnings, 1 checks, 317 lines checked 0ad1c861ceb6 drm/i915: Fix bigjoiner case for DP2.0
✗ Fi.CI.SPARSE: warning for Bigjoiner refactoring (rev8)
== Series Details == Series: Bigjoiner refactoring (rev8) URL : https://patchwork.freedesktop.org/series/128311/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:1
✓ Fi.CI.BAT: success for Bigjoiner refactoring (rev8)
== Series Details == Series: Bigjoiner refactoring (rev8) URL : https://patchwork.freedesktop.org/series/128311/ State : success == Summary == CI Bug Log - changes from CI_DRM_14311 -> Patchwork_128311v8 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v8/index.html Participating hosts (38 -> 36) -- Missing(2): bat-arls-2 fi-snb-2520m Known issues Here are the changes found in Patchwork_128311v8 that come from known issues: ### IGT changes ### Issues hit * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][1] ([i915#9197]) +1 other test skip [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v8/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-kbl-7567u: [CRASH][2] ([i915#9947]) -> [PASS][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-kbl-7567u/igt@i915_pm_...@module-reload.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v8/fi-kbl-7567u/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[ABORT][4] ([i915#7911]) -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v8/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#9197]: https://gitlab.freedesktop.org/drm/intel/issues/9197 [i915#9947]: https://gitlab.freedesktop.org/drm/intel/issues/9947 Build changes - * Linux: CI_DRM_14311 -> Patchwork_128311v8 CI-20190529: 20190529 CI_DRM_14311: 06b279b4fb58a00667e47fafed72bba923d032ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7720: 7720 Patchwork_128311v8: 06b279b4fb58a00667e47fafed72bba923d032ae @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 00885cd760b3 drm/i915: Fix bigjoiner case for DP2.0 6701c68c1867 Start separating pipe vs transcoder set logic for bigjoiner during modeset dd42b05e3bca drm/i915/bigjoiner: Refactor bigjoiner state readout == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v8/index.html
✓ Fi.CI.IGT: success for drm/i915/display/debugfs: New entry "DRRS capable" to i915_drrs_status
== Series Details == Series: drm/i915/display/debugfs: New entry "DRRS capable" to i915_drrs_status URL : https://patchwork.freedesktop.org/series/130197/ State : success == Summary == CI Bug Log - changes from CI_DRM_14310_full -> Patchwork_130197v1_full Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/index.html Participating hosts (8 -> 7) -- Missing(1): shard-glk-0 Known issues Here are the changes found in Patchwork_130197v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][1], [FAIL][2], [PASS][3], [PASS][4], [PASS][5], [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]) ([i915#8293]) -> ([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], [PASS][49]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk1/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk2/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk2/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk2/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk3/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk3/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk3/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk4/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk4/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk4/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk7/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk7/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk7/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk8/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk8/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk8/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk9/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14310/shard-glk9/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk8/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk2/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk2/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk3/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk3/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk3/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk4/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk4/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk4/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk5/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130197v1/shard-glk5/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1301
Re: [PATCH 2/3] drm/i915/psr: Improve fast and IO wake lines calculation
Hi Jouni, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on drm-tip/drm-tip next-20240221] [cannot apply to drm-intel/for-linux-next-fixes linus/master v6.8-rc5] [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#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Jouni-H-gander/drm-i915-display-Add-aux-function-pointer-for-fast-wake-sync-pulse-count/20240221-160220 base: git://anongit.freedesktop.org/drm-intel for-linux-next patch link: https://lore.kernel.org/r/20240221075322.2764209-3-jouni.hogander%40intel.com patch subject: [PATCH 2/3] drm/i915/psr: Improve fast and IO wake lines calculation config: s390-allmodconfig (https://download.01.org/0day-ci/archive/20240222/202402220859.k3osmrci-...@intel.com/config) compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 36adfec155de366d722f2bac8ff9162289dcf06c) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240222/202402220859.k3osmrci-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202402220859.k3osmrci-...@intel.com/ All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/display/intel_psr.c:28: In file included from drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:15: In file included from drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h:11: In file included from drivers/gpu/drm/xe/xe_bo.h:11: In file included from drivers/gpu/drm/xe/xe_bo_types.h:9: In file included from include/linux/iosys-map.h:10: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:78: include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 547 | val = __raw_readb(PCI_IOBASE + addr); | ~~ ^ include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 560 | val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr)); | ~~ ^ include/uapi/linux/byteorder/big_endian.h:37:59: note: expanded from macro '__le16_to_cpu' 37 | #define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x)) | ^ include/uapi/linux/swab.h:102:54: note: expanded from macro '__swab16' 102 | #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x)) | ^ In file included from drivers/gpu/drm/i915/display/intel_psr.c:28: In file included from drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:15: In file included from drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h:11: In file included from drivers/gpu/drm/xe/xe_bo.h:11: In file included from drivers/gpu/drm/xe/xe_bo_types.h:9: In file included from include/linux/iosys-map.h:10: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:78: include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 573 | val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); | ~~ ^ include/uapi/linux/byteorder/big_endian.h:35:59: note: expanded from macro '__le32_to_cpu' 35 | #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) | ^ include/uapi/linux/swab.h:115:54: note: expanded from macro '__swab32' 115 | #define __swab32(x) (__u32)__builtin_bswap32((__u32)(x)) | ^ In file included from drivers/gpu/drm/i915/display/intel_psr.c:28: In file included from drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:15: In file included from drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h:11: In file included from drivers/gpu/drm/xe/xe_bo.h:11: In file included from drivers/gpu/drm/xe/xe_bo_types.h:9: In file included from include/linux/iosys-map.h:10: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:78: include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null p
[PATCH v2] drivers/i915/intel_bios: Fix parsing backlight BDB data
Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to
backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB
contents") updated the backlight BDB data accordingly. This broke the
parsing of backlight BDB data in VBT for versions 236 - 238 (both
inclusive) and hence the backlight controls are not responding on units
with the concerned BDB version.
backlight_control information has been present in backlight BDB data
from at least BDB version 191 onwards, if not before. Hence this patch
extracts the backlight_control information for BDB version 191 or newer.
Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236).
Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251).
Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents")
Cc: sta...@vger.kernel.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Karthikeyan Ramasubramanian
---
Changes in v2:
- removed checking the block size of the backlight BDB data
drivers/gpu/drm/i915/display/intel_bios.c | 19 ---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 -
2 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index aa169b0055e97..8c1eb05fe77d2 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1042,22 +1042,11 @@ parse_lfp_backlight(struct drm_i915_private *i915,
panel->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
panel->vbt.backlight.controller = 0;
if (i915->display.vbt.version >= 191) {
- size_t exp_size;
+ const struct lfp_backlight_control_method *method;
- if (i915->display.vbt.version >= 236)
- exp_size = sizeof(struct bdb_lfp_backlight_data);
- else if (i915->display.vbt.version >= 234)
- exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
- else
- exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_191;
-
- if (get_blocksize(backlight_data) >= exp_size) {
- const struct lfp_backlight_control_method *method;
-
- method = &backlight_data->backlight_control[panel_type];
- panel->vbt.backlight.type = method->type;
- panel->vbt.backlight.controller = method->controller;
- }
+ method = &backlight_data->backlight_control[panel_type];
+ panel->vbt.backlight.type = method->type;
+ panel->vbt.backlight.controller = method->controller;
}
panel->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index a9f44abfc9fc2..b50cd0dcabda9 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -897,11 +897,6 @@ struct lfp_brightness_level {
u16 reserved;
} __packed;
-#define EXP_BDB_LFP_BL_DATA_SIZE_REV_191 \
- offsetof(struct bdb_lfp_backlight_data, brightness_level)
-#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
- offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
-
struct bdb_lfp_backlight_data {
u8 entry_size;
struct lfp_backlight_data_entry data[16];
--
2.44.0.rc0.258.g7320e95886-goog
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:47:6: error: redefinition of
'rzg2l_du_vsp_enable'
47 | void rzg2l_du_vsp_enable(struct rzg2l_du_crtc *crtc)
| ^~~
In file included from drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h:18,
from drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:30:
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:72:20: note: previous definition
of 'rzg2l_du_vsp_enable' with type 'void(struct rzg2l_du_crtc *)'
72 | static inline void rzg2l_du_vsp_enable(struct rzg2l_du_crtc *crtc) { };
|^~~
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:61:6: error: redefinition of
'rzg2l_du_vsp_disable'
61 | void rzg2l_du_vsp_disable(struct rzg2l_du_crtc *crtc)
| ^~~~
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:73:20: note: previous definition
of 'rzg2l_du_vsp_disable' with type 'void(struct rzg2l_du_crtc *)'
73 | static inline void rzg2l_du_vsp_disable(struct rzg2l_du_crtc *crtc) { };
|^~~~
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:66:6: error: redefinition of
'rzg2l_du_vsp_atomic_flush'
66 | void rzg2l_du_vsp_atomic_flush(struct rzg2l_du_crtc *crtc)
| ^
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:74:20: note: previous definition
of 'rzg2l_du_vsp_atomic_flush' with type 'void(struct rzg2l_du_crtc *)'
74 | static inline void rzg2l_du_vsp_atomic_flush(struct rzg2l_du_crtc
*crtc) { };
|^
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:76:19: error: redefinition of
'rzg2l_du_vsp_get_drm_plane'
76 | struct drm_plane *rzg2l_du_vsp_get_drm_plane(struct rzg2l_du_crtc *crtc,
| ^~
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:75:33: note: previous definition
of 'rzg2l_du_vsp_get_drm_plane' with type 'struct drm_plane *(struct
rzg2l_du_crtc *, unsigned int)'
75 | static inline struct drm_plane *rzg2l_du_vsp_get_drm_plane(struct
rzg2l_du_crtc *crtc,
| ^~
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:302:5: error: redefinition of
'rzg2l_du_vsp_init'
302 | int rzg2l_du_vsp_init(struct rzg2l_du_vsp *vsp, struct device_node *np,
| ^
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:66:19: note: previous definition
of 'rzg2l_du_vsp_init' with type 'int(struct rzg2l_du_vsp *, struct device_node
*, unsigned int)'
66 | static inline int rzg2l_du_vsp_init(struct rzg2l_du_vsp *vsp, struct
device_node *np,
| ^
Caused by commit
768e9e61b3b9 ("drm: renesas: Add RZ/G2L DU Support")
I have used the drm-misc tree from next-20240221 for today.
--
Cheers,
Stephen Rothwell
pgp5Yv6hyy52w.pgp
Description: OpenPGP digital signature
✓ Fi.CI.BAT: success for drivers/i915/intel_bios: Fix parsing backlight BDB data (rev2)
== Series Details ==
Series: drivers/i915/intel_bios: Fix parsing backlight BDB data (rev2)
URL : https://patchwork.freedesktop.org/series/130152/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14311 -> Patchwork_130152v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130152v2/index.html
Participating hosts (38 -> 36)
--
Missing(2): fi-snb-2520m bat-arls-3
Known issues
Here are the changes found in Patchwork_130152v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-1115g4: [PASS][1] -> [DMESG-FAIL][2] ([i915#10141])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-tgl-1115g4/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130152v2/fi-tgl-1115g4/igt@i915_selftest@live@gt_lrc.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-kbl-7567u: [CRASH][3] ([i915#9947]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130152v2/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[ABORT][5] ([i915#7911]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130152v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10141]: https://gitlab.freedesktop.org/drm/intel/issues/10141
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#9947]: https://gitlab.freedesktop.org/drm/intel/issues/9947
Build changes
-
* Linux: CI_DRM_14311 -> Patchwork_130152v2
CI-20190529: 20190529
CI_DRM_14311: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7720: 7720
Patchwork_130152v2: 06b279b4fb58a00667e47fafed72bba923d032ae @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
fc6e0656bc50 drivers/i915/intel_bios: Fix parsing backlight BDB data
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130152v2/index.html
RE: [PATCH] drm/i915/display/debugfs: New entry "DRRS capable" to i915_drrs_status
> -Original Message-
> From: Intel-gfx On Behalf Of
> Bhanuprakash Modem
> Sent: Wednesday, February 21, 2024 4:42 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Modem, Bhanuprakash
> Subject: [PATCH] drm/i915/display/debugfs: New entry "DRRS capable" to
> i915_drrs_status
>
> If the connected panel supports both DRRS & PSR, driver gives preference to
> PSR ("DRRS enabled: no"). Even though the hardware supports DRRS, IGT
> treats ("DRRS enabled: yes") as not capable.
>
> Introduce a new entry "DRRS capable" to debugfs i915_drrs_status, so that
> IGT will read the DRRS capability as "DRRS capable: yes".
>
> Signed-off-by: Bhanuprakash Modem
> ---
> drivers/gpu/drm/i915/display/intel_drrs.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
> b/drivers/gpu/drm/i915/display/intel_drrs.c
> index 6282ec0fc9b4..169ef38ff188 100644
> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> @@ -299,6 +299,7 @@ void intel_drrs_crtc_init(struct intel_crtc *crtc) static
> int intel_drrs_debugfs_status_show(struct seq_file *m, void *unused) {
> struct intel_crtc *crtc = m->private;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> const struct intel_crtc_state *crtc_state;
> int ret;
>
> @@ -310,6 +311,11 @@ static int intel_drrs_debugfs_status_show(struct
> seq_file *m, void *unused)
>
> mutex_lock(&crtc->drrs.mutex);
>
> + seq_printf(m, "DRRS capable: %s\n",
> +str_yes_no(crtc_state->has_drrs ||
> + HAS_DOUBLE_BUFFERED_M_N(i915) ||
> + intel_cpu_transcoder_has_m2_n2(i915,
> +crtc_state->cpu_transcoder)));
> +
Adding DRRS capable property to debugfs.
Change LGTM
Reviewed-by: Mitul Golani
> seq_printf(m, "DRRS enabled: %s\n",
> str_yes_no(crtc_state->has_drrs));
>
> --
> 2.43.0
Re: [PATCH] drm/ttm: Fix an invalid freeing on already freed page in error path
On Wed, 2024-02-21 at 11:26 +0100, Christian König wrote:
> Am 21.02.24 um 08:33 schrieb Thomas Hellström:
> > If caching mode change fails due to, for example, OOM we
> > free the allocated pages in a two-step process. First the pages
> > for which the caching change has already succeeded. Secondly
> > the pages for which a caching change did not succeed.
> >
> > However the second step was incorrectly freeing the pages already
> > freed in the first step.
> >
> > Fix.
> >
> > Signed-off-by: Thomas Hellström
> > Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
> > Cc: Christian König
> > Cc: Dave Airlie
> > Cc: Christian Koenig
> > Cc: Huang Rui
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: # v6.4+
>
> You don't know how much time I've spend staring at this line to find
> the
> bug in it and haven't seen it. Got bug reports about that for month
> as well.
Yeah, sorry about that. We should probably have Kunit tests exercising
OOM in the pool code involving WC pages.
I'll push this to drm-misc-next.
/Thomas
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
> > b/drivers/gpu/drm/ttm/ttm_pool.c
> > index b62f420a9f96..112438d965ff 100644
> > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > @@ -387,7 +387,7 @@ static void ttm_pool_free_range(struct ttm_pool
> > *pool, struct ttm_tt *tt,
> > enum ttm_caching caching,
> > pgoff_t start_page, pgoff_t
> > end_page)
> > {
> > - struct page **pages = tt->pages;
> > + struct page **pages = &tt->pages[start_page];
> > unsigned int order;
> > pgoff_t i, nr;
> >
>
RE: [RFC v1 0/3] drm/i915: Add support for XRandR Border property
Hi Ville, > > Some customers and users have expressed interest in adding borders > > (or margins) to certain displays in their multi-display configurations. > > To address this need, this patchset implements the XRandR Border > > property as defined here: > > > https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n2 > 032 > > > > --- > > > > Patchset overview: > > > > Patch 1: Create skl_program_crtc_scaler() to program scaler for crtc > > Patch 2: Create and attach the Border property to DP and HDMI > > Patch 3: Implement Border property by enabling crtc scalar > > > > This series is tested using following method: > > - Run the following xrandr command with different parameters: > > xrandr --output HDMI-3 --pos 1920x0 --mode 1280x1024 --fb 3840x2160 -- > scale 2.11x2.11 --set "Border" 150,0,150,0 > > > > The following patch was also added to the modesetting driver to > > implement the Border property: > > https://gitlab.freedesktop.org/Vivek/xserver/- > /commit/62abfc438f0d17fe7f88bf2826c9784c2b36443b > > I have an old branch implementing the margin properties: > https://github.com/vsyrjala/linux.git hdmi_margins_3 > > but it got stalled due to the scaler code being in a very poor state. > I started sketching some reworks there, but that got put on the > backburner due to other stuff: > https://github.com/vsyrjala/linux.git scaler_rework_2 > > I might have somehting more recent than that locally, but I'd have > to trawl through my branches to check what's the latest state. There is a lot to unpack in these two branches than what I had anticipated. However, it looks like some of the patches are already merged. Do you have any plan to revive this work anytime soon? And, besides the remaining unmerged patches in the above two branches, are there still any other missing pieces preventing this feature from getting merged? Thanks, Vivek > > > > > Cc: Ville Syrjälä > > Cc: Matt Roper > > Cc: Dongwon Kim > > > > Vivek Kasireddy (3): > > drm/i915: Rename skl_pfit_enable() to skl_program_crtc_scaler() > > drm/i915: Attach the Border property to DP and HDMI connectors > > drm/i915: Apply border adjustments and enable scaler on the crtc > > > > drivers/gpu/drm/i915/display/intel_atomic.c | 29 ++- > > .../gpu/drm/i915/display/intel_connector.c| 49 +++ > > .../gpu/drm/i915/display/intel_connector.h| 3 ++ > > drivers/gpu/drm/i915/display/intel_display.c | 25 -- > > .../gpu/drm/i915/display/intel_display_core.h | 1 + > > .../drm/i915/display/intel_display_types.h| 6 +++ > > drivers/gpu/drm/i915/display/intel_dp.c | 11 + > > drivers/gpu/drm/i915/display/intel_hdmi.c | 11 + > > drivers/gpu/drm/i915/display/skl_scaler.c | 27 ++ > > drivers/gpu/drm/i915/display/skl_scaler.h | 3 +- > > 10 files changed, 149 insertions(+), 16 deletions(-) > > > > -- > > 2.43.0 > > -- > Ville Syrjälä > Intel
[PATCH 00/13] HDCP MST Type1 fixes
We were seeing a blank screen whenever Type1 content was played. This was due to extra timing which was taken as we had moved to remote read and writes previously for MST scenario, which in turn was done as we were not able to do direct read and writes to the immediate downstream device. The correct flow should be that we talk only to the immediate downstream device and the rest needs to be taken care by that device. With this patch series we move back to direct reads and writes, fix the fastset setting because of which direct reads and writes to HDCP related DPCD register stopped working, derive hdcp structure correctly and increase robustability if rxcaps HDCP capability reporting. Signed-off-by: Suraj Kandpal Suraj Kandpal (13): drm/i915/hdcp: Move to direct reads for HDCP drm/i915/hdcp: Move source hdcp2 checks into its own function drm/i915/hdcp: Refactor intel_dp_hdcp2_capable drm/i915/hdcp: Pass drm_dp_aux to read_bcaps function drm/i915/hdcp: Rename hdcp capable functions drm/i915/hdcp: Add new remote capability check shim function drm/i915/hdcp: HDCP Capability for the downstream device drm/i915/hdcp: Remove additional timing for reading mst hdcp message drm/i915/hdcp: Extract hdcp structure from correct connector drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link drm/i915/hdcp: Don't enable HDCP1.4 directly from check_link drm/i915/hdcp: Allocate stream id after HDCP AKE stage drm/i915/hdcp: Read Rxcaps for robustibility .../drm/i915/display/intel_display_debugfs.c | 21 +- .../drm/i915/display/intel_display_types.h| 12 +- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 137 +++ drivers/gpu/drm/i915/display/intel_hdcp.c | 226 +- drivers/gpu/drm/i915/display/intel_hdcp.h | 7 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +- 6 files changed, 228 insertions(+), 181 deletions(-) -- 2.43.2
[PATCH 01/13] drm/i915/hdcp: Move to direct reads for HDCP
Even for MST scenarios we need to do direct reads only on the
immediate downstream device the rest of the authentication is taken
care by that device. Remote reads will only be used to check
capability of the monitors in MST topology.
--v2
-Add fixes tag [Ankit]
-Derive aux where needed rather than through a function [Ankit]
Fixes: ae4f902bb344 ("drm/i915/hdcp: Send the correct aux for DPMST HDCP
scenario")
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 31 ++--
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 9dff4bdfeec8..92642e8d82db 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -333,23 +333,13 @@ static const struct hdcp2_dp_msg_data hdcp2_dp_msg_data[]
= {
0, 0 },
};
-static struct drm_dp_aux *
-intel_dp_hdcp_get_aux(struct intel_connector *connector)
-{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
-
- if (intel_encoder_is_mst(connector->encoder))
- return &connector->port->aux;
- else
- return &dig_port->dp.aux;
-}
-
static int
intel_dp_hdcp2_read_rx_status(struct intel_connector *connector,
u8 *rx_status)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
- struct drm_dp_aux *aux = intel_dp_hdcp_get_aux(connector);
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = &dig_port->dp.aux;
ssize_t ret;
ret = drm_dp_dpcd_read(aux,
@@ -458,8 +448,9 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = &dig_port->dp.aux;
const struct hdcp2_dp_msg_data *hdcp2_msg_data;
- struct drm_dp_aux *aux;
hdcp2_msg_data = get_hdcp2_dp_msg_data(*byte);
if (!hdcp2_msg_data)
@@ -467,8 +458,6 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
offset = hdcp2_msg_data->offset;
- aux = intel_dp_hdcp_get_aux(connector);
-
/* No msg_id in DP HDCP2.2 msgs */
bytes_to_write = size - 1;
byte++;
@@ -494,7 +483,8 @@ static
ssize_t get_receiver_id_list_rx_info(struct intel_connector *connector,
u32 *dev_cnt, u8 *byte)
{
- struct drm_dp_aux *aux = intel_dp_hdcp_get_aux(connector);
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = &dig_port->dp.aux;
ssize_t ret;
u8 *rx_info = byte;
@@ -520,7 +510,7 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
- struct drm_dp_aux *aux;
+ struct drm_dp_aux *aux = &dig_port->dp.aux;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_recv, len;
@@ -534,8 +524,6 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
return -EINVAL;
offset = hdcp2_msg_data->offset;
- aux = intel_dp_hdcp_get_aux(connector);
-
ret = intel_dp_hdcp2_wait_for_msg(connector, hdcp2_msg_data);
if (ret < 0)
return ret;
@@ -655,12 +643,11 @@ static
int intel_dp_hdcp2_capable(struct intel_connector *connector,
bool *capable)
{
- struct drm_dp_aux *aux;
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = &dig_port->dp.aux;
u8 rx_caps[3];
int ret;
- aux = intel_dp_hdcp_get_aux(connector);
-
*capable = false;
ret = drm_dp_dpcd_read(aux,
DP_HDCP_2_2_REG_RX_CAPS_OFFSET,
--
2.43.2
