[Intel-gfx] [PATCH] drm/edid: Parse VRR cap fields from HFVSDB block
This patch parses HFVSDB fields for VRR capabilities of an
HDMI2.1 sink and stores the VRR caps in a new structure in
drm_hdmi_info.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 26 --
include/drm/drm_connector.h | 27 +++
2 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 47465b9765f1..bb1f7d899580 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5823,6 +5823,21 @@ static void drm_parse_ycbcr420_deep_color_info(struct
drm_connector *connector,
hdmi->y420_dc_modes = dc_mask;
}
+static void drm_parse_vrr_info(struct drm_hdmi_vrr_cap *hdmi_vrr,
+ const u8 *hf_scds)
+{
+ if (hf_scds[8] & DRM_EDID_CNMVRR)
+ hdmi_vrr->cnm_vrr = true;
+ if (hf_scds[8] & DRM_EDID_CINEMA_VRR)
+ hdmi_vrr->cinema_vrr = true;
+ if (hf_scds[8] & DRM_EDID_MDELTA)
+ hdmi_vrr->m_delta = true;
+
+ hdmi_vrr->vrr_min = hf_scds[9] & DRM_EDID_VRR_MIN_MASK;
+ hdmi_vrr->vrr_max = (hf_scds[9] & DRM_EDID_VRR_MAX_UPPER_MASK) << 2;
+ hdmi_vrr->vrr_max |= hf_scds[10] & DRM_EDID_VRR_MAX_LOWER_MASK;
+}
+
static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap *hdmi_dsc,
const u8 *hf_scds)
{
@@ -5901,9 +5916,11 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
struct drm_display_info *display = >display_info;
struct drm_hdmi_info *hdmi = >hdmi;
struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
+ struct drm_hdmi_vrr_cap *hdmi_vrr = >vrr_cap;
int max_tmds_clock = 0;
u8 max_frl_rate = 0;
bool dsc_support = false;
+ bool vrr_support = false;
display->has_hdmi_infoframe = true;
@@ -5949,14 +5966,19 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
+ if (cea_db_payload_len(hf_scds) >= 8 && hf_scds[8]) {
+ drm_parse_vrr_info(hdmi_vrr, hf_scds);
+ vrr_support = true;
+ }
+
if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11]) {
drm_parse_dsc_info(hdmi_dsc, hf_scds);
dsc_support = true;
}
drm_dbg_kms(connector->dev,
- "HF-VSDB: max TMDS clock: %d KHz, HDMI 2.1 support: %s, DSC
1.2 support: %s\n",
- max_tmds_clock, str_yes_no(max_frl_rate),
str_yes_no(dsc_support));
+ "HF-VSDB: max TMDS clock: %d KHz, HDMI 2.1 support: %s, VRR
support: %s, DSC 1.2 support: %s\n",
+ max_tmds_clock, str_yes_no(max_frl_rate),
str_yes_no(vrr_support), str_yes_no(dsc_support));
}
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index b1b2df48d42c..ec6ef71ab5cd 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -219,6 +219,30 @@ struct drm_hdmi_dsc_cap {
u8 total_chunk_kbytes;
};
+
+/**
+ * struct drm_hdmi_vrr_cap - VRR capabilities of HDMI sink
+ * Describes the VRR support provided by HDMI 2.1 sink.
+ * The information is fetched fom additional HFVSDB blocks defined
+ * for HDMI 2.1.
+ */
+struct drm_hdmi_vrr_cap {
+ /** @cnm_vrr: sink supports negative Mvrr values*/
+ bool cnm_vrr;
+
+ /** @cinema_vrr: sink supports fractional and integer media rates <
VRRmin*/
+ bool cinema_vrr;
+
+ /** @m_delta: sink can anticipate and compensate for frame-to-frame
variation in Mvrr */
+ bool m_delta;
+
+ /** @vrr_min: VRRmin - lowest framerate in Hz that sink can support in
VRR */
+ u8 vrr_min;
+
+ /** @vrr_max: VRRmax - highest framerate in Hz that sink can support in
VRR */
+ u16 vrr_max;
+};
+
/**
* struct drm_hdmi_info - runtime information about the connected HDMI sink
*
@@ -259,6 +283,9 @@ struct drm_hdmi_info {
/** @dsc_cap: DSC capabilities of the sink */
struct drm_hdmi_dsc_cap dsc_cap;
+
+ /** @vrr_cap: VRR capabilities of the sink */
+ struct drm_hdmi_vrr_cap vrr_cap;
};
/**
--
2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for Move all drivers to a common dma-buf locking convention
== Series Details == Series: Move all drivers to a common dma-buf locking convention URL : https://patchwork.freedesktop.org/series/109786/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109786v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_109786v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_109786v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (12 -> 10) -- Missing(2): pig-skl-6260u shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_109786v1_full: ### IGT changes ### Possible regressions * igt@i915_suspend@debugfs-reader: - shard-apl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/shard-apl8/igt@i915_susp...@debugfs-reader.html Warnings * igt@gem_pwrite@basic-exhaustion: - shard-apl: [INCOMPLETE][2] ([i915#7234]) -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl7/igt@gem_pwr...@basic-exhaustion.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/shard-apl3/igt@gem_pwr...@basic-exhaustion.html * igt@gem_softpin@noreloc-s3: - shard-apl: [INCOMPLETE][4] ([i915#7236]) -> [INCOMPLETE][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl8/igt@gem_soft...@noreloc-s3.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/shard-apl7/igt@gem_soft...@noreloc-s3.html Known issues Here are the changes found in Patchwork_109786v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-snb: ([PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [FAIL][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30]) ([i915#4338]) -> ([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], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/shard-snb7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/shard-snb7/boot.html
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Add intel_ prefix to struct ip_version
On Mon, Oct 17, 2022 at 10:29:56AM -0700, Lucas De Marchi wrote: On Tue, Oct 11, 2022 at 08:38:50AM -0700, Radhakrishna Sripada wrote: Rename struct ip_version to intel_ip_version to comply with the naming conventions for structures. Suggested-by: Jani Nikula Signed-off-by: Radhakrishna Sripada Reviewed-by: Lucas De Marchi both patches pushed, thanks Lucas De Marchi
Re: [Intel-gfx] [PATCH] drm/i915: fix clear mask in GEN7_MISCCPCTL update
On Mon, Oct 17, 2022 at 10:22:08AM -0700, Lucas De Marchi wrote:
On Mon, Oct 17, 2022 at 10:55:25AM +0200, Andrzej Hajda wrote:
GEN7_DOP_CLOCK_GATE_ENABLE bit should be cleared, not inverse.
The bug was introduced during conversion to intel_uncore_rmw helper.
Suggested-by: Matt Roper
Fixes: 8cee664d3eb6f8 ("drm/i915: use proper helper for register updates")
Signed-off-by: Andrzej Hajda
Reviewed-by: Lucas De Marchi
and pushed
thanks
Lucas De Marchi
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add error-capture init warnings when needed
On 10/17/2022 16:36, Teres Alexis, Alan Previn wrote:
Agreed on all the others (as per my other reply to Tvrtko), but on that 2nd
last one:
On Mon, 2022-10-17 at 12:33 -0700, Harrison, John C wrote:
On 10/14/2022 20:59, Alan Previn wrote:
If GuC is being used and we initialized GuC-error-capture,
we need to be warning if we don't provide an error-capture
register list in the firmware ADS, for valid GT engines.
A warning makes sense as this would impact debugability
without realizing why a reglist wasn't retrieved and reported
by GuC.
+ if (!guc_capture_get_one_list(gc->reglists, owner, type, classid)) {
+ if (owner == GUC_CAPTURE_LIST_INDEX_PF && type ==
GUC_CAPTURE_LIST_TYPE_GLOBAL)
+ drm_warn(>drm, "GuC-capture: missing reglist
type-Global\n");
+ if (owner == GUC_CAPTURE_LIST_INDEX_PF)
+ drm_warn(>drm, "GuC-capture: missing regiist
type(%d)-%s : "
+"%s(%d)-Engine\n", type,
__stringify_type(type),
What Tvrtko is meaning here is to not split the string at all. You can
ignore a line length warning message if the only alternatives are either
to split the string or to obfuscate the code with unreadable/unnecessary
construction methods.
I dont see how not splitting the string makes the grep work as per the reason
Tvrtko was bringing up... but sure,..
ignoring a checkpatch here is fine by me - as i do agree having a single line
is better to read.
I don't think Tvrtko was meaning anything other than the line wrap.
Having %d, %s, etc. in a string is fine if that's what you are meaning.
You really don't want to go the route of expanding all possible options
of those. And you can still grep for 'missing reglist.*Engine' for
example. But yeah, with this particular one I think it is more about
code readability than greppability for me at least.
John.
...alan
Re: [Intel-gfx] [PATCH v5 4/4] drm/i915: Improve long running compute w/a for GuC submission
On 10/6/2022 2:38 PM, john.c.harri...@intel.com wrote: From: John Harrison A workaround was added to the driver to allow compute workloads to run 'forever' by disabling pre-emption on the RCS engine for Gen12. It is not totally unbound as the heartbeat will kick in eventually and cause a reset of the hung engine. However, this does not work well in GuC submission mode. In GuC mode, the pre-emption timeout is how GuC detects hung contexts and triggers a per engine reset. Thus, disabling the timeout means also losing all per engine reset ability. A full GT reset will still occur when the heartbeat finally expires, but that is a much more destructive and undesirable mechanism. The purpose of the workaround is actually to give compute tasks longer to reach a pre-emption point after a pre-emption request has been issued. This is necessary because Gen12 does not support mid-thread pre-emption and compute tasks can have long running threads. So, rather than disabling the timeout completely, just set it to a 'long' value. v2: Review feedback from Tvrtko - must hard code the 'long' value instead of determining it algorithmically. So make it an extra CONFIG definition. Also, remove the execlist centric comment from the existing pre-emption timeout CONFIG option given that it applies to more than just execlists. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio (v1) r-b stands. Daniele Acked-by: Michal Mrozek Acked-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/Kconfig.profile | 26 +++ drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 ++-- 2 files changed, 29 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/Kconfig.profile b/drivers/gpu/drm/i915/Kconfig.profile index 39328567c2007..7cc38d25ee5c8 100644 --- a/drivers/gpu/drm/i915/Kconfig.profile +++ b/drivers/gpu/drm/i915/Kconfig.profile @@ -57,10 +57,28 @@ config DRM_I915_PREEMPT_TIMEOUT default 640 # milliseconds help How long to wait (in milliseconds) for a preemption event to occur - when submitting a new context via execlists. If the current context - does not hit an arbitration point and yield to HW before the timer - expires, the HW will be reset to allow the more important context - to execute. + when submitting a new context. If the current context does not hit + an arbitration point and yield to HW before the timer expires, the + HW will be reset to allow the more important context to execute. + + This is adjustable via + /sys/class/drm/card?/engine/*/preempt_timeout_ms + + May be 0 to disable the timeout. + + The compiled in default may get overridden at driver probe time on + certain platforms and certain engines which will be reflected in the + sysfs control. + +config DRM_I915_PREEMPT_TIMEOUT_COMPUTE + int "Preempt timeout for compute engines (ms, jiffy granularity)" + default 7500 # milliseconds + help + How long to wait (in milliseconds) for a preemption event to occur + when submitting a new context to a compute capable engine. If the + current context does not hit an arbitration point and yield to HW + before the timer expires, the HW will be reset to allow the more + important context to execute. This is adjustable via /sys/class/drm/card?/engine/*/preempt_timeout_ms diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index fcbccd8d244e9..c1257723d1949 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -508,9 +508,14 @@ static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id, engine->props.timeslice_duration_ms = CONFIG_DRM_I915_TIMESLICE_DURATION; - /* Override to uninterruptible for OpenCL workloads. */ + /* +* Mid-thread pre-emption is not available in Gen12. Unfortunately, +* some compute workloads run quite long threads. That means they get +* reset due to not pre-empting in a timely manner. So, bump the +* pre-emption timeout value to be much higher for compute engines. +*/ if (GRAPHICS_VER(i915) == 12 && (engine->flags & I915_ENGINE_HAS_RCS_REG_STATE)) - engine->props.preempt_timeout_ms = 0; + engine->props.preempt_timeout_ms = CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE; /* Cap properties according to any system limits */ #define CLAMP_PROP(field) \
[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable YCbCr420 for VDSC (rev3)
== Series Details == Series: Enable YCbCr420 for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/109723/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109723v3_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_109723v3_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_109723v3_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (12 -> 11) -- Missing(1): shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_109723v3_full: ### IGT changes ### Possible regressions * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-tglb7/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/shard-tglb2/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_suspend@debugfs-reader: - shard-apl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/shard-apl7/igt@i915_susp...@debugfs-reader.html Warnings * igt@gem_pread@exhaustion: - shard-tglb: [WARN][4] ([i915#2658]) -> [INCOMPLETE][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-tglb2/igt@gem_pr...@exhaustion.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/shard-tglb7/igt@gem_pr...@exhaustion.html Known issues Here are the changes found in Patchwork_109723v3_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-skl: ([PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28]) -> ([PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [FAIL][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51]) ([i915#5032]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl6/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl9/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl9/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl9/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl7/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl7/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl10/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl10/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-skl10/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/shard-skl9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/shard-skl9/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/shard-skl9/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/shard-skl7/boot.html [33]:
Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/guc: Limit scheduling properties to avoid overflow
On 10/6/2022 2:38 PM, john.c.harri...@intel.com wrote:
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values and
then get confused by early timeouts, add limits when setting these
values.
v2: Add helper functions for clamping (review feedback from Tvrtko).
v3: Add a bunch of BUG_ON range checks in addition to the checks
already in the clamping functions (Tvrtko)
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio (v1)
r-b stands
Daniele
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h| 6 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 69 +++
drivers/gpu/drm/i915/gt/sysfs_engines.c | 25 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 21 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +++
5 files changed, 119 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 04e435bce79bd..cbc8b857d5f7a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -348,4 +348,10 @@ intel_engine_get_hung_context(struct intel_engine_cs
*engine)
return engine->hung_ce;
}
+u64 intel_clamp_heartbeat_interval_ms(struct intel_engine_cs *engine, u64 value);
+u64 intel_clamp_max_busywait_duration_ns(struct intel_engine_cs *engine, u64
value);
+u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs *engine, u64 value);
+u64 intel_clamp_stop_timeout_ms(struct intel_engine_cs *engine, u64 value);
+u64 intel_clamp_timeslice_duration_ms(struct intel_engine_cs *engine, u64
value);
+
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2ddcad497fa30..8f16955f0821e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -512,6 +512,26 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id,
engine->flags |= I915_ENGINE_HAS_EU_PRIORITY;
}
+ /* Cap properties according to any system limits */
+#define CLAMP_PROP(field) \
+ do { \
+ u64 clamp = intel_clamp_##field(engine, engine->props.field); \
+ if (clamp != engine->props.field) { \
+ drm_notice(>i915->drm, \
+ "Warning, clamping %s to %lld to prevent
overflow\n", \
+ #field, clamp); \
+ engine->props.field = clamp; \
+ } \
+ } while (0)
+
+ CLAMP_PROP(heartbeat_interval_ms);
+ CLAMP_PROP(max_busywait_duration_ns);
+ CLAMP_PROP(preempt_timeout_ms);
+ CLAMP_PROP(stop_timeout_ms);
+ CLAMP_PROP(timeslice_duration_ms);
+
+#undef CLAMP_PROP
+
engine->defaults = engine->props; /* never to change again */
engine->context_size = intel_engine_context_size(gt, engine->class);
@@ -534,6 +554,55 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id,
return 0;
}
+u64 intel_clamp_heartbeat_interval_ms(struct intel_engine_cs *engine, u64 value)
+{
+ value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+ return value;
+}
+
+u64 intel_clamp_max_busywait_duration_ns(struct intel_engine_cs *engine, u64
value)
+{
+ value = min(value, jiffies_to_nsecs(2));
+
+ return value;
+}
+
+u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs *engine, u64 value)
+{
+ /*
+* NB: The GuC API only supports 32bit values. However, the limit is
further
+* reduced due to internal calculations which would otherwise overflow.
+*/
+ if (intel_guc_submission_is_wanted(>gt->uc.guc))
+ value = min_t(u64, value, guc_policy_max_preempt_timeout_ms());
+
+ value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+ return value;
+}
+
+u64 intel_clamp_stop_timeout_ms(struct intel_engine_cs *engine, u64 value)
+{
+ value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+ return value;
+}
+
+u64 intel_clamp_timeslice_duration_ms(struct intel_engine_cs *engine, u64
value)
+{
+ /*
+* NB: The GuC API only supports 32bit values. However, the limit is
further
+* reduced due to internal calculations which would otherwise overflow.
+*/
+ if (intel_guc_submission_is_wanted(>gt->uc.guc))
+ value = min_t(u64, value, guc_policy_max_exec_quantum_ms());
+
+ value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+ return value;
+}
+
static void __setup_engine_capabilities(struct intel_engine_cs *engine)
{
struct
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915/uc: use different ggtt pin offsets for uc loads
On 10/12/2022 17:03, Daniele Ceraolo Spurio wrote:
Our current FW loading process is the same for all FWs:
- Pin FW to GGTT at the start of the ggtt->uc_fw node
- Load the FW
- Unpin
This worked because we didn't have a case where 2 FWs would be loaded on
the same GGTT at the same time. On MTL, however, this can happend if both
GTs are reset at the same time, so we can't pin everything in the same
spot and we need to use separate offset. For simplicity, instead of
calculating the exact required size, we reserve a 2MB slot for each fw.
v2: fail fetch if FW is > 2MBs, improve comments (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 30 +---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 13 ++
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index de2843dc1307..021290a26195 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -575,6 +575,17 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
err = firmware_request_nowarn(, uc_fw->file_selected.path, dev);
memcpy(_ideal, _fw->file_wanted, sizeof(file_ideal));
+ if (!err && fw->size > INTEL_UC_RSVD_GGTT_PER_FW) {
+ drm_err(>drm,
+ "%s firmware %s: size (%zuKB) exceeds max supported size
(%uKB)\n",
+ intel_uc_fw_type_repr(uc_fw->type),
uc_fw->file_selected.path,
+ fw->size / SZ_1K, INTEL_UC_RSVD_GGTT_PER_FW / SZ_1K);
+
+ /* try to find another blob to load */
+ release_firmware(fw);
+ err = -ENOENT;
+ }
+
/* Any error is terminal if overriding. Don't bother searching for
older versions */
if (err && intel_uc_fw_is_overridden(uc_fw))
goto fail;
@@ -677,14 +688,28 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
static u32 uc_fw_ggtt_offset(struct intel_uc_fw *uc_fw)
{
- struct i915_ggtt *ggtt = __uc_fw_to_gt(uc_fw)->ggtt;
+ struct intel_gt *gt = __uc_fw_to_gt(uc_fw);
+ struct i915_ggtt *ggtt = gt->ggtt;
struct drm_mm_node *node = >uc_fw;
+ u32 offset = uc_fw->type * INTEL_UC_RSVD_GGTT_PER_FW;
+
+ /*
+* To keep the math simple, we use 8MB for the root tile and 8MB for
+* the media one. This will need to be updated if we ever have more
+* than 1 media GT
+*/
+ BUILD_BUG_ON(INTEL_UC_FW_NUM_TYPES * INTEL_UC_RSVD_GGTT_PER_FW > SZ_8M);
+ GEM_BUG_ON(gt->type == GT_MEDIA && gt->info.id > 1);
+ if (gt->type == GT_MEDIA)
+ offset += SZ_8M;
This is all because render/media GTs share the same page tables? Regular
multi-tile is completely separate address spaces and can use a single
common address? Otherwise, it seems like 'offset = gt->info.id * 2M'
would be the generic solution and no reference to GT_MEDIA required. So
maybe add a quick comment to that effect?
GEM_BUG_ON(!drm_mm_node_allocated(node));
GEM_BUG_ON(upper_32_bits(node->start));
GEM_BUG_ON(upper_32_bits(node->start + node->size - 1));
+ GEM_BUG_ON(offset + uc_fw->obj->base.size > node->size);
+ GEM_BUG_ON(uc_fw->obj->base.size > INTEL_UC_RSVD_GGTT_PER_FW);
- return lower_32_bits(node->start);
+ return lower_32_bits(node->start + offset);
}
static void uc_fw_bind_ggtt(struct intel_uc_fw *uc_fw)
@@ -699,7 +724,6 @@ static void uc_fw_bind_ggtt(struct intel_uc_fw *uc_fw)
dummy->bi.pages = obj->mm.pages;
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
- GEM_BUG_ON(dummy->node_size > ggtt->uc_fw.size);
/* uc_fw->obj cache domains were not controlled across suspend */
if (i915_gem_object_has_struct_page(obj))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index cb586f7df270..7b3db41efa6e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -6,6 +6,7 @@
#ifndef _INTEL_UC_FW_H_
#define _INTEL_UC_FW_H_
+#include
#include
#include "intel_uc_fw_abi.h"
#include "intel_device_info.h"
@@ -114,6 +115,18 @@ struct intel_uc_fw {
(uc)->fw.file_selected.minor_ver, \
(uc)->fw.file_selected.patch_ver))
+/*
+ * When we load the uC binaries, we pin them in a reserved section at the top
of
+ * the GGTT, which is ~18 MBs. On multi-GT systems where the GTs share the
GGTT,
^^^ meaning only systems with a render GT + media GT as opposed to
regular multi-GT systems? Would be good to make that explicit either
here or above (or both).
John.
+ * we also need to make sure that each binary is pinned to a unique location
+ * during load, because the different GT
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add error-capture init warnings when needed
Agreed on all the others (as per my other reply to Tvrtko), but on that 2nd
last one:
On Mon, 2022-10-17 at 12:33 -0700, Harrison, John C wrote:
> On 10/14/2022 20:59, Alan Previn wrote:
> > If GuC is being used and we initialized GuC-error-capture,
> > we need to be warning if we don't provide an error-capture
> > register list in the firmware ADS, for valid GT engines.
> > A warning makes sense as this would impact debugability
> > without realizing why a reglist wasn't retrieved and reported
> > by GuC.
> >
> > + if (!guc_capture_get_one_list(gc->reglists, owner, type, classid)) {
> > + if (owner == GUC_CAPTURE_LIST_INDEX_PF && type ==
> > GUC_CAPTURE_LIST_TYPE_GLOBAL)
> > + drm_warn(>drm, "GuC-capture: missing reglist
> > type-Global\n");
> > + if (owner == GUC_CAPTURE_LIST_INDEX_PF)
> > + drm_warn(>drm, "GuC-capture: missing regiist
> > type(%d)-%s : "
> > +"%s(%d)-Engine\n", type,
> > __stringify_type(type),
> What Tvrtko is meaning here is to not split the string at all. You can
> ignore a line length warning message if the only alternatives are either
> to split the string or to obfuscate the code with unreadable/unnecessary
> construction methods.
>
>
I dont see how not splitting the string makes the grep work as per the reason
Tvrtko was bringing up... but sure,..
ignoring a checkpatch here is fine by me - as i do agree having a single line
is better to read.
...alan
Re: [Intel-gfx] [PATCH v7 00/21] Move all drivers to a common dma-buf locking convention
On 10/17/22 20:22, Dmitry Osipenko wrote: > Hello, > > This series moves all drivers to a dynamic dma-buf locking specification. > From now on all dma-buf importers are made responsible for holding > dma-buf's reservation lock around all operations performed over dma-bufs > in accordance to the locking specification. This allows us to utilize > reservation lock more broadly around kernel without fearing of a potential > deadlocks. > > This patchset passes all i915 selftests. It was also tested using VirtIO, > Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested cases > of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where appropriate), > which covers majority of kernel drivers since rest of the drivers share > same or similar code paths. > > Changelog: > > v7: - Rebased on top of recent drm-misc-next. > > - Added ack from Jason Gunthorpe to the RDMA patch. > > - Added iosys_map_clear() to dma_buf_vmap_unlocked(), making it fully > consistent with dma_buf_vmap(). > > v6: - Added r-b from Michael Ruhl to the i915 patch. > > - Added acks from Sumit Semwal and updated commit message of the > "Move dma_buf_vmap() to dynamic locking specification" patch like > was suggested by Sumit. > > - Added "!dmabuf" check to dma_buf_vmap_unlocked() to match the locked > variant of the function, for consistency. > > v5: - Added acks and r-bs that were given to v4. > > - Changed i915 preparation patch like was suggested by Michael Ruhl. > The scope of reservation locking is smaller now. > > v4: - Added dma_buf_mmap() to the "locking convention" documentation, > which was missed by accident in v3. > > - Added acks from Christian König, Tomasz Figa and Hans Verkuil that > they gave to couple v3 patches. > > - Dropped the "_unlocked" postfix from function names that don't have > the locked variant, as was requested by Christian König. > > - Factored out the per-driver preparations into separate patches > to ease reviewing of the changes, which is now doable without the > global dma-buf functions renaming. > > - Factored out the dynamic locking convention enforcements into separate > patches which add the final dma_resv_assert_held(dmabuf->resv) to the > dma-buf API functions. > > v3: - Factored out dma_buf_mmap_unlocked() and attachment functions > into aseparate patches, like was suggested by Christian König. > > - Corrected and factored out dma-buf locking documentation into > a separate patch, like was suggested by Christian König. > > - Intel driver dropped the reservation locking fews days ago from > its BO-release code path, but we need that locking for the imported > GEMs because in the end that code path unmaps the imported GEM. > So I added back the locking needed by the imported GEMs, updating > the "dma-buf attachment locking specification" patch appropriately. > > - Tested Nouveau+Intel dma-buf import/export combo. > > - Tested udmabuf import to i915/Nouveau/AMDGPU. > > - Fixed few places in Etnaviv, Panfrost and Lima drivers that I missed > to switch to locked dma-buf vmapping in the drm/gem: Take reservation > lock for vmap/vunmap operations" patch. In a result invalidated the > Christian's r-b that he gave to v2. > > - Added locked dma-buf vmap/vunmap functions that are needed for fixing > vmappping of Etnaviv, Panfrost and Lima drivers mentioned above. > I actually had this change stashed for the drm-shmem shrinker patchset, > but then realized that it's already needed by the dma-buf patches. > Also improved my tests to better cover these code paths. > > v2: - Changed locking specification to avoid problems with a cross-driver > ww locking, like was suggested by Christian König. Now the attach/detach > callbacks are invoked without the held lock and exporter should take the > lock. > > - Added "locking convention" documentation that explains which dma-buf > functions and callbacks are locked/unlocked for importers and exporters, > which was requested by Christian König. > > - Added ack from Tomasz Figa to the V4L patches that he gave to v1. > > Dmitry Osipenko (21): > dma-buf: Add unlocked variant of vmapping functions > dma-buf: Add unlocked variant of attachment-mapping functions > drm/gem: Take reservation lock for vmap/vunmap operations > drm/prime: Prepare to dynamic dma-buf locking specification > drm/armada: Prepare to dynamic dma-buf locking specification > drm/i915: Prepare to dynamic dma-buf locking specification > drm/omapdrm: Prepare to dynamic dma-buf locking specification > drm/tegra: Prepare to dynamic dma-buf locking specification > drm/etnaviv: Prepare to dynamic dma-buf locking specification > RDMA/umem: Prepare to dynamic dma-buf locking specification > misc: fastrpc: Prepare
[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_driver.c
between commit:
1c66a12ab431 ("drm/i915: Handle each GT on init/release and suspend/resume")
from Linus' tree and commit:
3703060d17b0 ("drm/i915/display: remove drm_device aliases")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/i915_driver.c
index c459eb362c47,e7b2ebc6b88d..
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@@ -337,10 -324,11 +337,11 @@@ static int i915_driver_early_probe(stru
if (i915_inject_probe_failure(dev_priv))
return -ENODEV;
- intel_device_info_subplatform_init(dev_priv);
+ intel_device_info_runtime_init_early(dev_priv);
+
intel_step_init(dev_priv);
- intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
+ intel_uncore_mmio_debug_init_early(dev_priv);
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->gpu_error.lock);
@@@ -738,10 -716,6 +739,9 @@@ static void i915_driver_hw_remove(struc
*/
static void i915_driver_register(struct drm_i915_private *dev_priv)
{
- struct drm_device *dev = _priv->drm;
+ struct intel_gt *gt;
+ unsigned int i;
+
i915_gem_driver_register(dev_priv);
i915_pmu_register(dev_priv);
pgplm44y4DCep.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add DG2 OA support (rev7)
== Series Details ==
Series: Add DG2 OA support (rev7)
URL : https://patchwork.freedesktop.org/series/107584/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
CC [M] drivers/gpu/drm/i915/i915_perf.o
In file included from drivers/gpu/drm/i915/i915_perf.c:207:
drivers/gpu/drm/i915/i915_perf.c: In function ‘gen12_enable_metric_set’:
drivers/gpu/drm/i915/gt/intel_gt_regs.h:11:25: error: incompatible type for
argument 2 of ‘intel_uncore_write’
#define MCR_REG(offset) ((const i915_mcr_reg_t){ .reg = (offset) })
^~~
drivers/gpu/drm/i915/gt/intel_gt_regs.h:1150:28: note: in expansion of macro
‘MCR_REG’
#define GEN8_ROW_CHICKEN MCR_REG(0xe4f0)
^~~
drivers/gpu/drm/i915/i915_perf.c:2798:30: note: in expansion of macro
‘GEN8_ROW_CHICKEN’
intel_uncore_write(uncore, GEN8_ROW_CHICKEN,
^~~~
In file included from ./drivers/gpu/drm/i915/gt/intel_engine_types.h:26,
from ./drivers/gpu/drm/i915/gt/intel_context_types.h:18,
from drivers/gpu/drm/i915/gem/i915_gem_context_types.h:20,
from drivers/gpu/drm/i915/gem/i915_gem_context.h:10,
from drivers/gpu/drm/i915/i915_perf.c:198:
./drivers/gpu/drm/i915/intel_uncore.h:353:18: note: expected ‘i915_reg_t’ {aka
‘struct ’} but argument is of type ‘i915_mcr_reg_t’ {aka ‘const
struct ’}
i915_reg_t reg, u##x__ val) \
~~~^~~
./drivers/gpu/drm/i915/intel_uncore.h:366:1: note: in expansion of macro
‘__uncore_write’
__uncore_write(write, 32, l, true)
^~
In file included from drivers/gpu/drm/i915/i915_perf.c:207:
drivers/gpu/drm/i915/i915_perf.c: In function ‘gen12_disable_metric_set’:
drivers/gpu/drm/i915/gt/intel_gt_regs.h:11:25: error: incompatible type for
argument 2 of ‘intel_uncore_write’
#define MCR_REG(offset) ((const i915_mcr_reg_t){ .reg = (offset) })
^~~
drivers/gpu/drm/i915/gt/intel_gt_regs.h:1150:28: note: in expansion of macro
‘MCR_REG’
#define GEN8_ROW_CHICKEN MCR_REG(0xe4f0)
^~~
drivers/gpu/drm/i915/i915_perf.c:2887:30: note: in expansion of macro
‘GEN8_ROW_CHICKEN’
intel_uncore_write(uncore, GEN8_ROW_CHICKEN,
^~~~
In file included from ./drivers/gpu/drm/i915/gt/intel_engine_types.h:26,
from ./drivers/gpu/drm/i915/gt/intel_context_types.h:18,
from drivers/gpu/drm/i915/gem/i915_gem_context_types.h:20,
from drivers/gpu/drm/i915/gem/i915_gem_context.h:10,
from drivers/gpu/drm/i915/i915_perf.c:198:
./drivers/gpu/drm/i915/intel_uncore.h:353:18: note: expected ‘i915_reg_t’ {aka
‘struct ’} but argument is of type ‘i915_mcr_reg_t’ {aka ‘const
struct ’}
i915_reg_t reg, u##x__ val) \
~~~^~~
./drivers/gpu/drm/i915/intel_uncore.h:366:1: note: in expansion of macro
‘__uncore_write’
__uncore_write(write, 32, l, true)
^~
scripts/Makefile.build:250: recipe for target
'drivers/gpu/drm/i915/i915_perf.o' failed
make[5]: *** [drivers/gpu/drm/i915/i915_perf.o] Error 1
scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm/i915' failed
make[4]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm' failed
make[3]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/gpu' failed
make[2]: *** [drivers/gpu] Error 2
scripts/Makefile.build:500: recipe for target 'drivers' failed
make[1]: *** [drivers] Error 2
Makefile:1992: recipe for target '.' failed
make: *** [.] Error 2
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Analog TV Improvements (rev5)
== Series Details == Series: drm: Analog TV Improvements (rev5) URL : https://patchwork.freedesktop.org/series/107892/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/107892/revisions/5/mbox/ not applied Applying: drm/tests: Add Kunit Helpers Applying: drm/connector: Rename legacy TV property Using index info to reconstruct a base tree... M drivers/gpu/drm/i2c/ch7006_drv.c M drivers/gpu/drm/i915/display/intel_tv.c M include/drm/drm_connector.h Falling back to patching base and 3-way merge... Auto-merging include/drm/drm_connector.h Auto-merging drivers/gpu/drm/i915/display/intel_tv.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_tv.c Auto-merging drivers/gpu/drm/i2c/ch7006_drv.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 drm/connector: Rename legacy TV property 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".
[Intel-gfx] ✗ Fi.CI.IGT: failure for Defeature Interlace modes for Display >= 12
== Series Details == Series: Defeature Interlace modes for Display >= 12 URL : https://patchwork.freedesktop.org/series/109773/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109773v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_109773v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_109773v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (12 -> 11) -- Missing(1): shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_109773v1_full: ### IGT changes ### Possible regressions * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-tglb7/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/shard-tglb2/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_suspend@debugfs-reader: - shard-apl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/shard-apl1/igt@i915_susp...@debugfs-reader.html Known issues Here are the changes found in Patchwork_109773v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-snb: ([PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [FAIL][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28]) ([i915#4338]) -> ([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], [PASS][50], [PASS][51], [PASS][52], [PASS][53]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/shard-snb7/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/shard-snb7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/shard-snb7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/shard-snb7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/shard-snb7/boot.html [34]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace kmap() with kmap_local_page() (rev2)
== Series Details == Series: drm/i915: Replace kmap() with kmap_local_page() (rev2) URL : https://patchwork.freedesktop.org/series/107277/ State : success == Summary == CI Bug Log - changes from CI_DRM_12252 -> Patchwork_107277v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/index.html Participating hosts (46 -> 43) -- Additional (1): fi-icl-u2 Missing(4): fi-bxt-dsi fi-cfl-8700k bat-atsm-1 fi-bdw-samus Known issues Here are the changes found in Patchwork_107277v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12252/fi-pnv-d510/igt@gem_exec_gttf...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.html * igt@gem_linear_blits@basic: - fi-pnv-d510:[PASS][3] -> [SKIP][4] ([fdo#109271]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12252/fi-pnv-d510/igt@gem_linear_bl...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/fi-pnv-d510/igt@gem_linear_bl...@basic.html * igt@runner@aborted: - fi-icl-u2: NOTRUN -> [FAIL][5] ([i915#7220]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/fi-icl-u2/igt@run...@aborted.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#7220]: https://gitlab.freedesktop.org/drm/intel/issues/7220 [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229 Build changes - * Linux: CI_DRM_12252 -> Patchwork_107277v2 CI-20190529: 20190529 CI_DRM_12252: 14867082ef288af10c90732e31b633af30e304c0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7017: 193c8bdd7df32556129482c52011e1b7a233b699 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_107277v2: 14867082ef288af10c90732e31b633af30e304c0 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 83c34dd3b2a2 drm/i915/gem: Replace kmap() with kmap_local_page() ade39e0c9963 drm/i915/gt: Replace kmap() with kmap_local_page() cd89efceb13c drm/i915: Replace kmap() with kmap_local_page() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Replace kmap() with kmap_local_page() (rev2)
== Series Details == Series: drm/i915: Replace kmap() with kmap_local_page() (rev2) URL : https://patchwork.freedesktop.org/series/107277/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 3/3] drm/i915/mtl: C6 residency and C state type for MTL SAMedia
On Fri, 14 Oct 2022 20:26:18 -0700, Ashutosh Dixit wrote:
>
> From: Badal Nilawar
Hi Badal,
One question below.
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> index 1fb053cbf52db..3a9bb4387248e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> @@ -256,6 +256,61 @@ static int ilk_drpc(struct seq_file *m)
> return 0;
> }
>
> +static int mtl_drpc(struct seq_file *m)
> +{
Here we have:
> + global_forcewake = intel_uncore_read(uncore, FORCEWAKE_GT_GEN9);
and
> + seq_printf(m, "Global Forcewake Requests: 0x%x\n", global_forcewake);
In gen6_drpc we have:
mt_fwake_req = intel_uncore_read_fw(uncore, FORCEWAKE_MT);
and
seq_printf(m, "Multi-threaded Forcewake Request: 0x%x\n", mt_fwake_req);
Also:
#define FORCEWAKE_MT_MMIO(0xa188)
#define FORCEWAKE_GT_GEN9 _MMIO(0xa188)
So they are both the same register. So what is the reason for this
difference, which one should we use?
Also let's have the prints in the same order as gen6_drpc (move fw request
before rc6 residency).
Thanks.
--
Ashutosh
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Extend Wa_1607297627 to Alderlake-P
== Series Details == Series: drm/i915: Extend Wa_1607297627 to Alderlake-P URL : https://patchwork.freedesktop.org/series/109772/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109772v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_109772v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_109772v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (12 -> 12) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_109772v1_full: ### IGT changes ### Possible regressions * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-tglb7/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/shard-tglb5/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_suspend@debugfs-reader: - shard-apl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/shard-apl3/igt@i915_susp...@debugfs-reader.html Warnings * igt@gem_eio@in-flight-suspend: - shard-apl: [INCOMPLETE][4] ([i915#7112]) -> [INCOMPLETE][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl2/igt@gem_...@in-flight-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/shard-apl6/igt@gem_...@in-flight-suspend.html Known issues Here are the changes found in Patchwork_109772v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-apl: ([PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29]) -> ([PASS][30], [PASS][31], [PASS][32], [FAIL][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], [PASS][50], [PASS][51], [PASS][52], [PASS][53]) ([i915#4386]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl8/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl7/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/shard-apl7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/shard-apl1/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/shard-apl2/boot.html
Re: [Intel-gfx] [PATCH] drm/edid/firmware: stop using throwaway platform device
By crash, I mean that an error is returned here: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git/+/refs/heads/master/drivers/gpu/drm/drm_edid_load.c#195 I don't really know what happens next, but on my machine the built-in screen and the external remains dark. Also the kernel seems to freeze. I suspect a kernel panic, but I'm not sure. Anyway, the error is definitely not well handled, and a fix would be great. Also, request_firmware() will crash if called for the first time on the resume path because the file system isn't reachable on the resume process. And no cache is available for this firmware. So I guess that in this case, request_firmware() returns an error. Suspend-plug-resume case is not my priority nether as long as it doesn't make the system crash (Which is currently the case). On Wed, Oct 12 2022 at 11:25:59 AM +0300, Jani Nikula wrote: On Tue, 11 Oct 2022, Matthieu CHARETTE wrote: Currently the EDID is requested during the resume. But since it's requested too early, this means before the filesystem is mounted, the firmware request fails. This make the DRM driver crash when resuming. This kind of issue should be prevented by the firmware caching process which cache every firmware requested for the next resume. But since we are using a temporary device, the firmware isn't cached on suspend since the device doesn't work anymore. When using a non temporary device to get the EDID, the firmware will be cached on suspend for the next resume. So requesting the firmware during resume will succeed. But if the firmware has never been requested since the boot, this means that the monitor isn't plugged since the boot. The kernel will not be caching the EDID. So if we plug the monitor while the machine is suspended. The resume will fail to load the firmware. And the DRM driver will crash. So basically, your fix should solve the issue except for the case where the monitor hasn't been plugged since boot and is plugged while the machine is suspended. I hope I was clear. Tell me if I wasn't. I'm not really good at explaining. That was a pretty good explanation. The only thing I'm missing is what the failure mode is exactly when you claim the driver will crash. Why would request_firmware() "crash" if called for the first time on the resume path? I'm not sure I care much about not being able to load the firmware EDID in the suspend-plug-resume case (as this can be remedied with a subsequent modeset), but obviously any errors need to be handled gracefully, without crashing. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v5 19/22] drm/vc4: vec: Check for VEC output constraints
Hi Maxime,
Sorry about the mess that happened to the previous message. I hope this one
will be delivered more cleanly.
W dniu 13.10.2022 o 15:19, Maxime Ripard pisze:
> From: Mateusz Kwiatkowski
>
> The VEC can accept pretty much any relatively reasonable mode, but still
> has a bunch of constraints to meet.
>
> Let's create an atomic_check() implementation that will make sure we
> don't end up accepting a non-functional mode.
>
> Acked-by: Noralf Trønnes
> Signed-off-by: Mateusz Kwiatkowski
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_vec.c | 48
>+++
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index 90e375a8a8f9..1fcb7baf874e 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -453,6 +453,7 @@ static int vc4_vec_encoder_atomic_check(struct
> drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state *conn_state)
> {
> + const struct drm_display_mode *mode = _state->adjusted_mode;
> const struct vc4_vec_tv_mode *vec_mode;
>
> vec_mode = _vec_tv_modes[conn_state->tv.legacy_mode];
> @@ -461,6 +462,53 @@ static int vc4_vec_encoder_atomic_check(struct
> drm_encoder *encoder,
> !drm_mode_equal(vec_mode->mode, _state->adjusted_mode))
> return -EINVAL;
>
> + if (mode->crtc_hdisplay % 4)
> + return -EINVAL;
> +
> + if (!(mode->crtc_hsync_end - mode->crtc_hsync_start))
> + return -EINVAL;
> +
> + switch (mode->vtotal) {
> + case 525:
> + if (mode->crtc_vtotal > 262)
> + return -EINVAL;
> +
> + if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay > 253)
> + return -EINVAL;
> +
> + if (!(mode->crtc_vsync_start - mode->crtc_vdisplay))
> + return -EINVAL;
> +
> + if ((mode->crtc_vsync_end - mode->crtc_vsync_start) != 3)
> + return -EINVAL;
> +
> + if ((mode->crtc_vtotal - mode->crtc_vsync_end) < 4)
> + return -EINVAL;
> +
> + break;
> +
> + case 625:
> + if (mode->crtc_vtotal > 312)
> + return -EINVAL;
> +
> + if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay > 305)
> + return -EINVAL;
> +
> + if (!(mode->crtc_vsync_start - mode->crtc_vdisplay))
> + return -EINVAL;
> +
> + if ((mode->crtc_vsync_end - mode->crtc_vsync_start) != 3)
> + return -EINVAL;
> +
> + if ((mode->crtc_vtotal - mode->crtc_vsync_end) < 2)
> + return -EINVAL;
> +
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> return 0;
> }
>
>
In my original version of this function
(https://github.com/raspberrypi/linux/pull/4406/files) the switch is over
reference_mode->vtotal, not mode->vtotal. This was intended to explicitly allow
a different value of mode->vtotal, to support non-standard modes, such as "fake"
525 lines with SECAM encoding, or the progressive modes.
You're switching over mode->vtotal, which makes specifying those impossible.
I don't think we should limit the users like that.
We're removing reference_mode in patch 20/22, so adding a switch over
reference_mode->vtotal is probably not a good idea -- in that case I'd switch
over mode->htotal instead: 858 for "NTSC" and 864 for "PAL". This may seem a bit
weird, but any other value of htotal causes the VEC to output garbage anyway.
Best regards,
Mateusz Kwiatkowski
[Intel-gfx] [PATCH] drm/vc4: vec: Add support for PAL-60
Add support for the PAL-60 mode. Because there is no separate TV mode
property value for PAL-60, this requires matching the settings based on
the modeline in addition to just that property alone.
Signed-off-by: Mateusz Kwiatkowski
---
This patch depends on patch
'[PATCH v5 21/22] drm/vc4: vec: Add support for more analog TV standards'
submitted by Maxime Ripard
(https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v5-21-d841cc64f...@cerno.tech/).
To Maxime: if you decide to post v6, feel free to include this in your patchset
instead if you want.
---
drivers/gpu/drm/vc4/vc4_vec.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 88b4330bfa39..bbc41e502cc3 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -235,6 +235,7 @@ enum vc4_vec_tv_mode_id {
struct vc4_vec_tv_mode {
unsigned int mode;
+ u16 expected_htotal;
u32 config0;
u32 config1;
u32 custom_freq;
@@ -270,37 +271,52 @@ static const struct debugfs_reg32 vec_regs[] = {
static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
{
.mode = DRM_MODE_TV_MODE_NTSC,
+ .expected_htotal = 858,
.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
{
.mode = DRM_MODE_TV_MODE_NTSC_443,
+ .expected_htotal = 858,
.config0 = VEC_CONFIG0_NTSC_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
.custom_freq = 0x2a098acb,
},
{
.mode = DRM_MODE_TV_MODE_NTSC_J,
+ .expected_htotal = 858,
.config0 = VEC_CONFIG0_NTSC_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
{
.mode = DRM_MODE_TV_MODE_PAL,
+ .expected_htotal = 864,
.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
+ {
+ /* PAL-60 */
+ .mode = DRM_MODE_TV_MODE_PAL,
+ .expected_htotal = 858,
+ .config0 = VEC_CONFIG0_PAL_M_STD,
+ .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
+ .custom_freq = 0x2a098acb,
+ },
{
.mode = DRM_MODE_TV_MODE_PAL_M,
+ .expected_htotal = 858,
.config0 = VEC_CONFIG0_PAL_M_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
{
.mode = DRM_MODE_TV_MODE_PAL_N,
+ .expected_htotal = 864,
.config0 = VEC_CONFIG0_PAL_N_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
{
.mode = DRM_MODE_TV_MODE_SECAM,
+ .expected_htotal = 864,
.config0 = VEC_CONFIG0_SECAM_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
.custom_freq = 0x29c71c72,
@@ -308,14 +324,15 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
};
static inline const struct vc4_vec_tv_mode *
-vc4_vec_tv_mode_lookup(unsigned int mode)
+vc4_vec_tv_mode_lookup(unsigned int mode, u16 htotal)
{
unsigned int i;
for (i = 0; i < ARRAY_SIZE(vc4_vec_tv_modes); i++) {
const struct vc4_vec_tv_mode *tv_mode = _vec_tv_modes[i];
- if (tv_mode->mode == mode)
+ if (tv_mode->mode == mode &&
+ tv_mode->expected_htotal == htotal)
return tv_mode;
}
@@ -394,6 +411,7 @@ vc4_vec_connector_set_property(struct drm_connector
*connector,
break;
case VC4_VEC_TV_MODE_PAL:
+ case VC4_VEC_TV_MODE_PAL_60:
state->tv.mode = DRM_MODE_TV_MODE_PAL;
break;
@@ -551,13 +569,16 @@ static void vc4_vec_encoder_enable(struct drm_encoder
*encoder,
struct drm_connector *connector = >connector;
struct drm_connector_state *conn_state =
drm_atomic_get_new_connector_state(state, connector);
+ struct drm_display_mode *adjusted_mode =
+ >crtc->state->adjusted_mode;
const struct vc4_vec_tv_mode *tv_mode;
int idx, ret;
if (!drm_dev_enter(drm, ))
return;
- tv_mode = vc4_vec_tv_mode_lookup(conn_state->tv.mode);
+ tv_mode = vc4_vec_tv_mode_lookup(conn_state->tv.mode,
+adjusted_mode->htotal);
if (!tv_mode)
goto err_dev_exit;
base-commit: e16415e3ddae9abb14a00793554a162403f9af6d
--
2.34.1
Re: [Intel-gfx] [PATCH v5 21/22] drm/vc4: vec: Add support for more analog TV standards
Hi Maxime, W dniu 13.10.2022 o 15:19, Maxime Ripard pisze: > From: Mateusz Kwiatkowski > > Add support for the following composite output modes (all of them are > somewhat more obscure than the previously defined ones): > > - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to > 4.43361875 MHz (the PAL subcarrier frequency). Never used for > broadcasting, but sometimes used as a hack to play NTSC content in PAL > regions (e.g. on VCRs). > - PAL_N - PAL with alternative chroma subcarrier frequency, > 3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay > and Uruguay to fit 576i50 with colour in 6 MHz channel raster. > - PAL60 - 480i60 signal with PAL-style color at normal European PAL > frequency. Another non-standard, non-broadcast mode, used in similar > contexts as NTSC_443. Some displays support one but not the other. The current version actually does not support PAL-60. Proper PAL-60 output from VEC requires configuring it differently than for regular PAL. We have unified the PAL and PAL-60 modes for the "TV mode" property, but the code here has not been adjusted appropriately. I'll try to submit an additional patch that fixes this shortly. > - SECAM - French frequency-modulated analog color standard; also have > been broadcast in Eastern Europe and various parts of Africa and Asia. > Uses the same 576i50 timings as PAL. > > Also added some comments explaining color subcarrier frequency > registers. > > Acked-by: Noralf Trønnes > Signed-off-by: Mateusz Kwiatkowski > Signed-off-by: Maxime Ripard > --- (snip) Best regards, Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v5 20/22] drm/vc4: vec: Convert to the new TV mode property
Hi Maxime,
Urgh. I cannot send e-mails apparently today, as I removed the second half of
the previous message. Here goes:
> @@ -454,13 +563,6 @@ static int vc4_vec_encoder_atomic_check(struct
> drm_encoder *encoder,
> struct drm_connector_state *conn_state)
> {
> const struct drm_display_mode *mode = _state->adjusted_mode;
You could add here something like:
+ const struct vc4_vec_tv_mode *tv_mode =
+ vc4_vec_tv_mode_lookup(conn_state->tv.mode);
+
+ if (!tv_mode)
+ return -EINVAL;
This should explicitly make it impossible to enter the equivalent condition in
vc4_vec_encoder_enable() that causes the problem mentioned in the previous
e-mail.
This is probably basically impossible already, but I triggered that when testing
a follow-up change I'd like to post shortly.
> - const struct vc4_vec_tv_mode *vec_mode;
> -
> - vec_mode = _vec_tv_modes[conn_state->tv.legacy_mode];
> -
> - if (conn_state->crtc &&
> - !drm_mode_equal(vec_mode->mode, _state->adjusted_mode))
> - return -EINVAL;
If you're removing the reference mode, then I think you should at least add
checks that the crtc_clock is set to 13.5 MHz (it's otherwise ignored) and that
crtc_htotal is either 858 or 864 (using a switch over reference_mode->htotal as
I proposed in my comment to patch 19/22 would double as such check), as all
other values causes VEC to output garbage.
Best regards,
Mateusz Kwiatkowski
[Intel-gfx] [RESEND PATCH 1/3] drm/i915: Replace kmap() with kmap_local_page()
kmap() is being deprecated in favor of kmap_local_page(). There are two main problems with kmap(): (1) It comes with an overhead as mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and are still valid. Since its use in i915_gem.c is safe everywhere, it should be preferred. Therefore, replace kmap() with kmap_local_page() in i915_gem.c Cc: "Venkataramanan, Anirudh" Suggested-by: Ira Weiny Signed-off-by: Fabio M. De Francesco --- drivers/gpu/drm/i915/i915_gem.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 702e5b89be22..43effce60e1b 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -212,14 +212,14 @@ shmem_pread(struct page *page, int offset, int len, char __user *user_data, char *vaddr; int ret; - vaddr = kmap(page); + vaddr = kmap_local_page(page); if (needs_clflush) drm_clflush_virt_range(vaddr + offset, len); ret = __copy_to_user(user_data, vaddr + offset, len); - kunmap(page); + kunmap_local(vaddr); return ret ? -EFAULT : 0; } @@ -634,7 +634,7 @@ shmem_pwrite(struct page *page, int offset, int len, char __user *user_data, char *vaddr; int ret; - vaddr = kmap(page); + vaddr = kmap_local_page(page); if (needs_clflush_before) drm_clflush_virt_range(vaddr + offset, len); @@ -643,7 +643,7 @@ shmem_pwrite(struct page *page, int offset, int len, char __user *user_data, if (!ret && needs_clflush_after) drm_clflush_virt_range(vaddr + offset, len); - kunmap(page); + kunmap_local(vaddr); return ret ? -EFAULT : 0; } -- 2.37.1
Re: [Intel-gfx] [PATCH] drm/edid/firmware: stop using throwaway platform device
It should fix the issue. Meanwhile, the system will still crash if a
new monitor is plugged while the machine is suspended. We might need to
precache the EDID to prevent that.
Matthieu
On Fri, Oct 7 2022 at 01:21:46 AM +0300, Jani Nikula
wrote:
We've used a temporary platform device for firmware EDID loading since
it was introduced in commit da0df92b5731 ("drm: allow loading an EDID
as
firmware to override broken monitor"), but there's no explanation why.
Do we need to?
Maybe this fixes the suspend/resume issue?
(Yes, I'll rewrite the commit message if this is the way to go ;)
References:
https://lore.kernel.org/r/20220727074152.43059-1-matthieu.chare...@gmail.com
Cc: Matthieu CHARETTE
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid_load.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c
b/drivers/gpu/drm/drm_edid_load.c
index 37d8ba3ddb46..fbae12130234 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -182,18 +182,9 @@ static void *edid_load(struct drm_connector
*connector, const char *name,
fwdata = generic_edid[builtin];
fwsize = sizeof(generic_edid[builtin]);
} else {
- struct platform_device *pdev;
int err;
- pdev = platform_device_register_simple(connector_name, -1, NULL,
0);
- if (IS_ERR(pdev)) {
- DRM_ERROR("Failed to register EDID firmware platform device
"
- "for connector \"%s\"\n", connector_name);
- return ERR_CAST(pdev);
- }
-
- err = request_firmware(, name, >dev);
- platform_device_unregister(pdev);
+ err = request_firmware(, name, connector->dev->dev);
if (err) {
DRM_ERROR("Requesting EDID firmware \"%s\" failed
(err=%d)\n",
name, err);
--
2.34.1
Re: [Intel-gfx] [PATCH v5 13/22] drm/modes: Introduce the tv_mode property as a command-line option
Hi Maxime, Noralf & everyone,
I'd like to address Noralf here in particular, and refer to these discussions
from the past:
-
https://lore.kernel.org/linux-arm-kernel/2f607c7d-6da1-c8df-1c02-8dd344a92...@gmail.com/
-
https://lore.kernel.org/linux-arm-kernel/9e76a508-f469-a54d-ecd7-b5868ca99...@tronnes.org/
> @@ -2230,20 +2256,22 @@ struct drm_named_mode {
> unsigned int xres;
> unsigned int yres;
> unsigned int flags;
> + unsigned int tv_mode;
> };
I saw that you (Noralf) opposed my suggestion about the DRM_MODE_TV_MODE_NONE
enum value in enum drm drm_connector_tv_mode. I get your argumentation, and I'm
not gonna argue, but I still don't like the fact that struct drm_named_mode now
includes a field that is only relevant for analog TV modes, has no "none" value,
and yet the type is supposed to be generic enough to be usable for other types
of outputs as well.
It's true that it can just be ignored (as Maxime mentioned in his response to
my e-mail linked above), and now the value of 0 corresponds to
DRM_MODE_TV_MODE_NTSC, which is a rather sane default, but it still feels messy
to me.
I'm not gonna force my opinion here, but I wanted to bring your attention to
this issue, maybe you have some other solution in mind for this problem. Or if
you don't see that as a problem at all, that's fine, too.
Best regards,
Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v5 19/22] drm/vc4: vec: Check for VEC output constraints
Hi Maxime,
W dniu 13.10.2022 o 15:19, Maxime Ripard pisze:
> From: Mateusz Kwiatkowski > > The VEC can accept pretty much any relatively
> reasonable mode, but still > has a bunch of constraints to meet. > > Let's
> create an atomic_check() implementation that will make sure we > don't end up
> accepting a non-functional mode. > > Acked-by: Noralf Trønnes >
> Signed-off-by: Mateusz Kwiatkowski > Signed-off-by: Maxime Ripard > --- >
> drivers/gpu/drm/vc4/vc4_vec.c | 48
> +++ > 1 file changed, 48
> insertions(+) > > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c
> b/drivers/gpu/drm/vc4/vc4_vec.c > index 90e375a8a8f9..1fcb7baf874e 100644 >
> --- a/drivers/gpu/drm/vc4/vc4_vec.c > +++ b/drivers/gpu/drm/vc4/vc4_vec.c >
> @@ -453,6 +453,7 @@ static int vc4_vec_encoder_atomic_check(struct
> drm_encoder *encoder, > struct drm_crtc_state *crtc_state, > struct
> drm_connector_state *conn_state) > { > + const struct drm_display_mode *mode
> = _state->adjusted_mode; > const struct vc4_vec_tv_mode *vec_mode; > >
> vec_mode =
_vec_tv_modes[conn_state->tv.legacy_mode]; > @@ -461,6 +462,53 @@ static
int vc4_vec_encoder_atomic_check(struct drm_encoder *encoder, >
!drm_mode_equal(vec_mode->mode, _state->adjusted_mode)) > return -EINVAL;
> > + if (mode->crtc_hdisplay % 4) > + return -EINVAL; > + > + if
(!(mode->crtc_hsync_end - mode->crtc_hsync_start)) > + return -EINVAL; > + > +
switch (mode->vtotal) { > + case 525: > + if (mode->crtc_vtotal > 262) > +
return -EINVAL; > + > + if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay >
253) > + return -EINVAL; > + > + if (!(mode->crtc_vsync_start -
mode->crtc_vdisplay)) > + return -EINVAL; > + > + if ((mode->crtc_vsync_end -
mode->crtc_vsync_start) != 3) > + return -EINVAL; > + > + if
((mode->crtc_vtotal - mode->crtc_vsync_end) < 4) > + return -EINVAL; > + > +
break; > + > + case 625: > + if (mode->crtc_vtotal > 312) > + return -EINVAL; >
+ > + if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay > 305) > + return
-EINVAL; > + > + if
(!(mode->crtc_vsync_start - mode->crtc_vdisplay)) > + return -EINVAL; > + > +
if ((mode->crtc_vsync_end - mode->crtc_vsync_start) != 3) > + return -EINVAL; >
+ > + if ((mode->crtc_vtotal - mode->crtc_vsync_end) < 2) > + return -EINVAL; >
+ > + break; > + > + default: > + return -EINVAL; > + } > + > return 0; > } In
my original version of this function
(https://github.com/raspberrypi/linux/pull/4406/files) the switch is over
reference_mode->vtotal, not mode->vtotal. This was intended to explicitly allow
a different value of mode->vtotal, to support non-standard modes, such as
"fake" 525 lines with SECAM encoding, or the progressive modes. You're
switching over mode->vtotal, which makes specifying those impossible. I don't
think we should limit the users like that. We're removing reference_mode in
patch 20/22, so adding a switch over reference_mode->vtotal is probably not a
good idea -- in that case I'd switch over mode->htotal instead: 858 for "NTSC"
and 864 for "PAL". This
may seem a bit weird, but any other value of htotal causes the VEC to output
garbage anyway. Best regards, Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v5 22/22] drm/sun4i: tv: Convert to the new TV mode property
Dne petek, 14. oktober 2022 ob 09:38:10 CEST je Maxime Ripard napisal(a):
> Hi Jernej,
>
> On Thu, Oct 13, 2022 at 08:23:51PM +0200, Jernej Škrabec wrote:
> > Dne četrtek, 13. oktober 2022 ob 15:19:06 CEST je Maxime Ripard
napisal(a):
> > > Now that the core can deal fine with analog TV modes, let's convert the
> > > sun4i TV driver to leverage those new features.
> > >
> > > Acked-by: Noralf Trønnes
> > > Signed-off-by: Maxime Ripard
> > >
> > > ---
> > > Changes in v5:
> > > - Removed the count variable in get_modes
> > > - Removed spurious vc4 change
> > > ---
> > >
> > > drivers/gpu/drm/sun4i/sun4i_tv.c | 145
> > >
> > > +-- 1 file changed, 48
> > > insertions(+),
> > > 97 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
> > > b/drivers/gpu/drm/sun4i/sun4i_tv.c index c65f0a89b6b0..4f07aff11551
> > > 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> > > @@ -141,23 +141,14 @@ struct resync_parameters {
> > >
> > > struct tv_mode {
> > >
> > > char*name;
> > >
> > > + unsigned inttv_mode;
> > > +
> > >
> > > u32 mode;
> > > u32 chroma_freq;
> > > u16 back_porch;
> > > u16 front_porch;
> > >
> > > - u16 line_number;
> > >
> > > u16 vblank_level;
> >
> > isn't there a way to get or calculate back_porch, front_porch and
> > vblank_level from mode? From quick glance over removed values below, I
> > would say that at least back_porch can be removed too?
>
> I tried actually, but I'm not sure what the front porch and back porch
> parameters actually are. They are called that way by Allwinner, but it
> doesn't match the PAL or NTSC timings at all.
>
> For example, back_porch is 118 for NTSC and 138 for PAL. Actual back
> porches would be around 12 and 16, respectively. Actually, the entire
> blanking area are 138 and 144. This is close enough for PAL, but pretty
> far off for NTSC.
>
> Allwinner has the habit of integrating the sync period into one of the
> porches, but still there's no obvious match.
>
> front_porch is pretty much in the same case.
Ok then.
>
> Since it affected the display output quite a lot, I chose to keep it for
> now unfortunately.
>
> > Otherwise this patch looks ok.
>
> Can I add your Acked-by/Reviewed-by then?
Sure.
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
Re: [Intel-gfx] [PATCH v5 06/22] drm/modes: Add a function to generate analog display modes
Hi Maxime & everyone,
Sorry for being inactive in the discussions about this patchset for the last
couple of weeks.
> +const static struct analog_parameters tv_modes_parameters[] = {
> + TV_MODE_PARAMETER(DRM_MODE_ANALOG_NTSC,
> + NTSC_LINES_NUMBER,
> + NTSC_LINE_DURATION_NS,
> + PARAM_RANGE(NTSC_HACT_DURATION_MIN_NS,
> + NTSC_HACT_DURATION_TYP_NS,
> + NTSC_HACT_DURATION_MAX_NS),
> + PARAM_RANGE(NTSC_HFP_DURATION_MIN_NS,
> + NTSC_HFP_DURATION_TYP_NS,
> + NTSC_HFP_DURATION_MAX_NS),
> + PARAM_RANGE(NTSC_HSLEN_DURATION_MIN_NS,
> + NTSC_HSLEN_DURATION_TYP_NS,
> + NTSC_HSLEN_DURATION_MAX_NS),
> + PARAM_RANGE(NTSC_HBP_DURATION_MIN_NS,
> + NTSC_HBP_DURATION_TYP_NS,
> + NTSC_HBP_DURATION_MAX_NS),
> + PARAM_RANGE(NTSC_HBLK_DURATION_MIN_NS,
> + NTSC_HBLK_DURATION_TYP_NS,
> + NTSC_HBLK_DURATION_MAX_NS),
> + 16,
> + PARAM_FIELD(3, 3),
> + PARAM_FIELD(3, 3),
> + PARAM_FIELD(16, 17)),
> + TV_MODE_PARAMETER(DRM_MODE_ANALOG_PAL,
> + PAL_LINES_NUMBER,
> + PAL_LINE_DURATION_NS,
> + PARAM_RANGE(PAL_HACT_DURATION_MIN_NS,
> + PAL_HACT_DURATION_TYP_NS,
> + PAL_HACT_DURATION_MAX_NS),
> + PARAM_RANGE(PAL_HFP_DURATION_MIN_NS,
> + PAL_HFP_DURATION_TYP_NS,
> + PAL_HFP_DURATION_MAX_NS),
> + PARAM_RANGE(PAL_HSLEN_DURATION_MIN_NS,
> + PAL_HSLEN_DURATION_TYP_NS,
> + PAL_HSLEN_DURATION_MAX_NS),
> + PARAM_RANGE(PAL_HBP_DURATION_MIN_NS,
> + PAL_HBP_DURATION_TYP_NS,
> + PAL_HBP_DURATION_MAX_NS),
> + PARAM_RANGE(PAL_HBLK_DURATION_MIN_NS,
> + PAL_HBLK_DURATION_TYP_NS,
> + PAL_HBLK_DURATION_MAX_NS),
> + 12,
> +
> + /*
> +* The front porch is actually 6 short sync
> +* pulses for the even field, and 5 for the
> +* odd field. Each sync takes half a life so
> +* the odd field front porch is shorter by
> +* half a line.
> +*
> +* In progressive, we're supposed to use 6
> +* pulses, so we're fine there
> +*/
> + PARAM_FIELD(3, 2),
> +
> + /*
> +* The vsync length is 5 long sync pulses,
> +* each field taking half a line. We're
> +* shorter for both fields by half a line.
> +*
> +* In progressive, we're supposed to use 5
> +* pulses, so we're off by half
> +* a line.
> +*
> +* In interlace, we're now off by half a line
> +* for the even field and one line for the odd
> +* field.
> +*/
> + PARAM_FIELD(3, 3),
> +
> + /*
> +* The back porch starts with post-equalizing
> +* pulses, consisting in 5 short sync pulses
> +* for the even field, 4 for the odd field. In
> +* progressive, it's 5 short syncs.
> +*
> +* In progressive, we thus have 2.5 lines,
> +* plus the 0.5 line we were missing
> +* previously, so we should use 3 lines.
> +*
> +* In interlace, the even field is in the
> +* exact same case than progressive. For the
> +* odd field, we should be using 2 lines but
> +* we're one line short, so we'll make up for
> +* it here by using 3.
> +*
> +* The entire blanking area is supposed to
> +* take 25 lines, so we also need to account
> +
Re: [Intel-gfx] [PATCH v5 22/22] drm/sun4i: tv: Convert to the new TV mode property
Hi Maxime,
Dne četrtek, 13. oktober 2022 ob 15:19:06 CEST je Maxime Ripard napisal(a):
> Now that the core can deal fine with analog TV modes, let's convert the
> sun4i TV driver to leverage those new features.
>
> Acked-by: Noralf Trønnes
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v5:
> - Removed the count variable in get_modes
> - Removed spurious vc4 change
> ---
> drivers/gpu/drm/sun4i/sun4i_tv.c | 145
> +-- 1 file changed, 48 insertions(+),
> 97 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
> b/drivers/gpu/drm/sun4i/sun4i_tv.c index c65f0a89b6b0..4f07aff11551 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -141,23 +141,14 @@ struct resync_parameters {
> struct tv_mode {
> char*name;
>
> + unsigned inttv_mode;
> +
> u32 mode;
> u32 chroma_freq;
> u16 back_porch;
> u16 front_porch;
> - u16 line_number;
> u16 vblank_level;
isn't there a way to get or calculate back_porch, front_porch and vblank_level
from mode? From quick glance over removed values below, I would say that at
least back_porch can be removed too?
Otherwise this patch looks ok.
Best regards,
Jernej
>
> - u32 hdisplay;
> - u16 hfront_porch;
> - u16 hsync_len;
> - u16 hback_porch;
> -
> - u32 vdisplay;
> - u16 vfront_porch;
> - u16 vsync_len;
> - u16 vback_porch;
> -
> boolyc_en;
> booldac3_en;
> booldac_bit25_en;
> @@ -213,7 +204,7 @@ static const struct resync_parameters
> pal_resync_parameters = {
>
> static const struct tv_mode tv_modes[] = {
> {
> - .name = "NTSC",
> + .tv_mode= DRM_MODE_TV_MODE_NTSC,
> .mode = SUN4I_TVE_CFG0_RES_480i,
> .chroma_freq= 0x21f07c1f,
> .yc_en = true,
> @@ -222,17 +213,6 @@ static const struct tv_mode tv_modes[] = {
>
> .back_porch = 118,
> .front_porch= 32,
> - .line_number= 525,
> -
> - .hdisplay = 720,
> - .hfront_porch = 18,
> - .hsync_len = 2,
> - .hback_porch= 118,
> -
> - .vdisplay = 480,
> - .vfront_porch = 26,
> - .vsync_len = 2,
> - .vback_porch= 17,
>
> .vblank_level = 240,
>
> @@ -242,23 +222,12 @@ static const struct tv_mode tv_modes[] = {
> .resync_params = _resync_parameters,
> },
> {
> - .name = "PAL",
> + .tv_mode= DRM_MODE_TV_MODE_PAL,
> .mode = SUN4I_TVE_CFG0_RES_576i,
> .chroma_freq= 0x2a098acb,
>
> .back_porch = 138,
> .front_porch= 24,
> - .line_number= 625,
> -
> - .hdisplay = 720,
> - .hfront_porch = 3,
> - .hsync_len = 2,
> - .hback_porch= 139,
> -
> - .vdisplay = 576,
> - .vfront_porch = 28,
> - .vsync_len = 2,
> - .vback_porch= 19,
>
> .vblank_level = 252,
>
> @@ -276,63 +245,21 @@ drm_encoder_to_sun4i_tv(struct drm_encoder *encoder)
> encoder);
> }
>
> -/*
> - * FIXME: If only the drm_display_mode private field was usable, this
> - * could go away...
> - *
> - * So far, it doesn't seem to be preserved when the mode is passed by
> - * to mode_set for some reason.
> - */
> -static const struct tv_mode *sun4i_tv_find_tv_by_mode(const struct
> drm_display_mode *mode) +static const struct tv_mode *
> +sun4i_tv_find_tv_by_mode(unsigned int mode)
> {
> int i;
>
> - /* First try to identify the mode by name */
> for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> const struct tv_mode *tv_mode = _modes[i];
>
> - DRM_DEBUG_DRIVER("Comparing mode %s vs %s",
> - mode->name, tv_mode->name);
> -
> - if (!strcmp(mode->name, tv_mode->name))
> - return tv_mode;
> - }
> -
> - /* Then by number of lines */
> - for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> - const struct tv_mode *tv_mode = _modes[i];
> -
> - DRM_DEBUG_DRIVER("Comparing mode %s vs %s (X: %d vs
%d)",
> - mode->name, tv_mode->name,
> - mode->vdisplay, tv_mode-
>vdisplay);
> -
> - if (mode->vdisplay == tv_mode->vdisplay)
> + if (tv_mode->tv_mode == mode)
> return tv_mode;
> }
>
> return NULL;
> }
>
> -static
[Intel-gfx] [RESEND PATCH 3/3] drm/i915/gem: Replace kmap() with kmap_local_page()
kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as
mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool wraps and it might block when the mapping space is fully
utilized until a slot becomes available.
With kmap_local_page() the mappings are per thread, CPU local, can take
page faults, and can be called from any context (including interrupts).
It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore,
the tasks can be preempted and, when they are scheduled to run again, the
kernel virtual addresses are restored and are still valid.
Since its use in i915/gem is safe everywhere, it should be preferred.
Therefore, replace kmap() with kmap_local_page() in i915/gem. Instead of
open-coding local map + memcpy + local unmap, use memcpy_to_page() in a
suited call site.
Cc: "Venkataramanan, Anirudh"
Suggested-by: Ira Weiny
Signed-off-by: Fabio M. De Francesco
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 ++
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 4eed3dd90ba8..2bc6ab9964ff 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -640,16 +640,14 @@ i915_gem_object_create_shmem_from_data(struct
drm_i915_private *dev_priv,
do {
unsigned int len = min_t(typeof(size), size, PAGE_SIZE);
struct page *page;
- void *pgdata, *vaddr;
+ void *pgdata;
err = aops->write_begin(file, file->f_mapping, offset, len,
, );
if (err < 0)
goto fail;
- vaddr = kmap(page);
- memcpy(vaddr, data, len);
- kunmap(page);
+ memcpy_to_page(page, 0, data, len);
err = aops->write_end(file, file->f_mapping, offset, len, len,
page, pgdata);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 3ced9948a331..bb25b50b5688 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -153,7 +153,7 @@ static int check_partial_mapping(struct drm_i915_gem_object
*obj,
intel_gt_flush_ggtt_writes(to_gt(i915));
p = i915_gem_object_get_page(obj, offset >> PAGE_SHIFT);
- cpu = kmap(p) + offset_in_page(offset);
+ cpu = kmap_local_page(p) + offset_in_page(offset);
drm_clflush_virt_range(cpu, sizeof(*cpu));
if (*cpu != (u32)page) {
pr_err("Partial view for %lu [%u] (offset=%llu, size=%u [%llu,
row size %u], fence=%d, tiling=%d, stride=%d) misalignment, expected write to
page (%llu + %u [0x%llx]) of 0x%x, found 0x%x\n",
@@ -171,7 +171,7 @@ static int check_partial_mapping(struct drm_i915_gem_object
*obj,
}
*cpu = 0;
drm_clflush_virt_range(cpu, sizeof(*cpu));
- kunmap(p);
+ kunmap_local(cpu);
out:
i915_gem_object_lock(obj, NULL);
@@ -249,7 +249,7 @@ static int check_partial_mappings(struct
drm_i915_gem_object *obj,
intel_gt_flush_ggtt_writes(to_gt(i915));
p = i915_gem_object_get_page(obj, offset >> PAGE_SHIFT);
- cpu = kmap(p) + offset_in_page(offset);
+ cpu = kmap_local_page(p) + offset_in_page(offset);
drm_clflush_virt_range(cpu, sizeof(*cpu));
if (*cpu != (u32)page) {
pr_err("Partial view for %lu [%u] (offset=%llu, size=%u
[%llu, row size %u], fence=%d, tiling=%d, stride=%d) misalignment, expected
write to page (%llu + %u [0x%llx]) of 0x%x, found 0x%x\n",
@@ -267,7 +267,7 @@ static int check_partial_mappings(struct
drm_i915_gem_object *obj,
}
*cpu = 0;
drm_clflush_virt_range(cpu, sizeof(*cpu));
- kunmap(p);
+ kunmap_local(cpu);
if (err)
return err;
--
2.37.1
[Intel-gfx] [RESEND PATCH 0/3] drm/i915: Replace kmap() with kmap_local_page()
kmap() is being deprecated in favor of kmap_local_page(). There are two main problems with kmap(): (1) It comes with an overhead as mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid. Since its use in drm/i915 is safe everywhere, it should be preferred. Therefore, replace kmap() with kmap_local_page() in drm/i915. These changes should be tested in an 32 bits system, booting a kernel with HIGHMEM enabled. Unfortunately I have no i915 based hardware, therefore any help with testing would be greatly appreciated. I'm resending this little series because I suspect that it has been lost, since it was submitted on Aug 11, 2022. In the meantime I'm adding one more recipient (Anirudh) who is helping, along with others, Ira and me with these conversions / removals of kmap() and kmap_atomic() Cc: "Venkataramanan, Anirudh" Suggested-by: Ira Weiny Signed-off-by: Fabio M. De Francesco Fabio M. De Francesco (3): drm/i915: Replace kmap() with kmap_local_page() drm/i915/gt: Replace kmap() with kmap_local_page() drm/i915/gem: Replace kmap() with kmap_local_page() drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 ++ drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++-- drivers/gpu/drm/i915/gt/shmem_utils.c | 11 --- drivers/gpu/drm/i915/i915_gem.c| 8 5 files changed, 16 insertions(+), 21 deletions(-) -- 2.37.1
[Intel-gfx] [RESEND PATCH 2/3] drm/i915/gt: Replace kmap() with kmap_local_page()
kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as
mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool wraps and it might block when the mapping space is fully
utilized until a slot becomes available.
With kmap_local_page() the mappings are per thread, CPU local, can take
page faults, and can be called from any context (including interrupts).
It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore,
the tasks can be preempted and, when they are scheduled to run again, the
kernel virtual addresses are restored and are still valid.
Since its use in i915/gt is safe everywhere, it should be preferred.
Therefore, replace kmap() with kmap_local_page() in i915/gt. Instead of
open-coding local mappings + memcpy() + local unmappings, use
the memcpy_{from,to}_page() helpers where these are better suited.
Cc: "Venkataramanan, Anirudh"
Suggested-by: Ira Weiny
Signed-off-by: Fabio M. De Francesco
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
drivers/gpu/drm/i915/gt/shmem_utils.c| 11 ---
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 6ebda3d65086..21d8ce40b897 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -747,7 +747,7 @@ static void swizzle_page(struct page *page)
char *vaddr;
int i;
- vaddr = kmap(page);
+ vaddr = kmap_local_page(page);
for (i = 0; i < PAGE_SIZE; i += 128) {
memcpy(temp, [i], 64);
@@ -755,7 +755,7 @@ static void swizzle_page(struct page *page)
memcpy([i + 64], temp, 64);
}
- kunmap(page);
+ kunmap_local(vaddr);
}
/**
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 402f085f3a02..48edbb8a33e5 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -98,22 +98,19 @@ static int __shmem_rw(struct file *file, loff_t off,
unsigned int this =
min_t(size_t, PAGE_SIZE - offset_in_page(off), len);
struct page *page;
- void *vaddr;
page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
GFP_KERNEL);
if (IS_ERR(page))
return PTR_ERR(page);
- vaddr = kmap(page);
if (write) {
- memcpy(vaddr + offset_in_page(off), ptr, this);
+ memcpy_to_page(page, offset_in_page(off), ptr, this);
set_page_dirty(page);
} else {
- memcpy(ptr, vaddr + offset_in_page(off), this);
+ memcpy_from_page(ptr, page, offset_in_page(off), this);
}
mark_page_accessed(page);
- kunmap(page);
put_page(page);
len -= this;
@@ -140,11 +137,11 @@ int shmem_read_to_iosys_map(struct file *file, loff_t off,
if (IS_ERR(page))
return PTR_ERR(page);
- vaddr = kmap(page);
+ vaddr = kmap_local_page(page);
iosys_map_memcpy_to(map, map_off, vaddr + offset_in_page(off),
this);
mark_page_accessed(page);
- kunmap(page);
+ kunmap_local(vaddr);
put_page(page);
len -= this;
--
2.37.1
Re: [Intel-gfx] [PATCH] drm/edid/firmware: stop using throwaway platform device
Currently the EDID is requested during the resume. But since it's
requested too early, this means before the filesystem is mounted, the
firmware request fails. This make the DRM driver crash when resuming.
This kind of issue should be prevented by the firmware caching process
which cache every firmware requested for the next resume. But since we
are using a temporary device, the firmware isn't cached on suspend
since the device doesn't work anymore.
When using a non temporary device to get the EDID, the firmware will
be cached on suspend for the next resume. So requesting the firmware
during resume will succeed.
But if the firmware has never been requested since the boot, this
means that the monitor isn't plugged since the boot. The kernel will
not be caching the EDID. So if we plug the monitor while the machine
is suspended. The resume will fail to load the firmware. And the DRM
driver will crash.
So basically, your fix should solve the issue except for the case
where the monitor hasn't been plugged since boot and is plugged while
the machine is suspended.
I hope I was clear. Tell me if I wasn't. I'm not really good at explaining.
Matthieu
On 10/11/22, Jani Nikula wrote:
> On Tue, 11 Oct 2022, Matthieu CHARETTE wrote:
>> It should fix the issue. Meanwhile, the system will still crash if a
>> new monitor is plugged while the machine is suspended. We might need to
>> precache the EDID to prevent that.
>
> Please elaborate.
>
> BR,
> Jani.
>
>
>>
>> Matthieu
>>
>> On Fri, Oct 7 2022 at 01:21:46 AM +0300, Jani Nikula
>> wrote:
>>> We've used a temporary platform device for firmware EDID loading since
>>> it was introduced in commit da0df92b5731 ("drm: allow loading an EDID
>>> as
>>> firmware to override broken monitor"), but there's no explanation why.
>>>
>>> Do we need to?
>>>
>>> Maybe this fixes the suspend/resume issue?
>>>
>>> (Yes, I'll rewrite the commit message if this is the way to go ;)
>>>
>>> References:
>>> https://lore.kernel.org/r/20220727074152.43059-1-matthieu.chare...@gmail.com
>>> Cc: Matthieu CHARETTE
>>> Cc: Ville Syrjälä
>>> Signed-off-by: Jani Nikula
>>> ---
>>> drivers/gpu/drm/drm_edid_load.c | 11 +--
>>> 1 file changed, 1 insertion(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid_load.c
>>> b/drivers/gpu/drm/drm_edid_load.c
>>> index 37d8ba3ddb46..fbae12130234 100644
>>> --- a/drivers/gpu/drm/drm_edid_load.c
>>> +++ b/drivers/gpu/drm/drm_edid_load.c
>>> @@ -182,18 +182,9 @@ static void *edid_load(struct drm_connector
>>> *connector, const char *name,
>>> fwdata = generic_edid[builtin];
>>> fwsize = sizeof(generic_edid[builtin]);
>>> } else {
>>> - struct platform_device *pdev;
>>> int err;
>>>
>>> - pdev = platform_device_register_simple(connector_name, -1, NULL,
>>> 0);
>>> - if (IS_ERR(pdev)) {
>>> - DRM_ERROR("Failed to register EDID firmware platform
>>> device "
>>> - "for connector \"%s\"\n", connector_name);
>>> - return ERR_CAST(pdev);
>>> - }
>>> -
>>> - err = request_firmware(, name, >dev);
>>> - platform_device_unregister(pdev);
>>> + err = request_firmware(, name, connector->dev->dev);
>>> if (err) {
>>> DRM_ERROR("Requesting EDID firmware \"%s\" failed
>>> (err=%d)\n",
>>> name, err);
>>> --
>>> 2.34.1
>>>
>>
>>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
>
Re: [Intel-gfx] [PATCH v5 20/22] drm/vc4: vec: Convert to the new TV mode property
Hi Maxime,
> static int vc4_vec_connector_get_modes(struct drm_connector *connector)
> {
> - struct drm_connector_state *state = connector->state;
> struct drm_display_mode *mode;
>
> - mode = drm_mode_duplicate(connector->dev,
> - vc4_vec_tv_modes[state->tv.legacy_mode].mode);
> + mode = drm_mode_analog_ntsc_480i(connector->dev);
> if (!mode) {
> DRM_ERROR("Failed to create a new display mode\n");
> return -ENOMEM;
> }
>
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> drm_mode_probed_add(connector, mode);
>
> - return 1;
> + mode = drm_mode_analog_pal_576i(connector->dev);
> + if (!mode) {
> + DRM_ERROR("Failed to create a new display mode\n");
> + return -ENOMEM;
> + }
> +
> + drm_mode_probed_add(connector, mode);
> +
> + return 2;
> +}
Referencing those previous discussions:
-
https://lore.kernel.org/dri-devel/0255f7c6-0484-6456-350d-cf24f3fee...@tronnes.org/
-
https://lore.kernel.org/dri-devel/c8f8015a-75da-afa8-ca7f-b2b134cac...@gmail.com/
Unconditionally setting the 480i mode as DRM_MODE_TYPE_PREFERRED causes Xorg
(at least on current Raspberry Pi OS) to display garbage when
video=Composite1:PAL is specified on the command line, so I'm afraid this won't
do.
As I see it, there are three viable solutions for this issue:
a) Somehow query the video= command line option from this function, and set
DRM_MODE_TYPE_PREFERRED appropriately. This would break the abstraction
provided by global DRM code, but should work fine.
b) Modify drm_helper_probe_add_cmdline_mode() so that it sets
DRM_MODE_TYPE_PREFERRED in addition to DRM_MODE_TYPE_USERDEF. This seems
pretty robust, but affects the entire DRM subsystem, which may break
userspace in different ways.
- Maybe this could be mitigated by adding some additional conditions, e.g.
setting the PREFERRED flag only if no modes are already flagged as such
and/or only if the cmdline mode is a named one (~= analog TV mode)
c) Forcing userspace (Xorg / Raspberry Pi OS) to get fixed and honor the USERDEF
flag.
Either way, hardcoding 480i as PREFERRED does not seem right.
Note: this also applies to the sun4i version (patch 22/22).
> @@ -366,13 +472,16 @@ static void vc4_vec_encoder_enable(struct drm_encoder
> *encoder,
> struct drm_connector *connector = >connector;
> struct drm_connector_state *conn_state =
> drm_atomic_get_new_connector_state(state, connector);
> - const struct vc4_vec_tv_mode *tv_mode =
> - _vec_tv_modes[conn_state->tv.legacy_mode];
> + const struct vc4_vec_tv_mode *tv_mode;
> int idx, ret;
>
> if (!drm_dev_enter(drm, ))
> return;
>
> + tv_mode = vc4_vec_tv_mode_lookup(conn_state->tv.mode);
> + if (!tv_mode)
> + goto err_dev_exit;
> +
> ret = pm_runtime_get_sync(>pdev->dev);
> if (ret < 0) {
> DRM_ERROR("Failed to retain power domain: %d\n", ret);
If this (!tv_mode) condition is somehow triggered, the power management goes
somewhat crazy. vc4_vec_encoder_enable() cannot return an error, so when
vc4_vec_encoder_disable() is eventually called after a failed enable, it hangs
in pm_runtime_put() for quite a bit.
At least I think that's what's happening. Anyway, to solve this, I'd propose
this thing below:
Best regards,
Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add error-capture init warnings when needed
On 10/14/2022 20:59, Alan Previn wrote:
If GuC is being used and we initialized GuC-error-capture,
we need to be warning if we don't provide an error-capture
register list in the firmware ADS, for valid GT engines.
A warning makes sense as this would impact debugability
without realizing why a reglist wasn't retrieved and reported
by GuC.
However, depending on the platform, we might have certain
engines that have a register list for engine instance error state
but not for engine class. Thus, add a check only to warn if the
register list was non existent vs an empty list (use the
empty lists to skip the warning).
Signed-off-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 55 ++-
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 8f1165146013..290c1e1343dd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -419,6 +419,44 @@ guc_capture_get_device_reglist(struct intel_guc *guc)
return default_lists;
}
+static const char *
+__stringify_type(u32 type)
+{
+ switch (type) {
+ case GUC_CAPTURE_LIST_TYPE_GLOBAL:
+ return "Global";
+ case GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS:
+ return "Class";
+ case GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE:
+ return "Instance";
+ default:
+ return "unknown";
+ }
+
+ return "";
As per Tvrtko's comment, this is dead code and unnecessary. A blank
'default:' that falls through to 'return "Unknown";' would be better.
+}
+
+static const char *
+__stringify_engclass(u32 class)
+{
+ switch (class) {
+ case GUC_RENDER_CLASS:
+ return "Render";
+ case GUC_VIDEO_CLASS:
+ return "Video";
+ case GUC_VIDEOENHANCE_CLASS:
+ return "VideoEnhance";
+ case GUC_BLITTER_CLASS:
+ return "Blitter";
+ case GUC_COMPUTE_CLASS:
+ return "Compute";
+ default:
+ return "unknown";
+ }
+
+ return "";
As above.
+}
+
static int
guc_capture_list_init(struct intel_guc *guc, u32 owner, u32 type, u32 classid,
struct guc_mmio_reg *ptr, u16 num_entries)
@@ -487,19 +525,32 @@ intel_guc_capture_getlistsize(struct intel_guc *guc, u32
owner, u32 type, u32 cl
size_t *size)
{
struct intel_guc_state_capture *gc = guc->capture;
+ struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct __guc_capture_ads_cache *cache =
>ads_cache[owner][type][classid];
int num_regs;
- if (!gc->reglists)
+ if (!gc->reglists) {
+ drm_warn(>drm, "GuC-capture: No reglist on this
device\n");
return -ENODEV;
+ }
if (cache->is_valid) {
*size = cache->size;
return cache->status;
}
+ if (!guc_capture_get_one_list(gc->reglists, owner, type, classid)) {
+ if (owner == GUC_CAPTURE_LIST_INDEX_PF && type ==
GUC_CAPTURE_LIST_TYPE_GLOBAL)
+ drm_warn(>drm, "GuC-capture: missing reglist
type-Global\n");
+ if (owner == GUC_CAPTURE_LIST_INDEX_PF)
+ drm_warn(>drm, "GuC-capture: missing regiist
type(%d)-%s : "
+"%s(%d)-Engine\n", type,
__stringify_type(type),
What Tvrtko is meaning here is to not split the string at all. You can
ignore a line length warning message if the only alternatives are either
to split the string or to obfuscate the code with unreadable/unnecessary
construction methods.
+__stringify_engclass(classid), classid);
+ return -ENODATA;
+ }
+
num_regs = guc_cap_list_num_regs(gc, owner, type, classid);
- if (!num_regs)
+ if (!num_regs) /* intentional empty lists can exist depending on hw
config */
Not sure if this is proper formatting for a comment? I would either put
it on the line before or inside the if with the addition of braces.
John.
return -ENODATA;
*size = PAGE_ALIGN((sizeof(struct guc_debug_capture_list)) +
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Explicit MCR handling and MTL steering (rev4)
Filed a new issue and re-reported. https://gitlab.freedesktop.org/drm/intel/-/issues/7230 igt@kms_async_flips@async-flip-with-page-flip-events@.* - fail - Failed assertion: (fps / 1000) > (data->refresh_rate * MIN_FLIPS_PER_FRAME), FPS should be significantly higher than the refresh rate Lakshmi. -Original Message- From: Roper, Matthew D Sent: Monday, October 17, 2022 9:18 AM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT: failure for Explicit MCR handling and MTL steering (rev4) On Sat, Oct 15, 2022 at 01:03:31AM +, Patchwork wrote: > == Series Details == > > Series: Explicit MCR handling and MTL steering (rev4) > URL : https://patchwork.freedesktop.org/series/108755/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_12242_full -> Patchwork_108755v4_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_108755v4_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_108755v4_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Participating hosts (9 -> 11) > -- > > Additional (2): shard-rkl shard-dg1 > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_108755v4_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_async_flips@async-flip-with-page-flip-events@pipe-c-edp-1: > - shard-skl: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-c-edp-1.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl3 > /igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-c-edp-1.htm > l GT multicast register handling wouldn't have changed the behavior of a SKL display test. This failure is unrelated. Other subtests of this test also seem to be sporadically failing in a similar manner. This might be related to the same root cause as fdo#2521. Matt > > > Warnings > > * igt@runner@aborted: > - shard-skl: ([FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6]) > ([i915#3002] / [i915#4312] / [i915#6949]) -> ([FAIL][7], [FAIL][8], > [FAIL][9]) ([i915#3002] / [i915#4312]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@run...@aborted.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@run...@aborted.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl4/igt@run...@aborted.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl10/igt@run...@aborted.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl1/igt@run...@aborted.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl2/igt@run...@aborted.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl7 > /igt@run...@aborted.html > > > Known issues > > > Here are the changes found in Patchwork_108755v4_full that come from known > issues: > > ### CI changes ### > > Possible fixes > > * boot: > - shard-skl: ([PASS][10], [PASS][11], [PASS][12], [PASS][13], > [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], > [PASS][20], [FAIL][21], [PASS][22], [FAIL][23], [PASS][24], [PASS][25], > [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], > [PASS][32], [PASS][33], [PASS][34]) ([i915#5032]) -> ([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], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], > [PASS][55], [PASS][56], [PASS][57]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html >[19]: >
[Intel-gfx] ✓ Fi.CI.BAT: success for Move all drivers to a common dma-buf locking convention
== Series Details ==
Series: Move all drivers to a common dma-buf locking convention
URL : https://patchwork.freedesktop.org/series/109786/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109786v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/index.html
Participating hosts (44 -> 45)
--
Additional (3): fi-hsw-4770 fi-rkl-11600 bat-atsm-1
Missing(2): fi-glk-j4005 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_109786v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {bat-atsm-1}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/bat-atsm-1/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_109786v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][2] ([fdo#109271]) +9 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3012])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@module-reload:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][4] ([i915#7221])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/fi-hsw-4770/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +7
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1072]) +3
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#4312] /
[i915#5594])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/fi-hsw-4770/igt@run...@aborted.html
- fi-rkl-11600: NOTRUN -> [FAIL][8] ([i915#7220])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/fi-rkl-11600/igt@run...@aborted.html
Possible fixes
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [FAIL][9] ([i915#6298]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-gvtdvm: [FAIL][11] ([fdo#103375]) -> [INCOMPLETE][12]
([i915#146])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bdw-gvtdvm/igt@i915_susp...@basic-s3-without-i915.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109786v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#7220]: https://gitlab.freedesktop.org/drm/intel/issues/7220
[i915#7221]: https://gitlab.freedesktop.org/drm/intel/issues/7221
Build changes
-
* Linux: CI_DRM_12251 -> Patchwork_109786v1
CI-20190529: 20190529
CI_DRM_12251: ff61e79b01712f5d31a4c4f23c6971bbaa71cecb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7016: 642f4bf44e2b42791b4d1684936a1bfbe2d099ee @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_109786v1:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Move all drivers to a common dma-buf locking convention
== Series Details == Series: Move all drivers to a common dma-buf locking convention URL : https://patchwork.freedesktop.org/series/109786/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add error-capture init warnings when needed
On Mon, 2022-10-17 at 09:42 +0100, Tvrtko Ursulin wrote:
> On 15/10/2022 04:59, Alan Previn wrote:
> > If GuC is being used and we initialized GuC-error-capture,
> > we need to be warning if we don't provide an error-capture
> > register list in the firmware ADS, for valid GT engines.
> > A warning makes sense as this would impact debugability
> > without realizing why a reglist wasn't retrieved and reported
> > by GuC.>
> > However, depending on the platform, we might have certain
> > engines that have a register list for engine instance error state
> > but not for engine class. Thus, add a check only to warn if the
> > register list was non existent vs an empty list (use the
> > empty lists to skip the warning).
> >
> > Signed-off-by: Alan Previn
> > ---
> > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 55 ++-
> > 1 file changed, 53 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > index 8f1165146013..290c1e1343dd 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > @@ -419,6 +419,44 @@ guc_capture_get_device_reglist(struct intel_guc *guc)
> > return default_lists;
> > }
> >
> > +static const char *
> > +__stringify_type(u32 type)
> > +{
> > + switch (type) {
> > + case GUC_CAPTURE_LIST_TYPE_GLOBAL:
> > + return "Global";
> > + case GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS:
> > + return "Class";
> > + case GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE:
> > + return "Instance";
> > + default:
> > + return "unknown";
> > + }
> > +
> > + return "";
>
> What's the point of these returns? Gcc complains about not returning a type
> from const char * return function?
>
Sorry i am not sure I saw any complain for Gcc. If you are referring to "" then
i can re-rev without the default and
just let the path outside return the unknown. Is that what you are referring to?
> > +}
> > +
> > +static const char *
> > +__stringify_engclass(u32 class)
> > +{
> > + switch (class) {
> > + case GUC_RENDER_CLASS:
> > + return "Render";
> > + case GUC_VIDEO_CLASS:
> > + return "Video";
> > + case GUC_VIDEOENHANCE_CLASS:
> > + return "VideoEnhance";
> > + case GUC_BLITTER_CLASS:
> > + return "Blitter";
> > + case GUC_COMPUTE_CLASS:
> > + return "Compute";
> > + default:
> > + return "unknown";
> > + }
> > +
> > + return "";
> > +}
> > +
> > static int
> > guc_capture_list_init(struct intel_guc *guc, u32 owner, u32 type, u32
> > classid,
> > struct guc_mmio_reg *ptr, u16 num_entries)
> > @@ -487,19 +525,32 @@ intel_guc_capture_getlistsize(struct intel_guc *guc,
> > u32 owner, u32 type, u32 cl
> > size_t *size)
> > {
> > struct intel_guc_state_capture *gc = guc->capture;
> > + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> > struct __guc_capture_ads_cache *cache =
> > >ads_cache[owner][type][classid];
> > int num_regs;
> >
> > - if (!gc->reglists)
> > + if (!gc->reglists) {
> > + drm_warn(>drm, "GuC-capture: No reglist on this
> > device\n");
> > return -ENODEV;
> > + }
> >
> > if (cache->is_valid) {
> > *size = cache->size;
> > return cache->status;
> > }
> >
> > + if (!guc_capture_get_one_list(gc->reglists, owner, type, classid)) {
> > + if (owner == GUC_CAPTURE_LIST_INDEX_PF && type ==
> > GUC_CAPTURE_LIST_TYPE_GLOBAL)
> > + drm_warn(>drm, "GuC-capture: missing reglist
> > type-Global\n");
> > + if (owner == GUC_CAPTURE_LIST_INDEX_PF)
>
> GUC_CAPTURE_LIST_INDEX_PF could be made once on the enclosing if statement?
Sure - will do.
>
> Btw what's with the PF and VF (cover letter) references while SRIOV does not
> exists upstream?
To maintain a scalable code flow across both the ADS code and guc-error-capture
code, we do have to skip over this enum
else we'll encounter lots of warnings about missing VF-reglist support (which
we cant check for since we dont even have
support - i.e we dont even have a "is not supported" check) but the GuC
firmware ADS buffer allocation includes an entry
for VFs so we have to skip over it. This is the cleanest way i can think of
without impacting other code areas and also
while adding the ability to warn when its important.
> > + drm_warn(>drm, "GuC-capture: missing regiist
> > type(%d)-%s : "
>
> reglist
thanks - will fix
>
> > +"%s(%d)-Engine\n", type,
> > __stringify_type(type),
> > +__stringify_engclass(classid), classid);
>
> One details to consider from Documentation/process/coding-style.rst
> """
> However, never break user-visible strings such as printk messages because
> that breaks the
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Explicit MCR handling and MTL steering (rev4)
On Mon, Oct 17, 2022 at 09:17:51AM -0700, Matt Roper wrote: > On Sat, Oct 15, 2022 at 01:03:31AM +, Patchwork wrote: > > == Series Details == > > > > Series: Explicit MCR handling and MTL steering (rev4) > > URL : https://patchwork.freedesktop.org/series/108755/ > > State : failure > > > > == Summary == > > > > CI Bug Log - changes from CI_DRM_12242_full -> Patchwork_108755v4_full > > > > > > Summary > > --- > > > > **FAILURE** > > > > Serious unknown changes coming with Patchwork_108755v4_full absolutely > > need to be > > verified manually. > > > > If you think the reported changes have nothing to do with the changes > > introduced in Patchwork_108755v4_full, please notify your bug team to > > allow them > > to document this new failure mode, which will reduce false positives in > > CI. > > > > > > > > Participating hosts (9 -> 11) > > -- > > > > Additional (2): shard-rkl shard-dg1 > > > > Possible new issues > > --- > > > > Here are the unknown changes that may have been introduced in > > Patchwork_108755v4_full: > > > > ### IGT changes ### > > > > Possible regressions > > > > * igt@kms_async_flips@async-flip-with-page-flip-events@pipe-c-edp-1: > > - shard-skl: [PASS][1] -> [FAIL][2] > >[1]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-c-edp-1.html > >[2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl3/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-c-edp-1.html > > GT multicast register handling wouldn't have changed the behavior of a > SKL display test. This failure is unrelated. > > Other subtests of this test also seem to be sporadically failing in a > similar manner. This might be related to the same root cause as > fdo#2521. > Series applied to drm-intel-gt-next. Thanks Bala for the reviews! Matt > > > Matt > > > > > > > Warnings > > > > * igt@runner@aborted: > > - shard-skl: ([FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6]) > > ([i915#3002] / [i915#4312] / [i915#6949]) -> ([FAIL][7], [FAIL][8], > > [FAIL][9]) ([i915#3002] / [i915#4312]) > >[3]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@run...@aborted.html > >[4]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@run...@aborted.html > >[5]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl4/igt@run...@aborted.html > >[6]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl10/igt@run...@aborted.html > >[7]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl1/igt@run...@aborted.html > >[8]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl2/igt@run...@aborted.html > >[9]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl7/igt@run...@aborted.html > > > > > > Known issues > > > > > > Here are the changes found in Patchwork_108755v4_full that come from > > known issues: > > > > ### CI changes ### > > > > Possible fixes > > > > * boot: > > - shard-skl: ([PASS][10], [PASS][11], [PASS][12], [PASS][13], > > [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], > > [PASS][20], [FAIL][21], [PASS][22], [FAIL][23], [PASS][24], [PASS][25], > > [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], > > [PASS][32], [PASS][33], [PASS][34]) ([i915#5032]) -> ([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], [PASS][50], [PASS][51], [PASS][52], [PASS][53], > > [PASS][54], [PASS][55], [PASS][56], [PASS][57]) > >[10]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html > >[11]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html > >[12]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html > >[13]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html > >[14]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html > >[15]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html > >[16]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html > >[17]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html > >[18]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html > >[19]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html > >[20]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/boot.html
Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Add compute reglist for GuC error capture
ADL-P doesnt support CCS and DG2 is stll force-probe (so hoping to get this
before DG2 goes live).
...alan
On Mon, 2022-10-17 at 09:43 +0100, Tvrtko Ursulin wrote:
> On 15/10/2022 04:59, Alan Previn wrote:
> > Add compute reglist for GuC error capture.
> >
> > Signed-off-by: Alan Previn
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > index 290c1e1343dd..da3a09c11d12 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > @@ -169,6 +169,8 @@ static struct __guc_mmio_reg_descr_group
> > default_lists[] = {
> > MAKE_REGLIST(default_global_regs, PF, GLOBAL, 0),
> > MAKE_REGLIST(default_rc_class_regs, PF, ENGINE_CLASS, GUC_RENDER_CLASS),
> > MAKE_REGLIST(xe_lpd_rc_inst_regs, PF, ENGINE_INSTANCE,
> > GUC_RENDER_CLASS),
> > + MAKE_REGLIST(default_rc_class_regs, PF, ENGINE_CLASS,
> > GUC_COMPUTE_CLASS),
> > + MAKE_REGLIST(xe_lpd_rc_inst_regs, PF, ENGINE_INSTANCE,
> > GUC_COMPUTE_CLASS),
>
> Does this means error capture on ADL-P was incomplete aka should
> something be sent to stable?
>
> Regards,
>
> Tvrtko
>
> > MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_VIDEO_CLASS),
> > MAKE_REGLIST(xe_lpd_vd_inst_regs, PF, ENGINE_INSTANCE, GUC_VIDEO_CLASS),
> > MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_VIDEOENHANCE_CLASS),
> > @@ -182,6 +184,8 @@ static const struct __guc_mmio_reg_descr_group
> > xe_lpd_lists[] = {
> > MAKE_REGLIST(xe_lpd_global_regs, PF, GLOBAL, 0),
> > MAKE_REGLIST(xe_lpd_rc_class_regs, PF, ENGINE_CLASS, GUC_RENDER_CLASS),
> > MAKE_REGLIST(xe_lpd_rc_inst_regs, PF, ENGINE_INSTANCE,
> > GUC_RENDER_CLASS),
> > + MAKE_REGLIST(xe_lpd_rc_class_regs, PF, ENGINE_CLASS, GUC_COMPUTE_CLASS),
> > + MAKE_REGLIST(xe_lpd_rc_inst_regs, PF, ENGINE_INSTANCE,
> > GUC_COMPUTE_CLASS),
> > MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_VIDEO_CLASS),
> > MAKE_REGLIST(xe_lpd_vd_inst_regs, PF, ENGINE_INSTANCE, GUC_VIDEO_CLASS),
> > MAKE_REGLIST(xe_lpd_vec_class_regs, PF, ENGINE_CLASS,
> > GUC_VIDEOENHANCE_CLASS),
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Add intel_ prefix to struct ip_version
On Tue, Oct 11, 2022 at 08:38:50AM -0700, Radhakrishna Sripada wrote: Rename struct ip_version to intel_ip_version to comply with the naming conventions for structures. Suggested-by: Jani Nikula Signed-off-by: Radhakrishna Sripada Reviewed-by: Lucas De Marchi Lucas De Marchi
[Intel-gfx] [PATCH v7 21/21] dma-buf: Remove obsoleted internal lock
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Acked-by: Sumit Semwal
Acked-by: Christian König
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 14 --
include/linux/dma-buf.h | 9 -
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f1d968e5bac4..7663c4e784b6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -657,7 +657,6 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
dmabuf->file = file;
- mutex_init(>lock);
INIT_LIST_HEAD(>attachments);
mutex_lock(_list.lock);
@@ -1503,7 +1502,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
{
struct iosys_map ptr;
- int ret = 0;
+ int ret;
iosys_map_clear(map);
@@ -1515,28 +1514,25 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct
iosys_map *map)
if (!dmabuf->ops->vmap)
return -EINVAL;
- mutex_lock(>lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(iosys_map_is_null(>vmap_ptr));
*map = dmabuf->vmap_ptr;
- goto out_unlock;
+ return 0;
}
BUG_ON(iosys_map_is_set(>vmap_ptr));
ret = dmabuf->ops->vmap(dmabuf, );
if (WARN_ON_ONCE(ret))
- goto out_unlock;
+ return ret;
dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
*map = dmabuf->vmap_ptr;
-out_unlock:
- mutex_unlock(>lock);
- return ret;
+ return 0;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vmap, DMA_BUF);
@@ -1583,13 +1579,11 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct
iosys_map *map)
BUG_ON(dmabuf->vmapping_counter == 0);
BUG_ON(!iosys_map_is_equal(>vmap_ptr, map));
- mutex_lock(>lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, map);
iosys_map_clear(>vmap_ptr);
}
- mutex_unlock(>lock);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap, DMA_BUF);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index f11b5bbc2f37..6fa8d4e29719 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -326,15 +326,6 @@ struct dma_buf {
/** @ops: dma_buf_ops associated with this buffer object. */
const struct dma_buf_ops *ops;
- /**
-* @lock:
-*
-* Used internally to serialize list manipulation, attach/detach and
-* vmap/unmap. Note that in many cases this is superseeded by
-* dma_resv_lock() on @resv.
-*/
- struct mutex lock;
-
/**
* @vmapping_counter:
*
--
2.37.3
[Intel-gfx] [PATCH v7 20/21] media: videobuf2: Stop using internal dma-buf lock
All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.
Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +--
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +--
drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +--
3 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 79f4d8301fbb..555bd40fa472 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -382,18 +382,12 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
{
struct vb2_dc_attachment *attach = db_attach->priv;
- /* stealing dmabuf mutex to serialize map/unmap operations */
- struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- mutex_lock(lock);
-
sgt = >sgt;
/* return previously mapped sg table */
- if (attach->dma_dir == dma_dir) {
- mutex_unlock(lock);
+ if (attach->dma_dir == dma_dir)
return sgt;
- }
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -409,14 +403,11 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
DMA_ATTR_SKIP_CPU_SYNC)) {
pr_err("failed to map scatterlist\n");
- mutex_unlock(lock);
return ERR_PTR(-EIO);
}
attach->dma_dir = dma_dir;
- mutex_unlock(lock);
-
return sgt;
}
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 36ecdea8d707..36981a5b5c53 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -424,18 +424,12 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
{
struct vb2_dma_sg_attachment *attach = db_attach->priv;
- /* stealing dmabuf mutex to serialize map/unmap operations */
- struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- mutex_lock(lock);
-
sgt = >sgt;
/* return previously mapped sg table */
- if (attach->dma_dir == dma_dir) {
- mutex_unlock(lock);
+ if (attach->dma_dir == dma_dir)
return sgt;
- }
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -446,14 +440,11 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
- mutex_unlock(lock);
return ERR_PTR(-EIO);
}
attach->dma_dir = dma_dir;
- mutex_unlock(lock);
-
return sgt;
}
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 7831bf545874..41db707e43a4 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -267,18 +267,12 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
{
struct vb2_vmalloc_attachment *attach = db_attach->priv;
- /* stealing dmabuf mutex to serialize map/unmap operations */
- struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- mutex_lock(lock);
-
sgt = >sgt;
/* return previously mapped sg table */
- if (attach->dma_dir == dma_dir) {
- mutex_unlock(lock);
+ if (attach->dma_dir == dma_dir)
return sgt;
- }
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -289,14 +283,11 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
- mutex_unlock(lock);
return ERR_PTR(-EIO);
}
attach->dma_dir = dma_dir;
- mutex_unlock(lock);
-
return sgt;
}
--
2.37.3
[Intel-gfx] [PATCH v7 19/21] dma-buf: Document dynamic locking convention
Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not. Acked-by: Sumit Semwal Reviewed-by: Christian König Signed-off-by: Dmitry Osipenko --- Documentation/driver-api/dma-buf.rst | 6 +++ drivers/dma-buf/dma-buf.c| 64 2 files changed, 70 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 36a76cbe9095..622b8156d212 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -119,6 +119,12 @@ DMA Buffer ioctls .. kernel-doc:: include/uapi/linux/dma-buf.h +DMA-BUF locking convention +~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: locking convention + Kernel Functions and Structures Reference ~ diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index f149b384f4dd..f1d968e5bac4 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -795,6 +795,70 @@ static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach, return sg_table; } +/** + * DOC: locking convention + * + * In order to avoid deadlock situations between dma-buf exports and importers, + * all dma-buf API users must follow the common dma-buf locking convention. + * + * Convention for importers + * + * 1. Importers must hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_pin() + * - dma_buf_unpin() + * - dma_buf_map_attachment() + * - dma_buf_unmap_attachment() + * - dma_buf_vmap() + * - dma_buf_vunmap() + * + * 2. Importers must not hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_attach() + * - dma_buf_dynamic_attach() + * - dma_buf_detach() + * - dma_buf_export( + * - dma_buf_fd() + * - dma_buf_get() + * - dma_buf_put() + * - dma_buf_mmap() + * - dma_buf_begin_cpu_access() + * - dma_buf_end_cpu_access() + * - dma_buf_map_attachment_unlocked() + * - dma_buf_unmap_attachment_unlocked() + * - dma_buf_vmap_unlocked() + * - dma_buf_vunmap_unlocked() + * + * Convention for exporters + * + * 1. These _buf_ops callbacks are invoked with unlocked dma-buf + *reservation and exporter can take the lock: + * + * - _buf_ops.attach() + * - _buf_ops.detach() + * - _buf_ops.release() + * - _buf_ops.begin_cpu_access() + * - _buf_ops.end_cpu_access() + * + * 2. These _buf_ops callbacks are invoked with locked dma-buf + *reservation and exporter can't take the lock: + * + * - _buf_ops.pin() + * - _buf_ops.unpin() + * - _buf_ops.map_dma_buf() + * - _buf_ops.unmap_dma_buf() + * - _buf_ops.mmap() + * - _buf_ops.vmap() + * - _buf_ops.vunmap() + * + * 3. Exporters must hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_move_notify() + */ + /** * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list * @dmabuf:[in]buffer to attach device to. -- 2.37.3
[Intel-gfx] [PATCH v7 16/21] dma-buf: Move dma_buf_attach() to dynamic locking specification
Move dma-buf attachment API functions to the dynamic locking specification
by taking the reservation lock around the mapping operations. The strict
locking convention prevents deadlock situations for dma-buf importers and
exporters.
Acked-by: Sumit Semwal
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 2c4381bb9478..d685a5adb122 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -859,8 +859,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
+ dma_resv_lock(attach->dmabuf->resv, NULL);
if (dma_buf_is_dynamic(attach->dmabuf)) {
- dma_resv_lock(attach->dmabuf->resv, NULL);
ret = dmabuf->ops->pin(attach);
if (ret)
goto err_unlock;
@@ -873,8 +873,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
ret = PTR_ERR(sgt);
goto err_unpin;
}
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_unlock(attach->dmabuf->resv);
+ dma_resv_unlock(attach->dmabuf->resv);
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
}
@@ -890,8 +889,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
dmabuf->ops->unpin(attach);
err_unlock:
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_unlock(attach->dmabuf->resv);
+ dma_resv_unlock(attach->dmabuf->resv);
dma_buf_detach(dmabuf, attach);
return ERR_PTR(ret);
@@ -937,21 +935,19 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
if (WARN_ON(!dmabuf || !attach))
return;
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+
if (attach->sgt) {
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_lock(attach->dmabuf->resv, NULL);
__unmap_dma_buf(attach, attach->sgt, attach->dir);
- if (dma_buf_is_dynamic(attach->dmabuf)) {
+ if (dma_buf_is_dynamic(attach->dmabuf))
dmabuf->ops->unpin(attach);
- dma_resv_unlock(attach->dmabuf->resv);
- }
}
-
- dma_resv_lock(dmabuf->resv, NULL);
list_del(>node);
+
dma_resv_unlock(dmabuf->resv);
+
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
--
2.37.3
[Intel-gfx] [PATCH v7 18/21] dma-buf: Move dma_buf_mmap() to dynamic locking specification
Move dma_buf_mmap() function to the dynamic locking specification by
taking the reservation lock. Neither of the today's drivers take the
reservation lock within the mmap() callback, hence it's safe to enforce
the locking.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f54c649f922a..f149b384f4dd 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1390,6 +1390,8 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1410,7 +1412,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
- return dmabuf->ops->mmap(dmabuf, vma);
+ dma_resv_lock(dmabuf->resv, NULL);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+ dma_resv_unlock(dmabuf->resv);
+
+ return ret;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
--
2.37.3
[Intel-gfx] [PATCH v7 17/21] dma-buf: Move dma_buf_map_attachment() to dynamic locking specification
Move dma-buf attachment mapping functions to the dynamic locking
specification by asserting that the reservation lock is held.
Acked-by: Sumit Semwal
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d685a5adb122..f54c649f922a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1038,8 +1038,7 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
- if (dma_buf_attachment_is_dynamic(attach))
- dma_resv_assert_held(attach->dmabuf->resv);
+ dma_resv_assert_held(attach->dmabuf->resv);
if (attach->sgt) {
/*
@@ -1054,7 +1053,6 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
if (dma_buf_is_dynamic(attach->dmabuf)) {
- dma_resv_assert_held(attach->dmabuf->resv);
if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
r = attach->dmabuf->ops->pin(attach);
if (r)
@@ -1143,15 +1141,11 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
- if (dma_buf_attachment_is_dynamic(attach))
- dma_resv_assert_held(attach->dmabuf->resv);
+ dma_resv_assert_held(attach->dmabuf->resv);
if (attach->sgt == sg_table)
return;
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_assert_held(attach->dmabuf->resv);
-
__unmap_dma_buf(attach, sg_table, direction);
if (dma_buf_is_dynamic(attach->dmabuf) &&
--
2.37.3
[Intel-gfx] [PATCH v7 11/21] misc: fastrpc: Prepare to dynamic dma-buf locking specification
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Acked-by: Srinivas Kandagatla
Signed-off-by: Dmitry Osipenko
---
drivers/misc/fastrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 93ebd174d848..6fcfb2e9f7a7 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -310,8 +310,8 @@ static void fastrpc_free_map(struct kref *ref)
return;
}
}
- dma_buf_unmap_attachment(map->attach, map->table,
-DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(map->attach, map->table,
+ DMA_BIDIRECTIONAL);
dma_buf_detach(map->buf, map->attach);
dma_buf_put(map->buf);
}
@@ -726,7 +726,7 @@ static int fastrpc_map_create(struct fastrpc_user *fl, int
fd,
goto attach_err;
}
- map->table = dma_buf_map_attachment(map->attach, DMA_BIDIRECTIONAL);
+ map->table = dma_buf_map_attachment_unlocked(map->attach,
DMA_BIDIRECTIONAL);
if (IS_ERR(map->table)) {
err = PTR_ERR(map->table);
goto map_err;
--
2.37.3
[Intel-gfx] [PATCH v7 12/21] xen/gntdev: Prepare to dynamic dma-buf locking specification
Prepare gntdev driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Juergen Gross
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/xen/gntdev-dmabuf.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 940e5e9e8a54..4440e626b797 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -600,7 +600,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct
device *dev,
gntdev_dmabuf->u.imp.attach = attach;
- sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+ sgt = dma_buf_map_attachment_unlocked(attach, DMA_BIDIRECTIONAL);
if (IS_ERR(sgt)) {
ret = ERR_CAST(sgt);
goto fail_detach;
@@ -658,7 +658,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct
device *dev,
fail_end_access:
dmabuf_imp_end_foreign_access(gntdev_dmabuf->u.imp.refs, count);
fail_unmap:
- dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(attach, sgt, DMA_BIDIRECTIONAL);
fail_detach:
dma_buf_detach(dma_buf, attach);
fail_free_obj:
@@ -708,8 +708,8 @@ static int dmabuf_imp_release(struct gntdev_dmabuf_priv
*priv, u32 fd)
attach = gntdev_dmabuf->u.imp.attach;
if (gntdev_dmabuf->u.imp.sgt)
- dma_buf_unmap_attachment(attach, gntdev_dmabuf->u.imp.sgt,
-DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(attach,
gntdev_dmabuf->u.imp.sgt,
+ DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
dma_buf_put(dma_buf);
--
2.37.3
[Intel-gfx] [PATCH v7 15/21] dma-buf: Move dma_buf_vmap() to dynamic locking specification
Move dma_buf_vmap/vunmap() functions to the dynamic locking specification by asserting that the reservation lock is held. Acked-by: Sumit Semwal Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 3e4060dadb74..2c4381bb9478 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1450,6 +1450,8 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map) if (WARN_ON(!dmabuf)) return -EINVAL; + dma_resv_assert_held(dmabuf->resv); + if (!dmabuf->ops->vmap) return -EINVAL; @@ -1515,6 +1517,8 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map) if (WARN_ON(!dmabuf)) return; + dma_resv_assert_held(dmabuf->resv); + BUG_ON(iosys_map_is_null(>vmap_ptr)); BUG_ON(dmabuf->vmapping_counter == 0); BUG_ON(!iosys_map_is_equal(>vmap_ptr, map)); -- 2.37.3
[Intel-gfx] [PATCH v7 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification
Prepare Etnaviv driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index 3fa2da149639..7031db145a77 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -65,7 +65,7 @@ static void etnaviv_gem_prime_release(struct etnaviv_gem_object *etnaviv_obj) struct iosys_map map = IOSYS_MAP_INIT_VADDR(etnaviv_obj->vaddr); if (etnaviv_obj->vaddr) - dma_buf_vunmap(etnaviv_obj->base.import_attach->dmabuf, ); + dma_buf_vunmap_unlocked(etnaviv_obj->base.import_attach->dmabuf, ); /* Don't drop the pages for imported dmabuf, as they are not * ours, just free the array we allocated: -- 2.37.3
[Intel-gfx] [PATCH v7 14/21] media: tegra-vde: Prepare to dynamic dma-buf locking specification
Prepare Tegra video decoder driver to the common dynamic dma-buf
locking convention by starting to use the unlocked versions of dma-buf
API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
b/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
index 69c346148070..1c5b94989aec 100644
--- a/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
+++ b/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
@@ -38,7 +38,7 @@ static void tegra_vde_release_entry(struct
tegra_vde_cache_entry *entry)
if (entry->vde->domain)
tegra_vde_iommu_unmap(entry->vde, entry->iova);
- dma_buf_unmap_attachment(entry->a, entry->sgt, entry->dma_dir);
+ dma_buf_unmap_attachment_unlocked(entry->a, entry->sgt, entry->dma_dir);
dma_buf_detach(dmabuf, entry->a);
dma_buf_put(dmabuf);
@@ -102,7 +102,7 @@ int tegra_vde_dmabuf_cache_map(struct tegra_vde *vde,
goto err_unlock;
}
- sgt = dma_buf_map_attachment(attachment, dma_dir);
+ sgt = dma_buf_map_attachment_unlocked(attachment, dma_dir);
if (IS_ERR(sgt)) {
dev_err(dev, "Failed to get dmabufs sg_table\n");
err = PTR_ERR(sgt);
@@ -152,7 +152,7 @@ int tegra_vde_dmabuf_cache_map(struct tegra_vde *vde,
err_free:
kfree(entry);
err_unmap:
- dma_buf_unmap_attachment(attachment, sgt, dma_dir);
+ dma_buf_unmap_attachment_unlocked(attachment, sgt, dma_dir);
err_detach:
dma_buf_detach(dmabuf, attachment);
err_unlock:
--
2.37.3
[Intel-gfx] [PATCH v7 13/21] media: videobuf2: Prepare to dynamic dma-buf locking specification
Prepare V4L2 memory allocators to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.
Acked-by: Tomasz Figa
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 ++-
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8
drivers/media/common/videobuf2/videobuf2-vmalloc.c| 6 +++---
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 678b359717c4..79f4d8301fbb 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -101,7 +101,7 @@ static void *vb2_dc_vaddr(struct vb2_buffer *vb, void
*buf_priv)
if (buf->db_attach) {
struct iosys_map map;
- if (!dma_buf_vmap(buf->db_attach->dmabuf, ))
+ if (!dma_buf_vmap_unlocked(buf->db_attach->dmabuf, ))
buf->vaddr = map.vaddr;
return buf->vaddr;
@@ -711,7 +711,7 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
}
/* get the associated scatterlist for this buffer */
- sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
+ sgt = dma_buf_map_attachment_unlocked(buf->db_attach, buf->dma_dir);
if (IS_ERR(sgt)) {
pr_err("Error getting dmabuf scatterlist\n");
return -EINVAL;
@@ -722,7 +722,8 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
if (contig_size < buf->size) {
pr_err("contiguous chunk is too small %lu/%lu\n",
contig_size, buf->size);
- dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+ dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt,
+ buf->dma_dir);
return -EFAULT;
}
@@ -750,10 +751,10 @@ static void vb2_dc_unmap_dmabuf(void *mem_priv)
}
if (buf->vaddr) {
- dma_buf_vunmap(buf->db_attach->dmabuf, );
+ dma_buf_vunmap_unlocked(buf->db_attach->dmabuf, );
buf->vaddr = NULL;
}
- dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+ dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt, buf->dma_dir);
buf->dma_addr = 0;
buf->dma_sgt = NULL;
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index fa69158a65b1..36ecdea8d707 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -309,7 +309,7 @@ static void *vb2_dma_sg_vaddr(struct vb2_buffer *vb, void
*buf_priv)
if (!buf->vaddr) {
if (buf->db_attach) {
- ret = dma_buf_vmap(buf->db_attach->dmabuf, );
+ ret = dma_buf_vmap_unlocked(buf->db_attach->dmabuf,
);
buf->vaddr = ret ? NULL : map.vaddr;
} else {
buf->vaddr = vm_map_ram(buf->pages, buf->num_pages, -1);
@@ -565,7 +565,7 @@ static int vb2_dma_sg_map_dmabuf(void *mem_priv)
}
/* get the associated scatterlist for this buffer */
- sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
+ sgt = dma_buf_map_attachment_unlocked(buf->db_attach, buf->dma_dir);
if (IS_ERR(sgt)) {
pr_err("Error getting dmabuf scatterlist\n");
return -EINVAL;
@@ -594,10 +594,10 @@ static void vb2_dma_sg_unmap_dmabuf(void *mem_priv)
}
if (buf->vaddr) {
- dma_buf_vunmap(buf->db_attach->dmabuf, );
+ dma_buf_vunmap_unlocked(buf->db_attach->dmabuf, );
buf->vaddr = NULL;
}
- dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+ dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt, buf->dma_dir);
buf->dma_sgt = NULL;
}
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 948152f1596b..7831bf545874 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -376,7 +376,7 @@ static int vb2_vmalloc_map_dmabuf(void *mem_priv)
struct iosys_map map;
int ret;
- ret = dma_buf_vmap(buf->dbuf, );
+ ret = dma_buf_vmap_unlocked(buf->dbuf, );
if (ret)
return -EFAULT;
buf->vaddr = map.vaddr;
@@ -389,7 +389,7 @@ static void vb2_vmalloc_unmap_dmabuf(void *mem_priv)
struct vb2_vmalloc_buf *buf = mem_priv;
struct iosys_map map = IOSYS_MAP_INIT_VADDR(buf->vaddr);
- dma_buf_vunmap(buf->dbuf, );
+ dma_buf_vunmap_unlocked(buf->dbuf, );
buf->vaddr = NULL;
}
@@
[Intel-gfx] [PATCH v7 10/21] RDMA/umem: Prepare to dynamic dma-buf locking specification
Prepare InfiniBand drivers to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Jason Gunthorpe Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/infiniband/core/umem_dmabuf.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c index 04c04e6d24c3..43b26bc12288 100644 --- a/drivers/infiniband/core/umem_dmabuf.c +++ b/drivers/infiniband/core/umem_dmabuf.c @@ -26,7 +26,8 @@ int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf) if (umem_dmabuf->sgt) goto wait_fence; - sgt = dma_buf_map_attachment(umem_dmabuf->attach, DMA_BIDIRECTIONAL); + sgt = dma_buf_map_attachment_unlocked(umem_dmabuf->attach, + DMA_BIDIRECTIONAL); if (IS_ERR(sgt)) return PTR_ERR(sgt); @@ -102,8 +103,8 @@ void ib_umem_dmabuf_unmap_pages(struct ib_umem_dmabuf *umem_dmabuf) umem_dmabuf->last_sg_trim = 0; } - dma_buf_unmap_attachment(umem_dmabuf->attach, umem_dmabuf->sgt, -DMA_BIDIRECTIONAL); + dma_buf_unmap_attachment_unlocked(umem_dmabuf->attach, umem_dmabuf->sgt, + DMA_BIDIRECTIONAL); umem_dmabuf->sgt = NULL; } -- 2.37.3
[Intel-gfx] [PATCH v7 08/21] drm/tegra: Prepare to dynamic dma-buf locking specification
Prepare Tegra DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gem.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 81991090adcc..b09b8ab40ae4 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -84,7 +84,7 @@ static struct host1x_bo_mapping *tegra_bo_pin(struct device
*dev, struct host1x_
goto free;
}
- map->sgt = dma_buf_map_attachment(map->attach, direction);
+ map->sgt = dma_buf_map_attachment_unlocked(map->attach,
direction);
if (IS_ERR(map->sgt)) {
dma_buf_detach(buf, map->attach);
err = PTR_ERR(map->sgt);
@@ -160,7 +160,8 @@ static struct host1x_bo_mapping *tegra_bo_pin(struct device
*dev, struct host1x_
static void tegra_bo_unpin(struct host1x_bo_mapping *map)
{
if (map->attach) {
- dma_buf_unmap_attachment(map->attach, map->sgt, map->direction);
+ dma_buf_unmap_attachment_unlocked(map->attach, map->sgt,
+ map->direction);
dma_buf_detach(map->attach->dmabuf, map->attach);
} else {
dma_unmap_sgtable(map->dev, map->sgt, map->direction, 0);
@@ -181,7 +182,7 @@ static void *tegra_bo_mmap(struct host1x_bo *bo)
if (obj->vaddr) {
return obj->vaddr;
} else if (obj->gem.import_attach) {
- ret = dma_buf_vmap(obj->gem.import_attach->dmabuf, );
+ ret = dma_buf_vmap_unlocked(obj->gem.import_attach->dmabuf,
);
return ret ? NULL : map.vaddr;
} else {
return vmap(obj->pages, obj->num_pages, VM_MAP,
@@ -197,7 +198,7 @@ static void tegra_bo_munmap(struct host1x_bo *bo, void
*addr)
if (obj->vaddr)
return;
else if (obj->gem.import_attach)
- dma_buf_vunmap(obj->gem.import_attach->dmabuf, );
+ dma_buf_vunmap_unlocked(obj->gem.import_attach->dmabuf, );
else
vunmap(addr);
}
@@ -461,7 +462,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device
*drm,
get_dma_buf(buf);
- bo->sgt = dma_buf_map_attachment(attach, DMA_TO_DEVICE);
+ bo->sgt = dma_buf_map_attachment_unlocked(attach, DMA_TO_DEVICE);
if (IS_ERR(bo->sgt)) {
err = PTR_ERR(bo->sgt);
goto detach;
@@ -479,7 +480,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device
*drm,
detach:
if (!IS_ERR_OR_NULL(bo->sgt))
- dma_buf_unmap_attachment(attach, bo->sgt, DMA_TO_DEVICE);
+ dma_buf_unmap_attachment_unlocked(attach, bo->sgt,
DMA_TO_DEVICE);
dma_buf_detach(buf, attach);
dma_buf_put(buf);
@@ -508,8 +509,8 @@ void tegra_bo_free_object(struct drm_gem_object *gem)
tegra_bo_iommu_unmap(tegra, bo);
if (gem->import_attach) {
- dma_buf_unmap_attachment(gem->import_attach, bo->sgt,
-DMA_TO_DEVICE);
+ dma_buf_unmap_attachment_unlocked(gem->import_attach, bo->sgt,
+ DMA_TO_DEVICE);
drm_prime_gem_destroy(gem, NULL);
} else {
tegra_bo_free(gem->dev, bo);
--
2.37.3
[Intel-gfx] [PATCH v7 07/21] drm/omapdrm: Prepare to dynamic dma-buf locking specification
Prepare OMAP DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 393f82e26927..8e194dbc9506 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -125,7 +125,7 @@ struct drm_gem_object *omap_gem_prime_import(struct
drm_device *dev,
get_dma_buf(dma_buf);
- sgt = dma_buf_map_attachment(attach, DMA_TO_DEVICE);
+ sgt = dma_buf_map_attachment_unlocked(attach, DMA_TO_DEVICE);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto fail_detach;
@@ -142,7 +142,7 @@ struct drm_gem_object *omap_gem_prime_import(struct
drm_device *dev,
return obj;
fail_unmap:
- dma_buf_unmap_attachment(attach, sgt, DMA_TO_DEVICE);
+ dma_buf_unmap_attachment_unlocked(attach, sgt, DMA_TO_DEVICE);
fail_detach:
dma_buf_detach(dma_buf, attach);
dma_buf_put(dma_buf);
--
2.37.3
[Intel-gfx] [PATCH v7 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
Prepare i915 driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions
and handling cases where importer now holds the reservation lock.
Acked-by: Christian König
Reviewed-by: Michael J. Ruhl
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 14 ++
.../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16
3 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..07eee1c09aaf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf,
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
void *vaddr;
- vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 85482a04d158..7cab89618bad 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -290,7 +290,21 @@ void __i915_gem_object_pages_fini(struct
drm_i915_gem_object *obj)
__i915_gem_object_free_mmaps(obj);
atomic_set(>mm.pages_pin_count, 0);
+
+ /*
+* dma_buf_unmap_attachment() requires reservation to be
+* locked. The imported GEM shouldn't share reservation lock
+* and ttm_bo_cleanup_memtype_use() shouldn't be invoked for
+* dma-buf, so it's safe to take the lock.
+*/
+ if (obj->base.import_attach)
+ i915_gem_object_lock(obj, NULL);
+
__i915_gem_object_put_pages(obj);
+
+ if (obj->base.import_attach)
+ i915_gem_object_unlock(obj);
+
GEM_BUG_ON(i915_gem_object_has_pages(obj));
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index 51ed824b020c..f2f3cfad807b 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
drm_i915_private *i915,
goto out_import;
}
- st = dma_buf_map_attachment(import_attach, DMA_BIDIRECTIONAL);
+ st = dma_buf_map_attachment_unlocked(import_attach, DMA_BIDIRECTIONAL);
if (IS_ERR(st)) {
err = PTR_ERR(st);
goto out_detach;
@@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
drm_i915_private *i915,
timeout = -ETIME;
}
err = timeout > 0 ? 0 : timeout;
- dma_buf_unmap_attachment(import_attach, st, DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(import_attach, st, DMA_BIDIRECTIONAL);
out_detach:
dma_buf_detach(dmabuf, import_attach);
out_import:
@@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
goto out_obj;
}
- err = dma_buf_vmap(dmabuf, );
+ err = dma_buf_vmap_unlocked(dmabuf, );
dma_map = err ? NULL : map.vaddr;
if (!dma_map) {
pr_err("dma_buf_vmap failed\n");
@@ -337,7 +337,7 @@ static int igt_dmabuf_import(void *arg)
err = 0;
out_dma_map:
- dma_buf_vunmap(dmabuf, );
+ dma_buf_vunmap_unlocked(dmabuf, );
out_obj:
i915_gem_object_put(obj);
out_dmabuf:
@@ -358,7 +358,7 @@ static int igt_dmabuf_import_ownership(void *arg)
if (IS_ERR(dmabuf))
return PTR_ERR(dmabuf);
- err = dma_buf_vmap(dmabuf, );
+ err = dma_buf_vmap_unlocked(dmabuf, );
ptr = err ? NULL : map.vaddr;
if (!ptr) {
pr_err("dma_buf_vmap failed\n");
@@ -367,7 +367,7 @@ static int igt_dmabuf_import_ownership(void *arg)
}
memset(ptr, 0xc5, PAGE_SIZE);
- dma_buf_vunmap(dmabuf, );
+ dma_buf_vunmap_unlocked(dmabuf, );
obj = to_intel_bo(i915_gem_prime_import(>drm, dmabuf));
if (IS_ERR(obj)) {
@@ -418,7 +418,7 @@ static int igt_dmabuf_export_vmap(void *arg)
}
i915_gem_object_put(obj);
- err = dma_buf_vmap(dmabuf, );
+ err = dma_buf_vmap_unlocked(dmabuf, );
ptr = err ? NULL : map.vaddr;
if (!ptr) {
pr_err("dma_buf_vmap failed\n");
@@ -435,7 +435,7 @@ static int igt_dmabuf_export_vmap(void *arg)
memset(ptr, 0xc5, dmabuf->size);
err = 0;
- dma_buf_vunmap(dmabuf, );
+ dma_buf_vunmap_unlocked(dmabuf, );
out:
dma_buf_put(dmabuf);
return err;
--
2.37.3
[Intel-gfx] [PATCH v7 05/21] drm/armada: Prepare to dynamic dma-buf locking specification
Prepare Armada driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/armada/armada_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 5430265ad458..26d10065d534 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -66,8 +66,8 @@ void armada_gem_free_object(struct drm_gem_object *obj)
if (dobj->obj.import_attach) {
/* We only ever display imported data */
if (dobj->sgt)
- dma_buf_unmap_attachment(dobj->obj.import_attach,
-dobj->sgt, DMA_TO_DEVICE);
+
dma_buf_unmap_attachment_unlocked(dobj->obj.import_attach,
+ dobj->sgt,
DMA_TO_DEVICE);
drm_prime_gem_destroy(>obj, NULL);
}
@@ -539,8 +539,8 @@ int armada_gem_map_import(struct armada_gem_object *dobj)
{
int ret;
- dobj->sgt = dma_buf_map_attachment(dobj->obj.import_attach,
- DMA_TO_DEVICE);
+ dobj->sgt = dma_buf_map_attachment_unlocked(dobj->obj.import_attach,
+ DMA_TO_DEVICE);
if (IS_ERR(dobj->sgt)) {
ret = PTR_ERR(dobj->sgt);
dobj->sgt = NULL;
--
2.37.3
[Intel-gfx] [PATCH v7 04/21] drm/prime: Prepare to dynamic dma-buf locking specification
Prepare DRM prime core to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_prime.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index a3f180653b8b..ef50c4e2e509 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -936,7 +936,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct
drm_device *dev,
get_dma_buf(dma_buf);
- sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+ sgt = dma_buf_map_attachment_unlocked(attach, DMA_BIDIRECTIONAL);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto fail_detach;
@@ -954,7 +954,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct
drm_device *dev,
return obj;
fail_unmap:
- dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(attach, sgt, DMA_BIDIRECTIONAL);
fail_detach:
dma_buf_detach(dma_buf, attach);
dma_buf_put(dma_buf);
@@ -1052,7 +1052,7 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj,
struct sg_table *sg)
attach = obj->import_attach;
if (sg)
- dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(attach, sg,
DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
/* remove the reference */
--
2.37.3
[Intel-gfx] [PATCH v7 02/21] dma-buf: Add unlocked variant of attachment-mapping functions
Add unlocked variant of dma_buf_map/unmap_attachment() that will
be used by drivers that don't take the reservation lock explicitly.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 53 +++
include/linux/dma-buf.h | 6 +
2 files changed, 59 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e95fc8dc3aed..3e4060dadb74 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1100,6 +1100,34 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
EXPORT_SYMBOL_NS_GPL(dma_buf_map_attachment, DMA_BUF);
+/**
+ * dma_buf_map_attachment_unlocked - Returns the scatterlist table of the
attachment;
+ * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
+ * dma_buf_ops.
+ * @attach:[in]attachment whose scatterlist is to be returned
+ * @direction: [in]direction of DMA transfer
+ *
+ * Unlocked variant of dma_buf_map_attachment().
+ */
+struct sg_table *
+dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
+ enum dma_data_direction direction)
+{
+ struct sg_table *sg_table;
+
+ might_sleep();
+
+ if (WARN_ON(!attach || !attach->dmabuf))
+ return ERR_PTR(-EINVAL);
+
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+ sg_table = dma_buf_map_attachment(attach, direction);
+ dma_resv_unlock(attach->dmabuf->resv);
+
+ return sg_table;
+}
+EXPORT_SYMBOL_NS_GPL(dma_buf_map_attachment_unlocked, DMA_BUF);
+
/**
* dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might
* deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
@@ -1136,6 +1164,31 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
}
EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment, DMA_BUF);
+/**
+ * dma_buf_unmap_attachment_unlocked - unmaps and decreases usecount of the
buffer;might
+ * deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
+ * dma_buf_ops.
+ * @attach:[in]attachment to unmap buffer from
+ * @sg_table: [in]scatterlist info of the buffer to unmap
+ * @direction: [in]direction of DMA transfer
+ *
+ * Unlocked variant of dma_buf_unmap_attachment().
+ */
+void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
+ struct sg_table *sg_table,
+ enum dma_data_direction direction)
+{
+ might_sleep();
+
+ if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
+ return;
+
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+ dma_buf_unmap_attachment(attach, sg_table, direction);
+ dma_resv_unlock(attach->dmabuf->resv);
+}
+EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, DMA_BUF);
+
/**
* dma_buf_move_notify - notify attachments that DMA-buf is moving
*
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 8daa054dd7fe..f11b5bbc2f37 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -627,6 +627,12 @@ int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direction dir);
int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direction dir);
+struct sg_table *
+dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
+ enum dma_data_direction direction);
+void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
+ struct sg_table *sg_table,
+ enum dma_data_direction direction);
int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
--
2.37.3
[Intel-gfx] [PATCH v7 03/21] drm/gem: Take reservation lock for vmap/vunmap operations
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update DRM drivers to
use the locked functions for the case where DRM core now holds the lock.
This patch prepares DRM core and drivers to the common dynamic dma-buf
locking convention.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_client.c | 4 ++--
drivers/gpu/drm/drm_gem.c| 24
drivers/gpu/drm/drm_gem_dma_helper.c | 6 ++---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++---
drivers/gpu/drm/drm_gem_ttm_helper.c | 9 +---
drivers/gpu/drm/lima/lima_sched.c| 4 ++--
drivers/gpu/drm/panfrost/panfrost_dump.c | 4 ++--
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 6 ++---
drivers/gpu/drm/qxl/qxl_object.c | 17 +++---
drivers/gpu/drm/qxl/qxl_prime.c | 4 ++--
include/drm/drm_gem.h| 3 +++
11 files changed, 54 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 2b230b4d6942..fbcb1e995384 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -323,7 +323,7 @@ drm_client_buffer_vmap(struct drm_client_buffer *buffer,
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- ret = drm_gem_vmap(buffer->gem, map);
+ ret = drm_gem_vmap_unlocked(buffer->gem, map);
if (ret)
return ret;
@@ -345,7 +345,7 @@ void drm_client_buffer_vunmap(struct drm_client_buffer
*buffer)
{
struct iosys_map *map = >map;
- drm_gem_vunmap(buffer->gem, map);
+ drm_gem_vunmap_unlocked(buffer->gem, map);
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 86d670c71286..dbee4863e4f7 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1171,6 +1171,8 @@ int drm_gem_vmap(struct drm_gem_object *obj, struct
iosys_map *map)
{
int ret;
+ dma_resv_assert_held(obj->resv);
+
if (!obj->funcs->vmap)
return -EOPNOTSUPP;
@@ -1186,6 +1188,8 @@ EXPORT_SYMBOL(drm_gem_vmap);
void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
{
+ dma_resv_assert_held(obj->resv);
+
if (iosys_map_is_null(map))
return;
@@ -1197,6 +1201,26 @@ void drm_gem_vunmap(struct drm_gem_object *obj, struct
iosys_map *map)
}
EXPORT_SYMBOL(drm_gem_vunmap);
+int drm_gem_vmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+ int ret;
+
+ dma_resv_lock(obj->resv, NULL);
+ ret = drm_gem_vmap(obj, map);
+ dma_resv_unlock(obj->resv);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_vmap_unlocked);
+
+void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+ dma_resv_lock(obj->resv, NULL);
+ drm_gem_vunmap(obj, map);
+ dma_resv_unlock(obj->resv);
+}
+EXPORT_SYMBOL(drm_gem_vunmap_unlocked);
+
/**
* drm_gem_lock_reservations - Sets up the ww context and acquires
* the lock on an array of GEM objects.
diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
b/drivers/gpu/drm/drm_gem_dma_helper.c
index f6901ff97bbb..1e658c448366 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -230,7 +230,7 @@ void drm_gem_dma_free(struct drm_gem_dma_object *dma_obj)
if (gem_obj->import_attach) {
if (dma_obj->vaddr)
- dma_buf_vunmap(gem_obj->import_attach->dmabuf, );
+ dma_buf_vunmap_unlocked(gem_obj->import_attach->dmabuf,
);
drm_prime_gem_destroy(gem_obj, dma_obj->sgt);
} else if (dma_obj->vaddr) {
if (dma_obj->map_noncoherent)
@@ -581,7 +581,7 @@ drm_gem_dma_prime_import_sg_table_vmap(struct drm_device
*dev,
struct iosys_map map;
int ret;
- ret = dma_buf_vmap(attach->dmabuf, );
+ ret = dma_buf_vmap_unlocked(attach->dmabuf, );
if (ret) {
DRM_ERROR("Failed to vmap PRIME buffer\n");
return ERR_PTR(ret);
@@ -589,7 +589,7 @@ drm_gem_dma_prime_import_sg_table_vmap(struct drm_device
*dev,
obj = drm_gem_dma_prime_import_sg_table(dev, attach, sgt);
if (IS_ERR(obj)) {
- dma_buf_vunmap(attach->dmabuf, );
+ dma_buf_vunmap_unlocked(attach->dmabuf, );
return obj;
}
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 880a4975507f..e35e224e6303 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -354,7 +354,7 @@ int
[Intel-gfx] [PATCH v7 01/21] dma-buf: Add unlocked variant of vmapping functions
Add unlocked variant of dma_buf_vmap/vunmap() that will be utilized
by drivers that don't take the reservation lock explicitly.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 43 +++
include/linux/dma-buf.h | 2 ++
2 files changed, 45 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index efb4990b29e1..e95fc8dc3aed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1425,6 +1425,33 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct
iosys_map *map)
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vmap, DMA_BUF);
+/**
+ * dma_buf_vmap_unlocked - Create virtual mapping for the buffer object into
kernel
+ * address space. Same restrictions as for vmap and friends apply.
+ * @dmabuf:[in]buffer to vmap
+ * @map: [out] returns the vmap pointer
+ *
+ * Unlocked version of dma_buf_vmap()
+ *
+ * Returns 0 on success, or a negative errno code otherwise.
+ */
+int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map)
+{
+ int ret;
+
+ iosys_map_clear(map);
+
+ if (WARN_ON(!dmabuf))
+ return -EINVAL;
+
+ dma_resv_lock(dmabuf->resv, NULL);
+ ret = dma_buf_vmap(dmabuf, map);
+ dma_resv_unlock(dmabuf->resv);
+
+ return ret;
+}
+EXPORT_SYMBOL_NS_GPL(dma_buf_vmap_unlocked, DMA_BUF);
+
/**
* dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
* @dmabuf:[in]buffer to vunmap
@@ -1449,6 +1476,22 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct
iosys_map *map)
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap, DMA_BUF);
+/**
+ * dma_buf_vunmap_unlocked - Unmap a vmap obtained by dma_buf_vmap.
+ * @dmabuf:[in]buffer to vunmap
+ * @map: [in]vmap pointer to vunmap
+ */
+void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map)
+{
+ if (WARN_ON(!dmabuf))
+ return;
+
+ dma_resv_lock(dmabuf->resv, NULL);
+ dma_buf_vunmap(dmabuf, map);
+ dma_resv_unlock(dmabuf->resv);
+}
+EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap_unlocked, DMA_BUF);
+
#ifdef CONFIG_DEBUG_FS
static int dma_buf_debug_show(struct seq_file *s, void *unused)
{
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 71731796c8c3..8daa054dd7fe 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -632,4 +632,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map);
void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map);
+int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map);
+void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map);
#endif /* __DMA_BUF_H__ */
--
2.37.3
[Intel-gfx] [PATCH v7 00/21] Move all drivers to a common dma-buf locking convention
Hello, This series moves all drivers to a dynamic dma-buf locking specification. >From now on all dma-buf importers are made responsible for holding dma-buf's reservation lock around all operations performed over dma-bufs in accordance to the locking specification. This allows us to utilize reservation lock more broadly around kernel without fearing of a potential deadlocks. This patchset passes all i915 selftests. It was also tested using VirtIO, Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested cases of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where appropriate), which covers majority of kernel drivers since rest of the drivers share same or similar code paths. Changelog: v7: - Rebased on top of recent drm-misc-next. - Added ack from Jason Gunthorpe to the RDMA patch. - Added iosys_map_clear() to dma_buf_vmap_unlocked(), making it fully consistent with dma_buf_vmap(). v6: - Added r-b from Michael Ruhl to the i915 patch. - Added acks from Sumit Semwal and updated commit message of the "Move dma_buf_vmap() to dynamic locking specification" patch like was suggested by Sumit. - Added "!dmabuf" check to dma_buf_vmap_unlocked() to match the locked variant of the function, for consistency. v5: - Added acks and r-bs that were given to v4. - Changed i915 preparation patch like was suggested by Michael Ruhl. The scope of reservation locking is smaller now. v4: - Added dma_buf_mmap() to the "locking convention" documentation, which was missed by accident in v3. - Added acks from Christian König, Tomasz Figa and Hans Verkuil that they gave to couple v3 patches. - Dropped the "_unlocked" postfix from function names that don't have the locked variant, as was requested by Christian König. - Factored out the per-driver preparations into separate patches to ease reviewing of the changes, which is now doable without the global dma-buf functions renaming. - Factored out the dynamic locking convention enforcements into separate patches which add the final dma_resv_assert_held(dmabuf->resv) to the dma-buf API functions. v3: - Factored out dma_buf_mmap_unlocked() and attachment functions into aseparate patches, like was suggested by Christian König. - Corrected and factored out dma-buf locking documentation into a separate patch, like was suggested by Christian König. - Intel driver dropped the reservation locking fews days ago from its BO-release code path, but we need that locking for the imported GEMs because in the end that code path unmaps the imported GEM. So I added back the locking needed by the imported GEMs, updating the "dma-buf attachment locking specification" patch appropriately. - Tested Nouveau+Intel dma-buf import/export combo. - Tested udmabuf import to i915/Nouveau/AMDGPU. - Fixed few places in Etnaviv, Panfrost and Lima drivers that I missed to switch to locked dma-buf vmapping in the drm/gem: Take reservation lock for vmap/vunmap operations" patch. In a result invalidated the Christian's r-b that he gave to v2. - Added locked dma-buf vmap/vunmap functions that are needed for fixing vmappping of Etnaviv, Panfrost and Lima drivers mentioned above. I actually had this change stashed for the drm-shmem shrinker patchset, but then realized that it's already needed by the dma-buf patches. Also improved my tests to better cover these code paths. v2: - Changed locking specification to avoid problems with a cross-driver ww locking, like was suggested by Christian König. Now the attach/detach callbacks are invoked without the held lock and exporter should take the lock. - Added "locking convention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (21): dma-buf: Add unlocked variant of vmapping functions dma-buf: Add unlocked variant of attachment-mapping functions drm/gem: Take reservation lock for vmap/vunmap operations drm/prime: Prepare to dynamic dma-buf locking specification drm/armada: Prepare to dynamic dma-buf locking specification drm/i915: Prepare to dynamic dma-buf locking specification drm/omapdrm: Prepare to dynamic dma-buf locking specification drm/tegra: Prepare to dynamic dma-buf locking specification drm/etnaviv: Prepare to dynamic dma-buf locking specification RDMA/umem: Prepare to dynamic dma-buf locking specification misc: fastrpc: Prepare to dynamic dma-buf locking specification xen/gntdev: Prepare to dynamic dma-buf locking specification media: videobuf2: Prepare to dynamic dma-buf locking specification media: tegra-vde: Prepare to dynamic dma-buf locking specification
Re: [Intel-gfx] [PATCH] drm/i915: fix clear mask in GEN7_MISCCPCTL update
On Mon, Oct 17, 2022 at 10:55:25AM +0200, Andrzej Hajda wrote:
GEN7_DOP_CLOCK_GATE_ENABLE bit should be cleared, not inverse.
The bug was introduced during conversion to intel_uncore_rmw helper.
Suggested-by: Matt Roper
Fixes: 8cee664d3eb6f8 ("drm/i915: use proper helper for register updates")
Signed-off-by: Andrzej Hajda
Reviewed-by: Lucas De Marchi
Lucas De Marchi
Re: [Intel-gfx] [PATCH v2 2/7] drm/i915/pxp: Make intel_pxp_is_enabled implicitly sort PXP-owning-GT
On Thu, 2022-10-13 at 14:10 -0700, Ceraolo Spurio, Daniele wrote:
>
> On 10/5/2022 9:38 PM, Alan Previn wrote:
> > Make intel_pxp_is_enabled implicitly find the PXP-owning-GT.
> > PXP feature support is a device-config flag. In preparation for MTL
> > PXP control-context shall reside on of the two GT's.
> > That said, update intel_pxp_is_enabled to take in i915 as its input
> > and internally find the right gt to check if PXP is enabled so
> > its transparent to callers of this functions.
> >
Alan:[snip]
> >
> > +struct intel_gt *intel_pxp_get_owning_gt(struct drm_i915_private *i915)
>
> This seems to only be used inside this file, so it should be static.
>
will fix this.
> > +{
> > + struct intel_gt *gt = NULL;
> > + int i = 0;
> > +
> > + for_each_gt(gt, i915, i) {
> > + if (gt && gt->pxptee_iface_owner)
> > + return gt;
> > + }
> > + return NULL;
> > +}
> > +
> > struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp)
> > {
> > return container_of(pxp, struct intel_gt, pxp);
> > }
> >
> > -bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
> > +static bool _pxp_is_enabled(struct intel_pxp *pxp)
>
> I believe this is going to be needed outside this file (more comments
> below, I'm going to refer to this as the per-gt checker).
>
> > {
> > return pxp->ce;
> > }
> >
> >
Alan:[snip]
> >
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> > index f41e45763d0d..1d409149c0e8 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> > @@ -99,7 +99,7 @@ int intel_pxp_terminate_session(struct intel_pxp *pxp,
> > u32 id)
> > u32 *cs;
> > int err = 0;
> >
> > - if (!intel_pxp_is_enabled(pxp))
> > + if (!intel_pxp_is_enabled(pxp_to_gt(pxp)->i915))
>
> This is a gt-specific function, so it should use the per-gt checker.
>
Understood - as per offline conversation, it looks like we need both a
gt-version and a global-version of
intel_pxp_enabled depending on the caller (and whether its being driven out of
a callstack/subsystem that is gt specific
or not).
> > return 0;
> >
> > rq = i915_request_create(ce);
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > index 7b37f061044d..907d3aba7a9c 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > @@ -18,7 +18,7 @@ static int pxp_info_show(struct seq_file *m, void *data)
> > {
> > struct intel_pxp *pxp = m->private;
> > struct drm_printer p = drm_seq_file_printer(m);
> > - bool enabled = intel_pxp_is_enabled(pxp);
> > + bool enabled = intel_pxp_is_enabled(pxp_to_gt(pxp)->i915);
>
> This is a gt-specific function, so it should use the per-gt checker.
agreed (same as above)
>
> >
> > if (!enabled) {
> > drm_printf(, "pxp disabled\n");
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > index c28be430718a..6f515c163d2f 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > @@ -22,7 +22,10 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16
> > iir)
> > {
> > struct intel_gt *gt = pxp_to_gt(pxp);
> >
> > - if (GEM_WARN_ON(!intel_pxp_is_enabled(pxp)))
> > + if (!gt->pxptee_iface_owner)
> > + return;
>
> Do you need this? the if below should include this case.
>
You are right but let me get back to you coz of future MTL support preparation
where we might need both these checks
(but perhaps we wont to debate this once we roll out the two versions of
'enabled' ( intel_pxp_enabled vs
intel_pxp_gt_enabled" then the irq handler would be calling ONLY the latter
newer function that would be enough.
> > +
> > + if (GEM_WARN_ON(!intel_pxp_is_enabled(gt->i915)))
> > return;
> >
> > lockdep_assert_held(gt->irq_lock);
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > index 6a7d4e2ee138..5f713ac5c3ce 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > @@ -11,7 +11,7 @@
> >
> > void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
> > {
> > - if (!intel_pxp_is_enabled(pxp))
> > + if (!intel_pxp_is_enabled(pxp_to_gt(pxp)->i915))
> > return;
> >
>
> This is called from a gt-specific function, so it should use the per-gt
> checker. Same for all the other suspend/resume calls.
yeah - undestood
>
> > pxp->arb_is_valid = false;
> > @@ -23,7 +23,7 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
> > {
> > intel_wakeref_t wakeref;
> >
> > - if (!intel_pxp_is_enabled(pxp))
> > + if (!intel_pxp_is_enabled(pxp_to_gt(pxp)->i915))
> > return;
> >
> >
Re: [Intel-gfx] [PATCH v3 14/14] drm/i915/xelpmp: Add multicast steering for media GT
On 14.10.2022 16:02, Matt Roper wrote:
> MTL's media IP (Xe_LPM+) only has a single type of steering ("OAADDRM")
> which selects between media slice 0 and media slice 1. We'll always
> steer to media slice 0 unless it is fused off (which is the case when
> VD0, VE0, and SFC0 are all reported as unavailable).
>
> Bspec: 67789
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 18 --
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 17 +++--
> 3 files changed, 32 insertions(+), 4 deletions(-)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index 23a1ef9659bf..0d2811724b00 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -42,6 +42,7 @@ static const char * const intel_steering_types[] = {
> "LNCF",
> "GAM",
> "DSS",
> + "OADDRM",
> "INSTANCE 0",
> };
>
> @@ -129,6 +130,11 @@ static const struct intel_mmio_range
> xelpg_dss_steering_table[] = {
> { 0x00DE80, 0x00E8FF }, /* DSS (0xE000-0xE0FF reserved) */
> };
>
> +static const struct intel_mmio_range xelpmp_oaddrm_steering_table[] = {
> + { 0x393200, 0x39323F },
> + { 0x393400, 0x3934FF },
> +};
> +
> void intel_gt_mcr_init(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> @@ -151,8 +157,9 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> drm_warn(>drm, "mslice mask all zero!\n");
> }
>
> - if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70) &&
> - gt->type == GT_PRIMARY) {
> + if (MEDIA_VER(i915) >= 13 && gt->type == GT_MEDIA) {
> + gt->steering_table[OADDRM] = xelpmp_oaddrm_steering_table;
> + } else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
> fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
>intel_uncore_read(gt->uncore, XEHP_FUSE4));
>
> @@ -514,6 +521,13 @@ static void get_nonterminated_steering(struct intel_gt
> *gt,
> *group = 0;
> *instance = 0;
> break;
> + case OADDRM:
> + if ((VDBOX_MASK(gt) | VEBOX_MASK(gt) | gt->info.sfc_mask) &
> BIT(0))
> + *group = 0;
> + else
> + *group = 1;
> + *instance = 0;
> + break;
> default:
> MISSING_CASE(type);
> *group = 0;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index 0bb73d110a84..64aa2ba624fc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -61,6 +61,7 @@ enum intel_steering_type {
> LNCF,
> GAM,
> DSS,
> + OADDRM,
>
> /*
>* On some platforms there are multiple types of MCR registers that
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 711a31935857..bae960486872 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1598,14 +1598,27 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> debug_dump_steering(gt);
> }
>
> +static void
> +xelpmp_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> +{
> + /* FIXME: Actual workarounds will be added in future patch(es) */
> +
> + debug_dump_steering(gt);
> +}
> +
> static void
> gt_init_workarounds(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> struct drm_i915_private *i915 = gt->i915;
>
> - /* FIXME: Media GT handling will be added in an upcoming patch */
> - if (gt->type == GT_MEDIA)
> + if (gt->type == GT_MEDIA) {
> + if (MEDIA_VER(i915) >= 13)
> + xelpmp_gt_workarounds_init(gt, wal);
> + else
> + MISSING_CASE(MEDIA_VER(i915));
> +
> return;
> + }
>
> if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
> xelpg_gt_workarounds_init(gt, wal);
> --
> 2.37.3
>
Re: [Intel-gfx] [PATCH v3 13/14] drm/i915/xelpg: Add multicast steering
On 14.10.2022 16:02, Matt Roper wrote:
> MTL's graphics IP (Xe_LPG) once again changes the multicast register
> types and steering details. Key changes from past platforms:
> * The number of instances of some MCR types (NODE, OAAL2, and GAM) vary
>according to the MTL subplatform and cannot be read from fuse
>registers. However steering to instance #0 will always provided a
>non-terminated value, so we can lump these all into a single
>"instance0" table.
> * The MCR steering register (and its bitfields) has changed.
>
> Unlike past platforms, we will be explicitly steering all types of MCR
> accesses, including those for "SLICE" and "DSS" ranges; we no longer
> rely on implicit steering. On previous platforms, various
> hardware/firmware agents that needed to access registers typically had
> their own steering control registers, allowing them to perform multicast
> steering without clobbering the CPU/kernel steering. Starting with MTL,
> more of these agents now share a single steering register (0xFD4) and it
> is no longer safe for us to assume that the value will remain unchanged
> from how we initialized it during startup. There is also a slight
> chance of race conditions between the driver and a hardware/firmware
> agent, so the hardware provides a semaphore register that can be used to
> coordinate access to the steering register. Support for the semaphore
> register will be introduced in a future patch.
>
> v2:
> - Use Xe_LPG terminology instead of "MTL 3D" since it's the IP version
>we're matching on now rather than the platform.
> - Don't combine l3bank and mslice masks into a union. It's not related
>to the other changes here and we might still need both of them on
>some future platform.
> - Separate debug dumping of steering settings to a separate helper
>function. (Tvrtko)
> - Update debug dumping to include DSS ranges (and future-proof it so
>that any new ranges added on future platforms will also be dumped).
> - Restore MULTICAST bit at the end of rw_with_mcr_steering_fw() if we
>cleared it. Also force the MULTICAST bit to true at the beginning of
>multicast writes just to be safe. (Bala)
>
> Bspec: 67788, 67112
> Cc: Radhakrishna Sripada
> Cc: Balasubramani Vivekanandan
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 135 +---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 33 -
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 5 files changed, 154 insertions(+), 21 deletions(-)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index 349074bf365f..23a1ef9659bf 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -41,6 +41,7 @@ static const char * const intel_steering_types[] = {
> "MSLICE",
> "LNCF",
> "GAM",
> + "DSS",
> "INSTANCE 0",
> };
>
> @@ -99,9 +100,40 @@ static const struct intel_mmio_range
> pvc_instance0_steering_table[] = {
> {},
> };
>
> +static const struct intel_mmio_range xelpg_instance0_steering_table[] = {
> + { 0x000B00, 0x000BFF }, /* SQIDI */
> + { 0x001000, 0x001FFF }, /* SQIDI */
> + { 0x004000, 0x0048FF }, /* GAM */
> + { 0x008700, 0x0087FF }, /* SQIDI */
> + { 0x00B000, 0x00B0FF }, /* NODE */
> + { 0x00C800, 0x00CFFF }, /* GAM */
> + { 0x00D880, 0x00D8FF }, /* NODE */
> + { 0x00DD00, 0x00DDFF }, /* OAAL2 */
> + {},
> +};
> +
> +static const struct intel_mmio_range xelpg_l3bank_steering_table[] = {
> + { 0x00B100, 0x00B3FF },
> + {},
> +};
> +
> +/* DSS steering is used for SLICE ranges as well */
> +static const struct intel_mmio_range xelpg_dss_steering_table[] = {
> + { 0x005200, 0x0052FF }, /* SLICE */
> + { 0x005500, 0x007FFF }, /* SLICE */
> + { 0x008140, 0x00815F }, /* SLICE (0x8140-0x814F), DSS
> (0x8150-0x815F) */
> + { 0x0094D0, 0x00955F }, /* SLICE (0x94D0-0x951F), DSS
> (0x9520-0x955F) */
> + { 0x009680, 0x0096FF }, /* DSS */
> + { 0x00D800, 0x00D87F }, /* SLICE */
> + { 0x00DC00, 0x00DCFF }, /* SLICE */
> + { 0x00DE80, 0x00E8FF }, /* DSS (0xE000-0xE0FF reserved) */
> +};
> +
> void intel_gt_mcr_init(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> + unsigned long fuse;
> + int i;
>
> /*
>* An mslice is unavailable only if both the meml3 for the slice is
> @@ -119,7 +151,22 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> drm_warn(>drm, "mslice mask all zero!\n");
> }
>
> - if (IS_PONTEVECCHIO(i915)) {
> + if
Re: [Intel-gfx] [PATCH v2 1/7] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT
On Thu, 2022-10-13 at 13:48 -0700, Ceraolo Spurio, Daniele wrote:
>
> On 10/5/2022 9:38 PM, Alan Previn wrote:
> > In preparation for future MTL-PXP feature support, PXP control
> > context should only valid on the correct gt tile. Depending on the
> > device-info this mat not necessarily be the root GT tile and
> > depends on which tile owns the VEBOX and KCR.
> >
Alan:[snip]
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index b367cfff48d5..e61f6c5ed440 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -850,6 +850,10 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> > gt->name = "Primary GT";
> > gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> >
> > + /* device config determines which GT owns the global pxp-tee context */
> > + if (VDBOX_MASK(gt) && !INTEL_INFO(i915)->has_nonroot_pxpgt)
> > + gt->pxptee_iface_owner = true;
> > +
>
> I'm not convinced that we need dedicated has_nonroot_pxpgt and
> pxptee_iface_owner flags. MTL moves the GSC inside a GT and the owner of
> PXP is the GT where the GSC engine resides. So we could have a checker like:
>
> bool intel_pxp_supported(struct intel_gt *gt)
> {
> /* we only support HECI PXP from the root GT */
> if (HAS_HECI_PXP(gt->i915))
> return gt_is_root(gt);
>
> return HAS_ENGINE(gt, GSC);
> }
>
> I'm aware that the GSC engine code is still not available, but we can
> special case for MTL for now and then replace it when the GSC code lands:
>
> bool intel_pxp_supported(struct intel_gt *gt)
> {
> /* we only support HECI PXP from the root GT */
> if (HAS_HECI_PXP(gt->i915))
> return gt_is_root(gt);
>
> /* TODO: replace with GSC check */
> return IS_METEORLAKE(gt->i915) && !gt_is_root(gt);
> }
>
> Then we can use intel_pxp_supported(gt) instead of
> gt->pxptee_iface_owner and we can drop has_nonroot_pxpgt. Might also be
> worth merging this with HAS_PXP for a unified check, but that can come
> later.
>
> Daniele
As per offline conversations, we know above combination may not work for the
DG2 case, but i'll go ahead and re-rev this
after i look for another way to avoid creating another device info variable-
i'll try to get a karnaugh map going to
ensure we have a good combination of existing device-config info that are
reliable for all current and MTL usages else
we may need a new device-config after all (maybe a better named one if needed).
Re: [Intel-gfx] [PATCH v3 12/14] drm/i915: Define multicast registers as a new type
On 14.10.2022 16:02, Matt Roper wrote:
> Rather than treating multicast registers as 'i915_reg_t' let's define
> them as a completely new type. This will allow the compiler to help us
> make sure we're using multicast-aware functions to operate on multicast
> registers.
>
> This plan does break down a bit in places where we're just maintaining
> heterogeneous lists of registers (e.g., various MMIO whitelists used by
> perf, GVT, etc.) rather than performing reads/writes. We only really
> care about the offset in those cases, so for now we can "cast" the
> registers as non-MCR, leaving us with a list of i915_reg_t's, but we may
> want to look for better ways to store mixed collections of i915_reg_t
> and i915_mcr_reg_t in the future.
>
> v2:
> - Add TLB invalidation registers
> v3:
> - Make type checking of i915_mmio_reg_offset() stricter. It will
>accept either i915_reg_t or i915_mcr_reg_t, but will now raise a
>compile error if any other type is passed, even if that type contains
>a 'reg' field. (Jani)
> - Drop a ton of GVT changes; allowing i915_mmio_reg_offset() to take
>either an i915_reg_t or an i915_mcr_reg_t means that the huge lists
>of MMIO_D*() macros used in GVT will continue to work without
>modification. We need only make changes to structures that have an
>explicit i915_reg_t in them now.
>
> Cc: Jani Nikula
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c| 16 --
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 51 ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.h| 18 +++
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 27 +++---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 32 ++--
> .../gpu/drm/i915/gt/intel_workarounds_types.h | 5 +-
> .../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 4 +-
> drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
> drivers/gpu/drm/i915/gvt/mmio_context.c | 14 ++---
> drivers/gpu/drm/i915/i915_reg_defs.h | 27 +-
> 12 files changed, 117 insertions(+), 83 deletions(-)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 3df0d0336dbc..27dbb9e4bd6c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -991,7 +991,10 @@ void intel_gt_info_print(const struct intel_gt_info
> *info,
> }
>
> struct reg_and_bit {
> - i915_reg_t reg;
> + union {
> + i915_reg_t reg;
> + i915_mcr_reg_t mcr_reg;
> + };
> u32 bit;
> };
>
> @@ -1033,7 +1036,7 @@ get_reg_and_bit(const struct intel_engine_cs *engine,
> const bool gen8,
> static int wait_for_invalidate(struct intel_gt *gt, struct reg_and_bit rb)
> {
> if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50))
> - return intel_gt_mcr_wait_for_reg_fw(gt, rb.reg, rb.bit, 0,
> + return intel_gt_mcr_wait_for_reg_fw(gt, rb.mcr_reg, rb.bit, 0,
> TLB_INVAL_TIMEOUT_US,
> TLB_INVAL_TIMEOUT_MS);
> else
> @@ -1058,7 +1061,7 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> [COPY_ENGINE_CLASS] = GEN12_BLT_TLB_INV_CR,
> [COMPUTE_CLASS] = GEN12_COMPCTX_TLB_INV_CR,
> };
> - static const i915_reg_t xehp_regs[] = {
> + static const i915_mcr_reg_t xehp_regs[] = {
> [RENDER_CLASS] = XEHP_GFX_TLB_INV_CR,
> [VIDEO_DECODE_CLASS]= XEHP_VD_TLB_INV_CR,
> [VIDEO_ENHANCEMENT_CLASS] = XEHP_VE_TLB_INV_CR,
> @@ -1131,7 +1134,12 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> for_each_engine_masked(engine, gt, awake, tmp) {
> struct reg_and_bit rb;
>
> - rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);
> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
> + rb.mcr_reg = xehp_regs[engine->class];
> + rb.bit = BIT(engine->instance);
> + } else {
> + rb = get_reg_and_bit(engine, regs == gen8_regs, regs,
> num);
> + }
>
> if (wait_for_invalidate(gt, rb))
> drm_err_ratelimited(>i915->drm,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index 1ed9bc4dccfd..349074bf365f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -150,6 +150,19 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> }
> }
>
> +/*
> + * Although the rest of the driver should use MCR-specific functions to
> + * read/write MCR registers, we still use the
Re: [Intel-gfx] [PATCH v3 11/14] drm/i915/gt: Add MCR-specific workaround initializers
On 14.10.2022 16:02, Matt Roper wrote:
> Let's be more explicit about which of our workarounds are updating MCR
> registers.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 433 +++---
> .../gpu/drm/i915/gt/intel_workarounds_types.h | 4 +-
> 2 files changed, 263 insertions(+), 174 deletions(-)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 96b9f02a2284..7671994d5b7a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -166,12 +166,33 @@ static void wa_add(struct i915_wa_list *wal, i915_reg_t
> reg,
> _wa_add(wal, );
> }
>
> +static void wa_mcr_add(struct i915_wa_list *wal, i915_reg_t reg,
> +u32 clear, u32 set, u32 read_mask, bool masked_reg)
> +{
> + struct i915_wa wa = {
> + .reg = reg,
> + .clr = clear,
> + .set = set,
> + .read = read_mask,
> + .masked_reg = masked_reg,
> + .is_mcr = 1,
> + };
> +
> + _wa_add(wal, );
> +}
> +
> static void
> wa_write_clr_set(struct i915_wa_list *wal, i915_reg_t reg, u32 clear, u32
> set)
> {
> wa_add(wal, reg, clear, set, clear, false);
> }
>
> +static void
> +wa_mcr_write_clr_set(struct i915_wa_list *wal, i915_reg_t reg, u32 clear,
> u32 set)
> +{
> + wa_mcr_add(wal, reg, clear, set, clear, false);
> +}
> +
> static void
> wa_write(struct i915_wa_list *wal, i915_reg_t reg, u32 set)
> {
> @@ -184,12 +205,24 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg,
> u32 set)
> wa_write_clr_set(wal, reg, set, set);
> }
>
> +static void
> +wa_mcr_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32 set)
> +{
> + wa_mcr_write_clr_set(wal, reg, set, set);
> +}
> +
> static void
> wa_write_clr(struct i915_wa_list *wal, i915_reg_t reg, u32 clr)
> {
> wa_write_clr_set(wal, reg, clr, 0);
> }
>
> +static void
> +wa_mcr_write_clr(struct i915_wa_list *wal, i915_reg_t reg, u32 clr)
> +{
> + wa_mcr_write_clr_set(wal, reg, clr, 0);
> +}
> +
> /*
> * WA operations on "masked register". A masked register has the upper 16
> bits
> * documented as "masked" in b-spec. Its purpose is to allow writing to just
> a
> @@ -207,12 +240,24 @@ wa_masked_en(struct i915_wa_list *wal, i915_reg_t reg,
> u32 val)
> wa_add(wal, reg, 0, _MASKED_BIT_ENABLE(val), val, true);
> }
>
> +static void
> +wa_mcr_masked_en(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
> +{
> + wa_mcr_add(wal, reg, 0, _MASKED_BIT_ENABLE(val), val, true);
> +}
> +
> static void
> wa_masked_dis(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
> {
> wa_add(wal, reg, 0, _MASKED_BIT_DISABLE(val), val, true);
> }
>
> +static void
> +wa_mcr_masked_dis(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
> +{
> + wa_mcr_add(wal, reg, 0, _MASKED_BIT_DISABLE(val), val, true);
> +}
> +
> static void
> wa_masked_field_set(struct i915_wa_list *wal, i915_reg_t reg,
> u32 mask, u32 val)
> @@ -220,6 +265,13 @@ wa_masked_field_set(struct i915_wa_list *wal, i915_reg_t
> reg,
> wa_add(wal, reg, 0, _MASKED_FIELD(mask, val), mask, true);
> }
>
> +static void
> +wa_mcr_masked_field_set(struct i915_wa_list *wal, i915_reg_t reg,
> + u32 mask, u32 val)
> +{
> + wa_mcr_add(wal, reg, 0, _MASKED_FIELD(mask, val), mask, true);
> +}
> +
> static void gen6_ctx_workarounds_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> {
> @@ -241,8 +293,8 @@ static void gen8_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> wa_masked_en(wal, RING_MI_MODE(RENDER_RING_BASE),
> ASYNC_FLIP_PERF_DISABLE);
>
> /* WaDisablePartialInstShootdown:bdw,chv */
> - wa_masked_en(wal, GEN8_ROW_CHICKEN,
> - PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
> + wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN,
> + PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
>
> /* Use Force Non-Coherent whenever executing a 3D context. This is a
>* workaround for a possible hang in the unlikely event a TLB
> @@ -288,18 +340,18 @@ static void bdw_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> gen8_ctx_workarounds_init(engine, wal);
>
> /* WaDisableThreadStallDopClockGating:bdw (pre-production) */
> - wa_masked_en(wal, GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
> + wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
>
> /* WaDisableDopClockGating:bdw
>*
>* Also see the related UCGTCL1 write in bdw_init_clock_gating()
>* to disable EUTC clock gating.
>*/
> - wa_masked_en(wal, GEN8_ROW_CHICKEN2,
> - DOP_CLOCK_GATING_DISABLE);
> + wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN2,
> +
Re: [Intel-gfx] [PATCH v3 10/14] drm/i915/guc: Handle save/restore of MCR registers explicitly
On 14.10.2022 16:02, Matt Roper wrote:
> MCR registers can be placed on the GuC's save/restore list, but at the
> moment they are always handled in a multicast manner (i.e., the GuC
> reads one instance to save the value and then does a multicast write to
> restore that single value to all instances). In the future the GuC will
> probably give us an alternate interface to do unicast per-instance
> save/restore operations, so we should be very clear about which
> registers on the list are MCR registers (and in the future which
> save/restore behavior we want for them).
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 55 +-
> 1 file changed, 34 insertions(+), 21 deletions(-)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index cc357fa0c270..de923fb82301 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -278,24 +278,16 @@ __mmio_reg_add(struct temp_regset *regset, struct
> guc_mmio_reg *reg)
> return slot;
> }
>
> -#define GUC_REGSET_STEERING(group, instance) ( \
> - FIELD_PREP(GUC_REGSET_STEERING_GROUP, (group)) | \
> - FIELD_PREP(GUC_REGSET_STEERING_INSTANCE, (instance)) | \
> - GUC_REGSET_NEEDS_STEERING \
> -)
> -
> static long __must_check guc_mmio_reg_add(struct intel_gt *gt,
> struct temp_regset *regset,
> - i915_reg_t reg, u32 flags)
> + u32 offset, u32 flags)
> {
> u32 count = regset->storage_used - (regset->registers -
> regset->storage);
> - u32 offset = i915_mmio_reg_offset(reg);
> struct guc_mmio_reg entry = {
> .offset = offset,
> .flags = flags,
> };
> struct guc_mmio_reg *slot;
> - u8 group, inst;
>
> /*
>* The mmio list is built using separate lists within the driver.
> @@ -307,17 +299,6 @@ static long __must_check guc_mmio_reg_add(struct
> intel_gt *gt,
> sizeof(entry), guc_mmio_reg_cmp))
> return 0;
>
> - /*
> - * The GuC doesn't have a default steering, so we need to explicitly
> - * steer all registers that need steering. However, we do not keep track
> - * of all the steering ranges, only of those that have a chance of using
> - * a non-default steering from the i915 pov. Instead of adding such
> - * tracking, it is easier to just program the default steering for all
> - * regs that don't need a non-default one.
> - */
> - intel_gt_mcr_get_nonterminated_steering(gt, reg, , );
> - entry.flags |= GUC_REGSET_STEERING(group, inst);
> -
> slot = __mmio_reg_add(regset, );
> if (IS_ERR(slot))
> return PTR_ERR(slot);
> @@ -335,6 +316,38 @@ static long __must_check guc_mmio_reg_add(struct
> intel_gt *gt,
>
> #define GUC_MMIO_REG_ADD(gt, regset, reg, masked) \
> guc_mmio_reg_add(gt, \
> + regset, \
> + i915_mmio_reg_offset(reg), \
> + (masked) ? GUC_REGSET_MASKED : 0)
> +
> +#define GUC_REGSET_STEERING(group, instance) ( \
> + FIELD_PREP(GUC_REGSET_STEERING_GROUP, (group)) | \
> + FIELD_PREP(GUC_REGSET_STEERING_INSTANCE, (instance)) | \
> + GUC_REGSET_NEEDS_STEERING \
> +)
> +
> +static long __must_check guc_mcr_reg_add(struct intel_gt *gt,
> + struct temp_regset *regset,
> + i915_reg_t reg, u32 flags)
> +{
> + u8 group, inst;
> +
> + /*
> + * The GuC doesn't have a default steering, so we need to explicitly
> + * steer all registers that need steering. However, we do not keep track
> + * of all the steering ranges, only of those that have a chance of using
> + * a non-default steering from the i915 pov. Instead of adding such
> + * tracking, it is easier to just program the default steering for all
> + * regs that don't need a non-default one.
> + */
> + intel_gt_mcr_get_nonterminated_steering(gt, reg, , );
> + flags |= GUC_REGSET_STEERING(group, inst);
> +
> + return guc_mmio_reg_add(gt, regset, i915_mmio_reg_offset(reg), flags);
> +}
> +
> +#define GUC_MCR_REG_ADD(gt, regset, reg, masked) \
> + guc_mcr_reg_add(gt, \
>regset, \
>(reg), \
>(masked) ? GUC_REGSET_MASKED : 0)
> @@ -375,7 +388,7 @@ static int guc_mmio_regset_init(struct temp_regset
> *regset,
> /* add in local MOCS registers */
> for (i = 0; i < LNCFCMOCS_REG_COUNT; i++)
> if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
> - ret |= GUC_MMIO_REG_ADD(gt, regset, XEHP_LNCFCMOCS(i),
> false);
> + ret |= GUC_MCR_REG_ADD(gt,
Re: [Intel-gfx] [PATCH v3 09/14] drm/i915/gt: Always use MCR functions on multicast registers
On 14.10.2022 16:02, Matt Roper wrote:
> Rather than relying on the implicit behavior of intel_uncore_*()
> functions, let's always use the intel_gt_mcr_*() functions to operate on
> multicast/replicated registers.
>
> v2:
> - Add TLB invalidation registers
>
> v3:
> - Switch more uncore operations in mmio_invalidate_full() to MCR
>operations for Xe_HP. (Bala)
>
> Cc: Balasubramani Vivekanandan
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c| 58 ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 13 ++---
> drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 12 +++--
> drivers/gpu/drm/i915/intel_pm.c | 19
> 4 files changed, 65 insertions(+), 37 deletions(-)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index e14f159ad9fc..3df0d0336dbc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -1017,6 +1017,32 @@ get_reg_and_bit(const struct intel_engine_cs *engine,
> const bool gen8,
> return rb;
> }
>
> +/*
> + * HW architecture suggest typical invalidation time at 40us,
> + * with pessimistic cases up to 100us and a recommendation to
> + * cap at 1ms. We go a bit higher just in case.
> + */
> +#define TLB_INVAL_TIMEOUT_US 100
> +#define TLB_INVAL_TIMEOUT_MS 4
> +
> +/*
> + * On Xe_HP the TLB invalidation registers are located at the same MMIO
> offsets
> + * but are now considered MCR registers. Since they exist within a GAM
> range,
> + * the primary instance of the register rolls up the status from each unit.
> + */
> +static int wait_for_invalidate(struct intel_gt *gt, struct reg_and_bit rb)
> +{
> + if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50))
> + return intel_gt_mcr_wait_for_reg_fw(gt, rb.reg, rb.bit, 0,
> + TLB_INVAL_TIMEOUT_US,
> + TLB_INVAL_TIMEOUT_MS);
> + else
> + return __intel_wait_for_register_fw(gt->uncore, rb.reg, rb.bit,
> 0,
> + TLB_INVAL_TIMEOUT_US,
> + TLB_INVAL_TIMEOUT_MS,
> + NULL);
> +}
> +
> static void mmio_invalidate_full(struct intel_gt *gt)
> {
> static const i915_reg_t gen8_regs[] = {
> @@ -1048,7 +1074,7 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> unsigned int num = 0;
>
> if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
> - regs = xehp_regs;
> + regs = NULL;
> num = ARRAY_SIZE(xehp_regs);
> } else if (GRAPHICS_VER(i915) == 12) {
> regs = gen12_regs;
> @@ -1075,11 +1101,17 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> if (!intel_engine_pm_is_awake(engine))
> continue;
>
> - rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);
> - if (!i915_mmio_reg_offset(rb.reg))
> - continue;
> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
> + intel_gt_mcr_multicast_write_fw(gt,
> +
> xehp_regs[engine->class],
> + BIT(engine->instance));
> + } else {
> + rb = get_reg_and_bit(engine, regs == gen8_regs, regs,
> num);
> + if (!i915_mmio_reg_offset(rb.reg))
> + continue;
>
> - intel_uncore_write_fw(uncore, rb.reg, rb.bit);
> + intel_uncore_write_fw(uncore, rb.reg, rb.bit);
> + }
> awake |= engine->mask;
> }
>
> @@ -1099,22 +1131,12 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> for_each_engine_masked(engine, gt, awake, tmp) {
> struct reg_and_bit rb;
>
> - /*
> - * HW architecture suggest typical invalidation time at 40us,
> - * with pessimistic cases up to 100us and a recommendation to
> - * cap at 1ms. We go a bit higher just in case.
> - */
> - const unsigned int timeout_us = 100;
> - const unsigned int timeout_ms = 4;
> -
> rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);
> - if (__intel_wait_for_register_fw(uncore,
> - rb.reg, rb.bit, 0,
> - timeout_us, timeout_ms,
> - NULL))
> +
> + if (wait_for_invalidate(gt, rb))
> drm_err_ratelimited(>i915->drm,
> "%s TLB invalidation did not
> complete in %ums!\n",
> -
Re: [Intel-gfx] [PATCH v3 08/14] drm/i915: Define MCR registers explicitly
On 14.10.2022 16:02, Matt Roper wrote: > Rather than using the same _MMIO() macro to define MCR registers as > singleton registers, let's use a new MCR_REG() macro to make it clear > that these registers are special and should be handled accordingly. For > now MCR_REG() will still generate an i915_reg_t with the given offset, > but we'll change that in future patches. > > Bspec: 66673, 66696, 66534, 67609 > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 134 > 1 file changed, 68 insertions(+), 66 deletions(-) Reviewed-by: Balasubramani Vivekanandan Regards, Bala > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index 890960b56b9e..ad9985015b0e 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -8,6 +8,8 @@ > > #include "i915_reg_defs.h" > > +#define MCR_REG(offset) _MMIO(offset) > + > /* RPM unit config (Gen8+) */ > #define RPM_CONFIG0 _MMIO(0xd00) > #define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT 3 > @@ -333,12 +335,12 @@ > #define GEN7_TLB_RD_ADDR _MMIO(0x4700) > > #define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) > * 4) > -#define XEHP_PAT_INDEX(index)_MMIO(0x4800 + (index) > * 4) > +#define XEHP_PAT_INDEX(index)MCR_REG(0x4800 + > (index) * 4) > > -#define XEHP_TILE0_ADDR_RANGE_MMIO(0x4900) > +#define XEHP_TILE0_ADDR_RANGEMCR_REG(0x4900) > #define XEHP_TILE_LMEM_RANGE_SHIFT 8 > > -#define XEHP_FLAT_CCS_BASE_ADDR _MMIO(0x4910) > +#define XEHP_FLAT_CCS_BASE_ADDR MCR_REG(0x4910) > #define XEHP_CCS_BASE_SHIFT8 > > #define GAMTARBMODE _MMIO(0x4a08) > @@ -388,18 +390,18 @@ > #define CHICKEN_RASTER_2 _MMIO(0x6208) > #define TBIMR_FAST_CLIPREG_BIT(5) > > -#define VFLSKPD _MMIO(0x62a8) > +#define VFLSKPD MCR_REG(0x62a8) > #define DIS_OVER_FETCH_CACHE REG_BIT(1) > #define DIS_MULT_MISS_RD_SQUASHREG_BIT(0) > > #define GEN12_FF_MODE2 _MMIO(0x6604) > -#define XEHP_FF_MODE2_MMIO(0x6604) > +#define XEHP_FF_MODE2MCR_REG(0x6604) > #define FF_MODE2_GS_TIMER_MASK REG_GENMASK(31, 24) > #define FF_MODE2_GS_TIMER_224 > REG_FIELD_PREP(FF_MODE2_GS_TIMER_MASK, 224) > #define FF_MODE2_TDS_TIMER_MASKREG_GENMASK(23, 16) > #define FF_MODE2_TDS_TIMER_128 > REG_FIELD_PREP(FF_MODE2_TDS_TIMER_MASK, 4) > > -#define XEHPG_INSTDONE_GEOM_SVG _MMIO(0x666c) > +#define XEHPG_INSTDONE_GEOM_SVG MCR_REG(0x666c) > > #define CACHE_MODE_0_GEN7_MMIO(0x7000) /* IVB+ */ > #define RC_OP_FLUSH_ENABLE (1 << 0) > @@ -448,14 +450,14 @@ > #define GEN8_HDC_CHICKEN1_MMIO(0x7304) > > #define GEN11_COMMON_SLICE_CHICKEN3 _MMIO(0x7304) > -#define XEHP_COMMON_SLICE_CHICKEN3 _MMIO(0x7304) > +#define XEHP_COMMON_SLICE_CHICKEN3 MCR_REG(0x7304) > #define DG1_FLOAT_POINT_BLEND_OPT_STRICT_MODE_EN REG_BIT(12) > #define XEHP_DUAL_SIMD8_SEQ_MERGE_DISABLE REG_BIT(12) > #define GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC REG_BIT(11) > #define GEN12_DISABLE_CPS_AWARE_COLOR_PIPE REG_BIT(9) > > #define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c) > -#define XEHP_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c) > +#define XEHP_SLICE_COMMON_ECO_CHICKEN1 MCR_REG(0x731c) > #define MSC_MSAA_REODER_BUF_BYPASS_DISABLE REG_BIT(14) > #define GEN11_STATE_CACHE_REDIRECT_TO_CS (1 << 11) > > @@ -486,7 +488,7 @@ > > #define GEN8_RC6_CTX_INFO_MMIO(0x8504) > > -#define XEHP_SQCM_MMIO(0x8724) > +#define XEHP_SQCMMCR_REG(0x8724) > #define EN_32B_ACCESS REG_BIT(30) > > #define HSW_IDICR_MMIO(0x9008) > @@ -647,7 +649,7 @@ > #define GEN7_MISCCPCTL _MMIO(0x9424) > #define GEN7_DOP_CLOCK_GATE_ENABLE (1 << 0) > > -#define GEN8_MISCCPCTL _MMIO(0x9424) > +#define GEN8_MISCCPCTL MCR_REG(0x9424) > #define GEN8_DOP_CLOCK_GATE_ENABLE REG_BIT(0) > #define GEN12_DOP_CLOCK_GATE_RENDER_ENABLE REG_BIT(1) > #define GEN8_DOP_CLOCK_GATE_CFCLK_ENABLE (1 << 2) > @@ -703,7 +705,7 @@ > #define LTCDD_CLKGATE_DIS REG_BIT(10) > > #define
Re: [Intel-gfx] [PATCH v3 07/14] drm/i915/gt: Add intel_gt_mcr_wait_for_reg_fw()
On 14.10.2022 16:02, Matt Roper wrote:
> Xe_HP has some MCR registers that need to be polled for completion of
> operations like TLB invalidation. Those registers are in the GAM range,
> which rolls up the status from each unit into the 'primary' instance's
> value. This makes it useful to have a dedicated 'wait for register'
> function that handles this on MCR registers, similar to the
> __intel_wait_for_register_fw() function we already have for regular
> registers.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 55 ++
> drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 7
> 2 files changed, 62 insertions(+)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index 4dc360f4e344..1ed9bc4dccfd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -568,3 +568,58 @@ void intel_gt_mcr_get_ss_steering(struct intel_gt *gt,
> unsigned int dss,
> return;
> }
> }
> +
> +/**
> + * intel_gt_mcr_wait_for_reg_fw - wait until MCR register matches expected
> state
> + * @gt: GT structure
> + * @reg: the register to read
> + * @mask: mask to apply to register value
> + * @value: value to wait for
> + * @fast_timeout_us: fast timeout in microsecond for atomic/tight wait
> + * @slow_timeout_ms: slow timeout in millisecond
> + *
> + * This routine waits until the target register @reg contains the expected
> + * @value after applying the @mask, i.e. it waits until ::
> + *
> + * (intel_gt_mcr_read_any_fw(gt, reg) & mask) == value
> + *
> + * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds.
> + * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us
> + * must be not larger than 20, microseconds.
> + *
> + * This function is basically an MCR-friendly version of
> + * __intel_wait_for_register_fw(). Generally this function will only be used
> + * on GAM registers which are a bit special --- although they're MCR
> registers,
> + * reads (e.g., waiting for status updates) are always directed to the
> primary
> + * instance.
> + *
> + * Note that this routine assumes the caller holds forcewake asserted, it is
> + * not suitable for very long waits.
> + *
> + * Return: 0 if the register matches the desired condition, or -ETIMEDOUT.
> + */
> +int intel_gt_mcr_wait_for_reg_fw(struct intel_gt *gt,
> + i915_reg_t reg,
> + u32 mask,
> + u32 value,
> + unsigned int fast_timeout_us,
> + unsigned int slow_timeout_ms)
> +{
> + u32 reg_value = 0;
> +#define done (((reg_value = intel_gt_mcr_read_any_fw(gt, reg)) & mask) ==
> value)
> + int ret;
> +
> + /* Catch any overuse of this function */
> + might_sleep_if(slow_timeout_ms);
> + GEM_BUG_ON(fast_timeout_us > 2);
> + GEM_BUG_ON(!fast_timeout_us && !slow_timeout_ms);
> +
> + ret = -ETIMEDOUT;
> + if (fast_timeout_us && fast_timeout_us <= 2)
> + ret = _wait_for_atomic(done, fast_timeout_us, 0);
> + if (ret && slow_timeout_ms)
> + ret = wait_for(done, slow_timeout_ms);
> +
> + return ret;
> +#undef done
> +}
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> index 781b267478db..548f922cd9fa 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> @@ -37,6 +37,13 @@ void intel_gt_mcr_report_steering(struct drm_printer *p,
> struct intel_gt *gt,
> void intel_gt_mcr_get_ss_steering(struct intel_gt *gt, unsigned int dss,
> unsigned int *group, unsigned int *instance);
>
> +int intel_gt_mcr_wait_for_reg_fw(struct intel_gt *gt,
> + i915_reg_t reg,
> + u32 mask,
> + u32 value,
> + unsigned int fast_timeout_us,
> + unsigned int slow_timeout_ms);
> +
> /*
> * Helper for for_each_ss_steering loop. On pre-Xe_HP platforms, subslice
> * presence is determined by using the group/instance as direct lookups in
> the
> --
> 2.37.3
>
Re: [Intel-gfx] [PATCH v3 06/14] drm/i915/xehp: Check for faults on primary GAM
On 14.10.2022 16:02, Matt Roper wrote:
> On Xe_HP the fault registers are now in a multicast register range.
> However as part of the GAM these registers follow special rules and we
> need only read from the "primary" GAM's instance to get the information
> we need. So a single intel_gt_mcr_read_any() (which will automatically
> steer to the primary GAM) is sufficient; we don't need to loop over each
> instance of the MCR register.
>
> v2:
> - Update more instances of fault registers. (Bala)
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c| 52 +++
> drivers/gpu/drm/i915/i915_gpu_error.c | 12 +--
> 2 files changed, 55 insertions(+), 9 deletions(-)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 445e171940fa..e14f159ad9fc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -270,7 +270,11 @@ intel_gt_clear_error_registers(struct intel_gt *gt,
> I915_MASTER_ERROR_INTERRUPT);
> }
>
> - if (GRAPHICS_VER(i915) >= 12) {
> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
> + intel_gt_mcr_multicast_rmw(gt, XEHP_RING_FAULT_REG,
> +RING_FAULT_VALID, 0);
> + intel_gt_mcr_read_any(gt, XEHP_RING_FAULT_REG);
> + } else if (GRAPHICS_VER(i915) >= 12) {
> rmw_clear(uncore, GEN12_RING_FAULT_REG, RING_FAULT_VALID);
> intel_uncore_posting_read(uncore, GEN12_RING_FAULT_REG);
> } else if (GRAPHICS_VER(i915) >= 8) {
> @@ -308,17 +312,49 @@ static void gen6_check_faults(struct intel_gt *gt)
> }
> }
>
> +static void xehp_check_faults(struct intel_gt *gt)
> +{
> + u32 fault;
> +
> + /*
> + * Although the fault register now lives in an MCR register range,
> + * the GAM registers are special and we only truly need to read
> + * the "primary" GAM instance rather than handling each instance
> + * individually. intel_gt_mcr_read_any() will automatically steer
> + * toward the primary instance.
> + */
> + fault = intel_gt_mcr_read_any(gt, XEHP_RING_FAULT_REG);
> + if (fault & RING_FAULT_VALID) {
> + u32 fault_data0, fault_data1;
> + u64 fault_addr;
> +
> + fault_data0 = intel_gt_mcr_read_any(gt, XEHP_FAULT_TLB_DATA0);
> + fault_data1 = intel_gt_mcr_read_any(gt, XEHP_FAULT_TLB_DATA1);
> +
> + fault_addr = ((u64)(fault_data1 & FAULT_VA_HIGH_BITS) << 44) |
> + ((u64)fault_data0 << 12);
> +
> + drm_dbg(>i915->drm, "Unexpected fault\n"
> + "\tAddr: 0x%08x_%08x\n"
> + "\tAddress space: %s\n"
> + "\tEngine ID: %d\n"
> + "\tSource ID: %d\n"
> + "\tType: %d\n",
> + upper_32_bits(fault_addr), lower_32_bits(fault_addr),
> + fault_data1 & FAULT_GTT_SEL ? "GGTT" : "PPGTT",
> + GEN8_RING_FAULT_ENGINE_ID(fault),
> + RING_FAULT_SRCID(fault),
> + RING_FAULT_FAULT_TYPE(fault));
> + }
> +}
> +
> static void gen8_check_faults(struct intel_gt *gt)
> {
> struct intel_uncore *uncore = gt->uncore;
> i915_reg_t fault_reg, fault_data0_reg, fault_data1_reg;
> u32 fault;
>
> - if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50)) {
> - fault_reg = XEHP_RING_FAULT_REG;
> - fault_data0_reg = XEHP_FAULT_TLB_DATA0;
> - fault_data1_reg = XEHP_FAULT_TLB_DATA1;
> - } else if (GRAPHICS_VER(gt->i915) >= 12) {
> + if (GRAPHICS_VER(gt->i915) >= 12) {
> fault_reg = GEN12_RING_FAULT_REG;
> fault_data0_reg = GEN12_FAULT_TLB_DATA0;
> fault_data1_reg = GEN12_FAULT_TLB_DATA1;
> @@ -358,7 +394,9 @@ void intel_gt_check_and_clear_faults(struct intel_gt *gt)
> struct drm_i915_private *i915 = gt->i915;
>
> /* From GEN8 onwards we only have one 'All Engine Fault Register' */
> - if (GRAPHICS_VER(i915) >= 8)
> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
> + xehp_check_faults(gt);
> + else if (GRAPHICS_VER(i915) >= 8)
> gen8_check_faults(gt);
> else if (GRAPHICS_VER(i915) >= 6)
> gen6_check_faults(gt);
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 9ea2fe34e7d3..f2d53edcd2ee 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1221,7 +1221,10 @@ static void engine_record_registers(struct
> intel_engine_coredump *ee)
> if (GRAPHICS_VER(i915) >= 6) {
> ee->rc_psmi = ENGINE_READ(engine, RING_PSMI_CTL);
>
> - if (GRAPHICS_VER(i915) >= 12)
> +
Re: [Intel-gfx] [PATCH v3 05/14] drm/i915/gt: Add intel_gt_mcr_multicast_rmw() operation
On 14.10.2022 16:02, Matt Roper wrote:
> There are cases where we wish to read from any non-terminated MCR
> register instance (or the primary instance in the case of GAM ranges),
> clear/set some bits, and then write the value back out to the register
> in a multicast manner. Adding a "multicast RMW" will avoid the need to
> open-code this.
>
> v2:
> - Return a u32 to align with the recent change to intel_uncore_rmw.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 28 ++
> drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 3 +++
> 2 files changed, 31 insertions(+)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index a2047a68ea7a..4dc360f4e344 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -302,6 +302,34 @@ void intel_gt_mcr_multicast_write_fw(struct intel_gt
> *gt, i915_reg_t reg, u32 va
> intel_uncore_write_fw(gt->uncore, reg, value);
> }
>
> +/**
> + * intel_gt_mcr_multicast_rmw - Performs a multicast RMW operations
> + * @gt: GT structure
> + * @reg: the MCR register to read and write
> + * @clear: bits to clear during RMW
> + * @set: bits to set during RMW
> + *
> + * Performs a read-modify-write on an MCR register in a multicast manner.
> + * This operation only makes sense on MCR registers where all instances are
> + * expected to have the same value. The read will target any non-terminated
> + * instance and the write will be applied to all instances.
> + *
> + * This function assumes the caller is already holding any necessary
> forcewake
> + * domains; use intel_gt_mcr_multicast_rmw() in cases where forcewake should
> + * be obtained automatically.
> + *
> + * Returns the old (unmodified) value read.
> + */
> +u32 intel_gt_mcr_multicast_rmw(struct intel_gt *gt, i915_reg_t reg,
> +u32 clear, u32 set)
> +{
> + u32 val = intel_gt_mcr_read_any(gt, reg);
> +
> + intel_gt_mcr_multicast_write(gt, reg, (val & ~clear) | set);
> +
> + return val;
> +}
> +
> /*
> * reg_needs_read_steering - determine whether a register read requires
> * explicit steering
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> index 77a8b11c287d..781b267478db 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> @@ -24,6 +24,9 @@ void intel_gt_mcr_multicast_write(struct intel_gt *gt,
> void intel_gt_mcr_multicast_write_fw(struct intel_gt *gt,
>i915_reg_t reg, u32 value);
>
> +u32 intel_gt_mcr_multicast_rmw(struct intel_gt *gt, i915_reg_t reg,
> +u32 clear, u32 set);
> +
> void intel_gt_mcr_get_nonterminated_steering(struct intel_gt *gt,
>i915_reg_t reg,
>u8 *group, u8 *instance);
> --
> 2.37.3
>
Re: [Intel-gfx] [PATCH v3 04/14] drm/i915/gt: Correct prefix on a few registers
On 14.10.2022 16:02, Matt Roper wrote:
> We have a few registers that have existed for several hardware
> generations, but are only used by the driver on Xe_HP and beyond. In
> cases where the Xe_HP version of the register is now replicated and uses
> multicast behavior, but earlier generations were singleton, let's change
> the register prefix to "XEHP_" to help clarify that we're using the
> newer multicast form of the register.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
> 2 files changed, 9 insertions(+), 9 deletions(-)
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 71d8787230c1..890960b56b9e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -486,7 +486,7 @@
>
> #define GEN8_RC6_CTX_INFO_MMIO(0x8504)
>
> -#define GEN12_SQCM _MMIO(0x8724)
> +#define XEHP_SQCM_MMIO(0x8724)
> #define EN_32B_ACCESS REG_BIT(30)
>
> #define HSW_IDICR_MMIO(0x9008)
> @@ -989,7 +989,7 @@
> #define GEN11_SCRATCH2 _MMIO(0xb140)
> #define GEN11_COHERENT_PARTIAL_WRITE_MERGE_ENABLE (1 << 19)
>
> -#define GEN11_L3SQCREG5 _MMIO(0xb158)
> +#define XEHP_L3SQCREG5 _MMIO(0xb158)
> #define L3_PWM_TIMER_INIT_VAL_MASK REG_GENMASK(9, 0)
>
> #define MLTICTXCTL _MMIO(0xb170)
> @@ -1053,7 +1053,7 @@
> #define GEN12_COMPCTX_TLB_INV_CR _MMIO(0xcf04)
> #define XEHP_COMPCTX_TLB_INV_CR _MMIO(0xcf04)
>
> -#define GEN12_MERT_MOD_CTRL _MMIO(0xcf28)
> +#define XEHP_MERT_MOD_CTRL _MMIO(0xcf28)
> #define RENDER_MOD_CTRL _MMIO(0xcf2c)
> #define COMP_MOD_CTRL_MMIO(0xcf30)
> #define VDBX_MOD_CTRL_MMIO(0xcf34)
> @@ -1155,7 +1155,7 @@
> #define EU_PERF_CNTL1_MMIO(0xe558)
> #define EU_PERF_CNTL5_MMIO(0xe55c)
>
> -#define GEN12_HDC_CHICKEN0 _MMIO(0xe5f0)
> +#define XEHP_HDC_CHICKEN0_MMIO(0xe5f0)
> #define LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK REG_GENMASK(13,
> 11)
> #define ICL_HDC_MODE _MMIO(0xe5f4)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3056b099dd17..96b9f02a2284 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -569,7 +569,7 @@ static void dg2_ctx_gt_tuning_init(struct intel_engine_cs
> *engine,
> struct i915_wa_list *wal)
> {
> wa_masked_en(wal, CHICKEN_RASTER_2, TBIMR_FAST_CLIP);
> - wa_write_clr_set(wal, GEN11_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
> + wa_write_clr_set(wal, XEHP_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
>REG_FIELD_PREP(L3_PWM_TIMER_INIT_VAL_MASK, 0x7f));
> wa_add(wal,
> XEHP_FF_MODE2,
> @@ -1514,7 +1514,7 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
>* recommended tuning settings documented in the bspec's
>* performance guide section.
>*/
> - wa_write_or(wal, GEN12_SQCM, EN_32B_ACCESS);
> + wa_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
>
> /* Wa_14015795083 */
> wa_write_clr(wal, GEN8_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
> @@ -2170,7 +2170,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
>* Wa_22010960976:dg2
>* Wa_14013347512:dg2
>*/
> - wa_masked_dis(wal, GEN12_HDC_CHICKEN0,
> + wa_masked_dis(wal, XEHP_HDC_CHICKEN0,
> LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK);
> }
>
> @@ -2223,7 +2223,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_A0, STEP_B0) ||
> IS_DG2_GRAPHICS_STEP(engine->i915, G11, STEP_A0, STEP_B0)) {
> /* Wa_14012362059:dg2 */
> - wa_write_or(wal, GEN12_MERT_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
> }
>
> if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_B0, STEP_FOREVER) ||
> @@ -2816,7 +2816,7 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
> }
>
> /* Wa_14012362059:xehpsdv */
> - wa_write_or(wal, GEN12_MERT_MOD_CTRL,
Re: [Intel-gfx] [PATCH v3 03/14] drm/i915/gt: Drop a few unused register definitions
On 14.10.2022 16:02, Matt Roper wrote: > Let's drop a few register definitions that are unused anywhere in the > driver today. Since the referenced offsets are part of what is now > considered a multicast register region, the current definitions would > not be correct for use on any future platform. > > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 17 - > 1 file changed, 17 deletions(-) Reviewed-by: Balasubramani Vivekanandan Regards, Bala
Re: [Intel-gfx] [PATCH v3 02/14] drm/i915/xehp: Create separate reg definitions for new MCR registers
On 14.10.2022 16:02, Matt Roper wrote: > Starting in Xe_HP, several registers our driver works with have been > converted from singleton registers into replicated registers with > multicast behavior. Although the registers are still located at the > same MMIO offsets as on previous platforms, let's duplicate the register > definitions in preparation for upcoming patches that will handle > multicast registers in a special manner. > > The registers that are now replicated on Xe_HP are: > * PAT_INDEX (mslice replication) > * FF_MODE2 (gslice replication) > * COMMON_SLICE_CHICKEN3 (gslice replication) > * SLICE_COMMON_ECO_CHICKEN1 (gslice replication) > * SLICE_UNIT_LEVEL_CLKGATE (gslice replication) > * LNCFCMOCS (lncf replication) > > Note that there are a couple places in selftest_mocs.c where the > gen9 version of LNCFCMOCS is still used without regards for which > platform we're on. Those cases are just doing an offset lookup and not > issuing any CPU reads/writes of the register, so the potentially > multicast nature of the register doesn't come into play. > > v2: > - Add commit message note about the unconditional GEN9_LNCFCMOCS usage >in selftest_mocs. (Bala) > - Include some additional TLB registers. > > Bspec: 66534 > Cc: Balasubramani Vivekanandan > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_ggtt.c| 4 ++-- > drivers/gpu/drm/i915/gt/intel_gt.c | 18 -- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 26 +++-- > drivers/gpu/drm/i915/gt/intel_gtt.c | 22 ++--- > drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +- > drivers/gpu/drm/i915/gt/intel_mocs.c| 5 +++- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-- > drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 7 -- > 8 files changed, 78 insertions(+), 30 deletions(-) Reviewed-by: Balasubramani Vivekanandan Regards, Bala
Re: [Intel-gfx] [PATCH v3 01/14] drm/i915/gen8: Create separate reg definitions for new MCR registers
On 14.10.2022 16:02, Matt Roper wrote: > Gen8 was the first time our hardware had multicast registers (or at > least the first time the multicast nature was exposed and MMIO accesses > could be steered). There are some registers that transitioned from > singleton behavior to multicast during the gen7 -> gen8 transition; > let's duplicate the register definitions for those registers in > preparation for upcoming patches that will handle MCR registers in a > special manner. > > The registers adjusted are: > * MISCCPCTL > * SAMPLER_INSTDONE > * ROW_INSTDONE > * ROW_CHICKEN2 > * HALF_SLICE_CHICKEN1 > * HALF_SLICE_CHICKEN3 > > v2: > - Use the gen8 version of HALF_SLICE_CHICKEN3 in GVT's gen9 engine MMIO >list. (Bala) > - Update to the gen8 version of MISCCPCTL in a couple new workarounds >that were recently added for DG2/PVC. (Bala) > > Signed-off-by: Matt Roper > Reviewed-by: Balasubramani Vivekanandan > --- > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 11 +++- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 +-- > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 4 +-- > drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +- > drivers/gpu/drm/i915/gvt/handlers.c | 2 +- > drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +- > drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 2 +- > drivers/gpu/drm/i915/intel_pm.c | 9 --- > 9 files changed, 36 insertions(+), 26 deletions(-) Reviewed-by: Balasubramani Vivekanandan Regards, Bala
[Intel-gfx] ✗ Fi.CI.IGT: failure for x86/hyperv: Replace kmap() with kmap_local_page()
== Series Details == Series: x86/hyperv: Replace kmap() with kmap_local_page() URL : https://patchwork.freedesktop.org/series/109762/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109762v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_109762v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_109762v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (12 -> 12) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_109762v1_full: ### IGT changes ### Possible regressions * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-tglb7/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109762v1/shard-tglb5/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_suspend@debugfs-reader: - shard-apl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109762v1/shard-apl2/igt@i915_susp...@debugfs-reader.html Warnings * igt@gem_eio@in-flight-suspend: - shard-apl: [INCOMPLETE][4] ([i915#7112]) -> [INCOMPLETE][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl2/igt@gem_...@in-flight-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109762v1/shard-apl1/igt@gem_...@in-flight-suspend.html Known issues Here are the changes found in Patchwork_109762v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-snb: ([PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [FAIL][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30]) ([i915#4338]) -> ([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], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109762v1/shard-snb7/boot.html [32]:
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Explicit MCR handling and MTL steering (rev4)
On Sat, Oct 15, 2022 at 01:03:31AM +, Patchwork wrote: > == Series Details == > > Series: Explicit MCR handling and MTL steering (rev4) > URL : https://patchwork.freedesktop.org/series/108755/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_12242_full -> Patchwork_108755v4_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_108755v4_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_108755v4_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Participating hosts (9 -> 11) > -- > > Additional (2): shard-rkl shard-dg1 > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_108755v4_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_async_flips@async-flip-with-page-flip-events@pipe-c-edp-1: > - shard-skl: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-c-edp-1.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl3/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-c-edp-1.html GT multicast register handling wouldn't have changed the behavior of a SKL display test. This failure is unrelated. Other subtests of this test also seem to be sporadically failing in a similar manner. This might be related to the same root cause as fdo#2521. Matt > > > Warnings > > * igt@runner@aborted: > - shard-skl: ([FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6]) > ([i915#3002] / [i915#4312] / [i915#6949]) -> ([FAIL][7], [FAIL][8], > [FAIL][9]) ([i915#3002] / [i915#4312]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@run...@aborted.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@run...@aborted.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl4/igt@run...@aborted.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl10/igt@run...@aborted.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl1/igt@run...@aborted.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl2/igt@run...@aborted.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v4/shard-skl7/igt@run...@aborted.html > > > Known issues > > > Here are the changes found in Patchwork_108755v4_full that come from known > issues: > > ### CI changes ### > > Possible fixes > > * boot: > - shard-skl: ([PASS][10], [PASS][11], [PASS][12], [PASS][13], > [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], > [PASS][20], [FAIL][21], [PASS][22], [FAIL][23], [PASS][24], [PASS][25], > [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], > [PASS][32], [PASS][33], [PASS][34]) ([i915#5032]) -> ([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], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], > [PASS][55], [PASS][56], [PASS][57]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/boot.html >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/boot.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/boot.html >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/boot.html >[24]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl4/boot.html >[25]: >
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable YCbCr420 for VDSC (rev3)
== Series Details == Series: Enable YCbCr420 for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/109723/ State : success == Summary == CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109723v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/index.html Participating hosts (44 -> 44) -- Additional (2): fi-hsw-4770 fi-rkl-11600 Missing(2): fi-icl-u2 fi-bdw-samus Known issues Here are the changes found in Patchwork_109723v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-pnv-d510/igt@gem_exec_gttf...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-pnv-d510/igt@gem_exec_gttf...@basic.html * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3012]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-hsw-4770:NOTRUN -> [INCOMPLETE][4] ([i915#7221]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@i915_pm_...@module-reload.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271]) +9 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +7 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html * igt@kms_psr@sprite_plane_onoff: - fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1072]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#4312] / [i915#5594]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@run...@aborted.html - fi-rkl-11600: NOTRUN -> [FAIL][9] ([i915#7220]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-rkl-11600/igt@run...@aborted.html Possible fixes * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size: - fi-bsw-kefka: [FAIL][10] ([i915#6298]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html Warnings * igt@i915_suspend@basic-s3-without-i915: - fi-bdw-gvtdvm: [FAIL][12] ([fdo#103375]) -> [INCOMPLETE][13] ([i915#146]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bdw-gvtdvm/igt@i915_susp...@basic-s3-without-i915.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-bdw-gvtdvm/igt@i915_susp...@basic-s3-without-i915.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146 [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594 [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298 [i915#7220]: https://gitlab.freedesktop.org/drm/intel/issues/7220 [i915#7221]: https://gitlab.freedesktop.org/drm/intel/issues/7221 [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229 Build changes - * Linux: CI_DRM_12251 -> Patchwork_109723v3 CI-20190529: 20190529 CI_DRM_12251: ff61e79b01712f5d31a4c4f23c6971bbaa71cecb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7016: 642f4bf44e2b42791b4d1684936a1bfbe2d099ee @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_109723v3: ff61e79b01712f5d31a4c4f23c6971bbaa71cecb @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 15b7864dfcc7 drm/i915: Fill in native_420 field 06bdd4dd286c drm/i915: Enable YCbCr420 for VDSC dbf9b77fa92e drm/i915: Adding the new registers for DSC 1651ca8b8b7e
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: fix clear mask in GEN7_MISCCPCTL update
== Series Details == Series: drm/i915: fix clear mask in GEN7_MISCCPCTL update URL : https://patchwork.freedesktop.org/series/109757/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109757v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_109757v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_109757v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (12 -> 12) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_109757v1_full: ### IGT changes ### Possible regressions * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-tglb7/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109757v1/shard-tglb2/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_suspend@debugfs-reader: - shard-apl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109757v1/shard-apl7/igt@i915_susp...@debugfs-reader.html Warnings * igt@gem_eio@in-flight-suspend: - shard-apl: [INCOMPLETE][4] ([i915#7112]) -> [INCOMPLETE][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-apl2/igt@gem_...@in-flight-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109757v1/shard-apl3/igt@gem_...@in-flight-suspend.html Known issues Here are the changes found in Patchwork_109757v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-snb: ([PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [FAIL][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30]) ([i915#4338]) -> ([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], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb5/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb4/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/shard-snb2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109757v1/shard-snb7/boot.html [32]:
[Intel-gfx] ✓ Fi.CI.BAT: success for Defeature Interlace modes for Display >= 12
== Series Details == Series: Defeature Interlace modes for Display >= 12 URL : https://patchwork.freedesktop.org/series/109773/ State : success == Summary == CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109773v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/index.html Participating hosts (44 -> 44) -- Additional (2): fi-hsw-4770 fi-rkl-11600 Missing(2): fi-icl-u2 fi-bdw-samus Known issues Here are the changes found in Patchwork_109773v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#3012]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-hsw-4770:NOTRUN -> [INCOMPLETE][2] ([i915#7221]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/fi-hsw-4770/igt@i915_pm_...@module-reload.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +7 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html * igt@kms_psr@sprite_plane_onoff: - fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1072]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][6] ([fdo#109271] / [i915#4312] / [i915#5594]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/fi-hsw-4770/igt@run...@aborted.html - fi-rkl-11600: NOTRUN -> [FAIL][7] ([i915#7220]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/fi-rkl-11600/igt@run...@aborted.html Possible fixes * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size: - fi-bsw-kefka: [FAIL][8] ([i915#6298]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html Warnings * igt@i915_suspend@basic-s3-without-i915: - fi-bdw-gvtdvm: [FAIL][10] ([fdo#103375]) -> [INCOMPLETE][11] ([i915#146]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bdw-gvtdvm/igt@i915_susp...@basic-s3-without-i915.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s3-without-i915.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146 [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594 [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298 [i915#7220]: https://gitlab.freedesktop.org/drm/intel/issues/7220 [i915#7221]: https://gitlab.freedesktop.org/drm/intel/issues/7221 Build changes - * Linux: CI_DRM_12251 -> Patchwork_109773v1 CI-20190529: 20190529 CI_DRM_12251: ff61e79b01712f5d31a4c4f23c6971bbaa71cecb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7016: 642f4bf44e2b42791b4d1684936a1bfbe2d099ee @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_109773v1: ff61e79b01712f5d31a4c4f23c6971bbaa71cecb @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 07f0302eb303 drm/i915/display: Prune Interlace modes for Display >=12 59440bde1e73 drm/i915/display: Drop check for doublescan mode in modevalid == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v1/index.html
Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related
Hi,
On 10/17/22 15:35, Jani Nikula wrote:
> On Mon, 17 Oct 2022, Hans de Goede wrote:
>> Hi,
>>
>> On 10/17/22 13:19, Thorsten Leemhuis wrote:
>>> CCing the regression mailing list, as it should be in the loop for all
>>> regressions, as explained here:
>>> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>>
>> Yes sorry about that I meant to Cc the regressions list, not you personally,
>> but the auto-completion picked the wrong address-book entry
>> (and I did not notice this).
>>
>>> On 17.10.22 12:48, Hans de Goede wrote:
On 10/17/22 10:39, Jani Nikula wrote:
> On Mon, 17 Oct 2022, Jani Nikula wrote:
>> On Thu, 13 Oct 2022, Hans de Goede wrote:
>>> With 6.0 the following WARN triggers:
>>> drivers/gpu/drm/i915/display/intel_bios.c:477:
>>>
>>> drm_WARN(>drm, min_size == 0,
>>> "Block %d min_size is zero\n", section_id);
>>
>> What's the value of section_id that gets printed?
>
> I'm guessing this is [1] fixed by commit d3a7051841f0 ("drm/i915/bios:
> Use hardcoded fp_timing size for generating LFP data pointers") in
> v6.1-rc1.
>
> I don't think this is the root cause for your issues, but I wonder if
> you could try v6.1-rc1 or drm-tip and see if we've fixed the other stuff
> already too?
6.1-rc1 indeed does not trigger the drm_WARN and for now (couple of
reboots, running for 5 minutes now) it seems stable. 6.0.0 usually
crashed during boot (but not always).
Do you think it would be worthwhile to try 6.0.0 with d3a7051841f0 ?
>>
>> So I have been trying 6.0.0 with d3a7051841f0 doing a whole bunch of
>> reboots + general use and that seems stable, then I reverted it and
>> the very first boot of the kernel with that broke again, so I'm
>> pretty sure that d3a7051841f0 fixes things.
>>
>> So d3a7051841f0 seems to do more then just fix the WARN().
>
> Wow, so I guess we do screw up the parsing royally then. :o
I'm running the kernel with lockdep + list-debugging enabled and
I could not reproduce this (not easily at least) on a standard
Fedora 6.0.0 build without that. So maybe the parsing just manages
to write out of binds a tiny bit which just happens to hit a list_head
somewhere ... ?
Either way things look stable with d3a7051841f0 and it turns out
that Fedora already had that cherry-picked downstream in the
5.19.13 kernel which was stable for me too.
>> So lets try to get d3a7051841f0 added to the official stable series
>> ASAP (I just noticed that Mark Pearson from Lenovo has already added it
>> to Fedora's 6.0.2 build.
>
> I think I'd also pick d3a7051841f0^ i.e. both commits:
>
> d3a7051841f0 ("drm/i915/bios: Use hardcoded fp_timing size for generating LFP
> data pointers")
> 4e78d6023c15 ("drm/i915/bios: Validate fp_timing terminator presence")
>
> for stable.
That sounds good, can you take care of submitting these to gkh ?
Regards,
Hans
[Intel-gfx] [PATCH 1/2] drm/i915/display: Drop check for doublescan mode in modevalid
Since the DP/HDMI connector do not set connector->doublescan_allowed, the doublescan modes will get automatically filtered during drm_helper_probe_single_connector_modes(). Therefore check for double scan modes is not required and is dropped from modevalid functions for both DP and HDMI. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_dp.c | 3 --- drivers/gpu/drm/i915/display/intel_hdmi.c | 3 --- 2 files changed, 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index a060903891b2..1f83ddf13928 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -973,9 +973,6 @@ intel_dp_mode_valid(struct drm_connector *_connector, enum drm_mode_status status; bool dsc = false, bigjoiner = false; - if (mode->flags & DRM_MODE_FLAG_DBLSCAN) - return MODE_NO_DBLESCAN; - if (mode->flags & DRM_MODE_FLAG_DBLCLK) return MODE_H_ILLEGAL; diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 93519fb23d9d..e21deb6ef7fa 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -1987,9 +1987,6 @@ intel_hdmi_mode_valid(struct drm_connector *connector, bool has_hdmi_sink = intel_has_hdmi_sink(hdmi, connector->state); bool ycbcr_420_only; - if (mode->flags & DRM_MODE_FLAG_DBLSCAN) - return MODE_NO_DBLESCAN; - if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == DRM_MODE_FLAG_3D_FRAME_PACKING) clock *= 2; -- 2.25.1
[Intel-gfx] [PATCH 2/2] drm/i915/display: Prune Interlace modes for Display >=12
Defeature Display Interlace support. Support for interlace modes is removed from Gen 12 onwards. Pruning the interlace modes for HDMI for Display >=12. Bspec: 50490 v2: Add check for both DP and HDMI. (Ville) Get rid of redundant check for interlace mode in modevalid. (Ville) Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_dp.c | 4 ++-- drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +++- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 1f83ddf13928..3dc197a45f16 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2032,7 +2032,7 @@ intel_dp_compute_config(struct intel_encoder *encoder, if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) return -EINVAL; - if (HAS_GMCH(dev_priv) && + if ((HAS_GMCH(dev_priv) || DISPLAY_VER(dev_priv) >= 12) && adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) return -EINVAL; @@ -5412,7 +5412,7 @@ intel_dp_init_connector(struct intel_digital_port *dig_port, drm_connector_init(dev, connector, _dp_connector_funcs, type); drm_connector_helper_add(connector, _dp_connector_helper_funcs); - if (!HAS_GMCH(dev_priv)) + if (!HAS_GMCH(dev_priv) && DISPLAY_VER(dev_priv) < 12) connector->interlace_allowed = true; intel_connector->polled = DRM_CONNECTOR_POLL_HPD; diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index e21deb6ef7fa..05ab0a4f6d39 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -2244,6 +2244,10 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder, if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) return -EINVAL; + if (DISPLAY_VER(dev_priv) >= 12 && + adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) + return -EINVAL; + pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi, conn_state); @@ -2953,7 +2957,9 @@ void intel_hdmi_init_connector(struct intel_digital_port *dig_port, ddc); drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); - connector->interlace_allowed = true; + if (DISPLAY_VER(dev_priv) < 12) + connector->interlace_allowed = true; + connector->stereo_allowed = true; if (DISPLAY_VER(dev_priv) >= 10) -- 2.25.1
[Intel-gfx] [PATCH 0/2] Defeature Interlace modes for Display >= 12
This patch series is a contination of patch: https://patchwork.freedesktop.org/patch/506835/?series=109646=1 Added change for DP as well as HDMI in the patch series. Also added a clean up patch to remove check for doublescan modes as that is no longer required. Ankit Nautiyal (2): drm/i915/display: Drop check for doublescan mode in modevalid drm/i915/display: Prune Interlace modes for Display >=12 drivers/gpu/drm/i915/display/intel_dp.c | 7 ++- drivers/gpu/drm/i915/display/intel_hdmi.c | 11 +++ 2 files changed, 9 insertions(+), 9 deletions(-) -- 2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Extend Wa_1607297627 to Alderlake-P
== Series Details == Series: drm/i915: Extend Wa_1607297627 to Alderlake-P URL : https://patchwork.freedesktop.org/series/109772/ State : success == Summary == CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109772v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/index.html Participating hosts (44 -> 45) -- Additional (2): fi-hsw-4770 fi-rkl-11600 Missing(1): fi-bdw-samus Known issues Here are the changes found in Patchwork_109772v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_softpin@allocator-basic-reserve: - fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271]) +9 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#3012]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-hsw-4770:NOTRUN -> [INCOMPLETE][3] ([i915#7221]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-hsw-4770/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bdw-gvtdvm: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-bdw-gvtdvm/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html * igt@kms_pipe_crc_basic@suspend-read-crc: - fi-bdw-gvtdvm: NOTRUN -> [SKIP][6] ([fdo#109271]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-bdw-gvtdvm/igt@kms_pipe_crc_ba...@suspend-read-crc.html * igt@kms_psr@sprite_plane_onoff: - fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1072]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#4312] / [i915#5594]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-hsw-4770/igt@run...@aborted.html - fi-rkl-11600: NOTRUN -> [FAIL][9] ([i915#7220]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-rkl-11600/igt@run...@aborted.html Possible fixes * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size: - fi-bsw-kefka: [FAIL][10] ([i915#6298]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html Warnings * igt@gem_exec_suspend@basic-s3@smem: - fi-bdw-gvtdvm: [INCOMPLETE][12] ([i915#146]) -> [FAIL][13] ([fdo#103375]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bdw-gvtdvm/igt@gem_exec_suspend@basic...@smem.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109772v1/fi-bdw-gvtdvm/igt@gem_exec_suspend@basic...@smem.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146 [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594 [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298 [i915#7220]: https://gitlab.freedesktop.org/drm/intel/issues/7220 [i915#7221]: https://gitlab.freedesktop.org/drm/intel/issues/7221 Build changes - * Linux: CI_DRM_12251 -> Patchwork_109772v1 CI-20190529: 20190529 CI_DRM_12251: ff61e79b01712f5d31a4c4f23c6971bbaa71cecb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7016: 642f4bf44e2b42791b4d1684936a1bfbe2d099ee @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_109772v1: ff61e79b01712f5d31a4c4f23c6971bbaa71cecb @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 942c73aca7bb drm/i915: Extend Wa_1607297627 to Alderlake-P == Logs == For more
Re: [Intel-gfx] [PATCH v2] drm/i915: Extend Wa_1607297627 to Alderlake-P
On 17/10/2022 14:24, José Roberto de Souza wrote:
Workaround 1607297627 was missed for Alderlake-P, so here extending it
to it and adding the fixes tag so this WA is backported to all
stable kernels.
v2:
- fixed subject
- added Fixes tag
BSpec: 54369
Fixes: dfb924e33927 ("drm/i915/adlp: Remove require_force_probe protection")
Cc: # v5.17+
Regards,
Tvrtko
Reviewed-by: Lucas De Marchi
Cc: Tvrtko Ursulin
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index b8eb20a155f0d..e1d5df3a5756e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2300,11 +2300,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
}
if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) ||
- IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
+ IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) {
/*
* Wa_1607030317:tgl
* Wa_1607186500:tgl
-* Wa_1607297627:tgl,rkl,dg1[a0]
+* Wa_1607297627:tgl,rkl,dg1[a0],adlp
*
* On TGL and RKL there are multiple entries for this WA in the
* BSpec; some indicate this is an A0-only WA, others indicate
Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related
On Mon, 17 Oct 2022, Hans de Goede wrote:
> Hi,
>
> On 10/17/22 13:19, Thorsten Leemhuis wrote:
>> CCing the regression mailing list, as it should be in the loop for all
>> regressions, as explained here:
>> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>
> Yes sorry about that I meant to Cc the regressions list, not you personally,
> but the auto-completion picked the wrong address-book entry
> (and I did not notice this).
>
>> On 17.10.22 12:48, Hans de Goede wrote:
>>> On 10/17/22 10:39, Jani Nikula wrote:
On Mon, 17 Oct 2022, Jani Nikula wrote:
> On Thu, 13 Oct 2022, Hans de Goede wrote:
>> With 6.0 the following WARN triggers:
>> drivers/gpu/drm/i915/display/intel_bios.c:477:
>>
>> drm_WARN(>drm, min_size == 0,
>> "Block %d min_size is zero\n", section_id);
>
> What's the value of section_id that gets printed?
I'm guessing this is [1] fixed by commit d3a7051841f0 ("drm/i915/bios:
Use hardcoded fp_timing size for generating LFP data pointers") in
v6.1-rc1.
I don't think this is the root cause for your issues, but I wonder if
you could try v6.1-rc1 or drm-tip and see if we've fixed the other stuff
already too?
>>>
>>> 6.1-rc1 indeed does not trigger the drm_WARN and for now (couple of
>>> reboots, running for 5 minutes now) it seems stable. 6.0.0 usually
>>> crashed during boot (but not always).
>>>
>>> Do you think it would be worthwhile to try 6.0.0 with d3a7051841f0 ?
>
> So I have been trying 6.0.0 with d3a7051841f0 doing a whole bunch of
> reboots + general use and that seems stable, then I reverted it and
> the very first boot of the kernel with that broke again, so I'm
> pretty sure that d3a7051841f0 fixes things.
>
> So d3a7051841f0 seems to do more then just fix the WARN().
Wow, so I guess we do screw up the parsing royally then. :o
> So lets try to get d3a7051841f0 added to the official stable series
> ASAP (I just noticed that Mark Pearson from Lenovo has already added it
> to Fedora's 6.0.2 build.
I think I'd also pick d3a7051841f0^ i.e. both commits:
d3a7051841f0 ("drm/i915/bios: Use hardcoded fp_timing size for generating LFP
data pointers")
4e78d6023c15 ("drm/i915/bios: Validate fp_timing terminator presence")
for stable.
BR,
Jani.
>
> Regards,
>
> Hans
>
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH v2] drm/i915: Extend Wa_1607297627 to Alderlake-P
Workaround 1607297627 was missed for Alderlake-P, so here extending it
to it and adding the fixes tag so this WA is backported to all
stable kernels.
v2:
- fixed subject
- added Fixes tag
BSpec: 54369
Fixes: dfb924e33927 ("drm/i915/adlp: Remove require_force_probe protection")
Reviewed-by: Lucas De Marchi
Cc: Tvrtko Ursulin
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index b8eb20a155f0d..e1d5df3a5756e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2300,11 +2300,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
}
if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) ||
- IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
+ IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) {
/*
* Wa_1607030317:tgl
* Wa_1607186500:tgl
-* Wa_1607297627:tgl,rkl,dg1[a0]
+* Wa_1607297627:tgl,rkl,dg1[a0],adlp
*
* On TGL and RKL there are multiple entries for this WA in the
* BSpec; some indicate this is an A0-only WA, others indicate
--
2.38.0
[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable YCbCr420 for VDSC (rev3)
== Series Details == Series: Enable YCbCr420 for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/109723/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109723v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_109723v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_109723v3, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/index.html Participating hosts (44 -> 44) -- Additional (2): fi-hsw-4770 fi-rkl-11600 Missing(2): fi-icl-u2 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_109723v3: ### IGT changes ### Possible regressions * igt@gem_exec_gttfill@basic: - fi-pnv-d510:[PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-pnv-d510/igt@gem_exec_gttf...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-pnv-d510/igt@gem_exec_gttf...@basic.html Known issues Here are the changes found in Patchwork_109723v3 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3012]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-hsw-4770:NOTRUN -> [INCOMPLETE][4] ([i915#7221]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@i915_pm_...@module-reload.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271]) +9 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +7 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html * igt@kms_psr@sprite_plane_onoff: - fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1072]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#4312] / [i915#5594]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-hsw-4770/igt@run...@aborted.html - fi-rkl-11600: NOTRUN -> [FAIL][9] ([i915#7220]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-rkl-11600/igt@run...@aborted.html Possible fixes * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size: - fi-bsw-kefka: [FAIL][10] ([i915#6298]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html Warnings * igt@i915_suspend@basic-s3-without-i915: - fi-bdw-gvtdvm: [FAIL][12] ([fdo#103375]) -> [INCOMPLETE][13] ([i915#146]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12251/fi-bdw-gvtdvm/igt@i915_susp...@basic-s3-without-i915.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109723v3/fi-bdw-gvtdvm/igt@i915_susp...@basic-s3-without-i915.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146 [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594 [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298 [i915#7220]: https://gitlab.freedesktop.org/drm/intel/issues/7220 [i915#7221]: https://gitlab.freedesktop.org/drm/intel/issues/7221 Build changes - * Linux: CI_DRM_12251 -> Patchwork_109723v3 CI-20190529: 20190529 CI_DRM_12251: ff61e79b01712f5d31a4c4f23c6971bbaa71cecb @ git://anongit.freedesktop.org/gfx-ci/linux
Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related
Hi,
On 10/17/22 13:19, Thorsten Leemhuis wrote:
> CCing the regression mailing list, as it should be in the loop for all
> regressions, as explained here:
> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
Yes sorry about that I meant to Cc the regressions list, not you personally,
but the auto-completion picked the wrong address-book entry
(and I did not notice this).
> On 17.10.22 12:48, Hans de Goede wrote:
>> On 10/17/22 10:39, Jani Nikula wrote:
>>> On Mon, 17 Oct 2022, Jani Nikula wrote:
On Thu, 13 Oct 2022, Hans de Goede wrote:
> With 6.0 the following WARN triggers:
> drivers/gpu/drm/i915/display/intel_bios.c:477:
>
> drm_WARN(>drm, min_size == 0,
> "Block %d min_size is zero\n", section_id);
What's the value of section_id that gets printed?
>>>
>>> I'm guessing this is [1] fixed by commit d3a7051841f0 ("drm/i915/bios:
>>> Use hardcoded fp_timing size for generating LFP data pointers") in
>>> v6.1-rc1.
>>>
>>> I don't think this is the root cause for your issues, but I wonder if
>>> you could try v6.1-rc1 or drm-tip and see if we've fixed the other stuff
>>> already too?
>>
>> 6.1-rc1 indeed does not trigger the drm_WARN and for now (couple of
>> reboots, running for 5 minutes now) it seems stable. 6.0.0 usually
>> crashed during boot (but not always).
>>
>> Do you think it would be worthwhile to try 6.0.0 with d3a7051841f0 ?
So I have been trying 6.0.0 with d3a7051841f0 doing a whole bunch of
reboots + general use and that seems stable, then I reverted it and
the very first boot of the kernel with that broke again, so I'm
pretty sure that d3a7051841f0 fixes things.
So d3a7051841f0 seems to do more then just fix the WARN().
So lets try to get d3a7051841f0 added to the official stable series
ASAP (I just noticed that Mark Pearson from Lenovo has already added it
to Fedora's 6.0.2 build.
Regards,
Hans
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable YCbCr420 for VDSC (rev3)
== Series Details ==
Series: Enable YCbCr420 for VDSC (rev3)
URL : https://patchwork.freedesktop.org/series/109723/
State : warning
== Summary ==
Error: dim checkpatch failed
55621de03fe4 drm/i915/dp: Check if DSC supports the given output_format
4f0091385d61 drm/i915: Adding the new registers for DSC
ccd21963a69f drm/i915: Enable YCbCr420 for VDSC
-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_row' - possible
side-effects?
#189: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420) do { \
+ if (bpc == (_bpc)) {\
+ if (_is_420)\
+ return
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+ else\
+ return
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+ } \
} while (0)
-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_col' - possible
side-effects?
#189: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420) do { \
+ if (bpc == (_bpc)) {\
+ if (_is_420)\
+ return
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+ else\
+ return
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+ } \
} while (0)
total: 0 errors, 0 warnings, 2 checks, 228 lines checked
f3ae50bc33c5 drm/i915: Fill in native_420 field
Re: [Intel-gfx] [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP scenario
On Mon, 10 Oct 2022, Animesh Manna wrote:
> From display gen12 onwards to support dual EDP two instances of pps added.
> Currently backlight controller and pps instance can be mapped together
> for a specific panel. Currently dual PPS support is broken. This patch fixes
> it and enables for display 12+.
>
> v1: Iniital revision.
> v2: Called intel_bios_panel_init w/o PNPID before intel_pps_init. [Jani]
> v3: Set pps_id to -1 for pnpid type of panel which will be used by
> bxt_power_sequencer_idx() to set 2nd pps instance as default for
> 2nd EDP panel. [Jani]
> v4: Early return for PANEL_TYPE_FALLBACK. [Jani]
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Uma Shankar
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 13 +++--
> drivers/gpu/drm/i915/display/intel_bios.h | 2 +-
> drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c| 10 +++---
> drivers/gpu/drm/i915/display/intel_pps.c | 12 +++-
> 5 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index c2987f2c2b2e..dd3cd2ca815d 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -3183,15 +3183,22 @@ void intel_bios_init(struct drm_i915_private *i915)
> kfree(oprom_vbt);
> }
>
> -void intel_bios_init_panel(struct drm_i915_private *i915,
> +bool intel_bios_init_panel(struct drm_i915_private *i915,
> struct intel_panel *panel,
> const struct intel_bios_encoder_data *devdata,
> const struct edid *edid)
> {
> init_vbt_panel_defaults(panel);
> -
Please don't do superfluous whitespace changes.
> panel->vbt.panel_type = get_panel_type(i915, devdata, edid);
>
> + if (panel->vbt.panel_type == PANEL_TYPE_PNPID ||
> + panel->vbt.panel_type == PANEL_TYPE_FALLBACK) {
> + panel->vbt.edp.pps_id = -1;
> +
> + if (!edid && intel_bios_encoder_supports_edp(devdata))
> + return true;
> + }
> +
if (panel->vbt.panel_type == PANEL_TYPE_FALLBACK && !edid) {
panel->vbt.backlight.controller = -1;
return true;
}
> parse_panel_options(i915, panel);
> parse_generic_dtd(i915, panel);
> parse_lfp_data(i915, panel);
> @@ -3203,6 +3210,8 @@ void intel_bios_init_panel(struct drm_i915_private
> *i915,
> parse_psr(i915, panel);
> parse_mipi_config(i915, panel);
> parse_mipi_sequence(i915, panel);
> +
> + return false;
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
> b/drivers/gpu/drm/i915/display/intel_bios.h
> index e375405a7828..f8ef0274f3ee 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.h
> +++ b/drivers/gpu/drm/i915/display/intel_bios.h
> @@ -232,7 +232,7 @@ struct mipi_pps_data {
> } __packed;
>
> void intel_bios_init(struct drm_i915_private *dev_priv);
> -void intel_bios_init_panel(struct drm_i915_private *dev_priv,
> +bool intel_bios_init_panel(struct drm_i915_private *dev_priv,
> struct intel_panel *panel,
> const struct intel_bios_encoder_data *devdata,
> const struct edid *edid);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 44ab296c1f04..37e8309207bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -307,6 +307,7 @@ struct intel_vbt_panel_data {
> int preemphasis;
> int vswing;
> int bpp;
> + int pps_id;
Unnecessary.
> struct edp_power_seq pps;
> u8 drrs_msa_timing_delay;
> bool low_vswing;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 70b06806ec0d..50d9223562e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5235,6 +5235,7 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> bool has_dpcd;
> struct edid *edid;
> + bool retry;
>
> if (!intel_dp_is_edp(intel_dp))
> return true;
> @@ -5254,6 +5255,9 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> return false;
> }
>
> + retry = intel_bios_init_panel(dev_priv, _connector->panel,
> + encoder->devdata, NULL);
> +
> intel_pps_init(intel_dp);
>
> /* Cache DPCD and EDID for edp. */
> @@ -5288,9 +5292,9 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
