[Intel-gfx] [PATCH v4 0/4] i915 lpsp support for lpsp igt
v4 has fixed the review comment provided by animesh. Test-with: 20200409053951.26929-2-anshuman.gu...@intel.com Anshuman Gupta (4): drm/i915: Power well id for ICL PG3 drm/i915: Add i915_lpsp_capability debugfs drm/i915: Add connector dbgfs for all connectors drm/i915: Add i915_lpsp_status debugfs attribute .../gpu/drm/i915/display/intel_connector.c| 3 + .../drm/i915/display/intel_display_debugfs.c | 109 ++ .../drm/i915/display/intel_display_power.c| 6 +- .../drm/i915/display/intel_display_power.h| 4 +- drivers/gpu/drm/i915/display/intel_dp.c | 3 - drivers/gpu/drm/i915/display/intel_hdmi.c | 3 - 6 files changed, 118 insertions(+), 10 deletions(-) -- 2.26.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/4] drm/i915: Add i915_lpsp_capability debugfs
New i915_pm_lpsp igt solution approach relies on connector specific
debugfs attribute i915_lpsp_capability, it exposes whether an output is
capable of driving lpsp.
v2:
- CI fixup.
v3:
- register i915_lpsp_info only for supported connector. [Jani]
- use intel_display_power_well_is_enabled() instead of looking
inside power_well count. [Jani]
- fixes the lpsp capable conditional logic. [Jani]
- combined the lpsp capable and enable info. [Jani]
v4:
- Separate out connector based debugfs i915_lpsp_capability
lpsp enable status would be exposes by different entry. [Animesh]
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_debugfs.c | 63 +++
1 file changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index bdeea2e02642..402b89daff62 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -611,6 +611,28 @@ static void intel_hdcp_info(struct seq_file *m,
seq_puts(m, "\n");
}
+#define LPSP_CAPABLE(COND) (COND ? seq_puts(m, "LPSP: capable\n") : \
+ seq_puts(m, "LPSP: incapable\n"))
+
+static bool intel_have_edp_dsi_panel(struct drm_connector *connector)
+{
+ return connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP;
+}
+
+static bool intel_have_dp_edp_dsi_panel(struct drm_connector *connector)
+{
+ return intel_have_edp_dsi_panel(connector) ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort;
+}
+
+static bool intel_have_hdmi_dp_edp_dsi_panel(struct drm_connector *connector)
+{
+ return intel_have_dp_edp_dsi_panel(connector) ||
+ connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+ connector->connector_type == DRM_MODE_CONNECTOR_HDMIB;
+}
+
static void intel_dp_info(struct seq_file *m,
struct intel_connector *intel_connector)
{
@@ -1991,6 +2013,42 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
}
DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
+static int i915_lpsp_capability_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct intel_encoder *encoder =
+ intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ switch (INTEL_GEN(i915)) {
+ case 12:
+ /*
+* Actually TGL can drive LPSP on port till DDI_C
+* but there is no physical connected DDI_C on TGL sku's,
+* even driver is not initilizing DDI_C port for gen12.
+*/
+ LPSP_CAPABLE(encoder->port <= PORT_B);
+ break;
+ case 11:
+ LPSP_CAPABLE(intel_have_edp_dsi_panel(connector));
+ break;
+ case 10:
+ case 9:
+ LPSP_CAPABLE(encoder->port == PORT_A &&
+intel_have_dp_edp_dsi_panel(connector));
+ break;
+ default:
+ if (IS_HASWELL(i915) || IS_BROADWELL(i915))
+ LPSP_CAPABLE(connector->connector_type ==
DRM_MODE_CONNECTOR_eDP);
+ }
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(i915_lpsp_capability);
+
static int i915_dsc_fec_support_show(struct seq_file *m, void *data)
{
struct drm_connector *connector = m->private;
@@ -2134,5 +2192,10 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
connector, &i915_dsc_fec_support_fops);
+ /* Legacy panels doesn't lpsp on any platform */
+ if (intel_have_hdmi_dp_edp_dsi_panel(connector))
+ debugfs_create_file("i915_lpsp_capability", 0444, root,
+ connector, &i915_lpsp_capability_fops);
+
return 0;
}
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/4] drm/i915: Add connector dbgfs for all connectors
Add connector debugfs attributes for each intel connector which is getting register. v2: - adding connector debugfs for each connector in intel_connector_register() to fix CI failure for legacy connectors. Reviewed-by: Jani Nikula Signed-off-by: Anshuman Gupta --- drivers/gpu/drm/i915/display/intel_connector.c | 3 +++ drivers/gpu/drm/i915/display/intel_dp.c| 3 --- drivers/gpu/drm/i915/display/intel_hdmi.c | 3 --- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_connector.c b/drivers/gpu/drm/i915/display/intel_connector.c index 98ec2ea86c7c..406e96785c76 100644 --- a/drivers/gpu/drm/i915/display/intel_connector.c +++ b/drivers/gpu/drm/i915/display/intel_connector.c @@ -33,6 +33,7 @@ #include "i915_drv.h" #include "intel_connector.h" +#include "intel_display_debugfs.h" #include "intel_display_types.h" #include "intel_hdcp.h" @@ -123,6 +124,8 @@ int intel_connector_register(struct drm_connector *connector) goto err_backlight; } + intel_connector_debugfs_add(connector); + return 0; err_backlight: diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 85cfd7210ad8..2cea1c0dcaa8 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -48,7 +48,6 @@ #include "intel_audio.h" #include "intel_connector.h" #include "intel_ddi.h" -#include "intel_display_debugfs.h" #include "intel_display_types.h" #include "intel_dp.h" #include "intel_dp_link_training.h" @@ -6451,8 +6450,6 @@ intel_dp_connector_register(struct drm_connector *connector) if (ret) return ret; - intel_connector_debugfs_add(connector); - drm_dbg_kms(&i915->drm, "registering %s bus for %s\n", intel_dp->aux.name, connector->kdev->kobj.name); diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 011d83c2a1e3..0ca8bf62cb8e 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -44,7 +44,6 @@ #include "intel_audio.h" #include "intel_connector.h" #include "intel_ddi.h" -#include "intel_display_debugfs.h" #include "intel_display_types.h" #include "intel_dp.h" #include "intel_dpio_phy.h" @@ -2877,8 +2876,6 @@ intel_hdmi_connector_register(struct drm_connector *connector) if (ret) return ret; - intel_connector_debugfs_add(connector); - intel_hdmi_create_i2c_symlink(connector); return ret; -- 2.26.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/4] drm/i915: Add i915_lpsp_status debugfs attribute
It requires a separate debugfs attribute to expose lpsp
status to user space, as there may be display less configuration
without any valid connected output, those configuration will not be
able to test lpsp status, if lpsp status exposed from a connector
based debugfs attribute.
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_debugfs.c | 46 +++
.../drm/i915/display/intel_display_power.h| 2 +
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 402b89daff62..9a5b7f1cbe07 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -9,6 +9,7 @@
#include "i915_debugfs.h"
#include "intel_csr.h"
#include "intel_display_debugfs.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_fbc.h"
@@ -613,6 +614,8 @@ static void intel_hdcp_info(struct seq_file *m,
#define LPSP_CAPABLE(COND) (COND ? seq_puts(m, "LPSP: capable\n") : \
seq_puts(m, "LPSP: incapable\n"))
+#define LPSP_STATUS(COND) (COND ? seq_puts(m, "LPSP: enabled\n") : \
+ seq_puts(m, "LPSP: disabled\n"))
static bool intel_have_edp_dsi_panel(struct drm_connector *connector)
{
@@ -1165,6 +1168,48 @@ static int i915_drrs_status(struct seq_file *m, void
*unused)
return 0;
}
+static bool
+intel_lpsp_power_well_enabled(struct drm_i915_private *i915,
+ enum i915_power_well_id power_well_id)
+{
+ intel_wakeref_t wakeref;
+ bool is_enabled;
+
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+ is_enabled = intel_display_power_well_is_enabled(i915,
+power_well_id);
+ intel_runtime_pm_put(&i915->runtime_pm, wakeref);
+
+ return is_enabled;
+}
+
+static int i915_lpsp_status(struct seq_file *m, void *unused)
+{
+ struct drm_i915_private *i915 = node_to_i915(m->private);
+
+ switch (INTEL_GEN(i915)) {
+ case 12:
+ case 11:
+ LPSP_STATUS(!intel_lpsp_power_well_enabled(i915,
ICL_DISP_PW_3));
+ break;
+ case 10:
+ case 9:
+ LPSP_STATUS(!intel_lpsp_power_well_enabled(i915,
SKL_DISP_PW_2));
+ break;
+ default:
+ /*
+* Apart from HASWELL/BROADWELL other legacy platform doesn't
+* support lpsp.
+*/
+ if (IS_HASWELL(i915) || IS_BROADWELL(i915))
+ LPSP_STATUS(!intel_lpsp_power_well_enabled(i915,
HSW_DISP_PW_GLOBAL));
+ else
+ seq_puts(m, "LPSP: not supported\n");
+ }
+
+ return 0;
+}
+
static int i915_dp_mst_info(struct seq_file *m, void *unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -1932,6 +1977,7 @@ static const struct drm_info_list
intel_display_debugfs_list[] = {
{"i915_dp_mst_info", i915_dp_mst_info, 0},
{"i915_ddb_info", i915_ddb_info, 0},
{"i915_drrs_status", i915_drrs_status, 0},
+ {"i915_lpsp_status", i915_lpsp_status, 0},
};
static const struct {
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 56cbae6327b7..14c5ad20287f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -266,6 +266,8 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain);
bool intel_display_power_is_enabled(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
+bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
+enum i915_power_well_id power_well_id);
bool __intel_display_power_is_enabled(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
intel_wakeref_t intel_display_power_get(struct drm_i915_private *dev_priv,
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/4] drm/i915: Power well id for ICL PG3
Gen11 onwards PG3 is contains functions for pipe B,
external displays, and VGA. It make sense to add
a power well id with name ICL_DISP_PW_3 rather then
TGL_DISP_PW_3, Also PG3 power well id requires to
know if lpsp is enabled.
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_power.c | 6 +++---
drivers/gpu/drm/i915/display/intel_display_power.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 433e5a81dd4d..3672c00be94a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -943,7 +943,7 @@ static void assert_can_enable_dc5(struct drm_i915_private
*dev_priv)
/* Power wells at this level and above must be disabled for DC5 entry */
if (INTEL_GEN(dev_priv) >= 12)
- high_pg = TGL_DISP_PW_3;
+ high_pg = ICL_DISP_PW_3;
else
high_pg = SKL_DISP_PW_2;
@@ -3571,7 +3571,7 @@ static const struct i915_power_well_desc
icl_power_wells[] = {
.name = "power well 3",
.domains = ICL_PW_3_POWER_DOMAINS,
.ops = &hsw_power_well_ops,
- .id = DISP_PW_ID_NONE,
+ .id = ICL_DISP_PW_3,
{
.hsw.regs = &hsw_power_well_regs,
.hsw.idx = ICL_PW_CTL_IDX_PW_3,
@@ -3949,7 +3949,7 @@ static const struct i915_power_well_desc
tgl_power_wells[] = {
.name = "power well 3",
.domains = TGL_PW_3_POWER_DOMAINS,
.ops = &hsw_power_well_ops,
- .id = TGL_DISP_PW_3,
+ .id = ICL_DISP_PW_3,
{
.hsw.regs = &hsw_power_well_regs,
.hsw.idx = ICL_PW_CTL_IDX_PW_3,
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index da64a5edae7a..56cbae6327b7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -100,7 +100,7 @@ enum i915_power_well_id {
SKL_DISP_PW_MISC_IO,
SKL_DISP_PW_1,
SKL_DISP_PW_2,
- TGL_DISP_PW_3,
+ ICL_DISP_PW_3,
SKL_DISP_DC_OFF,
};
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce drm scaling filter property (rev6)
== Series Details == Series: Introduce drm scaling filter property (rev6) URL : https://patchwork.freedesktop.org/series/73883/ State : success == Summary == CI Bug Log - changes from CI_DRM_8278_full -> Patchwork_17256_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17256_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-forked: - shard-snb: [PASS][1] -> [INCOMPLETE][2] ([i915#82]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-snb1/igt@gem_exec_whis...@basic-forked.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-snb6/igt@gem_exec_whis...@basic-forked.html * igt@gem_workarounds@suspend-resume-context: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#69]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-skl5/igt@gem_workarou...@suspend-resume-context.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-skl8/igt@gem_workarou...@suspend-resume-context.html * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-kbl6/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-kbl7/igt@gen9_exec_pa...@allowed-all.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#716]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-skl9/igt@gen9_exec_pa...@allowed-single.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-skl6/igt@gen9_exec_pa...@allowed-single.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109349]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-iclb4/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#79]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-glk8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-glk3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-kbl2/igt@kms_f...@flip-vs-suspend-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-kbl4/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180] / [i915#93] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-kbl3/igt@kms_frontbuffer_track...@fbc-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-pwrite: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#49]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-skl4/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-skl6/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/shard-iclb7/igt@kms_psr@psr2_primary_page_flip.html Possible fixes *
Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Drop gem_exec_suspend@basic-S4-device from BAT
On 2020-04-08 17:19, Chris Wilson wrote: > S4-devices is a debug only path, and while it can prove informative as > to the nature of suspend issues, being a debug only path it is not so > relevant towards the driver health. Relegate it to the shards and idle > runs, so we can shave 20s off BAT. > > gem_exec_suspend@basic itself is just a test suspend, a sanitycheck to > ensure the test is functional, for manual debugging of the tests. > > Signed-off-by: Chris Wilson > Cc: Martin Peres > Cc: Petri Latvala Acked-by: Martin Peres > --- > tests/intel-ci/fast-feedback.testlist | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/tests/intel-ci/fast-feedback.testlist > b/tests/intel-ci/fast-feedback.testlist > index 620d5f3a7..2ccad4386 100644 > --- a/tests/intel-ci/fast-feedback.testlist > +++ b/tests/intel-ci/fast-feedback.testlist > @@ -23,10 +23,8 @@ igt@gem_exec_fence@nb-await > igt@gem_exec_gttfill@basic > igt@gem_exec_parallel@engines > igt@gem_exec_store@basic > -igt@gem_exec_suspend@basic > igt@gem_exec_suspend@basic-s0 > igt@gem_exec_suspend@basic-s3 > -igt@gem_exec_suspend@basic-s4-devices > igt@gem_flink_basic@bad-flink > igt@gem_flink_basic@bad-open > igt@gem_flink_basic@basic > pEpkey.asc Description: pEpkey.asc ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Add Plane color encoding support for YCBCR_BT2020
> -Original Message-
> From: Kadiyala, Kishore
> Sent: Wednesday, April 8, 2020 7:52 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kadiyala, Kishore ; Ville Syrjala
> ; Shankar, Uma ; Nikula,
> Jani
> Subject: [PATCH v5] drm/i915: Add Plane color encoding support for
> YCBCR_BT2020
>
> Currently the plane property doesn't have support for YCBCR_BT2020, which
> enables
> the corresponding color conversion mode on plane CSC.
> Enabling the plane property for the planes for GLK & ICL+ platforms.
>
> V2: Enabling support for YCBCT_BT2020 for HDR planes on
> platforms GLK & ICL
>
> V3: Refined the condition check to handle GLK & ICL+ HDR planes
> Also added BT2020 handling in glk_plane_color_ctl.
>
> V4: Combine If-else into single If
>
> V5: Drop the checking for HDR planes and enable YCBCR_BT2020
> for platforms GLK & ICL+.
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Ville Syrjala
> Cc: Uma Shankar
> Cc: Jani Nikula
> Signed-off-by: Kishore Kadiyala
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 12 +---
> drivers/gpu/drm/i915/display/intel_sprite.c | 9 +++--
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 70ec301fe6e3..f2dfa61a49fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
> *crtc_state,
> plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
>
> if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> - if (plane_state->hw.color_encoding ==
> DRM_COLOR_YCBCR_BT709)
> + switch (plane_state->hw.color_encoding) {
> + case DRM_COLOR_YCBCR_BT709:
> plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> - else
> + break;
> + case DRM_COLOR_YCBCR_BT2020:
> + plane_color_ctl |=
> +
> PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> + break;
> + default:
> plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> -
> + }
> if (plane_state->hw.color_range ==
> DRM_COLOR_YCBCR_FULL_RANGE)
> plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> } else if (fb->format->is_yuv) {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index deda351719db..0072525046a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> struct intel_plane *plane;
> enum drm_plane_type plane_type;
> unsigned int supported_rotations;
> + unsigned int supported_csc;
> const u64 *modifiers;
> const u32 *formats;
> int num_formats;
> @@ -3105,9 +3106,13 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> DRM_MODE_ROTATE_0,
> supported_rotations);
>
> + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) |
> +BIT(DRM_COLOR_YCBCR_BT709);
> +
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> +
> drm_plane_create_color_properties(&plane->base,
> - BIT(DRM_COLOR_YCBCR_BT601) |
> - BIT(DRM_COLOR_YCBCR_BT709),
> + supported_csc,
>
> BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
> BIT(DRM_COLOR_YCBCR_FULL_RANGE),
> DRM_COLOR_YCBCR_BT709,
> --
> 2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev4)
== Series Details ==
Series: drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev4)
URL : https://patchwork.freedesktop.org/series/75660/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8277_full -> Patchwork_17254_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17254_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17254_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17254_full:
### IGT changes ###
Possible regressions
* igt@gem_softpin@noreloc-s3:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-iclb5/igt@gem_soft...@noreloc-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-iclb3/igt@gem_soft...@noreloc-s3.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@sysfs_heartbeat_interval@mixed@vecs0}:
- shard-skl: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-skl10/igt@sysfs_heartbeat_interval@mi...@vecs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-skl5/igt@sysfs_heartbeat_interval@mi...@vecs0.html
Known issues
Here are the changes found in Patchwork_17254_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#716])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-glk5/igt@gen9_exec_pa...@allowed-all.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-glk2/igt@gen9_exec_pa...@allowed-all.html
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#716])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-kbl7/igt@gen9_exec_pa...@allowed-all.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-kbl1/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +2 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html
- shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_flip@plain-flip-ts-check:
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#34])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-skl8/igt@kms_f...@plain-flip-ts-check.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-skl8/igt@kms_f...@plain-flip-ts-check.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +4 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-iclb4/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][17] -> [FAIL][18] ([i915#31])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-apl3/igt@kms_setm...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-apl8/igt@kms_setm...@basic.html
Possible fixes
* igt@kms_busy@basic-flip-pipe-a:
- shard-kbl: [INCOMPLETE][19] -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-kbl7/igt@kms_b...@basic-flip-pipe-a.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-kbl3/igt@kms_b...@basic-flip-pipe-a.html
* igt@kms_cursor_crc@pipe-c-cursor-64x21-onscreen:
- shard-skl: [FAIL][21] ([i915#54]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-64x21-onscreen.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-64x21-onscreen.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [FAIL][23] ([i915#1188]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/shard-skl2/igt
[Intel-gfx] ✓ Fi.CI.BAT: success for uC code cleanups
== Series Details ==
Series: uC code cleanups
URL : https://patchwork.freedesktop.org/series/75719/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8281 -> Patchwork_17262
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17262/index.html
Known issues
Here are the changes found in Patchwork_17262 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [PASS][1] -> [FAIL][2] ([i915#1158])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8281/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17262/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live@hangcheck:
- fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([i915#1580])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8281/fi-icl-y/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17262/fi-icl-y/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-icl-dsi: [INCOMPLETE][5] ([i915#189]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8281/fi-icl-dsi/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17262/fi-icl-dsi/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1158]: https://gitlab.freedesktop.org/drm/intel/issues/1158
[i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580
[i915#1604]: https://gitlab.freedesktop.org/drm/intel/issues/1604
[i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189
Participating hosts (51 -> 46)
--
Additional (1): fi-skl-6770hq
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8281 -> Patchwork_17262
CI-20190529: 20190529
CI_DRM_8281: 4d6c69198d6840226f92f2c4645e2c8260ca3e83 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5581: ab0620e555119ec55f12ba9ab9e6e9246d407648 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17262: 8a3c5810fd98a7985a71613dbe8f488f9d5aa749 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8a3c5810fd98 HAX: drm/i915: default to enable_guc=2
a473fe00b153 drm/i915: consolidate WOPCM management under gt/uc
db5f8b4a0580 drm/i915/guc: drop gt.pm_guc_events
8dddf55cb05f drm/i915/guc: drop guc parameter from guc_ggtt_offset
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17262/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for uC code cleanups
== Series Details == Series: uC code cleanups URL : https://patchwork.freedesktop.org/series/75719/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8dddf55cb05f drm/i915/guc: drop guc parameter from guc_ggtt_offset db5f8b4a0580 drm/i915/guc: drop gt.pm_guc_events a473fe00b153 drm/i915: consolidate WOPCM management under gt/uc -:240: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #240: rename from drivers/gpu/drm/i915/intel_wopcm.c total: 0 errors, 1 warnings, 0 checks, 396 lines checked 8a3c5810fd98 HAX: drm/i915: default to enable_guc=2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/guc: re-enable ARAT expired interrupt when using GuC
== Series Details == Series: series starting with [1/2] drm/i915/guc: re-enable ARAT expired interrupt when using GuC URL : https://patchwork.freedesktop.org/series/75715/ State : success == Summary == CI Bug Log - changes from CI_DRM_8281 -> Patchwork_17261 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17261/index.html Known issues Here are the changes found in Patchwork_17261 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][1] -> [FAIL][2] ([i915#262]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8281/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17261/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-icl-dsi: [INCOMPLETE][3] ([i915#189]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8281/fi-icl-dsi/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17261/fi-icl-dsi/igt@i915_pm_...@module-reload.html [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 Participating hosts (51 -> 46) -- Additional (1): fi-skl-6770hq Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8281 -> Patchwork_17261 CI-20190529: 20190529 CI_DRM_8281: 4d6c69198d6840226f92f2c4645e2c8260ca3e83 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5581: ab0620e555119ec55f12ba9ab9e6e9246d407648 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17261: 2b775979212a30032975bf16c18001c9b228626b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2b775979212a HAX: drm/i915: default to enable_guc=2 950b8648892c drm/i915/guc: re-enable ARAT expired interrupt when using GuC == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17261/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: consolidate WOPCM management under gt/uc
The WOPCM is not a uC-specific resource, but the only use-case we have
for it on the SW side is the programming of the related registers for
GuC/HuC DMA, everything else is HW-managed. Given that the wopcm init
functions are already heavily uC focused (to the point that they skip
on HW that doesn't have GuC/HuC), it makes sense to stop pretending we
handle WOPCM as a global resource and just focus on the part we care
about. Therefore, we can move the init functions inside gt/uc and
consolidate all the uC WOPCM functions inside the same file.
As part of the move, the initialization has been slightly simplified,
including dropping a check on FW fetch to verify that the FW blob is not
bigger that the whole WOPCM. This means that in the extremely unlikely
case we do have a FW that is too big (why would we ever ship a FW that
can't be loaded?) we might underflow in our partitioning math, but we're
still safe due to the check we perform when we verify the partitioning
after we're done with the calculations. Note that this is not a
regression given that even now we might underflow if the binary is close
to the size of the WOPCM due to adding the reserved regions to the mix.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
Documentation/gpu/i915.rst| 2 +-
drivers/gpu/drm/i915/Makefile | 4 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 67 +
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 25
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 11 --
.../{intel_wopcm.c => gt/uc/intel_uc_wopcm.c} | 141 --
drivers/gpu/drm/i915/i915_drv.c | 2 -
drivers/gpu/drm/i915/i915_drv.h | 3 -
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/intel_wopcm.h| 60
11 files changed, 128 insertions(+), 191 deletions(-)
rename drivers/gpu/drm/i915/{intel_wopcm.c => gt/uc/intel_uc_wopcm.c} (71%)
delete mode 100644 drivers/gpu/drm/i915/intel_wopcm.h
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 429b08aac797..28c396a18574 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -430,7 +430,7 @@ WOPCM
WOPCM Layout
-.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.c
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc_wopcm.c
:doc: WOPCM Layout
GuC
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2fce8b0040f3..c35d5e827836 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -162,13 +162,13 @@ i915-y += \
i915_scheduler.o \
i915_trace_points.o \
i915_vma.o \
- intel_region_lmem.o \
- intel_wopcm.o
+ intel_region_lmem.o
# general-purpose microcontroller (GuC) support
i915-y += gt/uc/intel_uc.o \
gt/uc/intel_uc_debugfs.o \
gt/uc/intel_uc_fw.o \
+ gt/uc/intel_uc_wopcm.o \
gt/uc/intel_guc.o \
gt/uc/intel_guc_ads.o \
gt/uc/intel_guc_ct.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index eebd1190506f..4a3b82dc2765 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -506,7 +506,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
* why.
*/
ggtt->pin_bias = max_t(u32, I915_GTT_PAGE_SIZE,
- intel_wopcm_guc_size(&ggtt->vm.i915->wopcm));
+ intel_uc_wopcm_guc_size(&ggtt->vm.gt->uc));
ret = intel_vgt_balloon(ggtt);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index f518fe05c6f9..ee3205eefd70 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -333,69 +333,6 @@ static int __uc_sanitize(struct intel_uc *uc)
return __intel_uc_reset_hw(uc);
}
-/* Initialize and verify the uC regs related to uC positioning in WOPCM */
-static int uc_init_wopcm(struct intel_uc *uc)
-{
- struct intel_gt *gt = uc_to_gt(uc);
- struct intel_uncore *uncore = gt->uncore;
- u32 base = intel_wopcm_guc_base(>->i915->wopcm);
- u32 size = intel_wopcm_guc_size(>->i915->wopcm);
- u32 huc_agent = intel_uc_uses_huc(uc) ? HUC_LOADING_AGENT_GUC : 0;
- u32 mask;
- int err;
-
- if (unlikely(!base || !size)) {
- i915_probe_error(gt->i915, "Unsuccessful WOPCM partitioning\n");
- return -E2BIG;
- }
-
- GEM_BUG_ON(!intel_uc_supports_guc(uc));
- GEM_BUG_ON(!(base & GUC_WOPCM_OFFSET_MASK));
- GEM_BUG_ON(base & ~GUC_WOPCM_OFFSET_MASK);
- GEM_BUG_ON(!(size & GUC_WOPCM_SIZE_MASK));
- GEM_BUG_ON(size & ~GUC_WOPCM_SIZE_MASK);
-
- err = i915_inject_probe_error(gt->i915, -ENXIO);
- if (err)
- retur
[Intel-gfx] [PATCH 1/4] drm/i915/guc: drop guc parameter from guc_ggtt_offset
We stopped using the parameter in commit dd18cedfa36f
("drm/i915/guc: Move the pin bias value from GuC to GGTT"),
so we can safely remove it.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Brost
Cc: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 6 +++---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 +---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 ++---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 3 +--
6 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 861657897c0f..5134d544bf4c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -220,7 +220,7 @@ static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
if (intel_guc_submission_is_used(guc)) {
u32 ctxnum, base;
- base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
+ base = intel_guc_ggtt_offset(guc->stage_desc_pool);
ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
base >>= PAGE_SHIFT;
@@ -232,7 +232,7 @@ static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
- u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
+ u32 offset = intel_guc_ggtt_offset(guc->log.vma) >> PAGE_SHIFT;
u32 flags;
#if (((CRASH_BUFFER_SIZE) % SZ_1M) == 0)
@@ -273,7 +273,7 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
static u32 guc_ctl_ads_flags(struct intel_guc *guc)
{
- u32 ads = intel_guc_ggtt_offset(guc, guc->ads_vma) >> PAGE_SHIFT;
+ u32 ads = intel_guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
u32 flags = ads << GUC_ADS_ADDR_SHIFT;
return flags;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index e84ab67b317d..366191204a7d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -103,7 +103,6 @@ static inline void intel_guc_to_host_event_handler(struct
intel_guc *guc)
/**
* intel_guc_ggtt_offset() - Get and validate the GGTT offset of @vma
- * @guc: intel_guc structure.
* @vma: i915 graphics virtual memory area.
*
* GuC does not allow any gfx GGTT address that falls into range
@@ -114,8 +113,7 @@ static inline void intel_guc_to_host_event_handler(struct
intel_guc *guc)
*
* Return: GGTT offset of the @vma.
*/
-static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc,
- struct i915_vma *vma)
+static inline u32 intel_guc_ggtt_offset(struct i915_vma *vma)
{
u32 offset = i915_ggtt_offset(vma);
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 101728006ae9..9237d798f7f4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -107,7 +107,7 @@ static void __guc_ads_init(struct intel_guc *guc)
blob->system_info.vebox_enable_mask = VEBOX_MASK(dev_priv);
blob->system_info.vdbox_sfc_support_mask =
RUNTIME_INFO(dev_priv)->vdbox_sfc_access;
- base = intel_guc_ggtt_offset(guc, guc->ads_vma);
+ base = intel_guc_ggtt_offset(guc->ads_vma);
/* Clients info */
guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool));
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 11742fca0e9e..aad5ac54c1ba 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -187,7 +187,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
return err;
}
- CT_DEBUG(ct, "vma base=%#x\n", intel_guc_ggtt_offset(guc, ct->vma));
+ CT_DEBUG(ct, "vma base=%#x\n", intel_guc_ggtt_offset(ct->vma));
/* store pointers to desc and cmds */
for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
@@ -220,7 +220,6 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
*/
int intel_guc_ct_enable(struct intel_guc_ct *ct)
{
- struct intel_guc *guc = ct_to_guc(ct);
u32 base, cmds, size;
int err;
int i;
@@ -229,7 +228,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
/* vma should be already allocated and map'ed */
GEM_BUG_ON(!ct->vma);
- base = intel_guc_ggtt_offset(guc, ct->vma);
+ base = intel_guc_ggtt_offset(ct->vma);
/* (re)initialize descriptors
* cmds buffers are in the second half of the blob page
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index fe7778c28d2d..7eaf173dd588 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submissi
[Intel-gfx] [PATCH 2/4] drm/i915/guc: drop gt.pm_guc_events
We always set it to the same value, so there is no need to actually have
a variable for it and we can just use the value directly.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 --
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 8
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 3 +++
drivers/gpu/drm/i915/i915_irq.c| 4
4 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 96890dd12b5f..81691cf1d411 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -85,8 +85,6 @@ struct intel_gt {
u32 pm_ier;
u32 pm_imr;
- u32 pm_guc_events;
-
struct intel_engine_cs *engine[I915_NUM_ENGINES];
struct intel_engine_cs *engine_class[MAX_ENGINE_CLASS + 1]
[MAX_ENGINE_INSTANCE + 1];
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 5134d544bf4c..eadea9d47e31 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -85,7 +85,7 @@ static void gen9_reset_guc_interrupts(struct intel_guc *guc)
assert_rpm_wakelock_held(>->i915->runtime_pm);
spin_lock_irq(>->irq_lock);
- gen6_gt_pm_reset_iir(gt, gt->pm_guc_events);
+ gen6_gt_pm_reset_iir(gt, GEN9_GUC_INTR_BIT(GUC2HOST));
spin_unlock_irq(>->irq_lock);
}
@@ -98,9 +98,9 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
spin_lock_irq(>->irq_lock);
if (!guc->interrupts.enabled) {
WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
-gt->pm_guc_events);
+GEN9_GUC_INTR_BIT(GUC2HOST));
guc->interrupts.enabled = true;
- gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
+ gen6_gt_pm_enable_irq(gt, GEN9_GUC_INTR_BIT(GUC2HOST));
}
spin_unlock_irq(>->irq_lock);
}
@@ -114,7 +114,7 @@ static void gen9_disable_guc_interrupts(struct intel_guc
*guc)
spin_lock_irq(>->irq_lock);
guc->interrupts.enabled = false;
- gen6_gt_pm_disable_irq(gt, gt->pm_guc_events);
+ gen6_gt_pm_disable_irq(gt, GEN9_GUC_INTR_BIT(GUC2HOST));
spin_unlock_irq(>->irq_lock);
intel_synchronize_irq(gt->i915);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
index 1949346e714e..ae785a757316 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
@@ -143,4 +143,7 @@ struct guc_doorbell_info {
#define GUC_INTR_SW_INT_1 BIT(1)
#define GUC_INTR_SW_INT_0 BIT(0)
+/* pre-gen11 the guc irqs bits are in the upper 16 bits of the pm reg */
+#define GEN9_GUC_INTR_BIT(x) (GUC_INTR_##x << 16)
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1502ab44f1a5..a224a05b0551 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3942,10 +3942,6 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
for (i = 0; i < MAX_L3_SLICES; ++i)
dev_priv->l3_parity.remap_info[i] = NULL;
- /* pre-gen11 the guc irqs bits are in the upper 16 bits of the pm reg */
- if (HAS_GT_UC(dev_priv) && INTEL_GEN(dev_priv) < 11)
- dev_priv->gt.pm_guc_events = GUC_INTR_GUC2HOST << 16;
-
dev->vblank_disable_immediate = true;
/* Most platforms treat the display irq block as an always-on
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] HAX: drm/i915: default to enable_guc=2
To enable GuC and HuC loading on all gen9+ CI machines. Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 45323732f099..7b5d32c990bc 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -56,7 +56,7 @@ struct drm_printer; param(int, disable_power_well, -1, 0400) \ param(int, enable_ips, 1, 0600) \ param(int, invert_brightness, 0, 0600) \ - param(int, enable_guc, 0, 0400) \ + param(int, enable_guc, 2, 0400) \ param(int, guc_log_level, -1, 0400) \ param(char *, guc_firmware_path, NULL, 0400) \ param(char *, huc_firmware_path, NULL, 0400) \ -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] uC code cleanups
Drop a couple of unused variables and move the wopcm code under gt/uc.
The 3 patches are independent from each other, I'm sending them as a
series just to avoid spamming CI.
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Daniele Ceraolo Spurio (4):
drm/i915/guc: drop guc parameter from guc_ggtt_offset
drm/i915/guc: drop gt.pm_guc_events
drm/i915: consolidate WOPCM management under gt/uc
HAX: drm/i915: default to enable_guc=2
Documentation/gpu/i915.rst| 2 +-
drivers/gpu/drm/i915/Makefile | 4 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 -
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 14 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h| 3 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 3 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 67 +
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 25
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 11 --
.../{intel_wopcm.c => gt/uc/intel_uc_wopcm.c} | 141 --
drivers/gpu/drm/i915/i915_drv.c | 2 -
drivers/gpu/drm/i915/i915_drv.h | 3 -
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 4 -
drivers/gpu/drm/i915/i915_params.h| 2 +-
drivers/gpu/drm/i915/intel_wopcm.h| 60
21 files changed, 146 insertions(+), 216 deletions(-)
rename drivers/gpu/drm/i915/{intel_wopcm.c => gt/uc/intel_uc_wopcm.c} (71%)
delete mode 100644 drivers/gpu/drm/i915/intel_wopcm.h
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/perf: Do not clear pollin for small user read buffers (rev8)
== Series Details == Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev8) URL : https://patchwork.freedesktop.org/series/75085/ State : failure == Summary == Applying: drm/i915/perf: Do not clear pollin for small user read buffers Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_perf.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_perf.c No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/guc: re-enable ARAT expired interrupt when using GuC
This is required for GuC to be able to handle timeouts. This is mainly
needed when using GuC submission, but there is no rule saying this won't
be used to handle HuC-related actions so turn it always on when using
the GuC. The routing bit name has also been renamed to indicate what it
actually does, i.e. setting the bit enables the routing to GuC (the bit
name was flipped because we use it in a mbz mask, in which we set the
bits we don't want to be set in the register).
Note that the ARAT interrupt used to be enabled in GuC submission mode,
but was then removed in commit 1cdc2330e8d3 ("drm/i915/guc: Properly
capture & release GuC interrupts on Gen11+"). While it is true that, as
stated in that patch, the host and the GuC have independent masks for
the interrupts, the PM interrupts still need to be additionally globally
unmasked in the PMINTRMSK register.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_rps.c | 21 +++--
drivers/gpu/drm/i915/i915_reg.h | 2 +-
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 86110458e2a7..f5e26b3e61c5 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1684,8 +1684,25 @@ void intel_rps_init(struct intel_rps *rps)
if (INTEL_GEN(i915) <= 7)
rps->pm_intrmsk_mbz |= GEN6_PM_RP_UP_EI_EXPIRED;
- if (INTEL_GEN(i915) >= 8 && INTEL_GEN(i915) < 11)
- rps->pm_intrmsk_mbz |= GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
+ if (INTEL_GEN(i915) >= 8) {
+ /*
+* The PMINTRMSK is not replicated on the GuC side, even on
+* gen11+ where GuC has additional control over its own
+* interrupts. The GuC does update the register during load to
+* unmask the ARAT interrupt, but we still need to make sure our
+* handler doesn't overwrite the setting.
+* On Gen11+ the ARAT interrupt is sent only to the GuC, while
+* on older gens we need to explicitly redirect it using the
+* GEN8_PMINTR_REDIRECT_TO_GUC bit; this bit is on the same
+* register, but it is not a mask and therefore we need to make
+* sure we leave it to one after GuC sets it (i.e. it is not a
+* mbz bit when GuC is enabled).
+*/
+ if (intel_uc_uses_guc(&rps_to_gt(rps)->uc))
+ rps->pm_intrmsk_mbz |= ARAT_EXPIRED_INTRMSK;
+ else if (INTEL_GEN(i915) < 11)
+ rps->pm_intrmsk_mbz |= GEN8_PMINTR_REDIRECT_TO_GUC;
+ }
}
u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0b39b9abf8a4..b65517f7d57a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9010,7 +9010,7 @@ enum {
#define VLV_RCEDATA_MMIO(0xA0BC)
#define GEN6_RC6pp_THRESHOLD _MMIO(0xA0C0)
#define GEN6_PMINTRMSK _MMIO(0xA168)
-#define GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC (1 << 31)
+#define GEN8_PMINTR_REDIRECT_TO_GUC (1 << 31)
#define ARAT_EXPIRED_INTRMSK (1 << 9)
#define GEN8_MISC_CTRL0_MMIO(0xA180)
#define VLV_PWRDWNUPCTL_MMIO(0xA294)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] HAX: drm/i915: default to enable_guc=2
To enable GuC and HuC loading on all gen9+ CI machines. Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 45323732f099..7b5d32c990bc 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -56,7 +56,7 @@ struct drm_printer; param(int, disable_power_well, -1, 0400) \ param(int, enable_ips, 1, 0600) \ param(int, invert_brightness, 0, 0600) \ - param(int, enable_guc, 0, 0400) \ + param(int, enable_guc, 2, 0400) \ param(int, guc_log_level, -1, 0400) \ param(char *, guc_firmware_path, NULL, 0400) \ param(char *, huc_firmware_path, NULL, 0400) \ -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Patches that didn't applied cleanly on drm-intel-next-fixes
On Wed, 08 Apr 2020 13:59:38 -0700, Rodrigo Vivi wrote:
>
> Hi Ashutosh and Chris,
>
> these patches seems needed for 5.7 but didn't applied cleanly on dinf:
>
> Failed to cherry-pick:
> 6352219c39c0 ("drm/i915/perf: Do not clear pollin for small user read
> buffers")
> 614654abe847 ("drm/i915: Check current i915_vma.pin_count status first on
> unbind")
> c4e8ba739034 ("drm/i915/gt: Yield the timeslice if caught waiting on a user
> semaphore")
>
> If they are critical for 5.7 please provide a version that applies or list
> the dependencies.
I have sent a version of 6352219c39c0 to intel-gfx which should apply on dinf:
https://patchwork.freedesktop.org/series/75085/#rev8
Thanks!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/perf: Do not clear pollin for small user read buffers
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smaller than the available data.
This change fixes this issue and allows user space to read all OA data
even when using a buffer size smaller than the available data using
multiple non-blocking reads rather than staying blocked in poll till
the next timer interrupt.
v2: Fix ret value for blocking reads (Umesh)
v3: Mistake during patch send (Ashutosh)
v4: Remove -EAGAIN from comment (Umesh)
v5: Improve condition for clearing pollin and return (Lionel)
v6: Improve blocking read loop and other cleanups (Lionel)
v7: Added Cc stable
Testcase: igt/perf/polling-small-buf
Reviewed-by: Lionel Landwerlin
Signed-off-by: Ashutosh Dixit
Cc: Umesh Nerlige Ramappa
Cc:
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20200403010120.3067-1-ashutosh.di...@intel.com
---
drivers/gpu/drm/i915/i915_perf.c | 65 ++--
1 file changed, 11 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 551be589d6f4..66a46e41d5ef 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2940,49 +2940,6 @@ void i915_oa_init_reg_state(const struct intel_context
*ce,
gen8_update_reg_state_unlocked(ce, stream);
}
-/**
- * i915_perf_read_locked - &i915_perf_stream_ops->read with error normalisation
- * @stream: An i915 perf stream
- * @file: An i915 perf stream file
- * @buf: destination buffer given by userspace
- * @count: the number of bytes userspace wants to read
- * @ppos: (inout) file seek position (unused)
- *
- * Besides wrapping &i915_perf_stream_ops->read this provides a common place to
- * ensure that if we've successfully copied any data then reporting that takes
- * precedence over any internal error status, so the data isn't lost.
- *
- * For example ret will be -ENOSPC whenever there is more buffered data than
- * can be copied to userspace, but that's only interesting if we weren't able
- * to copy some data because it implies the userspace buffer is too small to
- * receive a single record (and we never split records).
- *
- * Another case with ret == -EFAULT is more of a grey area since it would seem
- * like bad form for userspace to ask us to overrun its buffer, but the user
- * knows best:
- *
- * http://yarchive.net/comp/linux/partial_reads_writes.html
- *
- * Returns: The number of bytes copied or a negative error code on failure.
- */
-static ssize_t i915_perf_read_locked(struct i915_perf_stream *stream,
-struct file *file,
-char __user *buf,
-size_t count,
-loff_t *ppos)
-{
- /* Note we keep the offset (aka bytes read) separate from any
-* error status so that the final check for whether we return
-* the bytes read with a higher precedence than any error (see
-* comment below) doesn't need to be handled/duplicated in
-* stream->ops->read() implementations.
-*/
- size_t offset = 0;
- int ret = stream->ops->read(stream, buf, count, &offset);
-
- return offset ?: (ret ?: -EAGAIN);
-}
-
/**
* i915_perf_read - handles read() FOP for i915 perf stream FDs
* @file: An i915 perf stream file
@@ -3008,7 +2965,8 @@ static ssize_t i915_perf_read(struct file *file,
{
struct i915_perf_stream *stream = file->private_data;
struct i915_perf *perf = stream->perf;
- ssize_t ret;
+ size_t offset = 0;
+ int ret;
/* To ensure it's handled consistently we simply treat all reads of a
* disabled stream as an error. In particular it might otherwise lead
@@ -3031,13 +2989,12 @@ static ssize_t i915_perf_read(struct file *file,
return ret;
mutex_lock(&perf->lock);
- ret = i915_perf_read_locked(stream, file,
- buf, count, ppos);
+ ret = stream->ops->read(stream, buf, count, &offset);
mutex_unlock(&perf->lock);
- } while (ret == -EAGAIN);
+ } while (!offset && !ret);
} else {
mutex_lock(&perf->lock);
- ret = i915_perf_read_locked(stream, file, buf, count, ppos);
+ ret = stream->ops->read(stream, buf, count, &offset);
mutex_unlock(&perf->lock);
}
@@ -3048,15 +3005,15 @@ static ssize_t i915_perf_read(struct file *file,
* and read() returning -EAGAIN. Clearing the oa.pollin state here
* effectively ensures we back off until the
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Check current i915_vma.pin_count status first on unbind (rev8)
== Series Details == Series: drm/i915: Check current i915_vma.pin_count status first on unbind (rev8) URL : https://patchwork.freedesktop.org/series/72529/ State : failure == Summary == Applying: drm/i915: Check current i915_vma.pin_count status first on unbind Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_vma.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_vma.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_vma.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Check current i915_vma.pin_count status first on unbind 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 mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Adding YUV444 packed format support for skl+ (rev5)
== Series Details == Series: Adding YUV444 packed format support for skl+ (rev5) URL : https://patchwork.freedesktop.org/series/73020/ State : success == Summary == CI Bug Log - changes from CI_DRM_8269_full -> Patchwork_17241_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17241_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_params@invalid-bsd-ring: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-iclb4/igt@gem_exec_par...@invalid-bsd-ring.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-iclb6/igt@gem_exec_par...@invalid-bsd-ring.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][3] -> [FAIL][4] ([i915#454]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-iclb1/igt@i915_pm...@dc6-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-iclb2/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][5] -> [FAIL][6] ([i915#454]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-skl4/igt@i915_pm...@dc6-psr.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-skl9/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_crc@pipe-a-cursor-256x256-random: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#54] / [i915#93] / [i915#95]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-256x256-random.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-256x256-random.html * igt@kms_cursor_crc@pipe-c-cursor-256x85-onscreen: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#54]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-apl2/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-apl2/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html - shard-glk: [PASS][11] -> [FAIL][12] ([i915#54]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-glk3/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-glk3/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html - shard-skl: [PASS][13] -> [FAIL][14] ([i915#54]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#52] / [i915#54]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-glk9/igt@kms_draw_...@draw-method-rgb565-mmap-wc-untiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-glk9/igt@kms_draw_...@draw-method-rgb565-mmap-wc-untiled.html * igt@kms_draw_crc@draw-method-xrgb2101010-blt-xtiled: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#52] / [i915#54]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-skl3/igt@kms_draw_...@draw-method-xrgb2101010-blt-xtiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-skl6/igt@kms_draw_...@draw-method-xrgb2101010-blt-xtiled.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#46]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-glk9/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-glk1/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: - shard-glk: [PASS][23] -> [FAIL][24] ([i915#34]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/shard-glk7/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/shard-glk6/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff: - shard-apl: [PASS][25] -> [FAIL][26] ([i915#49]) [25]: https://intel-gfx-ci.01.org/tree/drm-ti
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave and Daniel, Couple display fixes, including vswing table and display TypeC port in TBT mode fix for ICL+ A few GT/GEM alloc/reloc fixes with one to flush all the reloc_gpu batch which has cc:stable #5.2 Here goes drm-intel-next-fixes-2020-04-08: - Flush all the reloc_gpu batch (Chris) - Ignore readonly failures when updating relocs (Chris) - Fill all the unused space in the GGTT (Chris) - Return the right vswing table (Jose) - Don't enable DDI IO power on a TypeC port in TBT mode for ICL+ (Imre) Thanks, Rodrigo. The following changes since commit 17d0c1062a0c60e17c96538adf4a84c208930d9d: Merge tag 'gvt-next-fixes-2020-03-31' of https://github.com/intel/gvt-linux into drm-intel-next-fixes (2020-03-31 09:25:15 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2020-04-08 for you to fetch changes up to 1aaea8476d9f014667d2cb24819f9bcaf3ebb7a4: drm/i915/gem: Flush all the reloc_gpu batch (2020-04-06 10:31:38 -0700) - Flush all the reloc_gpu batch (Chris) - Ignore readonly failures when updating relocs (Chris) - Fill all the unused space in the GGTT (Chris) - Return the right vswing table (Jose) - Don't enable DDI IO power on a TypeC port in TBT mode for ICL+ (Imre) Chris Wilson (3): drm/i915/gt: Fill all the unused space in the GGTT drm/i915/gem: Ignore readonly failures when updating relocs drm/i915/gem: Flush all the reloc_gpu batch Imre Deak (1): drm/i915/icl+: Don't enable DDI IO power on a TypeC port in TBT mode José Roberto de Souza (1): drm/i915/dp: Return the right vswing tables drivers/gpu/drm/i915/display/intel_ddi.c | 11 +--- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 37 +++--- 3 files changed, 42 insertions(+), 20 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only real complication is that the interrupt is only generated for
the start of the semaphore wait, and is asynchronous to our
process_csb() -- that is, we may not have registered the timeslice before
we see the interrupt. To ensure we don't miss a potential semaphore
blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark
the interrupt and apply it to the next timeslice regardless of whether it
was active at the time.
v2: We use semaphores in preempt-to-busy, within the timeslicing
implementation itself! Ergo, when we do insert a preemption due to an
expired timeslice, the new context may start with the missed semaphore
flagged by the retired context and be yielded, ad infinitum. To avoid
this, read the context id at the time of the semaphore interrupt and
only yield if that context is still active.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Kenneth Graunke
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20200407130811.17321-1-ch...@chris-wilson.co.uk
(cherry picked from commit c4e8ba7390346a77ffe33ec3f210bc62e0b6c8c6)
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 6 +++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 9 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 15 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 41 +---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 34
drivers/gpu/drm/i915/i915_reg.h | 1 +
6 files changed, 82 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 3aa8a652c16d..883a9b7fe88d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1295,6 +1295,12 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
if (engine->id == RENDER_CLASS && IS_GEN_RANGE(dev_priv, 4, 7))
drm_printf(m, "\tCCID: 0x%08x\n", ENGINE_READ(engine, CCID));
+ if (HAS_EXECLISTS(dev_priv)) {
+ drm_printf(m, "\tEL_STAT_HI: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_HI));
+ drm_printf(m, "\tEL_STAT_LO: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_LO));
+ }
drm_printf(m, "\tRING_START: 0x%08x\n",
ENGINE_READ(engine, RING_START));
drm_printf(m, "\tRING_HEAD: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 80cdde712842..ac283ab5d89c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -156,6 +156,15 @@ struct intel_engine_execlists {
*/
struct i915_priolist default_priolist;
+ /**
+* @yield: CCID at the time of the last semaphore-wait interrupt.
+*
+* Instead of leaving a semaphore busy-spinning on an engine, we would
+* like to switch to another ready context, i.e. yielding the semaphore
+* timeslice.
+*/
+ u32 yield;
+
/**
* @error_interrupt: CS Master EIR
*
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index f0e7fd95165a..0cc7dd54f4f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -39,6 +39,15 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
}
}
+ if (iir & GT_WAIT_SEMAPHORE_INTERRUPT) {
+ WRITE_ONCE(engine->execlists.yield,
+ ENGINE_READ_FW(engine, RING_EXECLIST_STATUS_HI));
+ ENGINE_TRACE(engine, "semaphore yield: %08x\n",
+engine->execlists.yield);
+ if (del_timer(&engine->execlists.timer))
+ tasklet = true;
+ }
+
if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
tasklet = true;
@@ -228,7 +237,8 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT;
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
struct intel_uncore *uncore = gt->uncore;
const u32 dmask = irqs << 16 | irqs;
const u32 smask = irqs << 16;
@@ -366,7 +376,8 @@ void gen8_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Workaround switching back to a completed context
In what seems remarkably similar to the w/a required to not reload an
idle context with HEAD==TAIL, it appears we must prevent the HW from
switching to an idle context in ELSP[1], while simultaneously trying to
preempt the HW to run another context and a continuation of the idle
context (which is no longer idle).
We can achieve this by preventing the context from completing while we
reload a new ELSP (by applying ring_set_paused(1) across the whole of
dequeue), except this eventually fails due to a lite-restore into a
waiting semaphore does not generate an ACK. Instead, we try to avoid
making the GPU do anything too challenging and not submit a new ELSP
while the interrupts + CSB events appear to have fallen behind the
completed contexts. We expect it to catch up shortly so we queue another
tasklet execution and hope for the best.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1501
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
Link:
https://patchwork.freedesktop.org/patch/msgid/20200327201433.21864-1-ch...@chris-wilson.co.uk
(cherry picked from commit 35f3fd8182ba26e766f7b814e903acf19d01bbb5)
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 683014e7bc51..cd63f431d662 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1915,11 +1915,26 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* of trouble.
*/
active = READ_ONCE(execlists->active);
- while ((last = *active) && i915_request_completed(last))
- active++;
- if (last) {
+ /*
+* In theory we can skip over completed contexts that have not
+* yet been processed by events (as those events are in flight):
+*
+* while ((last = *active) && i915_request_completed(last))
+* active++;
+*
+* However, the GPU cannot handle this as it will ultimately
+* find itself trying to jump back into a context it has just
+* completed and barf.
+*/
+
+ if ((last = *active)) {
if (need_preempt(engine, last, rb)) {
+ if (i915_request_completed(last)) {
+ tasklet_hi_schedule(&execlists->tasklet);
+ return;
+ }
+
ENGINE_TRACE(engine,
"preempting last=%llx:%lld, prio=%d,
hint=%d\n",
last->fence.context,
@@ -1947,6 +1962,11 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
last = NULL;
} else if (need_timeslice(engine, last) &&
timer_expired(&engine->execlists.timer)) {
+ if (i915_request_completed(last)) {
+ tasklet_hi_schedule(&execlists->tasklet);
+ return;
+ }
+
ENGINE_TRACE(engine,
"expired last=%llx:%lld, prio=%d,
hint=%d\n",
last->fence.context,
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check current i915_vma.pin_count status first on unbind
Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is
currently pinned, without waiting to see if the inflight operations may
unpin it. We see this problem with the shrinker trying to unbind the
active vma from inside its bind worker:
<6> [472.618968] Workqueue: events_unbound fence_work [i915]
<4> [472.618970] Call Trace:
<4> [472.618974] ? __schedule+0x2e5/0x810
<4> [472.618978] schedule+0x37/0xe0
<4> [472.618982] schedule_preempt_disabled+0xf/0x20
<4> [472.618984] __mutex_lock+0x281/0x9c0
<4> [472.618987] ? mark_held_locks+0x49/0x70
<4> [472.618989] ? _raw_spin_unlock_irqrestore+0x47/0x60
<4> [472.619038] ? i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619084] ? i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619122] i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619165] i915_gem_object_unbind+0x1dc/0x400 [i915]
<4> [472.619208] i915_gem_shrink+0x328/0x660 [i915]
<4> [472.619250] ? i915_gem_shrink_all+0x38/0x60 [i915]
<4> [472.619282] i915_gem_shrink_all+0x38/0x60 [i915]
<4> [472.619325] vm_alloc_page.constprop.25+0x1aa/0x240 [i915]
<4> [472.619330] ? rcu_read_lock_sched_held+0x4d/0x80
<4> [472.619363] ? __alloc_pd+0xb/0x30 [i915]
<4> [472.619366] ? module_assert_mutex_or_preempt+0xf/0x30
<4> [472.619368] ? __module_address+0x23/0xe0
<4> [472.619371] ? is_module_address+0x26/0x40
<4> [472.619374] ? static_obj+0x34/0x50
<4> [472.619376] ? lockdep_init_map+0x4d/0x1e0
<4> [472.619407] setup_page_dma+0xd/0x90 [i915]
<4> [472.619437] alloc_pd+0x29/0x50 [i915]
<4> [472.619470] __gen8_ppgtt_alloc+0x443/0x6b0 [i915]
<4> [472.619503] gen8_ppgtt_alloc+0xd7/0x300 [i915]
<4> [472.619535] ppgtt_bind_vma+0x2a/0xe0 [i915]
<4> [472.619577] __vma_bind+0x26/0x40 [i915]
<4> [472.619611] fence_work+0x1c/0x90 [i915]
<4> [472.619617] process_one_work+0x26a/0x620
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20200403120150.17091-1-ch...@chris-wilson.co.uk
(cherry picked from commit 614654abe847a42fc75d7eb5096e46f796a438b6)
---
drivers/gpu/drm/i915/i915_vma.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 08699fa069aa..24c23e6bba41 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1226,18 +1226,6 @@ int __i915_vma_unbind(struct i915_vma *vma)
lockdep_assert_held(&vma->vm->mutex);
- /*
-* First wait upon any activity as retiring the request may
-* have side-effects such as unpinning or even unbinding this vma.
-*
-* XXX Actually waiting under the vm->mutex is a hinderance and
-* should be pipelined wherever possible. In cases where that is
-* unavoidable, we should lift the wait to before the mutex.
-*/
- ret = i915_vma_sync(vma);
- if (ret)
- return ret;
-
if (i915_vma_is_pinned(vma)) {
vma_print_allocator(vma, "is pinned");
return -EAGAIN;
@@ -1311,15 +1299,20 @@ int i915_vma_unbind(struct i915_vma *vma)
if (!drm_mm_node_allocated(&vma->node))
return 0;
- if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
- /* XXX not always required: nop_clear_range */
- wakeref = intel_runtime_pm_get(&vm->i915->runtime_pm);
-
/* Optimistic wait before taking the mutex */
err = i915_vma_sync(vma);
if (err)
goto out_rpm;
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
+ return -EAGAIN;
+ }
+
+ if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
+ /* XXX not always required: nop_clear_range */
+ wakeref = intel_runtime_pm_get(&vm->i915->runtime_pm);
+
err = mutex_lock_interruptible(&vm->mutex);
if (err)
goto out_rpm;
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Mark up racy check of breadcrumb irq enabled
== Series Details == Series: drm/i915/gt: Mark up racy check of breadcrumb irq enabled URL : https://patchwork.freedesktop.org/series/75663/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8274_full -> Patchwork_17250_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17250_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17250_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17250_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-queues: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-iclb7/igt@gem_exec_whis...@basic-queues.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-iclb5/igt@gem_exec_whis...@basic-queues.html Known issues Here are the changes found in Patchwork_17250_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-kbl4/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-kbl1/igt@gem_exec_susp...@basic-s3.html - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#69]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-skl3/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-skl3/igt@gem_exec_susp...@basic-s3.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#177] / [i915#52] / [i915#54]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-glk6/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-glk8/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-apl3/igt@kms_f...@flip-vs-suspend-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-apl1/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#34]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-skl10/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-skl6/igt@kms_f...@plain-flip-fb-recreate-interruptible.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#1188]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-skl2/igt@kms_...@bpc-switch-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-skl7/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#648] / [i915#69]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-skl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-skl10/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-iclb8/igt@kms_psr@psr2_cursor_render.html Possible fixes * igt@i915_pm_rpm@system-suspend-modeset: - shard-skl: [INCOMPLETE][19] ([i915#151] / [i915#69]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-skl1/igt@i915_pm_...@system-suspend-modeset.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-skl9/igt@i915_pm_...@system-suspend-modeset.html * igt@i915_selftest@live@requests: - shard-tglb: [INCOMPLETE][21] ([i915#1531] / [i915#1658]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/shard-tglb1/igt@i915_selftest@l...@requests.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/shard-tglb6/igt@i915_selftest@l...@requests.html * ig
[Intel-gfx] Patches that didn't applied cleanly on drm-intel-next-fixes
Hi Ashutosh and Chris,
these patches seems needed for 5.7 but didn't applied cleanly on dinf:
Failed to cherry-pick:
6352219c39c0 ("drm/i915/perf: Do not clear pollin for small user read buffers")
614654abe847 ("drm/i915: Check current i915_vma.pin_count status first on
unbind")
c4e8ba739034 ("drm/i915/gt: Yield the timeslice if caught waiting on a user
semaphore")
If they are critical for 5.7 please provide a version that applies or list the
dependencies.
Thanks,
Rodrigo.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: Show the actual error from submitting the rendercopy
Signed-off-by: Chris Wilson
---
lib/gpu_cmds.c| 13 ++---
lib/rendercopy_gen4.c | 13 ++---
lib/rendercopy_gen6.c | 13 ++---
lib/rendercopy_gen7.c | 13 ++---
lib/rendercopy_gen8.c | 13 ++---
lib/rendercopy_gen9.c | 13 ++---
6 files changed, 36 insertions(+), 42 deletions(-)
diff --git a/lib/gpu_cmds.c b/lib/gpu_cmds.c
index 79412725a..dc0ae96c6 100644
--- a/lib/gpu_cmds.c
+++ b/lib/gpu_cmds.c
@@ -39,13 +39,12 @@ gen7_render_flush(struct intel_batchbuffer *batch, uint32_t
batch_end)
void
gen7_render_context_flush(struct intel_batchbuffer *batch, uint32_t batch_end)
{
- int ret;
-
- ret = drm_intel_bo_subdata(batch->bo, 0, 4096, batch->buffer);
- if (ret == 0)
- ret = drm_intel_gem_bo_context_exec(batch->bo, batch->ctx,
- batch_end, 0);
- igt_assert(ret == 0);
+ igt_assert_eq(drm_intel_bo_subdata(batch->bo,
+ 0, 4096, batch->buffer),
+ 0);
+ igt_assert_eq(drm_intel_gem_bo_context_exec(batch->bo, batch->ctx,
+ batch_end, 0),
+ 0);
}
uint32_t
diff --git a/lib/rendercopy_gen4.c b/lib/rendercopy_gen4.c
index d07b8e488..413e33578 100644
--- a/lib/rendercopy_gen4.c
+++ b/lib/rendercopy_gen4.c
@@ -124,13 +124,12 @@ static void
gen4_render_flush(struct intel_batchbuffer *batch,
drm_intel_context *context, uint32_t batch_end)
{
- int ret;
-
- ret = drm_intel_bo_subdata(batch->bo, 0, 4096, batch->buffer);
- if (ret == 0)
- ret = drm_intel_gem_bo_context_exec(batch->bo, context,
- batch_end, 0);
- assert(ret == 0);
+ igt_assert_eq(drm_intel_bo_subdata(batch->bo,
+ 0, 4096, batch->buffer),
+ 0);
+ igt_assert_eq(drm_intel_gem_bo_context_exec(batch->bo, context,
+ batch_end, 0),
+ 0);
}
static uint32_t
diff --git a/lib/rendercopy_gen6.c b/lib/rendercopy_gen6.c
index 870347748..16cbb679b 100644
--- a/lib/rendercopy_gen6.c
+++ b/lib/rendercopy_gen6.c
@@ -62,13 +62,12 @@ static void
gen6_render_flush(struct intel_batchbuffer *batch,
drm_intel_context *context, uint32_t batch_end)
{
- int ret;
-
- ret = drm_intel_bo_subdata(batch->bo, 0, 4096, batch->buffer);
- if (ret == 0)
- ret = drm_intel_gem_bo_context_exec(batch->bo, context,
- batch_end, 0);
- igt_assert(ret == 0);
+ igt_assert_eq(drm_intel_bo_subdata(batch->bo,
+ 0, 4096, batch->buffer),
+ 0);
+ igt_assert_eq(drm_intel_gem_bo_context_exec(batch->bo,
+ context, batch_end, 0),
+ 0);
}
static uint32_t
diff --git a/lib/rendercopy_gen7.c b/lib/rendercopy_gen7.c
index b88b75e98..93b4da720 100644
--- a/lib/rendercopy_gen7.c
+++ b/lib/rendercopy_gen7.c
@@ -36,13 +36,12 @@ static void
gen7_render_flush(struct intel_batchbuffer *batch,
drm_intel_context *context, uint32_t batch_end)
{
- int ret;
-
- ret = drm_intel_bo_subdata(batch->bo, 0, 4096, batch->buffer);
- if (ret == 0)
- ret = drm_intel_gem_bo_context_exec(batch->bo, context,
- batch_end, 0);
- igt_assert(ret == 0);
+ igt_assert_eq(drm_intel_bo_subdata(batch->bo,
+ 0, 4096, batch->buffer),
+ 0);
+ igt_assert_eq(drm_intel_gem_bo_context_exec(batch->bo, context,
+ batch_end, 0),
+ 0);
}
static uint32_t
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index bace64a7a..75005d0b9 100644
--- a/lib/rendercopy_gen8.c
+++ b/lib/rendercopy_gen8.c
@@ -132,13 +132,12 @@ static void
gen6_render_flush(struct intel_batchbuffer *batch,
drm_intel_context *context, uint32_t batch_end)
{
- int ret;
-
- ret = drm_intel_bo_subdata(batch->bo, 0, 4096, batch->buffer);
- if (ret == 0)
- ret = drm_intel_gem_bo_context_exec(batch->bo, context,
- batch_end, 0);
- igt_assert(ret == 0);
+ igt_assert_eq(drm_intel_bo_subdata(batch->bo,
+ 0, 4096, batch->buffer),
+ 0);
+ igt_assert_eq(drm_intel_gem_bo_context_exec(batch->bo, context,
+ batch_end, 0),
+ 0);
}
/* Mostly copy+paste from gen6, except height, width, pitch moved */
diff --git a/lib/rendercopy_gen9.c b/li
Re: [Intel-gfx] [PATCH] drm/i915/evict: watch out for unevictable nodes
Quoting Chris Wilson (2020-04-08 20:44:43)
> Quoting Matthew Auld (2020-04-08 18:04:56)
> > In an address space there can be sprinkling of I915_COLOR_UNEVICTABLE
> > nodes, which lack a parent vma. For platforms with cache coloring we
> > might be very unlucky and abut with such a node thinking we can simply
> > unbind the vma.
>
> I did notice this myself recently (from observation); it's highly
> unlikely to ever matter.
>
> > Signed-off-by: Matthew Auld
> > ---
> > drivers/gpu/drm/i915/i915_gem_evict.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> > b/drivers/gpu/drm/i915/i915_gem_evict.c
> > index 4518b9b35c3d..9e462c6a4c6a 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> > @@ -227,6 +227,10 @@ i915_gem_evict_something(struct i915_address_space *vm,
> > }
> >
> > while (ret == 0 && (node = drm_mm_scan_color_evict(&scan))) {
> > + /* If we find any non-objects (!vma), we cannot evict them
> > */
> > + if (node->color == I915_COLOR_UNEVICTABLE)
> > + return -ENOSPC;
>
> Returning error immediately looks ok, I was worried as around here we
> usually have lists to clean up, but this is after those. However, I
> would suggest that setting ret = -ENOSPC would be more consistent with
> the flow.
Actually, while this prevents an explosion [good], it now returns an
unexpected error [bad]. No explosion is the lesser evil.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] dma-buf: Report signaled links inside dma-fence-chain
On 03/04/2020 12:12, Chris Wilson wrote:
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element in a dma-fence-chain.
Report a NULL fence and success if the seqno has already been signaled.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/dma-fence-chain.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
index 3d123502ff12..c435bbba851c 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -99,6 +99,12 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence,
uint64_t seqno)
return -EINVAL;
dma_fence_chain_for_each(*pfence, &chain->base) {
+ if ((*pfence)->seqno < seqno) { /* already signaled */
+ dma_fence_put(*pfence);
+ *pfence = NULL;
+ break;
+ }
+
Wouldn't this condition been fulfilled in the previous check? :
chain = to_dma_fence_chain(*pfence);
if (!chain || chain->base.seqno < seqno)
return -EINVAL;
-Lionel
if ((*pfence)->context != chain->base.context ||
to_dma_fence_chain(*pfence)->prev_seqno < seqno)
break;
@@ -222,6 +228,7 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
* @chain: the chain node to initialize
* @prev: the previous fence
* @fence: the current fence
+ * @seqno: the sequence number (syncpt) of the fence within the chain
*
* Initialize a new chain node and either start a new chain or add the node to
* the existing chain of the previous fence.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/10] dma-buf: Exercise dma-fence-chain under selftests
On 20/04/03 10:12, Chris Wilson wrote:
> A few very simple testcases to exercise the dma-fence-chain API.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/dma-buf/Makefile | 3 +-
> drivers/dma-buf/selftests.h | 1 +
> drivers/dma-buf/st-dma-fence-chain.c | 713 +++
> 3 files changed, 716 insertions(+), 1 deletion(-)
> create mode 100644 drivers/dma-buf/st-dma-fence-chain.c
>
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index 9c190026bfab..995e05f609ff 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_UDMABUF) += udmabuf.o
>
> dmabuf_selftests-y := \
> selftest.o \
> - st-dma-fence.o
> + st-dma-fence.o \
> + st-dma-fence-chain.o
>
> obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
> diff --git a/drivers/dma-buf/selftests.h b/drivers/dma-buf/selftests.h
> index 5320386f02e5..55918ef9adab 100644
> --- a/drivers/dma-buf/selftests.h
> +++ b/drivers/dma-buf/selftests.h
> @@ -11,3 +11,4 @@
> */
> selftest(sanitycheck, __sanitycheck__) /* keep first (igt selfcheck) */
> selftest(dma_fence, dma_fence)
> +selftest(dma_fence_chain, dma_fence_chain)
> diff --git a/drivers/dma-buf/st-dma-fence-chain.c
> b/drivers/dma-buf/st-dma-fence-chain.c
> new file mode 100644
> index ..bd08ba67b03b
> --- /dev/null
> +++ b/drivers/dma-buf/st-dma-fence-chain.c
> @@ -0,0 +1,713 @@
> +// SPDX-License-Identifier: MIT
> +
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "selftest.h"
> +
> +static struct kmem_cache *slab_fences;
> +
> +static inline struct mock_fence {
> + struct dma_fence base;
> + spinlock_t lock;
> +} *to_mock_fence(struct dma_fence *f) {
> + return container_of(f, struct mock_fence, base);
> +}
> +
> +static const char *mock_name(struct dma_fence *f)
> +{
> + return "mock";
> +}
> +
> +static void mock_fence_release(struct dma_fence *f)
> +{
> + kmem_cache_free(slab_fences, to_mock_fence(f));
> +}
> +
> +static const struct dma_fence_ops mock_ops = {
> + .get_driver_name = mock_name,
> + .get_timeline_name = mock_name,
> + .release = mock_fence_release,
> +};
> +
> +static struct dma_fence *mock_fence(void)
> +{
> + struct mock_fence *f;
> +
> + f = kmem_cache_alloc(slab_fences, GFP_KERNEL);
> + if (!f)
> + return NULL;
> +
> + spin_lock_init(&f->lock);
> + dma_fence_init(&f->base, &mock_ops, &f->lock, 0, 0);
> +
> + return &f->base;
> +}
> +
> +static inline struct mock_chain {
> + struct dma_fence_chain base;
> +} *to_mock_chain(struct dma_fence *f) {
> + return container_of(f, struct mock_chain, base.base);
> +}
> +
> +static struct dma_fence *mock_chain(struct dma_fence *prev,
> + struct dma_fence *fence,
> + u64 seqno)
> +{
> + struct mock_chain *f;
> +
> + f = kmalloc(sizeof(*f), GFP_KERNEL);
> + if (!f)
> + return NULL;
> +
> + dma_fence_chain_init(&f->base,
> + dma_fence_get(prev),
> + dma_fence_get(fence),
> + seqno);
> +
> + return &f->base.base;
> +}
> +
> +static int sanitycheck(void *arg)
> +{
> + struct dma_fence *f, *chain;
> + int err = 0;
> +
> + f = mock_fence();
> + if (!f)
> + return -ENOMEM;
> +
> + chain = mock_chain(NULL, f, 1);
> + if (!chain)
> + err = -ENOMEM;
> +
> + dma_fence_signal(f);
> + dma_fence_put(f);
> +
> + dma_fence_put(chain);
> +
> + return err;
> +}
> +
> +struct fence_chains {
> + unsigned int chain_length;
> + struct dma_fence **fences;
> + struct dma_fence **chains;
> +
> + struct dma_fence *tail;
> +};
> +
> +static uint64_t seqno_inc(unsigned int i)
> +{
> + return i + 1;
> +}
> +
> +static int fence_chains_init(struct fence_chains *fc, unsigned int count,
> + uint64_t (*seqno_fn)(unsigned int))
> +{
> + unsigned int i;
> + int err = 0;
> +
> + fc->chains = kvmalloc_array(count, sizeof(*fc->chains),
> + GFP_KERNEL | __GFP_ZERO);
> + if (!fc->chains)
> + return -ENOMEM;
> +
> + fc->fences = kvmalloc_array(count, sizeof(*fc->fences),
> + GFP_KERNEL | __GFP_ZERO);
> + if (!fc->fences) {
> + err = -ENOMEM;
> + goto err_chains;
> + }
> +
> + fc->tail = NULL;
> + for (i = 0; i < count; i++) {
> + fc->fences[i] = mock_fence();
> + if (!fc->fences[i]) {
> + err = -ENOMEM;
> + goto unwind;
> + }
> +
> + fc->chains[i] = mock_chain(fc->tail,
> +
Re: [Intel-gfx] [PATCH 04/10] dma-buf: Report signaled links inside dma-fence-chain
On 20/04/03 10:12, Chris Wilson wrote:
> Whenever we walk along the dma-fence-chain, we prune signaled links to
> keep the chain nice and tidy. This leads to situations where we can
> prune a link and report the earlier fence as the target seqno --
> violating our own consistency checks that the seqno is not more advanced
> than the last element in a dma-fence-chain.
>
> Report a NULL fence and success if the seqno has already been signaled.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/dma-buf/dma-fence-chain.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-fence-chain.c
> b/drivers/dma-buf/dma-fence-chain.c
> index 3d123502ff12..c435bbba851c 100644
> --- a/drivers/dma-buf/dma-fence-chain.c
> +++ b/drivers/dma-buf/dma-fence-chain.c
> @@ -99,6 +99,12 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence,
> uint64_t seqno)
> return -EINVAL;
>
> dma_fence_chain_for_each(*pfence, &chain->base) {
> + if ((*pfence)->seqno < seqno) { /* already signaled */
> + dma_fence_put(*pfence);
> + *pfence = NULL;
> + break;
> + }
> +
Looks good to me.
Tested-by: Venkata Sandeep Dhanalakota
Reviewed-by: Venkata Sandeep Dhanalakota
> if ((*pfence)->context != chain->base.context ||
> to_dma_fence_chain(*pfence)->prev_seqno < seqno)
> break;
> @@ -222,6 +228,7 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
> * @chain: the chain node to initialize
> * @prev: the previous fence
> * @fence: the current fence
> + * @seqno: the sequence number (syncpt) of the fence within the chain
> *
> * Initialize a new chain node and either start a new chain or add the node
> to
> * the existing chain of the previous fence.
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/evict: watch out for unevictable nodes
Quoting Matthew Auld (2020-04-08 18:04:56)
> In an address space there can be sprinkling of I915_COLOR_UNEVICTABLE
> nodes, which lack a parent vma. For platforms with cache coloring we
> might be very unlucky and abut with such a node thinking we can simply
> unbind the vma.
I did notice this myself recently (from observation); it's highly
unlikely to ever matter.
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem_evict.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 4518b9b35c3d..9e462c6a4c6a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -227,6 +227,10 @@ i915_gem_evict_something(struct i915_address_space *vm,
> }
>
> while (ret == 0 && (node = drm_mm_scan_color_evict(&scan))) {
> + /* If we find any non-objects (!vma), we cannot evict them */
> + if (node->color == I915_COLOR_UNEVICTABLE)
> + return -ENOSPC;
Returning error immediately looks ok, I was worried as around here we
usually have lists to clean up, but this is after those. However, I
would suggest that setting ret = -ENOSPC would be more consistent with
the flow.
Fwiw, we can actually pull this logic into evict_for_node for a bit of
simplification.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/evict: watch out for unevictable nodes
== Series Details == Series: drm/i915/evict: watch out for unevictable nodes URL : https://patchwork.freedesktop.org/series/75691/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8278 -> Patchwork_17258 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17258 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17258, 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_17258/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17258: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-icl-y: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-icl-y/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17258/fi-icl-y/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_17258 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][3] ([i915#62]) -> [SKIP][4] ([fdo#109271]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17258/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (53 -> 47) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8278 -> Patchwork_17258 CI-20190529: 20190529 CI_DRM_8278: 6c961d30815647db306abce9e8129c9253abc33e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5581: ab0620e555119ec55f12ba9ab9e6e9246d407648 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17258: ef1b0db5ef6bddcf1849e714854352346d0c6e91 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ef1b0db5ef6b drm/i915/evict: watch out for unevictable nodes == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17258/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Take an explicit ref for rq->batch (rev2)
== Series Details ==
Series: drm/i915/selftests: Take an explicit ref for rq->batch (rev2)
URL : https://patchwork.freedesktop.org/series/75662/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8272_full -> Patchwork_17249_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17249_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#300])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +4 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
- shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-apl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][7] -> [FAIL][8] ([i915#1188]) +2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-skl2/igt@kms_...@bpc-switch-dpms.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-skl8/igt@kms_...@bpc-switch-dpms.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109642] / [fdo#111068])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-iclb2/igt@kms_psr2...@frontbuffer.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-iclb6/igt@kms_psr2...@frontbuffer.html
* igt@kms_psr@psr2_no_drrs:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-iclb8/igt@kms_psr@psr2_no_drrs.html
Possible fixes
* {igt@gem_ctx_isolation@preservation-s3@bcs0}:
- shard-apl: [DMESG-WARN][13] ([i915#180]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-apl6/igt@gem_ctx_isolation@preservation...@bcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-apl8/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_exec_params@invalid-bsd-ring:
- shard-iclb: [SKIP][15] ([fdo#109276]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-iclb7/igt@gem_exec_par...@invalid-bsd-ring.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-iclb2/igt@gem_exec_par...@invalid-bsd-ring.html
* igt@i915_suspend@fence-restore-untiled:
- shard-kbl: [DMESG-WARN][17] ([i915#180]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-kbl4/igt@i915_susp...@fence-restore-untiled.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-kbl6/igt@i915_susp...@fence-restore-untiled.html
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-ytiled:
- shard-glk: [FAIL][19] ([i915#52] / [i915#54]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-glk8/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-ytiled.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-glk3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-ytiled.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-skl: [INCOMPLETE][21] ([i915#69]) -> [PASS][22] +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-skl8/igt@kms_fbcon_...@psr-suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-skl1/igt@kms_fbcon_...@psr-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-glk: [FAIL][23] ([i915#79]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8272/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17249/shard-glk7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl: [DMESG-WARN][25] ([i915#180] / [i915#95]) ->
[PASS][26]
[25]:
https://intel-gfx-ci.01.org/t
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev6)
== Series Details == Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev6) URL : https://patchwork.freedesktop.org/series/45968/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8278 -> Patchwork_17257 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17257 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17257, 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_17257/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17257: ### IGT changes ### Possible regressions * igt@kms_busy@basic@modeset: - fi-apl-guc: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-apl-guc/igt@kms_busy@ba...@modeset.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-apl-guc/igt@kms_busy@ba...@modeset.html - fi-icl-dsi: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-icl-dsi/igt@kms_busy@ba...@modeset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-icl-dsi/igt@kms_busy@ba...@modeset.html - fi-cfl-guc: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-cfl-guc/igt@kms_busy@ba...@modeset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-cfl-guc/igt@kms_busy@ba...@modeset.html - fi-skl-6770hq: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-skl-6770hq/igt@kms_busy@ba...@modeset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-skl-6770hq/igt@kms_busy@ba...@modeset.html - fi-skl-6600u: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-skl-6600u/igt@kms_busy@ba...@modeset.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-skl-6600u/igt@kms_busy@ba...@modeset.html - fi-kbl-soraka: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-kbl-soraka/igt@kms_busy@ba...@modeset.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-kbl-soraka/igt@kms_busy@ba...@modeset.html - fi-skl-lmem:[PASS][13] -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-skl-lmem/igt@kms_busy@ba...@modeset.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-skl-lmem/igt@kms_busy@ba...@modeset.html - fi-byt-n2820: [PASS][15] -> [FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-byt-n2820/igt@kms_busy@ba...@modeset.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-byt-n2820/igt@kms_busy@ba...@modeset.html - fi-skl-6700k2: [PASS][17] -> [FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-skl-6700k2/igt@kms_busy@ba...@modeset.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-skl-6700k2/igt@kms_busy@ba...@modeset.html - fi-bsw-kefka: [PASS][19] -> [FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-bsw-kefka/igt@kms_busy@ba...@modeset.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-bsw-kefka/igt@kms_busy@ba...@modeset.html - fi-cfl-8109u: [PASS][21] -> [FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-cfl-8109u/igt@kms_busy@ba...@modeset.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-cfl-8109u/igt@kms_busy@ba...@modeset.html - fi-kbl-r: [PASS][23] -> [FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-kbl-r/igt@kms_busy@ba...@modeset.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-kbl-r/igt@kms_busy@ba...@modeset.html - fi-icl-u2: [PASS][25] -> [FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-icl-u2/igt@kms_busy@ba...@modeset.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-icl-u2/igt@kms_busy@ba...@modeset.html - fi-cml-u2: [PASS][27] -> [FAIL][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-cml-u2/igt@kms_busy@ba...@modeset.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-cml-u2/igt@kms_busy@ba...@modeset.html - fi-bxt-dsi: [PASS][29] -> [FAIL][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-bxt-dsi/igt@kms_busy@ba...@modeset.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17257/fi-bxt-dsi/igt@kms_busy@ba...@modeset.html - fi-cml-s: [PASS][31
Re: [Intel-gfx] [PATCH 02/44] drm: Add devm_drm_dev_alloc macro
Hi Daniel.
On Wed, Apr 08, 2020 at 02:11:47PM +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2020 at 08:57:14AM +0200, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > Finally managed to dive into this..
> >
> > Maybe I need more coffee, it is still morning here.
> > But alas this patch triggered a few comments.
> >
> > Sam
> >
> > On Fri, Apr 03, 2020 at 03:57:46PM +0200, Daniel Vetter wrote:
> > > The kerneldoc is only added for this new function. Existing kerneldoc
> > > and examples will be udated at the very end, since once all drivers
> > > are converted over to devm_drm_dev_alloc we can unexport a lot of
> > > interim functions and make the documentation for driver authors a lot
> > > cleaner and less confusing. There will be only one true way to
> > > initialize a drm_device at the end of this, which is going to be
> > > devm_drm_dev_alloc.
> >
> > This changelog entry does a poor job describing what the purpose of this
> > change is.
> > Try to read it outside context.
>
> Something like:
>
> Add a new macro helper to combine the usual init sequence in drivers,
> consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree
> triplet. This allows us to remove the rather unsightly
> drmm_add_final_kfree from all currently merged drivers.
Much better - thanks!
>
> This good enough, as an intro paragraph?
>
> >
> >
> > >
> > > Cc: Paul Kocialkowski
> > > Cc: Laurent Pinchart
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 23 +++
> > > include/drm/drm_drv.h | 33 +
> > > 2 files changed, 56 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 1bb4f636b83c..9e60b784b3ac 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -739,6 +739,29 @@ int devm_drm_dev_init(struct device *parent,
> > > }
> > > EXPORT_SYMBOL(devm_drm_dev_init);
> > >
> > > +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver
> > > *driver,
> > > +size_t size, size_t offset)
> > > +{
> > > + void *container;
> > > + struct drm_device *drm;
> > > + int ret;
> > > +
> > > + container = kzalloc(size, GFP_KERNEL);
> > > + if (!container)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + drm = container + offset;
> > > + ret = devm_drm_dev_init(parent, drm, driver);
> > > + if (ret) {
> > > + kfree(container);
> > > + return ERR_PTR(ret);
> > > + }
> > > + drmm_add_final_kfree(drm, container);
> > > +
> > > + return container;
> > > +}
> > > +EXPORT_SYMBOL(__devm_drm_dev_alloc);
> > > +
> > > /**
> > > * drm_dev_alloc - Allocate new DRM device
> > > * @driver: DRM driver to allocate device for
> > > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > > index e7c6ea261ed1..26776be5a21e 100644
> > > --- a/include/drm/drm_drv.h
> > > +++ b/include/drm/drm_drv.h
> > > @@ -626,6 +626,39 @@ int devm_drm_dev_init(struct device *parent,
> > > struct drm_device *dev,
> > > struct drm_driver *driver);
> > >
> > > +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver
> > > *driver,
> > > +size_t size, size_t offset);
> > > +
> > > +/**
> > > + * devm_drm_dev_alloc - Resource managed allocation of a &drm_device
> > > instance
> > > + * @parent: Parent device object
> > > + * @driver: DRM driver
> > > + * @type: the type of the struct which contains struct &drm_device
> > > + * @member: the name of the &drm_device within @type.
> > I am confused about the naming here.
> > devm_ implies we allocate something with a lifetime equal that of a
> > driver. So when the driver are gone what we allocate is also gone.
> > Like everythign else devm_ prefixed.
> >
> > But the lifetime of a drm_device is until the last userspace reference
> > is gone (final drm_dev_put() is called).
>
> The kerneldoc for this is largely copied from the existing
> devm_drm_dev_init. And yes the lifetime is bound to the device, we do the
> drm_dev_put() when that disappears. Now other users of drm_device might
> still hold references and delay cleanup, but "cleanup is done as a devres
> action" is very much what devm_ signifies.
After discussing this on IRC I took one more look at the code.
We have something like this:
devm_drm_dev_alloc()
|
+-> devm_drm_dev_init()
||
|+-> drm_dev_init()
|||
||+- kref_init(&dev->ref)
|||
||+- drmm_add_action(drm_dev_init_release)
||
|+-> devm_add_action(devm_drm_dev_init_release)
|
+-> drmm_add_final_kfree()
drm_dev_init_release() - does all the release stuff
devm_drm_dev_init_release() do a simple drm_dev_put()
In other words we use the devres functionality to keep track of the
reference count for the structure allocated by devm_drm_dev_alloc()
So the naming makes some sense anyway.
When there are no users left of drm_dev_init() outside
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev6)
== Series Details == Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev6) URL : https://patchwork.freedesktop.org/series/45968/ State : warning == Summary == $ dim checkpatch origin/drm-tip efd6fbbdbe13 drm: avoid spurious EBUSY due to nonblocking atomic modesets -:38: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #38: References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html -:56: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #56: FILE: drivers/gpu/drm/drm_atomic.c:1365: + unsigned requested_crtc = 0; -:57: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #57: FILE: drivers/gpu/drm/drm_atomic.c:1366: + unsigned affected_crtc = 0; -:97: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 4 warnings, 0 checks, 46 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce drm scaling filter property (rev6)
== Series Details ==
Series: Introduce drm scaling filter property (rev6)
URL : https://patchwork.freedesktop.org/series/73883/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8278 -> Patchwork_17256
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/index.html
Known issues
Here are the changes found in Patchwork_17256 that come from known issues:
### IGT changes ###
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [FAIL][1] ([i915#62]) -> [SKIP][2] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8278/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#460]: https://gitlab.freedesktop.org/drm/intel/issues/460
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
Participating hosts (53 -> 47)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8278 -> Patchwork_17256
CI-20190529: 20190529
CI_DRM_8278: 6c961d30815647db306abce9e8129c9253abc33e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5581: ab0620e555119ec55f12ba9ab9e6e9246d407648 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17256: a81f7638d04a2ab85d92a4940e3bda8727c6584a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a81f7638d04a drm/i915: Enable scaling filter for plane and CRTC
418a0d11c2c1 drm/i915/display: Add Nearest-neighbor based integer scaling
support
c85f9bde5ba8 drm/i915: Introduce scaling filter related registers and bit
fields.
e722fd229b86 drm/drm-kms.rst: Add plane and CRTC scaling filter property
documentation
6ca2d49eb95e drm: Introduce plane and CRTC scaling filter properties
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17256/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce drm scaling filter property (rev6)
== Series Details == Series: Introduce drm scaling filter property (rev6) URL : https://patchwork.freedesktop.org/series/73883/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6ca2d49eb95e drm: Introduce plane and CRTC scaling filter properties e722fd229b86 drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation c85f9bde5ba8 drm/i915: Introduce scaling filter related registers and bit fields. -:70: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #70: FILE: drivers/gpu/drm/i915/i915_reg.h:7419: +#define CNL_PS_COEF_INDEX_SET(pipe, id, set) _MMIO_PIPE(pipe,\ + _ID(id, _PS_COEF_SET0_INDEX_1A, _PS_COEF_SET0_INDEX_2A) + (set) * 8, \ + _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_2B) + (set) * 8) -:70: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'set' - possible side-effects? #70: FILE: drivers/gpu/drm/i915/i915_reg.h:7419: +#define CNL_PS_COEF_INDEX_SET(pipe, id, set) _MMIO_PIPE(pipe,\ + _ID(id, _PS_COEF_SET0_INDEX_1A, _PS_COEF_SET0_INDEX_2A) + (set) * 8, \ + _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_2B) + (set) * 8) -:74: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #74: FILE: drivers/gpu/drm/i915/i915_reg.h:7423: +#define CNL_PS_COEF_DATA_SET(pipe, id, set) _MMIO_PIPE(pipe, \ + _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A) + (set) * 8, \ + _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B) + (set) * 8) -:74: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'set' - possible side-effects? #74: FILE: drivers/gpu/drm/i915/i915_reg.h:7423: +#define CNL_PS_COEF_DATA_SET(pipe, id, set) _MMIO_PIPE(pipe, \ + _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A) + (set) * 8, \ + _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B) + (set) * 8) total: 0 errors, 0 warnings, 4 checks, 47 lines checked 418a0d11c2c1 drm/i915/display: Add Nearest-neighbor based integer scaling support a81f7638d04a drm/i915: Enable scaling filter for plane and CRTC -:94: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #94: FILE: drivers/gpu/drm/i915/display/intel_display.c:16626: + drm_crtc_create_scaling_filter_property(&crtc->base, + BIT(DRM_SCALING_FILTER_DEFAULT) | -:154: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #154: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:3132: + drm_plane_create_scaling_filter_property(&plane->base, + BIT(DRM_SCALING_FILTER_DEFAULT) | total: 0 errors, 0 warnings, 2 checks, 103 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for agp/intel: Disable use of WC for GMM updates
== Series Details == Series: agp/intel: Disable use of WC for GMM updates URL : https://patchwork.freedesktop.org/series/75680/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8277 -> Patchwork_17255 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17255 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17255, 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_17255/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17255: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/fi-icl-dsi/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17255/fi-icl-dsi/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_17255 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][3] ([i915#1158]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17255/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [i915#1158]: https://gitlab.freedesktop.org/drm/intel/issues/1158 Participating hosts (52 -> 47) -- Additional (1): fi-kbl-7560u Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8277 -> Patchwork_17255 CI-20190529: 20190529 CI_DRM_8277: f7d56913e1668f3a269db391189a7888a4b22570 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5581: ab0620e555119ec55f12ba9ab9e6e9246d407648 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17255: a18804e368c8302a0e6c48e902c2bcf92e30 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a18804e368c8 agp/intel: Disable use of WC for GMM updates == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17255/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
On 06/04/2020 23:07, Venkata Sandeep Dhanalakota wrote:
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence
(Lionel)
v5: Use BIT_ULL (Chris)
v6: Fix issue with already signaled timeline points,
dma_fence_chain_find_seqno() setting fence to NULL (Chris)
v7: Report ENOENT with invalid syncobj handle (Lionel)
v8: Check for out of order timeline point insertion (Chris)
v9: After explanations on
https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
drop the ordering check from v8 (Lionel)
v10: Set first extension enum item to 1 (Jason)
v11: Add wait on previous sync points in timelines (Sandeep)
Signed-off-by: Lionel Landwerlin
Signed-off-by: Venkata Sandeep Dhanalakota
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 312 ++
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/i915/i915_getparam.c | 1 +
include/uapi/drm/i915_drm.h | 38 +++
4 files changed, 296 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 16831f715daa..4cb4cd035daa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -230,6 +230,13 @@ enum {
* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
*/
+struct i915_eb_fences {
+ struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ struct dma_fence *dma_fence;
+ u64 value;
+ struct dma_fence_chain *chain_fence;
+};
+
struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -292,6 +299,7 @@ struct i915_execbuffer {
struct {
u64 flags; /** Available extensions parameters */
+ struct drm_i915_gem_execbuffer_ext_timeline_fences
timeline_fences;
} extensions;
};
@@ -2244,67 +2252,219 @@ eb_pin_engine(struct i915_execbuffer *eb,
}
static void
-__free_fence_array(struct drm_syncobj **fences, unsigned int n)
+__free_fence_array(struct i915_eb_fences *fences, unsigned int n)
{
- while (n--)
- drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+ while (n--) {
+ drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
+ dma_fence_put(fences[n].dma_fence);
+ kfree(fences[n].chain_fence);
+ }
kvfree(fences);
}
-static struct drm_syncobj **
-get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_file *file)
+static struct i915_eb_fences *
+get_timeline_fence_array(struct i915_execbuffer *eb, int *out_n_fences)
+{
+ struct drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences =
+ &eb->extensions.timeline_fences;
+ struct drm_i915_gem_exec_fence __user *user_fences;
+ struct i915_eb_fences *fences;
+ u64 __user *user_values;
+ u64 num_fences, num_user_fences = timeline_fences->fence_count;
+ unsigned long n;
+ int err = 0;
+
+ /* Check multiplication overflow for access_ok() and kvmalloc_array() */
+ BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
+ if (num_user_fences > min_t(unsigned long,
+ ULONG_MAX / sizeof(*user_fences),
+ SIZE_MAX / sizeof(*fences)))
+ return ERR_PTR(-EINVAL);
+
+ user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
+ if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
+ return ERR_PTR(-EFAULT);
+
+ user_values = u64_to_user_ptr(timeline_fences->values_ptr);
+ if (!access_ok(user_values, num_user_fences * sizeof(*user_values)))
+ return ERR_PTR(-EFAULT);
+
+ fences = kvmalloc_array(num_user_fences, sizeof(*fences),
+ __GFP_NOWARN | GFP_KERNEL);
+ if (!fences)
+ return ERR_PTR(-ENOMEM);
+
+ BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
+~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
+
+ for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++) {
+ struct drm_i915_gem_exec_fence user_fence;
+ struct drm_syncobj *syncobj;
+ struct dma_fence *fence = NULL;
+ u64 point;
+
+ if (__copy_from_user(&user_fence, user_fences++,
sizeof(user_fence))) {
+ err = -EFAULT;
+ goto err;
+ }
+
+ if (user_fence.flags & __I915_EXEC_FENCE_UNKNOWN_FLAGS) {
+ err = -EINVAL;
+ goto e
[Intel-gfx] [PATCH i-g-t v12] tests: Add a test for device hot unplug
From: Janusz Krzysztofik There is a test which verifies unloading of i915 driver module but no test exists that checks how a driver behaves when it gets unbound from a device or when the device gets unplugged. Implement such test using sysfs interface. Two minimalistic subtests - "unbind-rebind" and "unplug-rescan" - perform the named operations on a DRM device which is beleived to be not in use. Another pair of subtests named "hotunbind-lateclose" and hotunplug-lateclose" do the same on a DRM device while keeping its file descriptor open and close it thereafter. v2: Run a subprocess with dummy_load instead of external command (Antonio). v3: Run dummy_load from the test process directly (Antonio). v4: Run dummy_load from inside subtests (Antonio). v5: Try to restore the device to a working state after each subtest (Petri, Daniel). v6: Run workload inside an igt helper subprocess so resources consumed by the workload are cleaned up automatically on workload subprocess crash, without affecting test results, - move the igt helper with workload back from subtests to initial fixture so workload crash also does not affect test results, - other cleanups suggested by Katarzyna and Chris. v7: No changes. v8: Move workload functions back from fixture to subtests, - register different actions and different workloads in respective tables and iterate over those tables while enumerating subtests, - introduce new subtest flavors by simply omiting module unload step, - instead of simply requesting bus rescan or not, introduce action specific device recovery helpers, required specifically with those new subtests not touching the module, - split workload functions in two parts, one spawning the workload, the other waiting for its completion, - for the new subtests not requiring module unload, run workload functions directly from the test process and use new workload completion wait functions in place of subprocess completion wait, - take more control over logging, longjumps and exit codes in workload subprocesses, - add some debug messages for easy progress watching, - move function API descriptions on top of respective typedefs. v9: All changes after Daniel's comments - thanks! - flatten the code, don't try to create a midlayer (Daniel), - provide mimimal subtests that even don't keep device open (Daniel), - don't use driver unbind in more advanced subtests (Daniel), - provide subtests with different level of resources allocated during device unplug (Daniel), - provide subtests which check driver behavior after device hot unplug (Daniel). v10 Rename variables and function arguments to something that indicates they're file descriptors (Daniel), - introduce a data structure that contains various file descriptors and a helper function to set them all (Daniel), - fix strange indentation (Daniel), - limit scope to first three subtests as the initial set of tests to merge (Daniel). v11 Fix typos in some comments, - use SPDX license identifier, - include a per-patch changelog in the commit message (Daniel). v12 We don't use SPDX license identifiers nor GPL-2.0 in IGT (Petri), - avoid chipset, make sure we reopen the same device (Chris), - rename subtest "drm_open-hotunplug" to "hotunplug-lateclose", - add subtest "hotunbind-lateclose" (less affected by IOMMU issues), - move some redundant code to helpers, - reorder some helpers, - reword some messages and comments, - clean up headers. Cc: Antonio Argenziano Cc: Petri Latvala Cc: Daniel Vetter Cc: Katarzyna Dec Cc: Chris Wilson Signed-off-by: Janusz Krzysztofik --- tests/Makefile.sources | 1 + tests/core_hotunplug.c | 276 + tests/meson.build | 1 + 3 files changed, 278 insertions(+) create mode 100644 tests/core_hotunplug.c diff --git a/tests/Makefile.sources b/tests/Makefile.sources index 4e44c98c2..32cbbf4f9 100644 --- a/tests/Makefile.sources +++ b/tests/Makefile.sources @@ -18,6 +18,7 @@ TESTS_progs = \ core_getclient \ core_getstats \ core_getversion \ + core_hotunplug \ core_setmaster \ core_setmaster_vs_auth \ debugfs_test \ diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c new file mode 100644 index 0..64fb66005 --- /dev/null +++ b/tests/core_hotunplug.c @@ -0,0 +1,276 @@ +/* + * Copyright © 2019 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permis
[Intel-gfx] [PATCH] drm/i915/evict: watch out for unevictable nodes
In an address space there can be sprinkling of I915_COLOR_UNEVICTABLE
nodes, which lack a parent vma. For platforms with cache coloring we
might be very unlucky and abut with such a node thinking we can simply
unbind the vma.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_evict.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 4518b9b35c3d..9e462c6a4c6a 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -227,6 +227,10 @@ i915_gem_evict_something(struct i915_address_space *vm,
}
while (ret == 0 && (node = drm_mm_scan_color_evict(&scan))) {
+ /* If we find any non-objects (!vma), we cannot evict them */
+ if (node->color == I915_COLOR_UNEVICTABLE)
+ return -ENOSPC;
+
vma = container_of(node, struct i915_vma, node);
ret = __i915_vma_unbind(vma);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
On 20/04/08 07:29, Lionel Landwerlin wrote:
> On 06/04/2020 23:07, Venkata Sandeep Dhanalakota wrote:
> > Introduces a new parameters to execbuf so that we can specify syncobj
> > handles as well as timeline points.
> >
> > v2: Reuse i915_user_extension_fn
> >
> > v3: Check that the chained extension is only present once (Chris)
> >
> > v4: Check that dma_fence_chain_find_seqno returns a non NULL fence
> > (Lionel)
> >
> > v5: Use BIT_ULL (Chris)
> >
> > v6: Fix issue with already signaled timeline points,
> > dma_fence_chain_find_seqno() setting fence to NULL (Chris)
> >
> > v7: Report ENOENT with invalid syncobj handle (Lionel)
> >
> > v8: Check for out of order timeline point insertion (Chris)
> >
> > v9: After explanations on
> >
> > https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
> > drop the ordering check from v8 (Lionel)
> >
> > v10: Set first extension enum item to 1 (Jason)
> >
> > v11: Add wait on previous sync points in timelines (Sandeep)
>
>
> Thanks for picking this series up!
>
>
> Could you point to the changes in v11?
>
> I haven't look at it in a while and I can't remember what you would have
> changed.
>
Hi,
Mainly the changes are in get_timeline_fence_array(), to enforce the
implicit dependencies in signal fence-array. we want have efficient waits
on the last point on timelines so that we signal at a correct point in time
along the timeline
the order is controlled so that we always wait on the previous request/sync
point in the timeline
and signal after the completion of the current request.
Thank you,
~sandeep
>
> Thanks a lot,
>
>
> -Lionel
>
>
> >
> > Signed-off-by: Lionel Landwerlin
> > Signed-off-by: Venkata Sandeep Dhanalakota > intel.com>
> > ---
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 312 ++
> > drivers/gpu/drm/i915/i915_drv.c | 3 +-
> > drivers/gpu/drm/i915/i915_getparam.c | 1 +
> > include/uapi/drm/i915_drm.h | 38 +++
> > 4 files changed, 296 insertions(+), 58 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 16831f715daa..4cb4cd035daa 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -230,6 +230,13 @@ enum {
> >* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
> >*/
> > +struct i915_eb_fences {
> > + struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
> > + struct dma_fence *dma_fence;
> > + u64 value;
> > + struct dma_fence_chain *chain_fence;
> > +};
> > +
> > struct i915_execbuffer {
> > struct drm_i915_private *i915; /** i915 backpointer */
> > struct drm_file *file; /** per-file lookup tables and limits */
> > @@ -292,6 +299,7 @@ struct i915_execbuffer {
> > struct {
> > u64 flags; /** Available extensions parameters */
> > + struct drm_i915_gem_execbuffer_ext_timeline_fences
> > timeline_fences;
> > } extensions;
> > };
> > @@ -2244,67 +2252,219 @@ eb_pin_engine(struct i915_execbuffer *eb,
> > }
> > static void
> > -__free_fence_array(struct drm_syncobj **fences, unsigned int n)
> > +__free_fence_array(struct i915_eb_fences *fences, unsigned int n)
> > {
> > - while (n--)
> > - drm_syncobj_put(ptr_mask_bits(fences[n], 2));
> > + while (n--) {
> > + drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
> > + dma_fence_put(fences[n].dma_fence);
> > + kfree(fences[n].chain_fence);
> > + }
> > kvfree(fences);
> > }
> > -static struct drm_syncobj **
> > -get_fence_array(struct drm_i915_gem_execbuffer2 *args,
> > - struct drm_file *file)
> > +static struct i915_eb_fences *
> > +get_timeline_fence_array(struct i915_execbuffer *eb, int *out_n_fences)
> > +{
> > + struct drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences =
> > + &eb->extensions.timeline_fences;
> > + struct drm_i915_gem_exec_fence __user *user_fences;
> > + struct i915_eb_fences *fences;
> > + u64 __user *user_values;
> > + u64 num_fences, num_user_fences = timeline_fences->fence_count;
> > + unsigned long n;
> > + int err = 0;
> > +
> > + /* Check multiplication overflow for access_ok() and kvmalloc_array() */
> > + BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
> > + if (num_user_fences > min_t(unsigned long,
> > + ULONG_MAX / sizeof(*user_fences),
> > + SIZE_MAX / sizeof(*fences)))
> > + return ERR_PTR(-EINVAL);
> > +
> > + user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
> > + if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
> > + return ERR_PTR(-EFAULT);
> > +
> > + user_values = u64_to_user_ptr(timeline_fences->values_ptr);
> > + if (!access_ok(user_values, num_user_fenc
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev4)
== Series Details == Series: drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev4) URL : https://patchwork.freedesktop.org/series/75660/ State : success == Summary == CI Bug Log - changes from CI_DRM_8277 -> Patchwork_17254 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/index.html Known issues Here are the changes found in Patchwork_17254 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][1] ([i915#1158]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8277/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [i915#1158]: https://gitlab.freedesktop.org/drm/intel/issues/1158 Participating hosts (52 -> 47) -- Additional (1): fi-kbl-7560u Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8277 -> Patchwork_17254 CI-20190529: 20190529 CI_DRM_8277: f7d56913e1668f3a269db391189a7888a4b22570 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5581: ab0620e555119ec55f12ba9ab9e6e9246d407648 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17254: 5242e025d754e381e9299aac90078dd14b29011e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5242e025d754 drm/i915: Add Plane color encoding support for YCBCR_BT2020 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17254/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
On 06/04/2020 23:07, Venkata Sandeep Dhanalakota wrote:
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence
(Lionel)
v5: Use BIT_ULL (Chris)
v6: Fix issue with already signaled timeline points,
dma_fence_chain_find_seqno() setting fence to NULL (Chris)
v7: Report ENOENT with invalid syncobj handle (Lionel)
v8: Check for out of order timeline point insertion (Chris)
v9: After explanations on
https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
drop the ordering check from v8 (Lionel)
v10: Set first extension enum item to 1 (Jason)
v11: Add wait on previous sync points in timelines (Sandeep)
Thanks for picking this series up!
Could you point to the changes in v11?
I haven't look at it in a while and I can't remember what you would have
changed.
Thanks a lot,
-Lionel
Signed-off-by: Lionel Landwerlin
Signed-off-by: Venkata Sandeep Dhanalakota
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 312 ++
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/i915/i915_getparam.c | 1 +
include/uapi/drm/i915_drm.h | 38 +++
4 files changed, 296 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 16831f715daa..4cb4cd035daa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -230,6 +230,13 @@ enum {
* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
*/
+struct i915_eb_fences {
+ struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ struct dma_fence *dma_fence;
+ u64 value;
+ struct dma_fence_chain *chain_fence;
+};
+
struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -292,6 +299,7 @@ struct i915_execbuffer {
struct {
u64 flags; /** Available extensions parameters */
+ struct drm_i915_gem_execbuffer_ext_timeline_fences
timeline_fences;
} extensions;
};
@@ -2244,67 +2252,219 @@ eb_pin_engine(struct i915_execbuffer *eb,
}
static void
-__free_fence_array(struct drm_syncobj **fences, unsigned int n)
+__free_fence_array(struct i915_eb_fences *fences, unsigned int n)
{
- while (n--)
- drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+ while (n--) {
+ drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
+ dma_fence_put(fences[n].dma_fence);
+ kfree(fences[n].chain_fence);
+ }
kvfree(fences);
}
-static struct drm_syncobj **
-get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_file *file)
+static struct i915_eb_fences *
+get_timeline_fence_array(struct i915_execbuffer *eb, int *out_n_fences)
+{
+ struct drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences =
+ &eb->extensions.timeline_fences;
+ struct drm_i915_gem_exec_fence __user *user_fences;
+ struct i915_eb_fences *fences;
+ u64 __user *user_values;
+ u64 num_fences, num_user_fences = timeline_fences->fence_count;
+ unsigned long n;
+ int err = 0;
+
+ /* Check multiplication overflow for access_ok() and kvmalloc_array() */
+ BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
+ if (num_user_fences > min_t(unsigned long,
+ ULONG_MAX / sizeof(*user_fences),
+ SIZE_MAX / sizeof(*fences)))
+ return ERR_PTR(-EINVAL);
+
+ user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
+ if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
+ return ERR_PTR(-EFAULT);
+
+ user_values = u64_to_user_ptr(timeline_fences->values_ptr);
+ if (!access_ok(user_values, num_user_fences * sizeof(*user_values)))
+ return ERR_PTR(-EFAULT);
+
+ fences = kvmalloc_array(num_user_fences, sizeof(*fences),
+ __GFP_NOWARN | GFP_KERNEL);
+ if (!fences)
+ return ERR_PTR(-ENOMEM);
+
+ BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
+~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
+
+ for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++) {
+ struct drm_i915_gem_exec_fence user_fence;
+ struct drm_syncobj *syncobj;
+ struct dma_fence *fence = NULL;
+ u64 point;
+
+ if (__copy_from_user(&user_fence, user_fences++,
sizeof(user_fence))) {
+ err = -EFAULT;
+
[Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
of the additional commit inserted by the kernel without userspace's
knowledge
For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.
Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. As a stop-gap
plug this problem by demoting nonblocking commits which might cause
issues by including CRTCs not in the original request to blocking
commits.
v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.
v3: Fix inverted WARN_ON (Pekka).
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: sta...@vger.kernel.org
Reviewed-by: Daniel Stone
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
--
Resending because last attempt failed CI and meanwhile the results are
lost :-/
-Daniel
---
drivers/gpu/drm/drm_atomic.c | 34 +++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 965173fd0ac2..4f140ff6fb98 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
{
struct drm_mode_config *config = &state->dev->mode_config;
- int ret;
+ unsigned requested_crtc = 0;
+ unsigned affected_crtc = 0;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ bool nonblocking = true;
+ int ret, i;
+
+ /*
+* For commits that allow modesets drivers can add other CRTCs to the
+* atomic commit, e.g. when they need to reallocate global resources.
+*
+* But when userspace also requests a nonblocking commit then userspace
+* cannot know that the commit affects other CRTCs, which can result in
+* spurious EBUSY failures. Until we have better uapi plug this by
+* demoting such commits to blocking mode.
+*/
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+ requested_crtc |= drm_crtc_mask(crtc);
ret = drm_atomic_check_only(state);
if (ret)
return ret;
- DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+ affected_crtc |= drm_crtc_mask(crtc);
+
+ if (affected_crtc != requested_crtc) {
+ /* adding other CRTC is only allowed for modeset commits */
+ WARN_ON(!state->allow_modeset);
+
+ DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid
EBUSY\n", state);
+ nonblocking = false;
+ } else {
+ DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+ }
- return config->funcs->atomic_commit(state->dev, state, true);
+ return config->funcs->atomic_commit(state->dev, state, nonblocking);
}
EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v21 05/10] drm/i915: Extract gen specific functions from intel_can_enable_sagv
On Wed, Apr 08, 2020 at 06:54:09PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, Apr 08, 2020 at 05:55:02PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 08, 2020 at 10:58:04AM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, Apr 07, 2020 at 10:01:28PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Apr 03, 2020 at 09:20:03AM +0300, Stanislav Lisovskiy wrote:
> > > > > Addressing one of the comments, recommending to extract platform
> > > > > specific code from intel_can_enable_sagv as a preparation, before
> > > > > we are going to add support for tgl+.
> > > > >
> > > > > Current code in intel_can_enable_sagv is valid only for skl,
> > > > > so this patch adds also proper support for icl, subsequent
> > > > > patches will add support for tgl+, combined with other required
> > > > > changes.
> > > > >
> > > > > v2: - Renamed icl_can_enable_sagv into icl_crtc_can_enable_sagv(Ville)
> > > > > - Removed dev variables(Ville)
> > > > > - Constified crtc/plane_state in icl_crtc_can_enable_sagv
> > > > > function(Ville)
> > > > > - Added hw.active check(Ville)
> > > > > - Refactored if ladder(Ville)
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_pm.c | 84
> > > > > +
> > > > > 1 file changed, 55 insertions(+), 29 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > index f8d62d1977ac..27d4d626cb34 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > @@ -3757,42 +3757,25 @@ intel_disable_sagv(struct drm_i915_private
> > > > > *dev_priv)
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -bool intel_can_enable_sagv(struct intel_atomic_state *state)
> > > > > +static bool icl_crtc_can_enable_sagv(const struct intel_crtc_state
> > > > > *crtc_state)
> > > > > {
> > > > > - struct drm_device *dev = state->base.dev;
> > > > > - struct drm_i915_private *dev_priv = to_i915(dev);
> > > > > - struct intel_crtc *crtc;
> > > > > + struct drm_i915_private *dev_priv =
> > > > > to_i915(crtc_state->uapi.crtc->dev);
> > > > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > > struct intel_plane *plane;
> > > > > - struct intel_crtc_state *crtc_state;
> > > > > - enum pipe pipe;
> > > > > + const struct intel_plane_state *plane_state;
> > > > > int level, latency;
> > > > >
> > > > > - if (!intel_has_sagv(dev_priv))
> > > > > + if (crtc_state->hw.adjusted_mode.flags &
> > > > > DRM_MODE_FLAG_INTERLACE) {
> > > > > + DRM_DEBUG_KMS("No SAGV for interlaced mode on pipe
> > > > > %c\n",
> > > > > + pipe_name(crtc->pipe));
> > > > > return false;
> > > > > + }
> > > > >
> > > > > - /*
> > > > > - * If there are no active CRTCs, no additional checks need be
> > > > > performed
> > > > > - */
> > > > > - if (hweight8(state->active_pipes) == 0)
> > > > > + if (!crtc_state->hw.active)
> > > >
> > > > Should really be checked before anything else. Doesn't matter too much
> > > > anymore since I made us clear the crtc state always, but still a bit
> > > > inconsistent to look at other stuff in the state before we even know if
> > > > the crtc is even enabled.
> > > >
> > > > > return true;
> > > > >
> > > > > - /*
> > > > > - * SKL+ workaround: bspec recommends we disable SAGV when we
> > > > > have
> > > > > - * more then one pipe enabled
> > > > > - */
> > > > > - if (hweight8(state->active_pipes) > 1)
> > > > > - return false;
> > > > > -
> > > > > - /* Since we're now guaranteed to only have one active CRTC... */
> > > > > - pipe = ffs(state->active_pipes) - 1;
> > > > > - crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> > > > > - crtc_state = to_intel_crtc_state(crtc->base.state);
> > > > > -
> > > > > - if (crtc_state->hw.adjusted_mode.flags &
> > > > > DRM_MODE_FLAG_INTERLACE)
> > > > > - return false;
> > > > > -
> > > > > - for_each_intel_plane_on_crtc(dev, crtc, plane) {
> > > > > - struct skl_plane_wm *wm =
> > > > > + intel_atomic_crtc_state_for_each_plane_state(plane,
> > > > > plane_state, crtc_state) {
> > > > > + const struct skl_plane_wm *wm =
> > > > > &crtc_state->wm.skl.optimal.planes[plane->id];
> > > > >
> > > > > /* Skip this plane if it's not enabled */
> > > > > @@ -3807,7 +3790,7 @@ bool intel_can_enable_sagv(struct
> > > > > intel_atomic_state *state)
> > > > > latency = dev_priv->wm.skl_latency[level];
> > > > >
> > > > > if (skl_needs_memory_bw_wa(dev_priv) &&
> > > > > - plane->base.state->fb->modifier ==
> > > > > + plane_state->uapi.fb->modifier ==
> > > >
> > > > hw.
[Intel-gfx] [PATCH v4 1/5] drm: Introduce plane and CRTC scaling filter properties
Introduce per-plane and per-CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.
Drivers can set up this property for a plane by calling
drm_plane_create_scaling_filter() and for a CRTC by calling
drm_crtc_create_scaling_filter().
NN filter works by filling in the missing color values in the upscaled
image with that of the coordinate-mapped nearest source pixel value.
NN filter for integer multiple scaling can be particularly useful for
for pixel art games that rely on sharp, blocky images to deliver their
distinctive look.
changes since v3:
* Refactor code, add new function for common code (Ville)
changes since v2:
* Create per-plane and per-CRTC scaling filter property (Ville)
changes since v1:
* None
changes since RFC:
* Add separate properties for plane and CRTC (Ville)
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/drm_atomic_uapi.c | 8 +++
drivers/gpu/drm/drm_crtc.c | 48 +++
drivers/gpu/drm/drm_crtc_internal.h | 3 +
drivers/gpu/drm/drm_plane.c | 90 +
include/drm/drm_crtc.h | 16 +
include/drm/drm_plane.h | 21 +++
6 files changed, 186 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index a1e5e262bae2..ac7dabbf0bcf 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return -EFAULT;
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+ } else if (property == crtc->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
} else {
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == crtc->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
@@ -583,6 +587,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
sizeof(struct drm_rect),
&replaced);
return ret;
+ } else if (property == plane->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -641,6 +647,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
+ } else if (property == plane->scaling_filter_property) {
+ *val = state->scaling_filter;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4936e1080e41..91f0bb915dcd 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -748,3 +748,51 @@ int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
return ret;
}
+
+/**
+ * DOC: CRTC scaling filter property
+ *
+ * SCALING_FILTER:
+ *
+ * Indicates scaling filter to be used for CRTC scaler
+ *
+ * The value of this property can be one of the following:
+ * Default:
+ * Driver's default scaling filter
+ * Nearest Neighbor:
+ * Nearest Neighbor scaling filter
+ *
+ * Drivers can set up this property for a CRTC by calling
+ * drm_crtc_create_scaling_filter_property
+ */
+
+/**
+ * drm_crtc_create_scaling_filter_property - create a new scaling filter
+ * property
+ *
+ * @crtc: drm CRTC
+ * @supported_filters: bitmask of supported scaling filters, must include
+ *BIT(DRM_SCALING_FILTER_DEFAULT).
+ *
+ * This function lets driver to enable the scaling filter property on a given
+ * CRTC.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
+ unsigned int supported_filters)
+{
+ struct drm_property *prop =
+ drm_create_scaling_filter_prop(crtc->dev, supported_filters);
+
+ if (IS_ERR(prop))
+ return PTR_ERR(prop);
+
+ drm_object_attach_property(&crtc->base, pr
[Intel-gfx] [PATCH v4 3/5] drm/i915: Introduce scaling filter related registers and bit fields.
Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.
changes since v3:
* None
changes since v2:
* Change macro names to CNL_* and use +(set)*8 instead of adding
another trip through _PICK_EVEN (Ville).
changes since v1:
* None
changes since RFC:
* Parametrize scaler coeffient macros by 'set' (Ville)
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_reg.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a7bd6db164b..e8d9c3261ac2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7296,6 +7296,7 @@ enum {
#define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
#define PS_FILTER_MASK (3 << 23)
#define PS_FILTER_MEDIUM (0 << 23)
+#define PS_FILTER_PROGRAMMED (1 << 23)
#define PS_FILTER_EDGE_ENHANCE (2 << 23)
#define PS_FILTER_BILINEAR (3 << 23)
#define PS_VERT3TAP(1 << 21)
@@ -7310,6 +7311,10 @@ enum {
#define PS_VADAPT_MODE_MOST_ADAPT (3 << 5)
#define PS_PLANE_Y_SEL_MASK (7 << 5)
#define PS_PLANE_Y_SEL(plane) (((plane) + 1) << 5)
+#define PS_Y_VERT_FILTER_SELECT(set) ((set) << 4)
+#define PS_Y_HORZ_FILTER_SELECT(set) ((set) << 3)
+#define PS_UV_VERT_FILTER_SELECT(set) ((set) << 2)
+#define PS_UV_HORZ_FILTER_SELECT(set) ((set) << 1)
#define _PS_PWR_GATE_1A 0x68160
#define _PS_PWR_GATE_2A 0x68260
@@ -7372,6 +7377,17 @@ enum {
#define _PS_ECC_STAT_2B 0x68AD0
#define _PS_ECC_STAT_1C 0x691D0
+#define _PS_COEF_SET0_INDEX_1A0x68198
+#define _PS_COEF_SET0_INDEX_2A0x68298
+#define _PS_COEF_SET0_INDEX_1B0x68998
+#define _PS_COEF_SET0_INDEX_2B0x68A98
+#define PS_COEE_INDEX_AUTO_INC(1 << 10)
+
+#define _PS_COEF_SET0_DATA_1A 0x6819C
+#define _PS_COEF_SET0_DATA_2A 0x6829C
+#define _PS_COEF_SET0_DATA_1B 0x6899C
+#define _PS_COEF_SET0_DATA_2B 0x68A9C
+
#define _ID(id, a, b) _PICK_EVEN(id, a, b)
#define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
_ID(id, _PS_1A_CTRL, _PS_2A_CTRL), \
@@ -7400,7 +7416,13 @@ enum {
#define SKL_PS_ECC_STAT(pipe, id) _MMIO_PIPE(pipe, \
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
+#define CNL_PS_COEF_INDEX_SET(pipe, id, set) _MMIO_PIPE(pipe,\
+ _ID(id, _PS_COEF_SET0_INDEX_1A, _PS_COEF_SET0_INDEX_2A)
+ (set) * 8, \
+ _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_2B)
+ (set) * 8)
+#define CNL_PS_COEF_DATA_SET(pipe, id, set) _MMIO_PIPE(pipe, \
+ _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A) +
(set) * 8, \
+ _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B) +
(set) * 8)
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/5] drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation
Add documentation for newly introduced KMS plane and CRTC scaling filter properties. changes since v3: * None changes since v1: * None changes since RFC: * Add separate documentation for plane and CRTC. Signed-off-by: Pankaj Bharadiya --- Documentation/gpu/drm-kms.rst | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 397314d08f77..90250aa5395e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -512,6 +512,18 @@ Variable Refresh Properties .. kernel-doc:: drivers/gpu/drm/drm_connector.c :doc: Variable refresh properties +Plane Scaling Filter Property +--- + +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: Plane scaling filter property + +CRTC Scaling Filter Property +--- + +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :doc: CRTC scaling filter property + Existing KMS Properties --- -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/5] Introduce drm scaling filter property
This series is the continuation for the RFC that I posted earlier [1] [1] RFC: https://patchwork.freedesktop.org/series/73884/ Integer scaling (IS) is a nearest-neighbor upscaling technique that simply scales up the existing pixels by an integer (i.e., whole number) multiplier. Nearest-neighbor (NN) interpolation works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. Both IS and NN preserve the clarity of the original image. In contrast, traditional upscaling algorithms, such as bilinear or bicubic interpolation, result in blurry upscaled images because they employ interpolation techniques that smooth out the transition from one pixel to another. Therefore, integer scaling is particularly useful for pixel art games that rely on sharp, blocky images to deliver their distinctive look. Many gaming communities have been asking for integer-mode scaling support, some links and background: https://software.intel.com/en-us/articles/integer-scaling-support-on-intel-graphics http://tanalin.com/en/articles/lossless-scaling/ https://community.amd.com/thread/209107 https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/1002/feature-request-nonblurry-upscaling-at-integer-rat/ This patch series - - Introduces new scaling filter properties to allow userspace to select the driver's default scaling filter or Nearest-neighbor(NN) filter for scaling operations on crtc and plane. - Implements and enable integer scaling for i915 Userspace patch series link: https://github.com/lrusak/xbmc/pull/24 Thanks to Shashank for initiating this work. His initial work can be found here [2] [2] https://patchwork.freedesktop.org/patch/337082/ changes sinc v3: * Refactor code, add new function for common code in 1/5 (Ville) changes since v2: * Add per-crtc and per-plane scaling filter property (Ville) * Rename/refoctor functions and macros. * Duplicate the scaling filter in crtc and plane hw state (Ville) changes since v1: * Add userspace patch link to this cover letter. * 4/5 - Rearrange skl_scaler_setup_nearest_neighbor_filter() to iterate the registers directly instead of the phases and taps (Ville) Pankaj Bharadiya (5): drm: Introduce plane and CRTC scaling filter properties drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation drm/i915: Introduce scaling filter related registers and bit fields. drm/i915/display: Add Nearest-neighbor based integer scaling support drm/i915: Enable scaling filter for plane and CRTC Documentation/gpu/drm-kms.rst | 12 ++ drivers/gpu/drm/drm_atomic_uapi.c | 8 ++ drivers/gpu/drm/drm_crtc.c| 48 drivers/gpu/drm/drm_crtc_internal.h | 3 + drivers/gpu/drm/drm_plane.c | 90 ++ .../gpu/drm/i915/display/intel_atomic_plane.c | 1 + drivers/gpu/drm/i915/display/intel_display.c | 116 +- drivers/gpu/drm/i915/display/intel_display.h | 4 + .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_sprite.c | 15 ++- drivers/gpu/drm/i915/i915_reg.h | 22 include/drm/drm_crtc.h| 16 +++ include/drm/drm_plane.h | 21 13 files changed, 354 insertions(+), 4 deletions(-) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 5/5] drm/i915: Enable scaling filter for plane and CRTC
GEN >= 10 hardware supports the programmable scaler filter. Attach scaling filter property for CRTC and plane for GEN >= 10 hardwares and program scaler filter based on the selected filter type. changes since v3: * None changes since v2: * Use updated functions * Add ps_ctrl var to contain the full PS_CTRL register value (Ville) * Duplicate the scaling filter in crtc and plane hw state (Ville) changes since v1: * None Changes since RFC: * Enable properties for GEN >= 10 platforms (Ville) * Do not round off the crtc co-ordinate (Danial Stone, Ville) * Add new functions to handle scaling filter setup (Ville) * Remove coefficient set 0 hardcoding. Signed-off-by: Shashank Sharma Signed-off-by: Ankit Nautiyal Signed-off-by: Pankaj Bharadiya --- .../gpu/drm/i915/display/intel_atomic_plane.c | 1 + drivers/gpu/drm/i915/display/intel_display.c| 17 +++-- .../gpu/drm/i915/display/intel_display_types.h | 2 ++ drivers/gpu/drm/i915/display/intel_sprite.c | 15 +-- 4 files changed, 31 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c index 25dfeb3197aa..cfcc8df75656 100644 --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c @@ -262,6 +262,7 @@ void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state *plane_state, plane_state->hw.rotation = from_plane_state->uapi.rotation; plane_state->hw.color_encoding = from_plane_state->uapi.color_encoding; plane_state->hw.color_range = from_plane_state->uapi.color_range; + plane_state->hw.scaling_filter = from_plane_state->uapi.scaling_filter; } void intel_plane_set_invisible(struct intel_crtc_state *crtc_state, diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index d64a4db0e385..fa3b8d970487 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -6324,6 +6324,7 @@ static void skl_pfit_enable(const struct intel_crtc_state *crtc_state) int pfit_w, pfit_h, hscale, vscale; unsigned long irqflags; int id; + u32 ps_ctrl; if (drm_WARN_ON(&dev_priv->drm, crtc_state->scaler_state.scaler_id < 0)) @@ -6340,10 +6341,15 @@ static void skl_pfit_enable(const struct intel_crtc_state *crtc_state) id = scaler_state->scaler_id; + ps_ctrl = skl_scaler_get_filter_select(crtc_state->hw.scaling_filter, 0); + ps_ctrl |= PS_SCALER_EN | scaler_state->scalers[id].mode; + spin_lock_irqsave(&dev_priv->uncore.lock, irqflags); - intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN | - PS_FILTER_MEDIUM | scaler_state->scalers[id].mode); + skl_scaler_setup_filter(dev_priv, pipe, id, 0, + crtc_state->hw.scaling_filter); + + intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), ps_ctrl); intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id), PS_Y_PHASE(0) | PS_UV_RGB_PHASE(uv_rgb_vphase)); intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id), @@ -13242,6 +13248,7 @@ intel_crtc_copy_uapi_to_hw_state(struct intel_crtc_state *crtc_state) crtc_state->hw.active = crtc_state->uapi.active; crtc_state->hw.mode = crtc_state->uapi.mode; crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode; + crtc_state->hw.scaling_filter = crtc_state->uapi.scaling_filter; intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state); } @@ -13252,6 +13259,7 @@ static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state *crtc_state WARN_ON(drm_atomic_set_mode_for_crtc(&crtc_state->uapi, &crtc_state->hw.mode) < 0); crtc_state->uapi.adjusted_mode = crtc_state->hw.adjusted_mode; + crtc_state->uapi.scaling_filter = crtc_state->hw.scaling_filter; /* copy color blobs to uapi */ drm_property_replace_blob(&crtc_state->uapi.degamma_lut, @@ -16613,6 +16621,11 @@ static int intel_crtc_init(struct drm_i915_private *dev_priv, enum pipe pipe) dev_priv->plane_to_crtc_mapping[i9xx_plane] = crtc; } + if (INTEL_GEN(dev_priv) >= 10) + drm_crtc_create_scaling_filter_property(&crtc->base, + BIT(DRM_SCALING_FILTER_DEFAULT) | + BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR)); + intel_color_init(crtc); intel_crtc_crc_init(crtc); diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h index 0ddc98afe252..c7e8a0b76b38 100644 --- a/drivers/gpu/drm/i915/
[Intel-gfx] [PATCH v4 4/5] drm/i915/display: Add Nearest-neighbor based integer scaling support
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer
(i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
works by filling in the missing color values in the upscaled image
with that of the coordinate-mapped nearest source pixel value.
Both IS and NN preserve the clarity of the original image. Integer
scaling is particularly useful for pixel art games that rely on
sharp, blocky images to deliver their distinctive look.
Introduce functions to configure the scaler filter coefficients to
enable nearest-neighbor filtering.
Bspec: 49247
changes since v3:
* None
changes since v2:
* Move APIs from 5/5 into this patch.
* Change filter programming related function names to cnl_*, move
filter select bits related code into inline function (Ville)
changes since v1:
* Rearrange skl_scaler_setup_nearest_neighbor_filter() to iterate the
registers directly instead of the phases and taps (Ville)
changes since RFC:
* Refine the skl_scaler_setup_nearest_neighbor_filter() logic (Ville)
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_display.c | 99
drivers/gpu/drm/i915/display/intel_display.h | 4 +
2 files changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 70ec301fe6e3..d64a4db0e385 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6212,6 +6212,105 @@ void skl_scaler_disable(const struct intel_crtc_state
*old_crtc_state)
skl_detach_scaler(crtc, i);
}
+static int cnl_coef_tap(int i)
+{
+ return i % 7;
+}
+
+static u16 cnl_nearest_filter_coef(int t)
+{
+ return t == 3 ? 0x0800 : 0x3000;
+}
+
+/**
+ * Theory behind setting nearest-neighbor integer scaling:
+ *
+ * 17 phase of 7 taps requires 119 coefficients in 60 dwords per set.
+ * The letter represents the filter tap (D is the center tap) and the number
+ * represents the coefficient set for a phase (0-16).
+ *
+ * ++++
+ * |Index value | Data value coeffient 1 | Data value coeffient 2 |
+ * ++++
+ * | 00h | B0| A0|
+ * ++++
+ * | 01h | D0| C0|
+ * ++++
+ * | 02h | F0| E0|
+ * ++++
+ * | 03h | A1| G0|
+ * ++++
+ * | 04h | C1| B1|
+ * ++++
+ * | ... | ... | ... |
+ * ++++
+ * | 38h | B16 | A16 |
+ * ++++
+ * | 39h | D16 | C16 |
+ * ++++
+ * | 3Ah | F16 | C16 |
+ * ++++
+ * | 3Bh |Reserved| G16 |
+ * ++++
+ *
+ * To enable nearest-neighbor scaling: program scaler coefficents with
+ * the center tap (Dxx) values set to 1 and all other values set to 0 as per
+ * SCALER_COEFFICIENT_FORMAT
+ *
+ */
+
+static void cnl_program_nearest_filter_coefs(struct drm_i915_private *dev_priv,
+enum pipe pipe, int id, int set)
+{
+ int i;
+
+ intel_de_write_fw(dev_priv, CNL_PS_COEF_INDEX_SET(pipe, id, set),
+ PS_COEE_INDEX_AUTO_INC);
+
+ for (i = 0; i < 17 * 7; i += 2) {
+ u32 tmp;
+ int t;
+
+ t = cnl_coef_tap(i);
+ tmp = cnl_nearest_filter_coef(t);
+
+ t = cnl_coef_tap(i + 1);
+ tmp |= cnl_nearest_filter_coef(t) << 16;
+
+ intel_de_write_fw(dev_priv, CNL_PS_COEF_DATA_SET(pipe, id, set),
+ tmp);
+ }
+
+ intel_de_write_fw(dev_priv, CNL_PS_COEF_INDEX_SET(pipe, id, set), 0);
+}
+
+inline u32 skl_scaler_get_filter_select(enum drm_scaling_filter
Re: [Intel-gfx] [PATCH v21 05/10] drm/i915: Extract gen specific functions from intel_can_enable_sagv
On Wed, Apr 08, 2020 at 05:55:02PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 08, 2020 at 10:58:04AM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, Apr 07, 2020 at 10:01:28PM +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 03, 2020 at 09:20:03AM +0300, Stanislav Lisovskiy wrote:
> > > > Addressing one of the comments, recommending to extract platform
> > > > specific code from intel_can_enable_sagv as a preparation, before
> > > > we are going to add support for tgl+.
> > > >
> > > > Current code in intel_can_enable_sagv is valid only for skl,
> > > > so this patch adds also proper support for icl, subsequent
> > > > patches will add support for tgl+, combined with other required
> > > > changes.
> > > >
> > > > v2: - Renamed icl_can_enable_sagv into icl_crtc_can_enable_sagv(Ville)
> > > > - Removed dev variables(Ville)
> > > > - Constified crtc/plane_state in icl_crtc_can_enable_sagv
> > > > function(Ville)
> > > > - Added hw.active check(Ville)
> > > > - Refactored if ladder(Ville)
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy
> > > > ---
> > > > drivers/gpu/drm/i915/intel_pm.c | 84 +
> > > > 1 file changed, 55 insertions(+), 29 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index f8d62d1977ac..27d4d626cb34 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -3757,42 +3757,25 @@ intel_disable_sagv(struct drm_i915_private
> > > > *dev_priv)
> > > > return 0;
> > > > }
> > > >
> > > > -bool intel_can_enable_sagv(struct intel_atomic_state *state)
> > > > +static bool icl_crtc_can_enable_sagv(const struct intel_crtc_state
> > > > *crtc_state)
> > > > {
> > > > - struct drm_device *dev = state->base.dev;
> > > > - struct drm_i915_private *dev_priv = to_i915(dev);
> > > > - struct intel_crtc *crtc;
> > > > + struct drm_i915_private *dev_priv =
> > > > to_i915(crtc_state->uapi.crtc->dev);
> > > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > struct intel_plane *plane;
> > > > - struct intel_crtc_state *crtc_state;
> > > > - enum pipe pipe;
> > > > + const struct intel_plane_state *plane_state;
> > > > int level, latency;
> > > >
> > > > - if (!intel_has_sagv(dev_priv))
> > > > + if (crtc_state->hw.adjusted_mode.flags &
> > > > DRM_MODE_FLAG_INTERLACE) {
> > > > + DRM_DEBUG_KMS("No SAGV for interlaced mode on pipe
> > > > %c\n",
> > > > + pipe_name(crtc->pipe));
> > > > return false;
> > > > + }
> > > >
> > > > - /*
> > > > -* If there are no active CRTCs, no additional checks need be
> > > > performed
> > > > -*/
> > > > - if (hweight8(state->active_pipes) == 0)
> > > > + if (!crtc_state->hw.active)
> > >
> > > Should really be checked before anything else. Doesn't matter too much
> > > anymore since I made us clear the crtc state always, but still a bit
> > > inconsistent to look at other stuff in the state before we even know if
> > > the crtc is even enabled.
> > >
> > > > return true;
> > > >
> > > > - /*
> > > > -* SKL+ workaround: bspec recommends we disable SAGV when we
> > > > have
> > > > -* more then one pipe enabled
> > > > -*/
> > > > - if (hweight8(state->active_pipes) > 1)
> > > > - return false;
> > > > -
> > > > - /* Since we're now guaranteed to only have one active CRTC... */
> > > > - pipe = ffs(state->active_pipes) - 1;
> > > > - crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> > > > - crtc_state = to_intel_crtc_state(crtc->base.state);
> > > > -
> > > > - if (crtc_state->hw.adjusted_mode.flags &
> > > > DRM_MODE_FLAG_INTERLACE)
> > > > - return false;
> > > > -
> > > > - for_each_intel_plane_on_crtc(dev, crtc, plane) {
> > > > - struct skl_plane_wm *wm =
> > > > + intel_atomic_crtc_state_for_each_plane_state(plane,
> > > > plane_state, crtc_state) {
> > > > + const struct skl_plane_wm *wm =
> > > > &crtc_state->wm.skl.optimal.planes[plane->id];
> > > >
> > > > /* Skip this plane if it's not enabled */
> > > > @@ -3807,7 +3790,7 @@ bool intel_can_enable_sagv(struct
> > > > intel_atomic_state *state)
> > > > latency = dev_priv->wm.skl_latency[level];
> > > >
> > > > if (skl_needs_memory_bw_wa(dev_priv) &&
> > > > - plane->base.state->fb->modifier ==
> > > > + plane_state->uapi.fb->modifier ==
> > >
> > > hw.fb
> > >
> > > With those this is basically good, but still need to think how to avoid
> > > the regression due to only checking the crtcs in the state.
> >
> > Well tbh, initially you told me that this *_
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, Apr 8, 2020 at 4:03 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote:
> > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > > reconfiguring global resources).
> > > > >
> > > > > But in nonblocking mode userspace has then no idea this happened,
> > > > > which can lead to spurious EBUSY calls, both:
> > > > > - when that other CRTC is currently busy doing a page_flip the
> > > > > ALLOW_MODESET commit can fail with an EBUSY
> > > > > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > > > > of the additional commit inserted by the kernel without userspace's
> > > > > knowledge
> > > > >
> > > > > For blocking commits this isn't a problem, because everyone else will
> > > > > just block until all the CRTC are reconfigured. Only thing userspace
> > > > > can notice is the dropped frames without any reason for why frames got
> > > > > dropped.
> > > > >
> > > > > Consensus is that we need new uapi to handle this properly, but no one
> > > > > has any idea what exactly the new uapi should look like. As a stop-gap
> > > > > plug this problem by demoting nonblocking commits which might cause
> > > > > issues by including CRTCs not in the original request to blocking
> > > > > commits.
> > > > >
> > > > > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > > > > don't want to silently convert page flips into blocking plane updates
> > > > > just because the driver is buggy.
> > > > >
> > > > > v3: Fix inverted WARN_ON (Pekka).
> > > > >
> > > > > References:
> > > > > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > > > > Bugzilla:
> > > > > https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > > > > Cc: Daniel Stone
> > > > > Cc: Pekka Paalanen
> > > > > Cc: sta...@vger.kernel.org
> > > > > Reviewed-by: Daniel Stone
> > > > > Signed-off-by: Daniel Vetter
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > > > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > > > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > > > {
> > > > > struct drm_mode_config *config = &state->dev->mode_config;
> > > > > - int ret;
> > > > > + unsigned requested_crtc = 0;
> > > > > + unsigned affected_crtc = 0;
> > > > > + struct drm_crtc *crtc;
> > > > > + struct drm_crtc_state *crtc_state;
> > > > > + bool nonblocking = true;
> > > > > + int ret, i;
> > > > > +
> > > > > + /*
> > > > > + * For commits that allow modesets drivers can add other CRTCs
> > > > > to the
> > > > > + * atomic commit, e.g. when they need to reallocate global
> > > > > resources.
> > > > > + *
> > > > > + * But when userspace also requests a nonblocking commit then
> > > > > userspace
> > > > > + * cannot know that the commit affects other CRTCs, which can
> > > > > result in
> > > > > + * spurious EBUSY failures. Until we have better uapi plug this
> > > > > by
> > > > > + * demoting such commits to blocking mode.
> > > > > + */
> > > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > + requested_crtc |= drm_crtc_mask(crtc);
> > > > >
> > > > > ret = drm_atomic_check_only(state);
> > > > > if (ret)
> > > > > return ret;
> > > > >
> > > > > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > > +
> > > > > + if (affected_crtc != requested_crtc) {
> > > > > + /* adding other CRTC is only allowed for modeset
> > > > > commits */
> > > > > + WARN_ON(!state->allow_modeset);
> > > >
> > > > Not sure that's really true. What if the driver needs to eg.
> > > > redistribute FIFO space or something between the pipes? Or do we
> > > > expect drivers to now examine state->allow_modeset to figure out
> > > > if they're allowed to do certain things?
> > >
> > > Maybe we need more fine-grained flags here, but adding other states
> > > (and blocking a commit flow) is exactly the uapi headaches this patch
> > > tries to solve here. So if our driver currently adds crtc states to
> > > reallocate fifo between pipes for an
[Intel-gfx] [PATCH] agp/intel: Disable use of WC for GMM updates
It appears that Ironlake is very sensitive to having its GGTT PTE
updates flushed in a timely manner and requires UC rather than WC for
all, and not just under VT'd.
Signed-off-by: Chris Wilson
---
drivers/char/agp/intel-gtt.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 66a62d17a3f5..afe5e81bafac 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -565,35 +565,12 @@ static void intel_gtt_cleanup(void)
intel_gtt_teardown_scratch_page();
}
-/* Certain Gen5 chipsets require require idling the GPU before
- * unmapping anything from the GTT when VT-d is enabled.
- */
-static inline int needs_ilk_vtd_wa(void)
-{
-#ifdef CONFIG_INTEL_IOMMU
- const unsigned short gpu_devid = intel_private.pcidev->device;
-
- /* Query intel_iommu to see if we need the workaround. Presumably that
-* was loaded first.
-*/
- if ((gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_D_IG ||
-gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_IG) &&
-intel_iommu_gfx_mapped)
- return 1;
-#endif
- return 0;
-}
-
static bool intel_gtt_can_wc(void)
{
if (INTEL_GTT_GEN <= 2)
return false;
- if (INTEL_GTT_GEN >= 6)
- return false;
-
- /* Reports of major corruption with ILK vt'd enabled */
- if (needs_ilk_vtd_wa())
+ if (INTEL_GTT_GEN >= 5)
return false;
return true;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v21 05/10] drm/i915: Extract gen specific functions from intel_can_enable_sagv
On Wed, Apr 08, 2020 at 10:58:04AM +0300, Lisovskiy, Stanislav wrote:
> On Tue, Apr 07, 2020 at 10:01:28PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 03, 2020 at 09:20:03AM +0300, Stanislav Lisovskiy wrote:
> > > Addressing one of the comments, recommending to extract platform
> > > specific code from intel_can_enable_sagv as a preparation, before
> > > we are going to add support for tgl+.
> > >
> > > Current code in intel_can_enable_sagv is valid only for skl,
> > > so this patch adds also proper support for icl, subsequent
> > > patches will add support for tgl+, combined with other required
> > > changes.
> > >
> > > v2: - Renamed icl_can_enable_sagv into icl_crtc_can_enable_sagv(Ville)
> > > - Removed dev variables(Ville)
> > > - Constified crtc/plane_state in icl_crtc_can_enable_sagv
> > > function(Ville)
> > > - Added hw.active check(Ville)
> > > - Refactored if ladder(Ville)
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/intel_pm.c | 84 +
> > > 1 file changed, 55 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index f8d62d1977ac..27d4d626cb34 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -3757,42 +3757,25 @@ intel_disable_sagv(struct drm_i915_private
> > > *dev_priv)
> > > return 0;
> > > }
> > >
> > > -bool intel_can_enable_sagv(struct intel_atomic_state *state)
> > > +static bool icl_crtc_can_enable_sagv(const struct intel_crtc_state
> > > *crtc_state)
> > > {
> > > - struct drm_device *dev = state->base.dev;
> > > - struct drm_i915_private *dev_priv = to_i915(dev);
> > > - struct intel_crtc *crtc;
> > > + struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > struct intel_plane *plane;
> > > - struct intel_crtc_state *crtc_state;
> > > - enum pipe pipe;
> > > + const struct intel_plane_state *plane_state;
> > > int level, latency;
> > >
> > > - if (!intel_has_sagv(dev_priv))
> > > + if (crtc_state->hw.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE) {
> > > + DRM_DEBUG_KMS("No SAGV for interlaced mode on pipe %c\n",
> > > + pipe_name(crtc->pipe));
> > > return false;
> > > + }
> > >
> > > - /*
> > > - * If there are no active CRTCs, no additional checks need be performed
> > > - */
> > > - if (hweight8(state->active_pipes) == 0)
> > > + if (!crtc_state->hw.active)
> >
> > Should really be checked before anything else. Doesn't matter too much
> > anymore since I made us clear the crtc state always, but still a bit
> > inconsistent to look at other stuff in the state before we even know if
> > the crtc is even enabled.
> >
> > > return true;
> > >
> > > - /*
> > > - * SKL+ workaround: bspec recommends we disable SAGV when we have
> > > - * more then one pipe enabled
> > > - */
> > > - if (hweight8(state->active_pipes) > 1)
> > > - return false;
> > > -
> > > - /* Since we're now guaranteed to only have one active CRTC... */
> > > - pipe = ffs(state->active_pipes) - 1;
> > > - crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> > > - crtc_state = to_intel_crtc_state(crtc->base.state);
> > > -
> > > - if (crtc_state->hw.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
> > > - return false;
> > > -
> > > - for_each_intel_plane_on_crtc(dev, crtc, plane) {
> > > - struct skl_plane_wm *wm =
> > > + intel_atomic_crtc_state_for_each_plane_state(plane, plane_state,
> > > crtc_state) {
> > > + const struct skl_plane_wm *wm =
> > > &crtc_state->wm.skl.optimal.planes[plane->id];
> > >
> > > /* Skip this plane if it's not enabled */
> > > @@ -3807,7 +3790,7 @@ bool intel_can_enable_sagv(struct
> > > intel_atomic_state *state)
> > > latency = dev_priv->wm.skl_latency[level];
> > >
> > > if (skl_needs_memory_bw_wa(dev_priv) &&
> > > - plane->base.state->fb->modifier ==
> > > + plane_state->uapi.fb->modifier ==
> >
> > hw.fb
> >
> > With those this is basically good, but still need to think how to avoid
> > the regression due to only checking the crtcs in the state.
>
> Well tbh, initially you told me that this *_crtc_can_enable_sagv function
> extraction
> can be "trivially" done as a separate patch :)) So I followed your
> instruction, and
> then I got a comment saying that "this is now temporary busted because we are
> checking
> only crtcs in a state". This kind of contraversial requirements - in order
> not to
> have it "temporary busted", we should have introduced it at the same time
> with SAGV mask,
> at the same time you wanted it to be extracted as a separate patch.
TBF this patch does quite a bit more than extract the current code.
What I think would work as a series is something l
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/23] perf/core: Only copy-to-user after completely unlocking all locks, v3.
== Series Details == Series: series starting with [01/23] perf/core: Only copy-to-user after completely unlocking all locks, v3. URL : https://patchwork.freedesktop.org/series/75668/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8275 -> Patchwork_17253 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17253 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17253, 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_17253/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17253: ### IGT changes ### Possible regressions * igt@gem_close_race@basic-process: - fi-ivb-3770:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-ivb-3770/igt@gem_close_r...@basic-process.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-ivb-3770/igt@gem_close_r...@basic-process.html - fi-hsw-4770:[PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-hsw-4770/igt@gem_close_r...@basic-process.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-hsw-4770/igt@gem_close_r...@basic-process.html - fi-hsw-peppy: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-hsw-peppy/igt@gem_close_r...@basic-process.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-hsw-peppy/igt@gem_close_r...@basic-process.html * igt@gem_exec_fence@basic-await@rcs0: - fi-blb-e6850: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-blb-e6850/igt@gem_exec_fence@basic-aw...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-blb-e6850/igt@gem_exec_fence@basic-aw...@rcs0.html - fi-elk-e7500: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@rcs0.html - fi-pnv-d510:[PASS][11] -> [DMESG-WARN][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-pnv-d510/igt@gem_exec_fence@basic-aw...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-pnv-d510/igt@gem_exec_fence@basic-aw...@rcs0.html - fi-ilk-650: [PASS][13] -> [DMESG-WARN][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-ilk-650/igt@gem_exec_fence@basic-aw...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-ilk-650/igt@gem_exec_fence@basic-aw...@rcs0.html * igt@gem_exec_fence@basic-await@vcs0: - fi-ilk-650: [PASS][15] -> [INCOMPLETE][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-ilk-650/igt@gem_exec_fence@basic-aw...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-ilk-650/igt@gem_exec_fence@basic-aw...@vcs0.html * igt@gem_render_tiled_blits@basic: - fi-gdg-551: [PASS][17] -> [DMESG-WARN][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-gdg-551/igt@gem_render_tiled_bl...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-gdg-551/igt@gem_render_tiled_bl...@basic.html * igt@gem_sync@basic-each: - fi-cfl-8109u: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-cfl-8109u/igt@gem_s...@basic-each.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-cfl-8109u/igt@gem_s...@basic-each.html * igt@i915_selftest@live@gem_contexts: - fi-skl-6770hq: [PASS][21] -> [DMESG-WARN][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-skl-6770hq/igt@i915_selftest@live@gem_contexts.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-skl-6770hq/igt@i915_selftest@live@gem_contexts.html - fi-skl-lmem:[PASS][23] -> [DMESG-WARN][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html * igt@kms_busy@basic@flip: - fi-bwr-2160:[PASS][25] -> [FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-bwr-2160/igt@kms_busy@ba...@flip.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17253/fi-bwr-2160/igt@kms_busy@ba...@flip.html * igt@runner@aborted: - fi-ilk-650: NOTRUN -> [FAIL]
[Intel-gfx] [PATCH v5] drm/i915: Add Plane color encoding support for YCBCR_BT2020
Currently the plane property doesn't have support for YCBCR_BT2020,
which enables the corresponding color conversion mode on plane CSC.
Enabling the plane property for the planes for GLK & ICL+ platforms.
V2: Enabling support for YCBCT_BT2020 for HDR planes on
platforms GLK & ICL
V3: Refined the condition check to handle GLK & ICL+ HDR planes
Also added BT2020 handling in glk_plane_color_ctl.
V4: Combine If-else into single If
V5: Drop the checking for HDR planes and enable YCBCR_BT2020
for platforms GLK & ICL+.
Cc: Ville Syrjala
Cc: Uma Shankar
Cc: Jani Nikula
Signed-off-by: Kishore Kadiyala
---
drivers/gpu/drm/i915/display/intel_display.c | 12 +---
drivers/gpu/drm/i915/display/intel_sprite.c | 9 +++--
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 70ec301fe6e3..f2dfa61a49fa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
- if (plane_state->hw.color_encoding == DRM_COLOR_YCBCR_BT709)
+ switch (plane_state->hw.color_encoding) {
+ case DRM_COLOR_YCBCR_BT709:
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
- else
+ break;
+ case DRM_COLOR_YCBCR_BT2020:
+ plane_color_ctl |=
+ PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
+ break;
+ default:
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
-
+ }
if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
plane_color_ctl |=
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
} else if (fb->format->is_yuv) {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index deda351719db..0072525046a1 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
struct intel_plane *plane;
enum drm_plane_type plane_type;
unsigned int supported_rotations;
+ unsigned int supported_csc;
const u64 *modifiers;
const u32 *formats;
int num_formats;
@@ -3105,9 +3106,13 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
DRM_MODE_ROTATE_0,
supported_rotations);
+ supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | BIT(DRM_COLOR_YCBCR_BT709);
+
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
+
drm_plane_create_color_properties(&plane->base,
- BIT(DRM_COLOR_YCBCR_BT601) |
- BIT(DRM_COLOR_YCBCR_BT709),
+ supported_csc,
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
BIT(DRM_COLOR_YCBCR_FULL_RANGE),
DRM_COLOR_YCBCR_BT709,
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] intel-ci: Drop gem_exec_suspend@basic-S4-device from BAT
S4-devices is a debug only path, and while it can prove informative as to the nature of suspend issues, being a debug only path it is not so relevant towards the driver health. Relegate it to the shards and idle runs, so we can shave 20s off BAT. gem_exec_suspend@basic itself is just a test suspend, a sanitycheck to ensure the test is functional, for manual debugging of the tests. Signed-off-by: Chris Wilson Cc: Martin Peres Cc: Petri Latvala --- tests/intel-ci/fast-feedback.testlist | 2 -- 1 file changed, 2 deletions(-) diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist index 620d5f3a7..2ccad4386 100644 --- a/tests/intel-ci/fast-feedback.testlist +++ b/tests/intel-ci/fast-feedback.testlist @@ -23,10 +23,8 @@ igt@gem_exec_fence@nb-await igt@gem_exec_gttfill@basic igt@gem_exec_parallel@engines igt@gem_exec_store@basic -igt@gem_exec_suspend@basic igt@gem_exec_suspend@basic-s0 igt@gem_exec_suspend@basic-s3 -igt@gem_exec_suspend@basic-s4-devices igt@gem_flink_basic@bad-flink igt@gem_flink_basic@bad-open igt@gem_flink_basic@basic -- 2.26.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/23] perf/core: Only copy-to-user after completely unlocking all locks, v3.
== Series Details ==
Series: series starting with [01/23] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/75668/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bfdbf3931f48 perf/core: Only copy-to-user after completely unlocking all locks,
v3.
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#17:
<4> [604.892540] 8264a558 (rcu_state.barrier_mutex){+.+.}, at:
rcu_barrier+0x23/0x190
-:106: WARNING:BAD_SIGN_OFF: Duplicate signature
#106:
Signed-off-by: Maarten Lankhorst
-:180: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#180: FILE: kernel/events/core.c:4998:
+__perf_read(struct perf_event *event, char __user *buf,
+ size_t count, u64 *values)
total: 0 errors, 2 warnings, 1 checks, 106 lines checked
ae1f1cda17bc Revert "drm/i915/gem: Drop relocation slowpath"
-:78: WARNING:LINE_SPACING: Missing a blank line after declarations
#78: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1628:
+ int err = __get_user(c, addr);
+ if (err)
total: 0 errors, 1 warnings, 0 checks, 257 lines checked
0650546c9515 drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
-:506: WARNING:LONG_LINE: line over 100 characters
#506: FILE: drivers/gpu/drm/i915/i915_gem.c:1341:
+ while ((obj = list_first_entry_or_null(&ww->obj_list, struct
drm_i915_gem_object, obj_link))) {
total: 0 errors, 1 warnings, 0 checks, 481 lines checked
91b84c36aeac drm/i915: Remove locking from i915_gem_object_prepare_read/write
db3ef6207fc6 drm/i915: Parse command buffer earlier in eb_relocate(slow)
9b2e3aa9640b Revert "drm/i915/gem: Split eb_vma into its own allocation"
d3c15b6fa06a drm/i915: Use per object locking in execbuf, v7.
d7aeab78a2e2 drm/i915: Use ww locking in intel_renderstate.
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
Convert to using ww-waiting, and make sure we always pin intel_context_state,
total: 0 errors, 1 warnings, 0 checks, 209 lines checked
cfb0d26c1f8e drm/i915: Add ww context handling to context_barrier_task
-:19: WARNING:LONG_LINE: line over 100 characters
#19: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:1099:
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
total: 0 errors, 1 warnings, 0 checks, 146 lines checked
7749cc342e6f drm/i915: Nuke arguments to eb_pin_engine
e6d6e2ddae25 drm/i915: Pin engine before pinning all objects, v3.
d8aa2d4a5f34 drm/i915: Rework intel_context pinning to do everything outside of
pin_mutex
-:125: CHECK:LINE_SPACING: Please don't use multiple blank lines
#125: FILE: drivers/gpu/drm/i915/gt/intel_context.c:176:
+
+
-:338: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#338: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:3180:
+ *vaddr = i915_gem_object_pin_map(ce->state->obj,
+
i915_coherent_map_type(ce->engine->i915) |
total: 0 errors, 0 warnings, 2 checks, 435 lines checked
ffb87f30e8e4 drm/i915: Make sure execbuffer always passes ww state to
i915_vma_pin.
-:95: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#95: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:593:
+ err = i915_vma_pin_ww(vma, &eb->ww,
entry->pad_to_size, entry->alignment,
-:203: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#203: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2223:
+* hsw should have this fixed, but bdw mucks it up again. */
total: 0 errors, 1 warnings, 1 checks, 827 lines checked
19816681a8b9 drm/i915: Convert i915_gem_object/client_blt.c to use ww locking
as well, v2.
e3058c9e38cd drm/i915: Kill last user of intel_context_create_request outside
of selftests
8fa1ddf4790a drm/i915: Convert i915_perf to ww locking as well
76f08941fb96 drm/i915: Dirty hack to fix selftests locking inversion
bfc4aab3b1a2 drm/i915/selftests: Fix locking inversion in lrc selftest.
09011eb630f6 drm/i915: Use ww pinning for intel_context_create_request()
fcf3a2fda97b drm/i915: Move i915_vma_lock in the selftests to avoid lock
inversion, v2.
b8b699f678f6 drm/i915: Add ww locking to vm_fault_gtt
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 91 lines checked
ef4b37bc4757 drm/i915: Add ww locking to pin_to_display_plane
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 129 lines checked
68e985f3b25a drm/i915: Ensure we hold the pin mutex
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 37 lines checked
___
I
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/9] drm/i915/gt: Mark up racy read of intel_ring.head
== Series Details ==
Series: series starting with [CI,1/9] drm/i915/gt: Mark up racy read of
intel_ring.head
URL : https://patchwork.freedesktop.org/series/75667/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8275 -> Patchwork_17252
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17252 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17252, 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_17252/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17252:
### IGT changes ###
Possible regressions
* igt@gem_exec_gttfill@basic:
- fi-ilk-650: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-ilk-650/igt@gem_exec_gttf...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17252/fi-ilk-650/igt@gem_exec_gttf...@basic.html
* igt@gem_tiled_blits@basic:
- fi-blb-e6850: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-blb-e6850/igt@gem_tiled_bl...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17252/fi-blb-e6850/igt@gem_tiled_bl...@basic.html
Known issues
Here are the changes found in Patchwork_17252 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-icl-guc: [PASS][5] -> [DMESG-FAIL][6] ([i915#656])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-icl-guc/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17252/fi-icl-guc/igt@i915_selftest@l...@execlists.html
Possible fixes
* {igt@gem_wait@busy@all}:
- fi-bwr-2160:[FAIL][7] ([i915#1604]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-bwr-2160/igt@gem_wait@b...@all.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17252/fi-bwr-2160/igt@gem_wait@b...@all.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-icl-dsi: [INCOMPLETE][9] ([i915#189]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17252/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [FAIL][11] ([i915#62]) -> [SKIP][12] ([fdo#109271])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8275/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17252/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1604]: https://gitlab.freedesktop.org/drm/intel/issues/1604
[i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
Participating hosts (52 -> 47)
--
Additional (1): fi-kbl-7560u
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8275 -> Patchwork_17252
CI-20190529: 20190529
CI_DRM_8275: f2a4da2bcd576d1b56aeb53600e8a0b710117a20 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5581: ab0620e555119ec55f12ba9ab9e6e9246d407648 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17252: c498c6b039e88f76f02b1b6d714e9d81c3bb4b18 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c498c6b039e8 drm/i915/gem: Bind the fence async for execbuf
27d347f131a9 drm/i915/gem: Asynchronous GTT unbinding
2538bbe3b0dd drm/i915/gem: Separate the ww_mutex walker into its own list
50f81cbd53ef drm/i915: Export a preallocate variant of i915_active_acquire()
390e4f1dba9b drm/i915/gem: Assign context id for async work
5383336232fb drm/i915/gem: Include PIN_GLOBAL prior to using
I915_DISPATCH_SECURE
78a5ccdb8c47 drm/i915/gem: Apply more mb() around clflush relocation paths
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17252/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support for YCBCR_BT2020
> -Original Message-
> From: Shankar, Uma
> Sent: Wednesday, April 8, 2020 7:24 PM
> To: Ville Syrjälä
> Cc: Kadiyala, Kishore ; intel-
> g...@lists.freedesktop.org; Nikula, Jani
> Subject: RE: [PATCH v3] drm/i915: Add Plane color encoding support for
> YCBCR_BT2020
>
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, April 8, 2020 7:08 PM
> > To: Shankar, Uma
> > Cc: Kadiyala, Kishore ;
> > intel-gfx@lists.freedesktop.org; Nikula, Jani
> > Subject: Re: [PATCH v3] drm/i915: Add Plane color encoding support for
> > YCBCR_BT2020
> >
> > On Wed, Apr 08, 2020 at 01:23:27PM +, Shankar, Uma wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Ville Syrjälä
> > > > Sent: Wednesday, April 8, 2020 6:17 PM
> > > > To: Kadiyala, Kishore
> > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > > > ; Nikula, Jani
> > > > Subject: Re: [PATCH v3] drm/i915: Add Plane color encoding support
> > > > for
> > > > YCBCR_BT2020
> > > >
> > > > On Wed, Apr 08, 2020 at 04:43:47PM +0530, Kishore Kadiyala wrote:
> > > > > Currently the plane property doesn't have support for
> > > > > YCBCR_BT2020, which enables the corresponding color conversion
> > > > > mode on
> > plane CSC.
> > > > > In ICL+ platforms , this property setting is confined only to
> > > > > HDR Planes as there is limitation in SDR Planes and while in GLK
> > > > > it set for all planes.
> > > > >
> > > > > V2: Enabling support for YCBCT_BT2020 for HDR planes on
> > > > > platforms GLK & ICL
> > > > >
> > > > > V3: Refined the condition check to handle GLK & ICL+ HDR planes
> > > > > Also added BT2020 handling in glk_plane_color_ctl.
> > > > >
> > > > > Cc: Ville Syrjala
> > > > > Cc: Uma Shankar
> > > > > Cc: Jani Nikula
> > > > > Signed-off-by: Kishore Kadiyala
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 12 +---
> > > > > drivers/gpu/drm/i915/display/intel_sprite.c | 17
> > > > > +++--
> > > > > 2 files changed, 24 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index 70ec301fe6e3..f2dfa61a49fa 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct
> > > > > intel_crtc_state
> > > > *crtc_state,
> > > > > plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > > > >
> > > > > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv,
> > > > > plane->id)) {
> > > > > - if (plane_state->hw.color_encoding ==
> > > > DRM_COLOR_YCBCR_BT709)
> > > > > + switch (plane_state->hw.color_encoding) {
> > > > > + case DRM_COLOR_YCBCR_BT709:
> > > > > plane_color_ctl |=
> > > > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > > > - else
> > > > > + break;
> > > > > + case DRM_COLOR_YCBCR_BT2020:
> > > > > + plane_color_ctl |=
> > > > > +
> > > > PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > > > > + break;
> > > > > + default:
> > > > > plane_color_ctl |=
> > > > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > > > -
> > > > > + }
> > > > > if (plane_state->hw.color_range ==
> > > > DRM_COLOR_YCBCR_FULL_RANGE)
> > > > > plane_color_ctl |=
> > > > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > > > > } else if (fb->format->is_yuv) { diff --git
> > > > > a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > > index deda351719db..237c4b951f02 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > > @@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct
> > > > > drm_i915_private
> > > > *dev_priv,
> > > > > struct intel_plane *plane;
> > > > > enum drm_plane_type plane_type;
> > > > > unsigned int supported_rotations;
> > > > > + unsigned int supported_csc;
> > > > > const u64 *modifiers;
> > > > > const u32 *formats;
> > > > > int num_formats;
> > > > > @@ -3105,9 +3106,21 @@ skl_universal_plane_create(struct
> > > > > drm_i915_private
> > > > *dev_priv,
> > > > > DRM_MODE_ROTATE_0,
> > > > > supported_rotations);
> > > > >
> > > > > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) |
> > > > > +BIT(DRM_COLOR_YCBCR_BT709);
> > > > > +
> > > > > + /*
> > > > > + * Setting the CSC BT2020 for all the planes in case of GLK
> > > > > + * While for ICL+ platforms it is set only for HDR planes 1
> through 3
> > > > > + * as there are issues seen with SDR planes
> > > >
> >
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote:
> > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > reconfiguring global resources).
> > > >
> > > > But in nonblocking mode userspace has then no idea this happened,
> > > > which can lead to spurious EBUSY calls, both:
> > > > - when that other CRTC is currently busy doing a page_flip the
> > > > ALLOW_MODESET commit can fail with an EBUSY
> > > > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > > > of the additional commit inserted by the kernel without userspace's
> > > > knowledge
> > > >
> > > > For blocking commits this isn't a problem, because everyone else will
> > > > just block until all the CRTC are reconfigured. Only thing userspace
> > > > can notice is the dropped frames without any reason for why frames got
> > > > dropped.
> > > >
> > > > Consensus is that we need new uapi to handle this properly, but no one
> > > > has any idea what exactly the new uapi should look like. As a stop-gap
> > > > plug this problem by demoting nonblocking commits which might cause
> > > > issues by including CRTCs not in the original request to blocking
> > > > commits.
> > > >
> > > > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > > > don't want to silently convert page flips into blocking plane updates
> > > > just because the driver is buggy.
> > > >
> > > > v3: Fix inverted WARN_ON (Pekka).
> > > >
> > > > References:
> > > > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > > > Bugzilla:
> > > > https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > > > Cc: Daniel Stone
> > > > Cc: Pekka Paalanen
> > > > Cc: sta...@vger.kernel.org
> > > > Reviewed-by: Daniel Stone
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > > {
> > > > struct drm_mode_config *config = &state->dev->mode_config;
> > > > - int ret;
> > > > + unsigned requested_crtc = 0;
> > > > + unsigned affected_crtc = 0;
> > > > + struct drm_crtc *crtc;
> > > > + struct drm_crtc_state *crtc_state;
> > > > + bool nonblocking = true;
> > > > + int ret, i;
> > > > +
> > > > + /*
> > > > + * For commits that allow modesets drivers can add other CRTCs to
> > > > the
> > > > + * atomic commit, e.g. when they need to reallocate global
> > > > resources.
> > > > + *
> > > > + * But when userspace also requests a nonblocking commit then
> > > > userspace
> > > > + * cannot know that the commit affects other CRTCs, which can
> > > > result in
> > > > + * spurious EBUSY failures. Until we have better uapi plug this by
> > > > + * demoting such commits to blocking mode.
> > > > + */
> > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > + requested_crtc |= drm_crtc_mask(crtc);
> > > >
> > > > ret = drm_atomic_check_only(state);
> > > > if (ret)
> > > > return ret;
> > > >
> > > > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > +
> > > > + if (affected_crtc != requested_crtc) {
> > > > + /* adding other CRTC is only allowed for modeset commits
> > > > */
> > > > + WARN_ON(!state->allow_modeset);
> > >
> > > Not sure that's really true. What if the driver needs to eg.
> > > redistribute FIFO space or something between the pipes? Or do we
> > > expect drivers to now examine state->allow_modeset to figure out
> > > if they're allowed to do certain things?
> >
> > Maybe we need more fine-grained flags here, but adding other states
> > (and blocking a commit flow) is exactly the uapi headaches this patch
> > tries to solve here. So if our driver currently adds crtc states to
> > reallocate fifo between pipes for an atomic flip then yes we're
> > breaking userspace. Well, everyone figured out by now that you get
> > random EBUSY and dropped frames for no apparent reason at all, and
> > work around it. But happy, they are not.
>
> I don't think we do this currently for the FIFO, but in theor
Re: [Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support for YCBCR_BT2020
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, April 8, 2020 7:08 PM
> To: Shankar, Uma
> Cc: Kadiyala, Kishore ;
> intel-gfx@lists.freedesktop.org;
> Nikula, Jani
> Subject: Re: [PATCH v3] drm/i915: Add Plane color encoding support for
> YCBCR_BT2020
>
> On Wed, Apr 08, 2020 at 01:23:27PM +, Shankar, Uma wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: Wednesday, April 8, 2020 6:17 PM
> > > To: Kadiyala, Kishore
> > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > > ; Nikula, Jani
> > > Subject: Re: [PATCH v3] drm/i915: Add Plane color encoding support
> > > for
> > > YCBCR_BT2020
> > >
> > > On Wed, Apr 08, 2020 at 04:43:47PM +0530, Kishore Kadiyala wrote:
> > > > Currently the plane property doesn't have support for
> > > > YCBCR_BT2020, which enables the corresponding color conversion mode on
> plane CSC.
> > > > In ICL+ platforms , this property setting is confined only to HDR
> > > > Planes as there is limitation in SDR Planes and while in GLK it
> > > > set for all planes.
> > > >
> > > > V2: Enabling support for YCBCT_BT2020 for HDR planes on
> > > > platforms GLK & ICL
> > > >
> > > > V3: Refined the condition check to handle GLK & ICL+ HDR planes
> > > > Also added BT2020 handling in glk_plane_color_ctl.
> > > >
> > > > Cc: Ville Syrjala
> > > > Cc: Uma Shankar
> > > > Cc: Jani Nikula
> > > > Signed-off-by: Kishore Kadiyala
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 12 +---
> > > > drivers/gpu/drm/i915/display/intel_sprite.c | 17
> > > > +++--
> > > > 2 files changed, 24 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index 70ec301fe6e3..f2dfa61a49fa 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct
> > > > intel_crtc_state
> > > *crtc_state,
> > > > plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > > >
> > > > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv,
> > > > plane->id)) {
> > > > - if (plane_state->hw.color_encoding ==
> > > DRM_COLOR_YCBCR_BT709)
> > > > + switch (plane_state->hw.color_encoding) {
> > > > + case DRM_COLOR_YCBCR_BT709:
> > > > plane_color_ctl |=
> > > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > > - else
> > > > + break;
> > > > + case DRM_COLOR_YCBCR_BT2020:
> > > > + plane_color_ctl |=
> > > > +
> > > PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > > > + break;
> > > > + default:
> > > > plane_color_ctl |=
> > > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > > -
> > > > + }
> > > > if (plane_state->hw.color_range ==
> > > DRM_COLOR_YCBCR_FULL_RANGE)
> > > > plane_color_ctl |=
> > > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > > > } else if (fb->format->is_yuv) { diff --git
> > > > a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > index deda351719db..237c4b951f02 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > @@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct
> > > > drm_i915_private
> > > *dev_priv,
> > > > struct intel_plane *plane;
> > > > enum drm_plane_type plane_type;
> > > > unsigned int supported_rotations;
> > > > + unsigned int supported_csc;
> > > > const u64 *modifiers;
> > > > const u32 *formats;
> > > > int num_formats;
> > > > @@ -3105,9 +3106,21 @@ skl_universal_plane_create(struct
> > > > drm_i915_private
> > > *dev_priv,
> > > >DRM_MODE_ROTATE_0,
> > > >supported_rotations);
> > > >
> > > > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) |
> > > > +BIT(DRM_COLOR_YCBCR_BT709);
> > > > +
> > > > + /*
> > > > +* Setting the CSC BT2020 for all the planes in case of GLK
> > > > +* While for ICL+ platforms it is set only for HDR planes 1
> > > > through 3
> > > > +* as there are issues seen with SDR planes
> > >
> > > What issues are those?
> >
> > There was an issue on some of the hardcoded matrix values used in SDR
> > planes, hence it would be good to not enable BT2020 conversion on SDR
> > planes in ICL+ till this gets resolved.
> > Reference WA: #220884772
> > "Incorrect plane CSC coefficients for sRGB to Bt2020 :
> > SDR planes PLANE_COLOR_CTL Plane CSC Mode 100b, RGB709 to RGB2020,
> > uses hardcoded R-Y coefficient of 0.75 instead of 0.625, resulting
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/9] drm/i915/gt: Mark up racy read of intel_ring.head
== Series Details ==
Series: series starting with [CI,1/9] drm/i915/gt: Mark up racy read of
intel_ring.head
URL : https://patchwork.freedesktop.org/series/75667/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
78a5ccdb8c47 drm/i915/gem: Apply more mb() around clflush relocation paths
-:24: WARNING:MEMORY_BARRIER: memory barrier without comment
#24: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1041:
+ mb();
-:41: WARNING:MEMORY_BARRIER: memory barrier without comment
#41: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1063:
+ mb();
-:52: WARNING:MEMORY_BARRIER: memory barrier without comment
#52: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1170:
+ mb();
total: 0 errors, 3 warnings, 0 checks, 36 lines checked
5383336232fb drm/i915/gem: Include PIN_GLOBAL prior to using
I915_DISPATCH_SECURE
390e4f1dba9b drm/i915/gem: Assign context id for async work
50f81cbd53ef drm/i915: Export a preallocate variant of i915_active_acquire()
2538bbe3b0dd drm/i915/gem: Separate the ww_mutex walker into its own list
-:92: WARNING:LONG_LINE: line over 100 characters
#92: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1642:
+ list_for_each_entry_safe_continue_reverse(unlock, en,
&eb->lock, lock_link) {
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible
side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+ n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+ n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible
side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+ n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
total: 0 errors, 1 warnings, 3 checks, 120 lines checked
27d347f131a9 drm/i915/gem: Asynchronous GTT unbinding
c498c6b039e8 drm/i915/gem: Bind the fence async for execbuf
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce drm scaling filter property (rev5)
== Series Details == Series: Introduce drm scaling filter property (rev5) URL : https://patchwork.freedesktop.org/series/73883/ State : failure == Summary == Applying: drm: Introduce plane and CRTC scaling filter properties error: corrupt patch at line 98 error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm: Introduce plane and CRTC scaling filter properties 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 mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support for YCBCR_BT2020
On Wed, Apr 08, 2020 at 01:23:27PM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, April 8, 2020 6:17 PM
> > To: Kadiyala, Kishore
> > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma ;
> > Nikula, Jani
> > Subject: Re: [PATCH v3] drm/i915: Add Plane color encoding support for
> > YCBCR_BT2020
> >
> > On Wed, Apr 08, 2020 at 04:43:47PM +0530, Kishore Kadiyala wrote:
> > > Currently the plane property doesn't have support for YCBCR_BT2020,
> > > which enables the corresponding color conversion mode on plane CSC.
> > > In ICL+ platforms , this property setting is confined only to HDR
> > > Planes as there is limitation in SDR Planes and while in GLK it set
> > > for all planes.
> > >
> > > V2: Enabling support for YCBCT_BT2020 for HDR planes on
> > > platforms GLK & ICL
> > >
> > > V3: Refined the condition check to handle GLK & ICL+ HDR planes
> > > Also added BT2020 handling in glk_plane_color_ctl.
> > >
> > > Cc: Ville Syrjala
> > > Cc: Uma Shankar
> > > Cc: Jani Nikula
> > > Signed-off-by: Kishore Kadiyala
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 12 +---
> > > drivers/gpu/drm/i915/display/intel_sprite.c | 17 +++--
> > > 2 files changed, 24 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 70ec301fe6e3..f2dfa61a49fa 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct
> > > intel_crtc_state
> > *crtc_state,
> > > plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > >
> > > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> > > - if (plane_state->hw.color_encoding ==
> > DRM_COLOR_YCBCR_BT709)
> > > + switch (plane_state->hw.color_encoding) {
> > > + case DRM_COLOR_YCBCR_BT709:
> > > plane_color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > - else
> > > + break;
> > > + case DRM_COLOR_YCBCR_BT2020:
> > > + plane_color_ctl |=
> > > +
> > PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > > + break;
> > > + default:
> > > plane_color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > -
> > > + }
> > > if (plane_state->hw.color_range ==
> > DRM_COLOR_YCBCR_FULL_RANGE)
> > > plane_color_ctl |=
> > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > > } else if (fb->format->is_yuv) {
> > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > index deda351719db..237c4b951f02 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > @@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct drm_i915_private
> > *dev_priv,
> > > struct intel_plane *plane;
> > > enum drm_plane_type plane_type;
> > > unsigned int supported_rotations;
> > > + unsigned int supported_csc;
> > > const u64 *modifiers;
> > > const u32 *formats;
> > > int num_formats;
> > > @@ -3105,9 +3106,21 @@ skl_universal_plane_create(struct drm_i915_private
> > *dev_priv,
> > > DRM_MODE_ROTATE_0,
> > > supported_rotations);
> > >
> > > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) |
> > > +BIT(DRM_COLOR_YCBCR_BT709);
> > > +
> > > + /*
> > > + * Setting the CSC BT2020 for all the planes in case of GLK
> > > + * While for ICL+ platforms it is set only for HDR planes 1 through 3
> > > + * as there are issues seen with SDR planes
> >
> > What issues are those?
>
> There was an issue on some of the hardcoded matrix values used in SDR planes,
> hence it would be good to not enable BT2020 conversion on SDR planes in ICL+
> till this gets resolved.
> Reference WA: #220884772
> "Incorrect plane CSC coefficients for sRGB to Bt2020 :
> SDR planes PLANE_COLOR_CTL Plane CSC Mode 100b, RGB709 to RGB2020,
> uses hardcoded R-Y coefficient of 0.75 instead of 0.625, resulting in
> incorrect BT2020
> color conversion. WA: Limit RGB709 to RGB2020 conversion to the HDR capable
> planes"
That only matters for RGB->RGB conversion, which has nothing to do with
this patch.
>
> @Kishore : Please add this as comment here.
>
> > > + */
> > > + if ((INTEL_GEN(dev_priv) == 10) || IS_GEMINILAKE(dev_priv))
> > > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> > > + else
> > > + if (icl_is_hdr_plane(dev_priv, plane_id))
> > > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> > > +
> > > drm_plane_create_color_properties(&plane->base,
> > > - BIT(DRM_COLOR_YCBCR_BT601) |
> > > - BIT(DRM
Re: [Intel-gfx] [PATCH v3 1/5] drm: Introduce plane and CRTC scaling filter properties
On Wed, Apr 08, 2020 at 03:17:27PM +0530, Bharadiya,Pankaj wrote:
> On Tue, Apr 07, 2020 at 08:28:02PM +0300, Ville Syrjälä wrote:
> > On Tue, Mar 31, 2020 at 12:08:53AM +0530, Pankaj Bharadiya wrote:
> > > Introduce per-plane and per-CRTC scaling filter properties to allow
> > > userspace to select the driver's default scaling filter or
> > > Nearest-neighbor(NN) filter for upscaling operations on CRTC and
> > > plane.
> > >
> > > Drivers can set up this property for a plane by calling
> > > drm_plane_create_scaling_filter() and for a CRTC by calling
> > > drm_crtc_create_scaling_filter().
> > >
> > > NN filter works by filling in the missing color values in the upscaled
> > > image with that of the coordinate-mapped nearest source pixel value.
> > >
> > > NN filter for integer multiple scaling can be particularly useful for
> > > for pixel art games that rely on sharp, blocky images to deliver their
> > > distinctive look.
> > >
> > > changes since v2:
> > > * Create per-plane and per-CRTC scaling filter property (Ville)
> > > changes since v1:
> > > * None
> > > changes since RFC:
> > > * Add separate properties for plane and CRTC (Ville)
> > >
> > > Signed-off-by: Pankaj Bharadiya
> > > ---
> > > drivers/gpu/drm/drm_atomic_uapi.c | 8
> > > drivers/gpu/drm/drm_crtc.c| 78 +++
> > > drivers/gpu/drm/drm_plane.c | 78 +++
> > > include/drm/drm_crtc.h| 16 +++
> > > include/drm/drm_plane.h | 21 +
> > > 5 files changed, 201 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > index a1e5e262bae2..ac7dabbf0bcf 100644
> > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > @@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct
> > > drm_crtc *crtc,
> > > return -EFAULT;
> > >
> > > set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> > > + } else if (property == crtc->scaling_filter_property) {
> > > + state->scaling_filter = val;
> > > } else if (crtc->funcs->atomic_set_property) {
> > > return crtc->funcs->atomic_set_property(crtc, state, property,
> > > val);
> > > } else {
> > > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > > else if (property == config->prop_out_fence_ptr)
> > > *val = 0;
> > > + else if (property == crtc->scaling_filter_property)
> >
> > Random side observation: Why do we have two different styles to naming
> > these things (prop_foo vs. foo_property)? Would be nice to unify this
> > one way or the other.
>
> Need to handle this separately.
>
> All per-plane props follow foo_property convention and we have mixed
> conventions for properties in struct drm_mode_config with majority being
> foo_property.
>
> >
> > > + *val = state->scaling_filter;
> > > else if (crtc->funcs->atomic_get_property)
> > > return crtc->funcs->atomic_get_property(crtc, state, property,
> > > val);
> > > else
> > > @@ -583,6 +587,8 @@ static int drm_atomic_plane_set_property(struct
> > > drm_plane *plane,
> > > sizeof(struct drm_rect),
> > > &replaced);
> > > return ret;
> > > + } else if (property == plane->scaling_filter_property) {
> > > + state->scaling_filter = val;
> > > } else if (plane->funcs->atomic_set_property) {
> > > return plane->funcs->atomic_set_property(plane, state,
> > > property, val);
> > > @@ -641,6 +647,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > > } else if (property == config->prop_fb_damage_clips) {
> > > *val = (state->fb_damage_clips) ?
> > > state->fb_damage_clips->base.id : 0;
> > > + } else if (property == plane->scaling_filter_property) {
> > > + *val = state->scaling_filter;
> > > } else if (plane->funcs->atomic_get_property) {
> > > return plane->funcs->atomic_get_property(plane, state,
> > > property, val);
> > > } else {
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 4936e1080e41..95502c88966b 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -748,3 +748,81 @@ int drm_mode_crtc_set_obj_prop(struct
> > > drm_mode_object *obj,
> > >
> > > return ret;
> > > }
> > > +
> > > +/**
> > > + * DOC: CRTC scaling filter property
> > > + *
> > > + * SCALING_FILTER:
> > > + *
> > > + * Indicates scaling filter to be used for CRTC scaler
> > > + *
> > > + * The value of this property can be one of the following:
> > > + * Default:
> > > + * Driver's default scaling filter
> > > + * Nearest Neighbor:
> > > + * Nearest Neig
Re: [Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support for YCBCR_BT2020
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, April 8, 2020 6:17 PM
> > To: Kadiyala, Kishore
> > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > ; Nikula, Jani
> > Subject: Re: [PATCH v3] drm/i915: Add Plane color encoding support for
> > YCBCR_BT2020
> >
> > On Wed, Apr 08, 2020 at 04:43:47PM +0530, Kishore Kadiyala wrote:
> > > Currently the plane property doesn't have support for YCBCR_BT2020,
> > > which enables the corresponding color conversion mode on plane CSC.
> > > In ICL+ platforms , this property setting is confined only to HDR
> > > Planes as there is limitation in SDR Planes and while in GLK it set
> > > for all planes.
> > >
> > > V2: Enabling support for YCBCT_BT2020 for HDR planes on
> > > platforms GLK & ICL
> > >
> > > V3: Refined the condition check to handle GLK & ICL+ HDR planes
> > > Also added BT2020 handling in glk_plane_color_ctl.
> > >
> > > Cc: Ville Syrjala
> > > Cc: Uma Shankar
> > > Cc: Jani Nikula
> > > Signed-off-by: Kishore Kadiyala
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 12 +---
> > > drivers/gpu/drm/i915/display/intel_sprite.c | 17 +++--
> > > 2 files changed, 24 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 70ec301fe6e3..f2dfa61a49fa 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct
> > > intel_crtc_state
> > *crtc_state,
> > > plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > >
> > > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> > > - if (plane_state->hw.color_encoding ==
> > DRM_COLOR_YCBCR_BT709)
> > > + switch (plane_state->hw.color_encoding) {
> > > + case DRM_COLOR_YCBCR_BT709:
> > > plane_color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > - else
> > > + break;
> > > + case DRM_COLOR_YCBCR_BT2020:
> > > + plane_color_ctl |=
> > > +
> > PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > > + break;
> > > + default:
> > > plane_color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > -
> > > + }
> > > if (plane_state->hw.color_range ==
> > DRM_COLOR_YCBCR_FULL_RANGE)
> > > plane_color_ctl |=
> > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > > } else if (fb->format->is_yuv) {
> > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > index deda351719db..237c4b951f02 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > @@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct
> > > drm_i915_private
> > *dev_priv,
> > > struct intel_plane *plane;
> > > enum drm_plane_type plane_type;
> > > unsigned int supported_rotations;
> > > + unsigned int supported_csc;
> > > const u64 *modifiers;
> > > const u32 *formats;
> > > int num_formats;
> > > @@ -3105,9 +3106,21 @@ skl_universal_plane_create(struct
> > > drm_i915_private
> > *dev_priv,
> > > DRM_MODE_ROTATE_0,
> > > supported_rotations);
> > >
> > > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) |
> > > +BIT(DRM_COLOR_YCBCR_BT709);
> > > +
> > > + /*
> > > + * Setting the CSC BT2020 for all the planes in case of GLK
> > > + * While for ICL+ platforms it is set only for HDR planes 1 through 3
> > > + * as there are issues seen with SDR planes
> >
> > What issues are those?
>
> There was an issue on some of the hardcoded matrix values used in SDR planes,
> hence it would be good to not enable BT2020 conversion on SDR planes in ICL+
> till
> this gets resolved.
> Reference WA: #220884772
> "Incorrect plane CSC coefficients for sRGB to Bt2020 :
> SDR planes PLANE_COLOR_CTL Plane CSC Mode 100b, RGB709 to RGB2020, uses
> hardcoded R-Y coefficient of 0.75 instead of 0.625, resulting in incorrect
> BT2020
> color conversion. WA: Limit RGB709 to RGB2020 conversion to the HDR capable
> planes"
Also this is applicable only for ICL, so we can enable this from gen12 onwards.
> @Kishore : Please add this as comment here.
>
> > > + */
> > > + if ((INTEL_GEN(dev_priv) == 10) || IS_GEMINILAKE(dev_priv))
> > > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> > > + else
> > > + if (icl_is_hdr_plane(dev_priv, plane_id))
> > > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> > > +
> > > drm_plane_create_color_properties(&plane->base,
> > > - BIT(DRM_COLOR_YCBCR_BT601) |
> > > - BIT(DRM_COLOR_YCBCR_BT709),
> > > +
Re: [Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support for YCBCR_BT2020
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, April 8, 2020 6:17 PM
> To: Kadiyala, Kishore
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma ;
> Nikula, Jani
> Subject: Re: [PATCH v3] drm/i915: Add Plane color encoding support for
> YCBCR_BT2020
>
> On Wed, Apr 08, 2020 at 04:43:47PM +0530, Kishore Kadiyala wrote:
> > Currently the plane property doesn't have support for YCBCR_BT2020,
> > which enables the corresponding color conversion mode on plane CSC.
> > In ICL+ platforms , this property setting is confined only to HDR
> > Planes as there is limitation in SDR Planes and while in GLK it set
> > for all planes.
> >
> > V2: Enabling support for YCBCT_BT2020 for HDR planes on
> > platforms GLK & ICL
> >
> > V3: Refined the condition check to handle GLK & ICL+ HDR planes
> > Also added BT2020 handling in glk_plane_color_ctl.
> >
> > Cc: Ville Syrjala
> > Cc: Uma Shankar
> > Cc: Jani Nikula
> > Signed-off-by: Kishore Kadiyala
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 12 +---
> > drivers/gpu/drm/i915/display/intel_sprite.c | 17 +++--
> > 2 files changed, 24 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 70ec301fe6e3..f2dfa61a49fa 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct
> > intel_crtc_state
> *crtc_state,
> > plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> >
> > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> > - if (plane_state->hw.color_encoding ==
> DRM_COLOR_YCBCR_BT709)
> > + switch (plane_state->hw.color_encoding) {
> > + case DRM_COLOR_YCBCR_BT709:
> > plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > - else
> > + break;
> > + case DRM_COLOR_YCBCR_BT2020:
> > + plane_color_ctl |=
> > +
> PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > + break;
> > + default:
> > plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > -
> > + }
> > if (plane_state->hw.color_range ==
> DRM_COLOR_YCBCR_FULL_RANGE)
> > plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > } else if (fb->format->is_yuv) {
> > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > index deda351719db..237c4b951f02 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > @@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> > struct intel_plane *plane;
> > enum drm_plane_type plane_type;
> > unsigned int supported_rotations;
> > + unsigned int supported_csc;
> > const u64 *modifiers;
> > const u32 *formats;
> > int num_formats;
> > @@ -3105,9 +3106,21 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> >DRM_MODE_ROTATE_0,
> >supported_rotations);
> >
> > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) |
> > +BIT(DRM_COLOR_YCBCR_BT709);
> > +
> > + /*
> > +* Setting the CSC BT2020 for all the planes in case of GLK
> > +* While for ICL+ platforms it is set only for HDR planes 1 through 3
> > +* as there are issues seen with SDR planes
>
> What issues are those?
There was an issue on some of the hardcoded matrix values used in SDR planes,
hence it would be good to not enable BT2020 conversion on SDR planes in ICL+
till this gets resolved.
Reference WA: #220884772
"Incorrect plane CSC coefficients for sRGB to Bt2020 :
SDR planes PLANE_COLOR_CTL Plane CSC Mode 100b, RGB709 to RGB2020,
uses hardcoded R-Y coefficient of 0.75 instead of 0.625, resulting in incorrect
BT2020
color conversion. WA: Limit RGB709 to RGB2020 conversion to the HDR capable
planes"
@Kishore : Please add this as comment here.
> > +*/
> > + if ((INTEL_GEN(dev_priv) == 10) || IS_GEMINILAKE(dev_priv))
> > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> > + else
> > + if (icl_is_hdr_plane(dev_priv, plane_id))
> > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> > +
> > drm_plane_create_color_properties(&plane->base,
> > - BIT(DRM_COLOR_YCBCR_BT601) |
> > - BIT(DRM_COLOR_YCBCR_BT709),
> > + supported_csc,
> >
> BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
> > BIT(DRM_COLOR_YCBCR_FULL_RANGE),
> > DRM_COLOR_YCBCR_BT709,
> > --
> > 2.17.1
>
> --
> Ville Syrjälä
[Intel-gfx] ✓ Fi.CI.BAT: success for Adding YUV444 packed format support for skl+ (rev5)
== Series Details == Series: Adding YUV444 packed format support for skl+ (rev5) URL : https://patchwork.freedesktop.org/series/73020/ State : success == Summary == CI Bug Log - changes from CI_DRM_8269 -> Patchwork_17241 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/index.html Known issues Here are the changes found in Patchwork_17241 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-hsw-4770:[PASS][1] -> [SKIP][2] ([fdo#109271]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@execlists: - fi-icl-dsi: [PASS][3] -> [INCOMPLETE][4] ([i915#656]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-icl-dsi/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-icl-dsi/igt@i915_selftest@l...@execlists.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [DMESG-FAIL][5] ([i915#62] / [i915#95]) -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92]) -> [DMESG-WARN][8] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][10] ([i915#62] / [i915#92]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (53 -> 47) -- Additional (1): fi-kbl-r Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * IGT: IGT_5577 -> IGTPW_4428 * Linux: CI_DRM_8269 -> Patchwork_17241 CI-20190529: 20190529 CI_DRM_8269: 301d0427e2e3108839bf6c36f58dd0b2b5258c25 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_4428: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4428/index.html IGT_5577: 7ee7e86fd79e4dbb6300ef4c23e50cb699216ae2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17241: 6c533ea6ac21d40eeb4ac157b771579e9bc19b9b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6c533ea6ac21 drm/i915: Adding YUV444 packed format support for skl+ (V15) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check to see if the FPU is available before using it
On Sat, Mar 28, 2020 at 1:59 AM Chris Wilson wrote: > > Quoting Jason A. Donenfeld (2020-03-28 00:04:22) > > It's not safe to just grab the FPU willy nilly without first checking to > > see if it's available. This patch adds the usual call to may_use_simd() > > and falls back to boring memcpy if it's not available. > > These instructions do not use the fpu, nor are these registers aliased > over the fpu stack. This description and the may_use_simd() do not > look like they express the right granularity as to which simd state are > included Most of the time when discussing vector instructions in the kernel with x86, "FPU" is used to denote the whole shebang, because of similar XSAVE semantics and requirements with actual floating point instructions and SIMD instructions. So when I say "grab the FPU", I'm really referring to the act of messing with any registers that aren't saved and restored by default during context switch and need the explicit marking for XSAVE to come in -- the kernel_fpu_begin/end calls that you already have. With regards to the granularity here, you are in fact touching xmm registers. That means you need kernel_fpu_begin/end, which you correctly have. However, it also means that before using those, you should check to see if that's okay by using the may_use_simd() instruction. Now you may claim that at the moment may_use_simd()-->irq_fpu_usable()-->(!in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle()) always holds true, and you're a keen follower of the (recently changed) kernel fpu x86 semantics in case those conditions change, and that your driver is so strictly written that you know exactly the context this fancy memcpy will run in, always, and you'll never deviate from it, and therefore it's okay to depart from the rules and omit the check and safe fallback code. But c'mon - i915 is complex, and mixed context bugs abound, and the rules for using those registers might in fact change without you noticing. So why not apply this to have a safe fallback for when the numerous assumptions no longer hold? (If you're extra worried I suppose you could make it a `if (WARN_ON(!may_use_simd()))` instead or something, but that seems like a bit much.) > Look at caller, return the error and let them decide if they can avoid > the read from WC, which quite often they can. And no, this is not done > from interrupt context, we would be crucified if we did. Ahh, now, reading this comment here I realize maybe I've misunderstood you. Do you mean to say that checking for may_use_simd() is a thing that you'd like to do after all, but you don't like it falling back to slow memcpy. Instead, you'd like for the code to return an error value, and then caller can just optionally skip the memcpy under some complicated driver circumstances? Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/3] drm/i915/perf: prepare driver to receive multiple ctx handles
On 07/04/2020 19:22, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-07 13:35:39)
-static struct intel_context *oa_context(struct i915_perf_stream *stream)
-{
- return stream->pinned_ctx ?: stream->engine->kernel_context;
-}
Idle thought: create a
stream->context = intel_context_create(stream->engine);
so I can stop worrying about the kernel_context. (What's the cost of one
more context, heh?)
-Chris
Bah... Now I need to create a timeline. Who's timeline?
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/i915_pm_rc6_residency: Show where the time is spent
Sometimes the bg_load only wakes up once or twice in 3s. That's
just unbelievable, so include some measurements to see how long the
load spends in submission & waiting.
Signed-off-by: Chris Wilson
---
tests/i915/i915_pm_rc6_residency.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/tests/i915/i915_pm_rc6_residency.c
b/tests/i915/i915_pm_rc6_residency.c
index cd1a6c8d6..15efba186 100644
--- a/tests/i915/i915_pm_rc6_residency.c
+++ b/tests/i915/i915_pm_rc6_residency.c
@@ -304,11 +304,13 @@ static void bg_load(int i915, unsigned int flags,
unsigned long *ctl)
sigaction(SIGINT, &act, NULL);
do {
+ uint64_t submit, wait, elapsed;
struct timespec tv = {};
igt_nsec_elapsed(&tv);
gem_execbuf(i915, &execbuf);
+ submit = igt_nsec_elapsed(&tv);
if (flags & WAITBOOST) {
gem_sync(i915, obj.handle);
if (flags & ONCE)
@@ -317,6 +319,7 @@ static void bg_load(int i915, unsigned int flags, unsigned
long *ctl)
while (gem_bo_busy(i915, obj.handle))
usleep(0);
}
+ wait = igt_nsec_elapsed(&tv);
ctl[1]++;
/*
@@ -330,8 +333,15 @@ static void bg_load(int i915, unsigned int flags, unsigned
long *ctl)
if (!gem_has_execlists(i915))
igt_drop_caches_set(i915, DROP_IDLE);
+ elapsed = igt_nsec_elapsed(&tv);
+ igt_info("Pulse took %.3fms (submit %.1fus, wait %.1fus, idle
%.1fus)\n",
+1e-6 * elapsed,
+1e-3 * submit,
+1e-3 * (wait - submit),
+1e-3 * (elapsed - wait));
+
/* aim for ~1% busy */
- usleep(min(igt_nsec_elapsed(&tv) / 10, 50 * 1000));
+ usleep(min(elapsed / 10, 50 * 1000));
} while (!READ_ONCE(*ctl));
}
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 1/2] drm/i915: remove broken i915_sseu_status interface
On 08/04/2020 14:55, Andi Shyti wrote: Hi Tvrtko, I start by saying that this patch was mainly sent to kickstart a discussion about cleanups required in debugfs and how debugfs can be inconsistent and how much it looks to me that we are relying on its current state. The i915_sseu_status is broken and the tests on this interface are disabled. There is no reason to drag it along. Not saying we need it, but can you say how it is broken? well tests in igt are failing because we don't get the results we expect, I don't know where it is actually broken but the igt test looks straight forward to me. I assume (with some hints I received, though) that the sseu reads are inconsistent. Andi I think it's broken because we're reading an acknowledgement registers. These registers seems to be populated only after a context is run. If you read it before a context is run after coming out of power management, there is no request to acknowledge and you get 0 values. -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/phy-compliance
Hey, Here's a pull request to pull in the DP PHY Compliance series. It's based on top of drm/drm-next, and contains all patches for core, amd and i915. :) Cheers, Maarten topic/phy-compliance-2020-04-08: Topic pull request for topic/phy-compliance: - Standardize DP_PHY_TEST_PATTERN name. - Add support for setting/getting test pattern from sink. - Implement DP PHY compliance to i915. The following changes since commit 12ab316ced2c5f32ced0e6300a054db644b5444a: Merge tag 'amd-drm-next-5.7-2020-04-01' of git://people.freedesktop.org/~agd5f/linux into drm-next (2020-04-08 09:34:27 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/topic/phy-compliance-2020-04-08 for you to fetch changes up to 8cdf727119289db3a98835662eb28e1c5ad835f1: drm/i915/dp: Program vswing, pre-emphasis, test-pattern (2020-04-08 14:41:09 +0200) Topic pull request for topic/phy-compliance: - Standardize DP_PHY_TEST_PATTERN name. - Add support for setting/getting test pattern from sink. - Implement DP PHY compliance to i915. Animesh Manna (7): drm/amd/display: Align macro name as per DP spec drm/dp: get/set phy compliance pattern drm/i915/dp: Made intel_dp_adjust_train() non-static drm/i915/dp: Preparation for DP phy compliance auto test drm/i915/dp: Add debugfs entry for DP phy compliance drm/i915/dp: Register definition for DP compliance register drm/i915/dp: Program vswing, pre-emphasis, test-pattern drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- drivers/gpu/drm/drm_dp_helper.c| 94 +++ .../gpu/drm/i915/display/intel_display_debugfs.c | 12 +- drivers/gpu/drm/i915/display/intel_display_types.h | 1 + drivers/gpu/drm/i915/display/intel_dp.c| 171 + drivers/gpu/drm/i915/display/intel_dp.h| 1 + .../gpu/drm/i915/display/intel_dp_link_training.c | 9 +- .../gpu/drm/i915/display/intel_dp_link_training.h | 4 + drivers/gpu/drm/i915/i915_reg.h| 18 +++ include/drm/drm_dp_helper.h| 33 +++- 10 files changed, 337 insertions(+), 8 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support for YCBCR_BT2020
On Wed, Apr 08, 2020 at 04:43:47PM +0530, Kishore Kadiyala wrote:
> Currently the plane property doesn't have support for YCBCR_BT2020,
> which enables the corresponding color conversion mode on plane CSC.
> In ICL+ platforms , this property setting is confined only to HDR
> Planes as there is limitation in SDR Planes and while in GLK it
> set for all planes.
>
> V2: Enabling support for YCBCT_BT2020 for HDR planes on
> platforms GLK & ICL
>
> V3: Refined the condition check to handle GLK & ICL+ HDR planes
> Also added BT2020 handling in glk_plane_color_ctl.
>
> Cc: Ville Syrjala
> Cc: Uma Shankar
> Cc: Jani Nikula
> Signed-off-by: Kishore Kadiyala
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 12 +---
> drivers/gpu/drm/i915/display/intel_sprite.c | 17 +++--
> 2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 70ec301fe6e3..f2dfa61a49fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
> *crtc_state,
> plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
>
> if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> - if (plane_state->hw.color_encoding == DRM_COLOR_YCBCR_BT709)
> + switch (plane_state->hw.color_encoding) {
> + case DRM_COLOR_YCBCR_BT709:
> plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> - else
> + break;
> + case DRM_COLOR_YCBCR_BT2020:
> + plane_color_ctl |=
> + PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> + break;
> + default:
> plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> -
> + }
> if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
> plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> } else if (fb->format->is_yuv) {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index deda351719db..237c4b951f02 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> struct intel_plane *plane;
> enum drm_plane_type plane_type;
> unsigned int supported_rotations;
> + unsigned int supported_csc;
> const u64 *modifiers;
> const u32 *formats;
> int num_formats;
> @@ -3105,9 +3106,21 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> DRM_MODE_ROTATE_0,
> supported_rotations);
>
> + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | BIT(DRM_COLOR_YCBCR_BT709);
> +
> + /*
> + * Setting the CSC BT2020 for all the planes in case of GLK
> + * While for ICL+ platforms it is set only for HDR planes 1 through 3
> + * as there are issues seen with SDR planes
What issues are those?
> + */
> + if ((INTEL_GEN(dev_priv) == 10) || IS_GEMINILAKE(dev_priv))
> + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> + else
> + if (icl_is_hdr_plane(dev_priv, plane_id))
> + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> +
> drm_plane_create_color_properties(&plane->base,
> - BIT(DRM_COLOR_YCBCR_BT601) |
> - BIT(DRM_COLOR_YCBCR_BT709),
> + supported_csc,
> BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
> BIT(DRM_COLOR_YCBCR_FULL_RANGE),
> DRM_COLOR_YCBCR_BT709,
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Add Plane color encoding support for YCBCR_BT2020
Currently the plane property doesn't have support for YCBCR_BT2020,
which enables the corresponding color conversion mode on plane CSC.
In ICL+ platforms , this property setting is confined only to HDR
Planes as there is limitation in SDR Planes and while in GLK it
set for all planes.
V2: Enabling support for YCBCT_BT2020 for HDR planes on
platforms GLK & ICL
V3: Refined the condition check to handle GLK & ICL+ HDR planes
Also added BT2020 handling in glk_plane_color_ctl.
V4: Combine If-else into single If
Cc: Ville Syrjala
Cc: Uma Shankar
Cc: Jani Nikula
Signed-off-by: Kishore Kadiyala
---
drivers/gpu/drm/i915/display/intel_display.c | 12 +---
drivers/gpu/drm/i915/display/intel_sprite.c | 15 +--
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 70ec301fe6e3..f2dfa61a49fa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
- if (plane_state->hw.color_encoding == DRM_COLOR_YCBCR_BT709)
+ switch (plane_state->hw.color_encoding) {
+ case DRM_COLOR_YCBCR_BT709:
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
- else
+ break;
+ case DRM_COLOR_YCBCR_BT2020:
+ plane_color_ctl |=
+ PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
+ break;
+ default:
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
-
+ }
if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
plane_color_ctl |=
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
} else if (fb->format->is_yuv) {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index deda351719db..fe2ca3e6e026 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
struct intel_plane *plane;
enum drm_plane_type plane_type;
unsigned int supported_rotations;
+ unsigned int supported_csc;
const u64 *modifiers;
const u32 *formats;
int num_formats;
@@ -3105,9 +3106,19 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
DRM_MODE_ROTATE_0,
supported_rotations);
+ supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | BIT(DRM_COLOR_YCBCR_BT709);
+
+ /*
+* Setting the CSC BT2020 for all the planes in case of GLK
+* While for ICL+ platforms it is set only for HDR planes 1 through 3
+* as there are issues seen with SDR planes
+*/
+ if (IS_GEN(dev_priv, 10) || IS_GEMINILAKE(dev_priv) ||
+ icl_is_hdr_plane(dev_priv, plane_id))
+ supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
+
drm_plane_create_color_properties(&plane->base,
- BIT(DRM_COLOR_YCBCR_BT601) |
- BIT(DRM_COLOR_YCBCR_BT709),
+ supported_csc,
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
BIT(DRM_COLOR_YCBCR_FULL_RANGE),
DRM_COLOR_YCBCR_BT709,
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Mark up racy check of breadcrumb irq enabled
== Series Details == Series: drm/i915/gt: Mark up racy check of breadcrumb irq enabled URL : https://patchwork.freedesktop.org/series/75663/ State : success == Summary == CI Bug Log - changes from CI_DRM_8274 -> Patchwork_17250 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/index.html Known issues Here are the changes found in Patchwork_17250 that come from known issues: ### IGT changes ### Issues hit * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6770hq: [PASS][1] -> [SKIP][2] ([fdo#109271]) +24 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html Possible fixes * igt@i915_pm_rpm@basic-rte: - fi-hsw-4770:[SKIP][3] ([fdo#109271]) -> [PASS][4] +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8274/fi-hsw-4770/igt@i915_pm_...@basic-rte.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/fi-hsw-4770/igt@i915_pm_...@basic-rte.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 Participating hosts (51 -> 47) -- Additional (1): fi-kbl-7560u Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8274 -> Patchwork_17250 CI-20190529: 20190529 CI_DRM_8274: 860acd37e552def563b63ac3f77ad002b58fada0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5580: fb488389a7a263b649361ec9c29e8b3b69851122 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17250: 3fc532718c8a0bba71f95c542817b955487663d2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3fc532718c8a drm/i915/gt: Mark up racy check of breadcrumb irq enabled == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17250/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/44] devm_drm_dev_alloc, no more drmm_add_final_kfree
On Wed, Apr 08, 2020 at 10:08:17AM +0200, Sam Ravnborg wrote: > Hi Daniel. > > Made specific reply to several patches. > > This bunch: > > drm/st7735r: Use devm_drm_dev_alloc > > drm/st7586: Use devm_drm_dev_alloc > > drm/repaper: Use devm_drm_dev_alloc > > drm/mi0283qt: Use devm_drm_dev_alloc > > drm/ili9486: Use devm_drm_dev_alloc > > drm/ili9341: Use devm_drm_dev_alloc > > drm/ili9225: Use devm_drm_dev_alloc > > drm/hx8357d: Use devm_drm_dev_alloc > > drm/gm12u320: Use devm_drm_dev_alloc > > drm/gm12u320: Don't use drm_device->dev_private > > are all: > Acked-by: Sam Ravnborg > > I will take a look at patch 44 later today. > I steered away from the vgem, i915 stuff on purpose. > I leave that to more competent persons. Yeah I think next round I'll leave out the vkms, vgem and i915-selftest, since that's a bigger discussion. But hopefully I can land the devm_drm_dev_alloc and many of the more basic conversions in here soonish. Thanks a lot for looking through this all. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/44] drm/v3d: Delete v3d_dev->pdev
On Wed, Apr 08, 2020 at 09:27:01AM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Fri, Apr 03, 2020 at 03:57:58PM +0200, Daniel Vetter wrote:
> > We already have it in v3d_dev->drm.dev with zero additional pointer
> > chasing. Personally I don't like duplicated pointers like this
> > because:
> > - reviewers need to check whether the pointer is for the same or
> > different objects if there's multiple
> > - compilers have an easier time too
> >
> > To avoid having to pull in some big headers I implemented the casting
> > function as a macro instead of a static inline.
> Hmm...
>
> > Typechecking thanks to
> > container_of still assured.
> >
> > But also a bit a bikeshed, so feel free to ignore.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Eric Anholt
>
> This and patch 13 has same subject - confusing.
dev != pdev
But yeah I agree it's a nice trick I'm pulling here :-)
Cheers, Daniel
>
> Sam
>
> > ---
> > drivers/gpu/drm/v3d/v3d_drv.c | 3 +--
> > drivers/gpu/drm/v3d/v3d_drv.h | 3 ++-
> > drivers/gpu/drm/v3d/v3d_irq.c | 8 +---
> > 3 files changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
> > index 37cb880f2826..82a7dfdd14c2 100644
> > --- a/drivers/gpu/drm/v3d/v3d_drv.c
> > +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> > @@ -235,7 +235,7 @@ static int
> > map_regs(struct v3d_dev *v3d, void __iomem **regs, const char *name)
> > {
> > struct resource *res =
> > - platform_get_resource_byname(v3d->pdev, IORESOURCE_MEM, name);
> > + platform_get_resource_byname(v3d_to_pdev(v3d), IORESOURCE_MEM,
> > name);
> >
> > *regs = devm_ioremap_resource(v3d->drm.dev, res);
> > return PTR_ERR_OR_ZERO(*regs);
> > @@ -255,7 +255,6 @@ static int v3d_platform_drm_probe(struct
> > platform_device *pdev)
> > if (IS_ERR(v3d))
> > return PTR_ERR(v3d);
> >
> > - v3d->pdev = pdev;
> > drm = &v3d->drm;
> >
> > platform_set_drvdata(pdev, drm);
> > diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
> > index 4d2d1f2fe1af..935f23b524b2 100644
> > --- a/drivers/gpu/drm/v3d/v3d_drv.h
> > +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> > @@ -46,7 +46,6 @@ struct v3d_dev {
> > int ver;
> > bool single_irq_line;
> >
> > - struct platform_device *pdev;
> > void __iomem *hub_regs;
> > void __iomem *core_regs[3];
> > void __iomem *bridge_regs;
> > @@ -128,6 +127,8 @@ v3d_has_csd(struct v3d_dev *v3d)
> > return v3d->ver >= 41;
> > }
> >
> > +#define v3d_to_pdev(v3d) to_platform_device(v3d->drm.dev)
> > +
> > /* The per-fd struct, which tracks the MMU mappings. */
> > struct v3d_file_priv {
> > struct v3d_dev *v3d;
> > diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
> > index f4ce6d057c90..51b65263c657 100644
> > --- a/drivers/gpu/drm/v3d/v3d_irq.c
> > +++ b/drivers/gpu/drm/v3d/v3d_irq.c
> > @@ -217,7 +217,7 @@ v3d_irq_init(struct v3d_dev *v3d)
> > V3D_CORE_WRITE(core, V3D_CTL_INT_CLR, V3D_CORE_IRQS);
> > V3D_WRITE(V3D_HUB_INT_CLR, V3D_HUB_IRQS);
> >
> > - irq1 = platform_get_irq(v3d->pdev, 1);
> > + irq1 = platform_get_irq(v3d_to_pdev(v3d), 1);
> > if (irq1 == -EPROBE_DEFER)
> > return irq1;
> > if (irq1 > 0) {
> > @@ -226,7 +226,8 @@ v3d_irq_init(struct v3d_dev *v3d)
> >"v3d_core0", v3d);
> > if (ret)
> > goto fail;
> > - ret = devm_request_irq(v3d->drm.dev,
> > platform_get_irq(v3d->pdev, 0),
> > + ret = devm_request_irq(v3d->drm.dev,
> > + platform_get_irq(v3d_to_pdev(v3d), 0),
> >v3d_hub_irq, IRQF_SHARED,
> >"v3d_hub", v3d);
> > if (ret)
> > @@ -234,7 +235,8 @@ v3d_irq_init(struct v3d_dev *v3d)
> > } else {
> > v3d->single_irq_line = true;
> >
> > - ret = devm_request_irq(v3d->drm.dev,
> > platform_get_irq(v3d->pdev, 0),
> > + ret = devm_request_irq(v3d->drm.dev,
> > + platform_get_irq(v3d_to_pdev(v3d), 0),
> >v3d_irq, IRQF_SHARED,
> >"v3d", v3d);
> > if (ret)
> > --
> > 2.25.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/44] drm: Add devm_drm_dev_alloc macro
On Wed, Apr 08, 2020 at 08:57:14AM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> Finally managed to dive into this..
>
> Maybe I need more coffee, it is still morning here.
> But alas this patch triggered a few comments.
>
> Sam
>
> On Fri, Apr 03, 2020 at 03:57:46PM +0200, Daniel Vetter wrote:
> > The kerneldoc is only added for this new function. Existing kerneldoc
> > and examples will be udated at the very end, since once all drivers
> > are converted over to devm_drm_dev_alloc we can unexport a lot of
> > interim functions and make the documentation for driver authors a lot
> > cleaner and less confusing. There will be only one true way to
> > initialize a drm_device at the end of this, which is going to be
> > devm_drm_dev_alloc.
>
> This changelog entry does a poor job describing what the purpose of this
> change is.
> Try to read it outside context.
Something like:
Add a new macro helper to combine the usual init sequence in drivers,
consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree
triplet. This allows us to remove the rather unsightly
drmm_add_final_kfree from all currently merged drivers.
This good enough, as an intro paragraph?
>
>
> >
> > Cc: Paul Kocialkowski
> > Cc: Laurent Pinchart
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 23 +++
> > include/drm/drm_drv.h | 33 +
> > 2 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 1bb4f636b83c..9e60b784b3ac 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -739,6 +739,29 @@ int devm_drm_dev_init(struct device *parent,
> > }
> > EXPORT_SYMBOL(devm_drm_dev_init);
> >
> > +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver
> > *driver,
> > + size_t size, size_t offset)
> > +{
> > + void *container;
> > + struct drm_device *drm;
> > + int ret;
> > +
> > + container = kzalloc(size, GFP_KERNEL);
> > + if (!container)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + drm = container + offset;
> > + ret = devm_drm_dev_init(parent, drm, driver);
> > + if (ret) {
> > + kfree(container);
> > + return ERR_PTR(ret);
> > + }
> > + drmm_add_final_kfree(drm, container);
> > +
> > + return container;
> > +}
> > +EXPORT_SYMBOL(__devm_drm_dev_alloc);
> > +
> > /**
> > * drm_dev_alloc - Allocate new DRM device
> > * @driver: DRM driver to allocate device for
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index e7c6ea261ed1..26776be5a21e 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -626,6 +626,39 @@ int devm_drm_dev_init(struct device *parent,
> > struct drm_device *dev,
> > struct drm_driver *driver);
> >
> > +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver
> > *driver,
> > + size_t size, size_t offset);
> > +
> > +/**
> > + * devm_drm_dev_alloc - Resource managed allocation of a &drm_device
> > instance
> > + * @parent: Parent device object
> > + * @driver: DRM driver
> > + * @type: the type of the struct which contains struct &drm_device
> > + * @member: the name of the &drm_device within @type.
> I am confused about the naming here.
> devm_ implies we allocate something with a lifetime equal that of a
> driver. So when the driver are gone what we allocate is also gone.
> Like everythign else devm_ prefixed.
>
> But the lifetime of a drm_device is until the last userspace reference
> is gone (final drm_dev_put() is called).
The kerneldoc for this is largely copied from the existing
devm_drm_dev_init. And yes the lifetime is bound to the device, we do the
drm_dev_put() when that disappears. Now other users of drm_device might
still hold references and delay cleanup, but "cleanup is done as a devres
action" is very much what devm_ signifies.
"
> > + *
> > + * This allocates and initialize a new DRM device. No device registration
> > is done.
> > + * Call drm_dev_register() to advertice the device to user space and
> > register it
> > + * with other core subsystems. This should be done last in the device
> s/This/Calling drm_dev_register()/ will make this sentence a bit more
> explicit.
>
> > + * initialization sequence to make sure userspace can't access an
> > inconsistent
> > + * state.
> > + *
> > + * The initial ref-count of the object is 1. Use drm_dev_get() and
> > + * drm_dev_put() to take and drop further ref-counts.
> > + *
> > + * It is recommended that drivers embed &struct drm_device into their own
> > device
> > + * structure.
> > + *
> > + * Note that this manages the lifetime of the resulting &drm_device
> > + * automatically using devres.
> Hmm, no this is managed by drmres???
Yup, the next sentence explains how. And note that we're already using
this in the form of devm_drm_dev_init. So not clear what
Re: [Intel-gfx] [PATCH v7 1/2] drm/i915: remove broken i915_sseu_status interface
Hi Tvrtko, I start by saying that this patch was mainly sent to kickstart a discussion about cleanups required in debugfs and how debugfs can be inconsistent and how much it looks to me that we are relying on its current state. > > The i915_sseu_status is broken and the tests on this interface > > are disabled. There is no reason to drag it along. > > Not saying we need it, but can you say how it is broken? well tests in igt are failing because we don't get the results we expect, I don't know where it is actually broken but the igt test looks straight forward to me. I assume (with some hints I received, though) that the sseu reads are inconsistent. Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support for YCBCR_BT2020
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, April 8, 2020 5:13 PM
> To: Kadiyala, Kishore ; intel-
> g...@lists.freedesktop.org
> Cc: Kadiyala, Kishore
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support
> for YCBCR_BT2020
>
> On Wed, 08 Apr 2020, Kishore Kadiyala wrote:
> > Currently the plane property doesn't have support for YCBCR_BT2020,
> > which enables the corresponding color conversion mode on plane CSC.
> > In ICL+ platforms , this property setting is confined only to HDR
> > Planes as there is limitation in SDR Planes and while in GLK it set
> > for all planes.
> >
> > V2: Enabling support for YCBCT_BT2020 for HDR planes on
> > platforms GLK & ICL
> >
> > V3: Refined the condition check to handle GLK & ICL+ HDR planes
> > Also added BT2020 handling in glk_plane_color_ctl.
> >
> > Cc: Ville Syrjala
> > Cc: Uma Shankar
> > Cc: Jani Nikula
> > Signed-off-by: Kishore Kadiyala
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 12 +---
> > drivers/gpu/drm/i915/display/intel_sprite.c | 17 +++--
> > 2 files changed, 24 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 70ec301fe6e3..f2dfa61a49fa 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct
> intel_crtc_state *crtc_state,
> > plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> >
> > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> > - if (plane_state->hw.color_encoding ==
> DRM_COLOR_YCBCR_BT709)
> > + switch (plane_state->hw.color_encoding) {
> > + case DRM_COLOR_YCBCR_BT709:
> > plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > - else
> > + break;
> > + case DRM_COLOR_YCBCR_BT2020:
> > + plane_color_ctl |=
> > +
> PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > + break;
> > + default:
> > plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > -
> > + }
> > if (plane_state->hw.color_range ==
> DRM_COLOR_YCBCR_FULL_RANGE)
> > plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > } else if (fb->format->is_yuv) {
> > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > index deda351719db..237c4b951f02 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > @@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> > struct intel_plane *plane;
> > enum drm_plane_type plane_type;
> > unsigned int supported_rotations;
> > + unsigned int supported_csc;
> > const u64 *modifiers;
> > const u32 *formats;
> > int num_formats;
> > @@ -3105,9 +3106,21 @@ skl_universal_plane_create(struct
> drm_i915_private *dev_priv,
> >DRM_MODE_ROTATE_0,
> >supported_rotations);
> >
> > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) |
> > +BIT(DRM_COLOR_YCBCR_BT709);
> > +
> > + /*
> > +* Setting the CSC BT2020 for all the planes in case of GLK
> > +* While for ICL+ platforms it is set only for HDR planes 1 through 3
> > +* as there are issues seen with SDR planes
> > +*/
> > + if ((INTEL_GEN(dev_priv) == 10) || IS_GEMINILAKE(dev_priv))
> > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> > + else
> > + if (icl_is_hdr_plane(dev_priv, plane_id))
> > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
>
> IOW,
>
> if (IS_GEN(dev_priv, 10) || IS_GEMINILAKE(dev_priv) ||
> icl_is_hdr_plane(dev_priv, plane_id))
> supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
>
Got it Jani,
Thanks,
Kishore
> > +
> > drm_plane_create_color_properties(&plane->base,
> > - BIT(DRM_COLOR_YCBCR_BT601) |
> > - BIT(DRM_COLOR_YCBCR_BT709),
> > + supported_csc,
> >
> BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
> >
> BIT(DRM_COLOR_YCBCR_FULL_RANGE),
> > DRM_COLOR_YCBCR_BT709,
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support for YCBCR_BT2020
On Wed, 08 Apr 2020, Kishore Kadiyala wrote:
> Currently the plane property doesn't have support for YCBCR_BT2020,
> which enables the corresponding color conversion mode on plane CSC.
> In ICL+ platforms , this property setting is confined only to HDR
> Planes as there is limitation in SDR Planes and while in GLK it
> set for all planes.
>
> V2: Enabling support for YCBCT_BT2020 for HDR planes on
> platforms GLK & ICL
>
> V3: Refined the condition check to handle GLK & ICL+ HDR planes
> Also added BT2020 handling in glk_plane_color_ctl.
>
> Cc: Ville Syrjala
> Cc: Uma Shankar
> Cc: Jani Nikula
> Signed-off-by: Kishore Kadiyala
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 12 +---
> drivers/gpu/drm/i915/display/intel_sprite.c | 17 +++--
> 2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 70ec301fe6e3..f2dfa61a49fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
> *crtc_state,
> plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
>
> if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> - if (plane_state->hw.color_encoding == DRM_COLOR_YCBCR_BT709)
> + switch (plane_state->hw.color_encoding) {
> + case DRM_COLOR_YCBCR_BT709:
> plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> - else
> + break;
> + case DRM_COLOR_YCBCR_BT2020:
> + plane_color_ctl |=
> + PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> + break;
> + default:
> plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> -
> + }
> if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
> plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> } else if (fb->format->is_yuv) {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index deda351719db..237c4b951f02 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> struct intel_plane *plane;
> enum drm_plane_type plane_type;
> unsigned int supported_rotations;
> + unsigned int supported_csc;
> const u64 *modifiers;
> const u32 *formats;
> int num_formats;
> @@ -3105,9 +3106,21 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> DRM_MODE_ROTATE_0,
> supported_rotations);
>
> + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | BIT(DRM_COLOR_YCBCR_BT709);
> +
> + /*
> + * Setting the CSC BT2020 for all the planes in case of GLK
> + * While for ICL+ platforms it is set only for HDR planes 1 through 3
> + * as there are issues seen with SDR planes
> + */
> + if ((INTEL_GEN(dev_priv) == 10) || IS_GEMINILAKE(dev_priv))
> + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> + else
> + if (icl_is_hdr_plane(dev_priv, plane_id))
> + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
IOW,
if (IS_GEN(dev_priv, 10) || IS_GEMINILAKE(dev_priv) ||
icl_is_hdr_plane(dev_priv, plane_id))
supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> +
> drm_plane_create_color_properties(&plane->base,
> - BIT(DRM_COLOR_YCBCR_BT601) |
> - BIT(DRM_COLOR_YCBCR_BT709),
> + supported_csc,
> BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
> BIT(DRM_COLOR_YCBCR_FULL_RANGE),
> DRM_COLOR_YCBCR_BT709,
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Take an explicit ref for rq->batch
Chris Wilson writes: > Since we are peeking into the batch object of the request, it is > beholden on us to hold a reference to it. > > Closes: https://gitlab.freedesktop.org/drm/intel/issues/1634 > Signed-off-by: Chris Wilson Follow the mon^H^H^H request. Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/selftest_lrc.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c > b/drivers/gpu/drm/i915/gt/selftest_lrc.c > index 57db3d0ffaf2..616d03506c2c 100644 > --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c > +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c > @@ -2655,7 +2655,7 @@ static int create_gang(struct intel_engine_cs *engine, > if (IS_ERR(rq)) > goto err_obj; > > - rq->batch = vma; > + rq->batch = i915_vma_get(vma); > i915_request_get(rq); > > i915_vma_lock(vma); > @@ -2679,6 +2679,7 @@ static int create_gang(struct intel_engine_cs *engine, > return 0; > > err_rq: > + i915_vma_put(rq->batch); > i915_request_put(rq); > err_obj: > i915_gem_object_put(obj); > @@ -2775,6 +2776,7 @@ static int live_preempt_gang(void *arg) > err = -ETIME; > } > > + i915_vma_put(rq->batch); > i915_request_put(rq); > rq = n; > } > -- > 2.20.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Mark up racy check of breadcrumb irq enabled
Chris Wilson writes: > We control b->irq_enabled inside the b->irq_lock, but we check before > entering the spinlock whether or not the interrupt is currently > unmasked. > > [ 1511.735208] BUG: KCSAN: data-race in __intel_breadcrumbs_disarm_irq [i915] > / intel_engine_disarm_breadcrumbs [i915] > [ 1511.735231] > [ 1511.735242] write to 0x8881f75fc214 of 1 bytes by interrupt on cpu 2: > [ 1511.735440] __intel_breadcrumbs_disarm_irq+0x4b/0x160 [i915] > [ 1511.735635] signal_irq_work+0x337/0x710 [i915] > [ 1511.735652] irq_work_run_list+0xd7/0x110 > [ 1511.735666] irq_work_run+0x1d/0x50 > [ 1511.735681] smp_irq_work_interrupt+0x21/0x30 > [ 1511.735701] irq_work_interrupt+0xf/0x20 > [ 1511.735722] __do_softirq+0x6f/0x206 > [ 1511.735736] irq_exit+0xcd/0xe0 > [ 1511.735756] do_IRQ+0x44/0xc0 > [ 1511.735773] ret_from_intr+0x0/0x1c > [ 1511.735787] schedule+0x0/0xb0 > [ 1511.735803] worker_thread+0x194/0x670 > [ 1511.735823] kthread+0x19a/0x1e0 > [ 1511.735837] ret_from_fork+0x1f/0x30 > [ 1511.735848] > [ 1511.735867] read to 0x8881f75fc214 of 1 bytes by task 432 on cpu 1: > [ 1511.736068] intel_engine_disarm_breadcrumbs+0x22/0x80 [i915] > [ 1511.736263] __engine_park+0x107/0x5d0 [i915] > [ 1511.736453] intel_wakeref_put_last+0x44/0x90 [i915] > [ 1511.736648] __intel_wakeref_put_last+0x5a/0x70 [i915] > [ 1511.736842] intel_context_exit_engine+0xf2/0x100 [i915] > [ 1511.737044] i915_request_retire+0x6b2/0x770 [i915] > [ 1511.737244] retire_requests+0x7a/0xd0 [i915] > [ 1511.737438] intel_gt_retire_requests_timeout+0x3a7/0x6f0 [i915] > [ 1511.737633] i915_drop_caches_set+0x1e7/0x260 [i915] > [ 1511.737650] simple_attr_write+0xfa/0x110 > [ 1511.737665] full_proxy_write+0x94/0xc0 > [ 1511.737679] __vfs_write+0x4b/0x90 > [ 1511.737697] vfs_write+0xfc/0x280 > [ 1511.737718] ksys_write+0x78/0x100 > [ 1511.737732] __x64_sys_write+0x44/0x60 > [ 1511.737751] do_syscall_64+0x6e/0x2c0 > [ 1511.737769] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala On these parts, avoiding the cost of spinlock is warranted. Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c > b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c > index cbad7fe722ce..cbedba857d43 100644 > --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c > +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c > @@ -64,7 +64,7 @@ static void __intel_breadcrumbs_disarm_irq(struct > intel_breadcrumbs *b) > if (!--b->irq_enabled) > irq_disable(engine); > > - b->irq_armed = false; > + WRITE_ONCE(b->irq_armed, false); > intel_gt_pm_put_async(engine->gt); > } > > @@ -73,7 +73,7 @@ void intel_engine_disarm_breadcrumbs(struct intel_engine_cs > *engine) > struct intel_breadcrumbs *b = &engine->breadcrumbs; > unsigned long flags; > > - if (!b->irq_armed) > + if (!READ_ONCE(b->irq_armed)) > return; > > spin_lock_irqsave(&b->irq_lock, flags); > @@ -233,7 +233,7 @@ static bool __intel_breadcrumbs_arm_irq(struct > intel_breadcrumbs *b) >* which we can add a new waiter and avoid the cost of re-enabling >* the irq. >*/ > - b->irq_armed = true; > + WRITE_ONCE(b->irq_armed, true); > > /* >* Since we are waiting on a request, the GPU should be busy > -- > 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Drop vestigal timeslicing assert
== Series Details ==
Series: drm/i915/selftests: Drop vestigal timeslicing assert
URL : https://patchwork.freedesktop.org/series/75640/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8270_full -> Patchwork_17245_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17245_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17245_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17245_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_whisper@basic-fds-forked:
- shard-kbl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-kbl7/igt@gem_exec_whis...@basic-fds-forked.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-kbl2/igt@gem_exec_whis...@basic-fds-forked.html
Known issues
Here are the changes found in Patchwork_17245_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_big_fb@y-tiled-16bpp-rotate-0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#1119])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-glk4/igt@kms_big...@y-tiled-16bpp-rotate-0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-glk3/igt@kms_big...@y-tiled-16bpp-rotate-0.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#72])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180] / [i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-apl4/igt@kms_fbcon_...@fbc-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-apl1/igt@kms_fbcon_...@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#79])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-glk1/igt@kms_f...@flip-vs-expired-vblank.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-glk5/igt@kms_f...@flip-vs-expired-vblank.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#1188])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-skl6/igt@kms_...@bpc-switch-suspend.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-skl4/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#69])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-skl9/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-skl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_psr@psr2_no_drrs:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-iclb3/igt@kms_psr@psr2_no_drrs.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +6
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-kbl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-kbl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
- shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-apl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-apl8/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
Possible fixes
* {igt@gem_wait@write-busy@all}:
- shard-glk: [FAIL][21] ([i915#1604]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8270/shard-glk2/igt@gem_wait@write-b...@all.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17245/shard-glk7/igt@gem_wait@write-b...@all.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-snb: [FAIL][23] ([i915#1066]) -> [PASS][24]
[23]:
http
[Intel-gfx] [PATCH v3] drm/i915: Add Plane color encoding support for YCBCR_BT2020
Currently the plane property doesn't have support for YCBCR_BT2020,
which enables the corresponding color conversion mode on plane CSC.
In ICL+ platforms , this property setting is confined only to HDR
Planes as there is limitation in SDR Planes and while in GLK it
set for all planes.
V2: Enabling support for YCBCT_BT2020 for HDR planes on
platforms GLK & ICL
V3: Refined the condition check to handle GLK & ICL+ HDR planes
Also added BT2020 handling in glk_plane_color_ctl.
Cc: Ville Syrjala
Cc: Uma Shankar
Cc: Jani Nikula
Signed-off-by: Kishore Kadiyala
---
drivers/gpu/drm/i915/display/intel_display.c | 12 +---
drivers/gpu/drm/i915/display/intel_sprite.c | 17 +++--
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 70ec301fe6e3..f2dfa61a49fa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4808,11 +4808,17 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
- if (plane_state->hw.color_encoding == DRM_COLOR_YCBCR_BT709)
+ switch (plane_state->hw.color_encoding) {
+ case DRM_COLOR_YCBCR_BT709:
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
- else
+ break;
+ case DRM_COLOR_YCBCR_BT2020:
+ plane_color_ctl |=
+ PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
+ break;
+ default:
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
-
+ }
if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
plane_color_ctl |=
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
} else if (fb->format->is_yuv) {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index deda351719db..237c4b951f02 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -3031,6 +3031,7 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
struct intel_plane *plane;
enum drm_plane_type plane_type;
unsigned int supported_rotations;
+ unsigned int supported_csc;
const u64 *modifiers;
const u32 *formats;
int num_formats;
@@ -3105,9 +3106,21 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
DRM_MODE_ROTATE_0,
supported_rotations);
+ supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | BIT(DRM_COLOR_YCBCR_BT709);
+
+ /*
+* Setting the CSC BT2020 for all the planes in case of GLK
+* While for ICL+ platforms it is set only for HDR planes 1 through 3
+* as there are issues seen with SDR planes
+*/
+ if ((INTEL_GEN(dev_priv) == 10) || IS_GEMINILAKE(dev_priv))
+ supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
+ else
+ if (icl_is_hdr_plane(dev_priv, plane_id))
+ supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
+
drm_plane_create_color_properties(&plane->base,
- BIT(DRM_COLOR_YCBCR_BT601) |
- BIT(DRM_COLOR_YCBCR_BT709),
+ supported_csc,
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
BIT(DRM_COLOR_YCBCR_FULL_RANGE),
DRM_COLOR_YCBCR_BT709,
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/23] drm/i915: Use ww locking in intel_renderstate.
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_gt.c | 21 +++---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 79 ++---
drivers/gpu/drm/i915/gt/intel_renderstate.h | 9 ++-
3 files changed, 72 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 6eae4c791007..c11e89472ad8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -406,21 +406,20 @@ static int __engines_record_defaults(struct intel_gt *gt)
/* We must be able to switch to something! */
GEM_BUG_ON(!engine->kernel_context);
- err = intel_renderstate_init(&so, engine);
- if (err)
- goto out;
-
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
err = PTR_ERR(ce);
goto out;
}
- rq = intel_context_create_request(ce);
+ err = intel_renderstate_init(&so, ce);
+ if (err)
+ goto err;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- intel_context_put(ce);
- goto out;
+ goto err_fini;
}
err = intel_engine_emit_ctx_wa(rq);
@@ -434,9 +433,13 @@ static int __engines_record_defaults(struct intel_gt *gt)
err_rq:
requests[id] = i915_request_get(rq);
i915_request_add(rq);
- intel_renderstate_fini(&so);
- if (err)
+err_fini:
+ intel_renderstate_fini(&so, ce);
+err:
+ if (err) {
+ intel_context_put(ce);
goto out;
+ }
}
/* Flush the default context image to memory, and enable powersaving. */
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c
b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index ca533d98d14d..5e980642e479 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -27,6 +27,7 @@
#include "i915_drv.h"
#include "intel_renderstate.h"
+#include "gt/intel_context.h"
#include "intel_ring.h"
static const struct intel_renderstate_rodata *
@@ -74,10 +75,9 @@ static int render_state_setup(struct intel_renderstate *so,
u32 *d;
int ret;
- i915_gem_object_lock(so->vma->obj, NULL);
ret = i915_gem_object_prepare_write(so->vma->obj, &needs_clflush);
if (ret)
- goto out_unlock;
+ return ret;
d = kmap_atomic(i915_gem_object_get_dirty_page(so->vma->obj, 0));
@@ -158,8 +158,6 @@ static int render_state_setup(struct intel_renderstate *so,
ret = 0;
out:
i915_gem_object_finish_access(so->vma->obj);
-out_unlock:
- i915_gem_object_unlock(so->vma->obj);
return ret;
err:
@@ -171,33 +169,47 @@ static int render_state_setup(struct intel_renderstate
*so,
#undef OUT_BATCH
int intel_renderstate_init(struct intel_renderstate *so,
- struct intel_engine_cs *engine)
+ struct intel_context *ce)
{
- struct drm_i915_gem_object *obj;
+ struct intel_engine_cs *engine = ce->engine;
+ struct drm_i915_gem_object *obj = NULL;
int err;
memset(so, 0, sizeof(*so));
so->rodata = render_state_get_rodata(engine);
- if (!so->rodata)
- return 0;
+ if (so->rodata) {
+ if (so->rodata->batch_items * 4 > PAGE_SIZE)
+ return -EINVAL;
+
+ obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
+ if (IS_ERR(so->vma)) {
+ err = PTR_ERR(so->vma);
+ goto err_obj;
+ }
+ }
- if (so->rodata->batch_items * 4 > PAGE_SIZE)
- return -EINVAL;
+ i915_gem_ww_ctx_init(&so->ww, true);
+retry:
+ err = intel_context_pin(ce);
+ if (err)
+ goto err_fini;
- obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ /* return early if there's nothing to setup */
+ if (!err && !so->rodata)
+ return 0;
- so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
- if (
[Intel-gfx] [PATCH 06/23] Revert "drm/i915/gem: Split eb_vma into its own allocation"
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 131 --
1 file changed, 58 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1e9e89603e91..5e093488dd48 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -40,11 +40,6 @@ struct eb_vma {
u32 handle;
};
-struct eb_vma_array {
- struct kref kref;
- struct eb_vma vma[];
-};
-
enum {
FORCE_CPU_RELOC = 1,
FORCE_GTT_RELOC,
@@ -57,6 +52,7 @@ enum {
#define __EXEC_OBJECT_NEEDS_MAPBIT(29)
#define __EXEC_OBJECT_NEEDS_BIAS BIT(28)
#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 28) /* all of the above */
+#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_INTERNAL_FLAGS (~0u << 31)
@@ -287,7 +283,6 @@ struct i915_execbuffer {
*/
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
- struct eb_vma_array *array;
};
static int eb_parse(struct i915_execbuffer *eb);
@@ -299,62 +294,8 @@ static inline bool eb_use_cmdparser(const struct
i915_execbuffer *eb)
eb->args->batch_len);
}
-static struct eb_vma_array *eb_vma_array_create(unsigned int count)
-{
- struct eb_vma_array *arr;
-
- arr = kvmalloc(struct_size(arr, vma, count), GFP_KERNEL | __GFP_NOWARN);
- if (!arr)
- return NULL;
-
- kref_init(&arr->kref);
- arr->vma[0].vma = NULL;
-
- return arr;
-}
-
-static inline void eb_unreserve_vma(struct eb_vma *ev)
-{
- struct i915_vma *vma = ev->vma;
-
- if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
- __i915_vma_unpin_fence(vma);
-
- if (ev->flags & __EXEC_OBJECT_HAS_PIN)
- __i915_vma_unpin(vma);
-
- ev->flags &= ~(__EXEC_OBJECT_HAS_PIN |
- __EXEC_OBJECT_HAS_FENCE);
-}
-
-static void eb_vma_array_destroy(struct kref *kref)
-{
- struct eb_vma_array *arr = container_of(kref, typeof(*arr), kref);
- struct eb_vma *ev = arr->vma;
-
- while (ev->vma) {
- eb_unreserve_vma(ev);
- i915_vma_put(ev->vma);
- ev++;
- }
-
- kvfree(arr);
-}
-
-static void eb_vma_array_put(struct eb_vma_array *arr)
-{
- kref_put(&arr->kref, eb_vma_array_destroy);
-}
-
static int eb_create(struct i915_execbuffer *eb)
{
- /* Allocate an extra slot for use by the command parser + sentinel */
- eb->array = eb_vma_array_create(eb->buffer_count + 2);
- if (!eb->array)
- return -ENOMEM;
-
- eb->vma = eb->array->vma;
-
if (!(eb->args->flags & I915_EXEC_HANDLE_LUT)) {
unsigned int size = 1 + ilog2(eb->buffer_count);
@@ -388,10 +329,8 @@ static int eb_create(struct i915_execbuffer *eb)
break;
} while (--size);
- if (unlikely(!size)) {
- eb_vma_array_put(eb->array);
+ if (unlikely(!size))
return -ENOMEM;
- }
eb->lut_size = size;
} else {
@@ -502,6 +441,26 @@ eb_pin_vma(struct i915_execbuffer *eb,
return !eb_vma_misplaced(entry, vma, ev->flags);
}
+static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
+{
+ GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
+
+ if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
+ __i915_vma_unpin_fence(vma);
+
+ __i915_vma_unpin(vma);
+}
+
+static inline void
+eb_unreserve_vma(struct eb_vma *ev)
+{
+ if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
+ return;
+
+ __eb_unreserve_vma(ev->vma, ev->flags);
+ ev->flags &= ~__EXEC_OBJECT_RESERVED;
+}
+
static int
eb_validate_vma(struct i915_execbuffer *eb,
struct drm_i915_gem_exec_object2 *entry,
@@ -944,13 +903,31 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned
long handle)
}
}
+static void eb_release_vmas(const struct i915_execbuffer *eb)
+{
+ const unsigned int count = eb->buffer_count;
+ unsigned int i;
+
+ for (i = 0; i < count; i++) {
+ struct eb_vma *ev = &eb->vma[i];
+ struct i915_vma *vma = ev->vma;
+
+ if (!vma)
+ break;
+
+ eb->vma[i].vma = NULL;
+
+ if (ev->flags & __EXEC_OBJECT_HAS_PIN)
+ __eb_unreserve_vma(vma, ev->flags);
+
+ i915_vma_put(vma);
+ }
+}
+
static v
[Intel-gfx] [PATCH 21/23] drm/i915: Add ww locking to vm_fault_gtt
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..e35e8d0b6938 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -283,37 +283,46 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
struct intel_runtime_pm *rpm = &i915->runtime_pm;
struct i915_ggtt *ggtt = &i915->ggtt;
bool write = area->vm_flags & VM_WRITE;
+ struct i915_gem_ww_ctx ww;
intel_wakeref_t wakeref;
struct i915_vma *vma;
pgoff_t page_offset;
int srcu;
int ret;
- /* Sanity check that we allow writing into this object */
- if (i915_gem_object_is_readonly(obj) && write)
- return VM_FAULT_SIGBUS;
-
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
trace_i915_gem_object_fault(obj, page_offset, true, write);
- ret = i915_gem_object_pin_pages(obj);
+ wakeref = intel_runtime_pm_get(rpm);
+
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ ret = i915_gem_object_lock(obj, &ww);
if (ret)
- goto err;
+ goto err_rpm;
- wakeref = intel_runtime_pm_get(rpm);
+ /* Sanity check that we allow writing into this object */
+ if (i915_gem_object_is_readonly(obj) && write) {
+ ret = -EFAULT;
+ goto err_rpm;
+ }
- ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+ ret = i915_gem_object_pin_pages(obj);
if (ret)
goto err_rpm;
+ ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+ if (ret)
+ goto err_pages;
+
/* Now pin it into the GTT as needed */
- vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
- PIN_MAPPABLE |
- PIN_NONBLOCK /* NOWARN */ |
- PIN_NOEVICT);
- if (IS_ERR(vma)) {
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, NULL, 0, 0,
+ PIN_MAPPABLE |
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
+ if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK)) {
/* Use a partial view if it is bigger than available space */
struct i915_ggtt_view view =
compute_partial_view(obj, page_offset, MIN_CHUNK_PAGES);
@@ -328,11 +337,11 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
* all hope that the hardware is able to track future writes.
*/
- vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
- if (IS_ERR(vma)) {
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0, 0, flags);
+ if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK)) {
flags = PIN_MAPPABLE;
view.type = I915_GGTT_VIEW_PARTIAL;
- vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0,
0, flags);
}
/* The entire mappable GGTT is pinned? Unexpected! */
@@ -389,10 +398,16 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
__i915_vma_unpin(vma);
err_reset:
intel_gt_reset_unlock(ggtt->vm.gt, srcu);
+err_pages:
+ i915_gem_object_unpin_pages(obj);
err_rpm:
+ if (ret == -EDEADLK) {
+ ret = i915_gem_ww_ctx_backoff(&ww);
+ if (!ret)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
intel_runtime_pm_put(rpm, wakeref);
- i915_gem_object_unpin_pages(obj);
-err:
return i915_error_to_vmf_fault(ret);
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/23] drm/i915: Move i915_vma_lock in the selftests to avoid lock inversion, v2.
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/gpu/drm/i915/selftests/i915_request.c | 18 +---
3 files changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 99f8466a108a..d93b7d9ad174 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -199,25 +199,25 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
i915_gem_object_lock(ctx->obj, NULL);
err = i915_gem_object_set_to_gtt_domain(ctx->obj, true);
- i915_gem_object_unlock(ctx->obj);
if (err)
- return err;
+ goto out_unlock;
vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto out_unlock;
+ }
rq = intel_engine_create_kernel_request(ctx->engine);
if (IS_ERR(rq)) {
- i915_vma_unpin(vma);
- return PTR_ERR(rq);
+ err = PTR_ERR(rq);
+ goto out_unpin;
}
cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs)) {
- i915_request_add(rq);
- i915_vma_unpin(vma);
- return PTR_ERR(cs);
+ err = PTR_ERR(cs);
+ goto out_rq;
}
if (INTEL_GEN(ctx->engine->i915) >= 8) {
@@ -238,14 +238,16 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
}
intel_ring_advance(rq, cs);
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
- i915_vma_unpin(vma);
+out_rq:
i915_request_add(rq);
+out_unpin:
+ i915_vma_unpin(vma);
+out_unlock:
+ i915_gem_object_unlock(ctx->obj);
return err;
}
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 eec58da734bd..c8b9343cc88c 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -528,31 +528,42 @@ static int make_obj_busy(struct drm_i915_gem_object *obj)
for_each_uabi_engine(engine, i915) {
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
int err;
vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
if (IS_ERR(vma))
return PTR_ERR(vma);
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(obj, &ww);
+ if (!err)
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_USER);
if (err)
- return err;
+ goto err;
rq = intel_engine_create_kernel_request(engine);
if (IS_ERR(rq)) {
- i915_vma_unpin(vma);
- return PTR_ERR(rq);
+ err = PTR_ERR(rq);
+ goto err_unpin;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq,
EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
i915_request_add(rq);
+err_unpin:
i915_vma_unpin(vma);
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
if (err)
return err;
}
@@ -1000,6 +1011,7 @@ static int __igt_mmap_gpu(struct drm_i915_private *i915,
for_each_uabi_engine(engine, i915) {
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
vma = i915_vma_instance(obj, engine->kernel_context->vm, NULL);
if (IS_ERR(vma)) {
@@ -1007,9 +1019,13 @@ static int __igt_mmap_gpu(struct drm_i915_private *i915,
goto out_unmap;
}
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ i915_gem
[Intel-gfx] [PATCH 22/23] drm/i915: Add ww locking to pin_to_display_plane
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 1a3dd77a35b9..4be148392acc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -37,6 +37,12 @@ void i915_gem_object_flush_if_display(struct
drm_i915_gem_object *obj)
i915_gem_object_unlock(obj);
}
+void i915_gem_object_flush_if_display_locked(struct drm_i915_gem_object *obj)
+{
+ if (i915_gem_object_is_framebuffer(obj))
+ __i915_gem_object_flush_for_display(obj);
+}
+
/**
* Moves a single object to the WC read, and possibly write domain.
* @obj: object to act on
@@ -197,18 +203,12 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
if (ret)
return ret;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
-
/* Always invalidate stale cachelines */
if (obj->cache_level != cache_level) {
i915_gem_object_set_cache_coherency(obj, cache_level);
obj->cache_dirty = true;
}
- i915_gem_object_unlock(obj);
-
/* The cache-level will be applied when each vma is rebound. */
return i915_gem_object_unbind(obj,
I915_GEM_OBJECT_UNBIND_ACTIVE |
@@ -255,6 +255,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void
*data,
struct drm_i915_gem_caching *args = data;
struct drm_i915_gem_object *obj;
enum i915_cache_level level;
+ struct i915_gem_ww_ctx ww;
int ret = 0;
switch (args->caching) {
@@ -293,7 +294,18 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev,
void *data,
goto out;
}
- ret = i915_gem_object_set_cache_level(obj, level);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ ret = i915_gem_object_lock(obj, &ww);
+ if (!ret)
+ ret = i915_gem_object_set_cache_level(obj, level);
+
+ if (ret == -EDEADLK) {
+ ret = i915_gem_ww_ctx_backoff(&ww);
+ if (!ret)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
out:
i915_gem_object_put(obj);
@@ -313,6 +325,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
unsigned int flags)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct i915_gem_ww_ctx ww;
struct i915_vma *vma;
int ret;
@@ -320,6 +333,11 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj))
return ERR_PTR(-EINVAL);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ ret = i915_gem_object_lock(obj, &ww);
+ if (ret)
+ goto err;
/*
* The display engine is not coherent with the LLC cache on gen6. As
* a result, we make sure that the pinning that is about to occur is
@@ -334,7 +352,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
HAS_WT(i915) ?
I915_CACHE_WT : I915_CACHE_NONE);
if (ret)
- return ERR_PTR(ret);
+ goto err;
/*
* As the user may map the buffer once pinned in the display plane
@@ -347,18 +365,31 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
vma = ERR_PTR(-ENOSPC);
if ((flags & PIN_MAPPABLE) == 0 &&
(!view || view->type == I915_GGTT_VIEW_NORMAL))
- vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment,
- flags |
- PIN_MAPPABLE |
- PIN_NONBLOCK);
- if (IS_ERR(vma))
- vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment, flags);
- if (IS_ERR(vma))
- return vma;
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, view, 0, alignment,
+ flags | PIN_MAPPABLE |
+ PIN_NONBLOCK);
+ if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK))
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, view, 0,
+ alignment, flags);
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
+ goto err;
+ }
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
- i915_gem_object_flush_if_display(obj);
+ i915_gem_object_flush_if_display_loc
