i915 selftest hangcheck is causing the i915 driver timeouts, as reported
by Intel CI bot:
http://gfx-ci.fi.intel.com/cibuglog-ng/issuefilterassoc/24297?query_key=42a…
When such test runs, the only output is:
[ 68.811639] i915: Performing live selftests with st_random_seed=0xe138eac7 st_timeout=500
[ 68.811792] i915: Running hangcheck
[ 68.811859] i915: Running intel_hangcheck_live_selftests/igt_hang_sanitycheck
[ 68.816910] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes
…
[View More][ 68.841597] i915: Running intel_hangcheck_live_selftests/igt_reset_nop
[ 69.346347] igt_reset_nop: 80 resets
[ 69.362695] i915: Running intel_hangcheck_live_selftests/igt_reset_nop_engine
[ 69.863559] igt_reset_nop_engine(rcs0): 709 resets
[ 70.364924] igt_reset_nop_engine(bcs0): 903 resets
[ 70.866005] igt_reset_nop_engine(vcs0): 659 resets
[ 71.367934] igt_reset_nop_engine(vcs1): 549 resets
[ 71.869259] igt_reset_nop_engine(vecs0): 553 resets
[ 71.882592] i915: Running intel_hangcheck_live_selftests/igt_reset_idle_engine
[ 72.383554] rcs0: Completed 16605 idle resets
[ 72.884599] bcs0: Completed 18641 idle resets
[ 73.385592] vcs0: Completed 17517 idle resets
[ 73.886658] vcs1: Completed 15474 idle resets
[ 74.387600] vecs0: Completed 17983 idle resets
[ 74.387667] i915: Running intel_hangcheck_live_selftests/igt_reset_active_engine
[ 74.889017] rcs0: Completed 747 active resets
[ 75.174240] intel_engine_reset(bcs0) failed, err:-110
[ 75.174301] bcs0: Completed 525 active resets
After that, the machine just silently hangs.
Bisecting the issue, the patch that introduced the regression is:
7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Reverting it fix the issues, but introduce other problems, as TLB
won't be invalidated anymore. So, instead, let's fix the root cause.
It turns that the TLB flush logic ends conflicting with i915 reset,
which is called during selftest hangcheck. So, the TLB cache should
be serialized, but other TLB fix patches are required for this one
to work.
Tested on an Intel NUC5i7RYB with an i7-5557U Broadwell CPU.
Chris Wilson (6):
drm/i915/gt: Ignore TLB invalidations on idle engines
drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations
drm/i915/gt: Skip TLB invalidations once wedged
drm/i915/gt: Only invalidate TLBs exposed to user manipulation
drm/i915/gt: Serialize GRDOM access between multiple engine resets
drm/i915/gt: Serialize TLB invalidates with GT resets
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 +++---
drivers/gpu/drm/i915/gt/intel_gt.c | 43 +++++++++++++++++++----
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 3 ++
drivers/gpu/drm/i915/gt/intel_reset.c | 37 ++++++++++++++-----
drivers/gpu/drm/i915/i915_vma.c | 3 +-
5 files changed, 75 insertions(+), 21 deletions(-)
--
2.36.1
[View Less]
This is the i915 driver VM_BIND feature design RFC patch series along
with the required uapi definition and description of intended use cases.
v2: Reduce the scope to simple Mesa use case.
Remove all compute related uapi, vm_bind/unbind queue support and
only support a timeline out fence instead of an in/out timeline
fence array.
v3: Expand documentation on dma-resv usage, TLB flushing, execbuf3 and
VM_UNBIND. Add FENCE_VALID and TLB_FLUSH flags.
Signed-off-by: Niranjana …
[View More]Vishwanathapura <niranjana.vishwanathapura(a)intel.com>
Niranjana Vishwanathapura (3):
drm/doc/rfc: VM_BIND feature design document
drm/i915: Update i915 uapi documentation
drm/doc/rfc: VM_BIND uapi definition
Documentation/gpu/rfc/i915_vm_bind.h | 243 ++++++++++++++++++++++++
Documentation/gpu/rfc/i915_vm_bind.rst | 247 +++++++++++++++++++++++++
Documentation/gpu/rfc/index.rst | 4 +
include/uapi/drm/i915_drm.h | 205 +++++++++++++++-----
4 files changed, 654 insertions(+), 45 deletions(-)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst
--
2.21.0.rc0.32.g243a4c7e27
[View Less]
It's v11 time. There's only one small change to v10. Discussion seems to
have settled now. Is there anything left that prevents the series from
being merged? I'd really like to have it in during the next merge
window.
This series still depends on:
drm/rockchip: Refactor IOMMU initialisation (https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html)
arm64: dts: rockchip: add basic dts for the radxa rock3 model a
Sascha
Changes since v10:
- relax mode_valid hook rather than …
[View More]dropping it in hdmi driver
Changes since v9:
- rebase on v5.18-rc1
- Do not register windows which don't have its own framebuffer on RK3566
- fix mixed up register writes in vop2_setup_dly_for_windows()
- move call to rockchip_drm_dma_attach_device() from vop2_bind() to vop2_enable()
- Fix zpos handling
Changes since v8:
- make hclk_vo a critical clock instead of enabling it in the hdmi driver
- Fix vop2_setup_layer_mixer(), reported by Andy Yan
- Limit planes possible_crtcs to actually existing crtcs
- simplify vop2_create_crtc() a bit
Changes since v7:
- rename hclk to niu
Changes since v6:
- Move of_graph parsing out of runtime code to initialization
Changes since v5:
- Add new patch to fix dw-hdmi of_graph binding
- Drop "drm/encoder: Add of_graph port to struct drm_encoder" and solve
issue internally in the driver
- make checkpatch cleaner
Changes since v4:
- Reorder patches in a way that binding/dts/driver patches are closer together
- Drop clk patches already applied by Heiko
Changes since v3:
- added changelog to each patch
- Add 4k support to hdmi driver
- rebase on v5.17-rc1
Changes since v2:
- Add pin names to HDMI supply pin description
- Add hclk support to HDMI driver
- Dual license rockchip-vop2 binding, update binding
- Add HDMI connector to board dts files
- drop unnecessary gamma_lut registers from vop2
- Update dclk_vop[012] clock handling, no longer hacks needed
- Complete regmap conversion
Changes since v1:
- drop all unnecessary waiting for frames within atomic modeset and plane update
- Cluster subwin support removed
- gamma support removed
- unnecessary irq_lock removed
- interrupt handling simplified
- simplified zpos handling
- drop is_alpha_support(), use fb->format->has_alpha instead
- use devm_regulator_get() rather than devm_regulator_get_optional() for hdmi regulators
- Use fixed number of planes per video port
- Drop homegrown regmap code from vop2 driver (not complete yet)
- Add separate include file for vop2 driver to not pollute the vop include
Andy Yan (1):
drm: rockchip: Add VOP2 driver
Benjamin Gaignard (1):
dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568
HDMI
Douglas Anderson (2):
drm/rockchip: dw_hdmi: Use auto-generated tables
drm/rockchip: dw_hdmi: Set cur_ctr to 0 always
Michael Riesch (2):
arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a
arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
Nickey Yang (1):
drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz
Sascha Hauer (17):
clk: rk3568: Mark hclk_vo as critical
drm/rockchip: Embed drm_encoder into rockchip_decoder
drm/rockchip: Add crtc_endpoint_id to rockchip_encoder
drm/rockchip: dw_hdmi: rename vpll clock to reference clock
dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name
arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'
drm/rockchip: dw_hdmi: add rk3568 support
drm/rockchip: dw_hdmi: add regulator support
dt-bindings: display: rockchip: dw-hdmi: Add regulator support
drm/rockchip: dw_hdmi: relax mode_valid hook
dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional
arm64: dts: rockchip: rk356x: Add VOP2 nodes
arm64: dts: rockchip: rk356x: Add HDMI nodes
arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi
drm/rockchip: Make VOP driver optional
dt-bindings: display: rockchip: Add binding for VOP2
dt-bindings: display: rockchip: dw-hdmi: fix ports description
.../display/rockchip/rockchip,dw-hdmi.yaml | 46 +-
.../display/rockchip/rockchip-vop2.yaml | 140 +
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
.../boot/dts/rockchip/rk3566-quartz64-a.dts | 47 +
arch/arm64/boot/dts/rockchip/rk3566.dtsi | 4 +
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 47 +
.../boot/dts/rockchip/rk3568-rock-3a.dts | 47 +
arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 +
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 83 +
drivers/clk/rockchip/clk-rk3568.c | 1 +
drivers/gpu/drm/rockchip/Kconfig | 14 +
drivers/gpu/drm/rockchip/Makefile | 4 +-
.../gpu/drm/rockchip/analogix_dp-rockchip.c | 32 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c | 18 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +-
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 17 +-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 257 +-
drivers/gpu/drm/rockchip/inno_hdmi.c | 32 +-
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 34 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 36 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 20 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 15 +
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2706 +++++++++++++++++
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 477 +++
drivers/gpu/drm/rockchip/rockchip_lvds.c | 26 +-
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 281 ++
include/dt-bindings/soc/rockchip,vop2.h | 14 +
28 files changed, 4235 insertions(+), 173 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
create mode 100644 include/dt-bindings/soc/rockchip,vop2.h
--
2.30.2
[View Less]
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi.
This driver calls drm_detect_hdmi_monitor() to receive the same
information, which is less efficient.
Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi
instead.
Signed-off-by: hongao <hongao(a)uniontech.com>
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/…
[View More]drivers/gpu/drm/exynos/exynos_hdmi.c
index 7655142a4651..17e9f5efbcfc 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -893,7 +893,7 @@ static int hdmi_get_modes(struct drm_connector *connector)
if (!edid)
return -ENODEV;
- hdata->dvi_mode = !drm_detect_hdmi_monitor(edid);
+ hdata->dvi_mode = !connector->display_info.is_hdmi;
DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n",
(hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"),
edid->width_cm, edid->height_cm);
--
2.20.1
[View Less]
This is the i915 driver VM_BIND feature design RFC patch series along
with the required uapi definition and description of intended use cases.
v2: Reduce the scope to simple Mesa use case.
Remove all compute related uapi, vm_bind/unbind queue support and
only support a timeline out fence instead of an in/out timeline
fence array.
v3: Expand documentation on dma-resv usage, TLB flushing, execbuf3 and
VM_UNBIND. Add FENCE_VALID and TLB_FLUSH flags.
v4: Remove …
[View More]I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
uapi documentation for vm_bind/unbind.
v5: Update TLB flushing documentation.
Add version support to stage implementation.
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura(a)intel.com>
Niranjana Vishwanathapura (3):
drm/doc/rfc: VM_BIND feature design document
drm/i915: Update i915 uapi documentation
drm/doc/rfc: VM_BIND uapi definition
Documentation/gpu/rfc/i915_vm_bind.h | 256 +++++++++++++++++++++++++
Documentation/gpu/rfc/i915_vm_bind.rst | 246 ++++++++++++++++++++++++
Documentation/gpu/rfc/index.rst | 4 +
include/uapi/drm/i915_drm.h | 205 +++++++++++++++-----
4 files changed, 666 insertions(+), 45 deletions(-)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst
--
2.21.0.rc0.32.g243a4c7e27
[View Less]
Hi guys,
we are currently working an Freesync and direct scan out from system
memory on AMD APUs in A+A laptops.
On problem we stumbled over is that our display hardware needs to scan
out from uncached system memory and we currently don't have a way to
communicate that through DMA-buf.
For our specific use case at hand we are going to implement something
driver specific, but the question is should we have something more
generic for this?
After all the system memory access pattern is a …
[View More]PCIe extension and as
such something generic.
Regards,
Christian.
[View Less]
Provide drm_atomic_helper_check_crtc_state() for validating a CRTC
state against common constraints. As many CRTC need a primary plane
to work correctly, add this as the first test.
The simple-KMS helpers already contain related code. Convert it
to the new helper. Also add this test to ast.
The simple-kms changes were tested with simpledrm. The ast changes
were tested in AST2300 hardware.
Thomas Zimmermann (3):
drm/atomic-helper: Add helper drm_atomic_helper_check_crtc_state()
drm/simple-…
[View More]kms: Use drm_atomic_helper_check_crtc_state()
drm/ast: Enable primary plane with CRTC
drivers/gpu/drm/ast/ast_mode.c | 13 ++++--
drivers/gpu/drm/drm_atomic_helper.c | 55 +++++++++++++++++++++++++
drivers/gpu/drm/drm_simple_kms_helper.c | 14 +++----
include/drm/drm_atomic_helper.h | 2 +
4 files changed, 72 insertions(+), 12 deletions(-)
base-commit: 822a8442835012ce405080cb40f6317ef1e854ac
--
2.36.1
[View Less]
Hello everyone,
To summarize the issue I'm trying to address here: Processes can allocate
resources through a file descriptor without being held responsible for it.
I'm not explaining all the details again. See here for a more deeply
description of the problem: https://lwn.net/ml/linux-kernel/20220531100007.174649-1-christian.koenig@am…
With this iteration I'm trying to address a bunch of the comments Michal Hocko
(thanks a lot for that) gave as well as giving some new ideas.
Changes made …
[View More]so far:
1. Renamed the callback into file_rss(). This is at least a start to better
describe what this is all about. I've been going back and forth over the
naming here, if you have any better idea please speak up.
2. Cleanups, e.g. now providing a helper function in the fs layer to sum up
all the pages allocated by the files in a file descriptor table.
3. Using the actual number of allocated pages for the shmem implementation
instead of just the size. I also tried to ignore shmem files which are part
of tmpfs, cause that has a separate accounting/limitation approach.
4. The OOM killer now prints the memory of the killed process including the per
file pages which makes the whole things much more comprehensible.
5. I've added the per file pages to the different reports in RSS in procfs.
This has the interesting effect that tools like top suddenly give a much
more accurate overview of the memory use as well. This of course increases
the overhead of gathering those information quite a bit and I'm not sure how
feasible that is for up-streaming. On the other hand this once more clearly
shows that we need to do something about this issue.
Another rather interesting observation is that multiple subsystems (shmem,
tmpfs, ttm) came up with the same workaround of limiting the memory which can
be allocated through them to 50% of the whole system memory. Unfortunately
that isn't the same 50% and it doesn't apply everywhere, so you can still
easily crash the box.
Ideas and/or comments are really welcome.
Thanks,
Christian.
[View Less]
With an AST2600, the screen is garbage when going out of suspend.
This is because color settings are lost, and not restored on resume.
Force the color settings on DPMS_ON, to make sure the settings are correct.
I didn't write this code, it comes from the out-of-tree aspeed driver v1.13
https://www.aspeedtech.com/support_driver/
Signed-off-by: Jocelyn Falempe <jfalempe(a)redhat.com>
Tested-by: Venkat Tadikonda <venkateswara.rao(a)intel.com>
---
drivers/gpu/drm/ast/ast_mode.c | 13 +…
[View More]++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 3eb9afecd9d4..cdddcb5c4439 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -990,6 +990,9 @@ static void ast_crtc_dpms(struct drm_crtc *crtc, int mode)
{
struct ast_private *ast = to_ast_private(crtc->dev);
u8 ch = AST_DPMS_VSYNC_OFF | AST_DPMS_HSYNC_OFF;
+ struct ast_crtc_state *ast_state;
+ const struct drm_format_info *format;
+ struct ast_vbios_mode_info *vbios_mode_info;
/* TODO: Maybe control display signal generation with
* Sync Enable (bit CR17.7).
@@ -1007,6 +1010,16 @@ static void ast_crtc_dpms(struct drm_crtc *crtc, int mode)
ast_dp_set_on_off(crtc->dev, 1);
}
+ ast_state = to_ast_crtc_state(crtc->state);
+ format = ast_state->format;
+
+ if (format){
+ vbios_mode_info = &ast_state->vbios_mode_info;
+
+ ast_set_color_reg(ast, format);
+ ast_set_vbios_color_reg(ast, format, vbios_mode_info);
+ }
+
ast_crtc_load_lut(ast, crtc);
break;
case DRM_MODE_DPMS_STANDBY:
--
2.36.1
[View Less]
It's possible for users to try to duplicate the CRTC state even when the
state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other
users of __drm_atomic_helper_crtc_duplicate_state()) already guard this
with a WARN_ON() instead of crashing, so let's do that here too.
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/…
[View More]drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 74562d40f639..daf192881353 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1570,6 +1570,9 @@ static struct drm_crtc_state *vop_crtc_duplicate_state(struct drm_crtc *crtc)
{
struct rockchip_crtc_state *rockchip_state;
+ if (WARN_ON(!crtc->state))
+ return NULL;
+
rockchip_state = kzalloc(sizeof(*rockchip_state), GFP_KERNEL);
if (!rockchip_state)
return NULL;
--
2.36.1.476.g0c4daa206d-goog
[View Less]