July 2023 - Linux-stable-mirror

[PATCH v2] drm/i915/dpt: Use shmem for dpt objects

by Radhakrishna Sripada

Dpt objects that are created from internal get evicted when there is memory pressure and do not get restored when pinned during scanout. The pinned page table entries look corrupted and programming the display engine with the incorrect pte's result in DE throwing pipe faults. Create DPT objects from shmem and mark the object as dirty when pinning so that the object is restored when shrinker evicts an unpinned buffer object. v2: Unconditionally mark the dpt objects dirty during pinning(Chris). Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt") Cc: <stable(a)vger.kernel.org> # v6.0+ Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com> Suggested-by: Chris Wilson <chris.p.wilson(a)intel.com> Signed-off-by: Fei Yang <fei.yang(a)intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada(a)intel.com> --- drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c b/drivers/gpu/drm/i915/display/intel_dpt.c index 7c5fddb203ba..fbfd8f959f17 100644 --- a/drivers/gpu/drm/i915/display/intel_dpt.c +++ b/drivers/gpu/drm/i915/display/intel_dpt.c @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm) i915_vma_get(vma); } + dpt->obj->mm.dirty = true; + atomic_dec(&i915->gpu_error.pending_fb_pin); intel_runtime_pm_put(&i915->runtime_pm, wakeref); @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb) dpt_obj = i915_gem_object_create_stolen(i915, size); if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) { drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n"); - dpt_obj = i915_gem_object_create_internal(i915, size); + dpt_obj = i915_gem_object_create_shmem(i915, size); } if (IS_ERR(dpt_obj)) return ERR_CAST(dpt_obj); -- 2.34.1

2 years, 3 months

4
7
0 0

[PATCH net] can: raw: fix lockdep issue in raw_release()

by Eric Dumazet

syzbot complained about a lockdep issue [1] Since raw_bind() and raw_setsockopt() first get RTNL before locking the socket, we must adopt the same order in raw_release() [1] WARNING: possible circular locking dependency detected 6.5.0-rc1-syzkaller-00192-g78adb4bcf99e #0 Not tainted ------------------------------------------------------ syz-executor.0/14110 is trying to acquire lock: ffff88804e4b6130 (sk_lock-AF_CAN){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1708 [inline] ffff88804e4b6130 (sk_lock-AF_CAN){+.+.}-{0:0}, at: raw_bind+0xb1/0xab0 net/can/raw.c:435 but task is already holding lock: ffffffff8e3df368 (rtnl_mutex){+.+.}-{3:3}, at: raw_bind+0xa7/0xab0 net/can/raw.c:434 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x181/0x1340 kernel/locking/mutex.c:747 raw_release+0x1c6/0x9b0 net/can/raw.c:391 __sock_release+0xcd/0x290 net/socket.c:654 sock_close+0x1c/0x20 net/socket.c:1386 __fput+0x3fd/0xac0 fs/file_table.c:384 task_work_run+0x14d/0x240 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:297 do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #0 (sk_lock-AF_CAN){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x2e3d/0x5de0 kernel/locking/lockdep.c:5144 lock_acquire kernel/locking/lockdep.c:5761 [inline] lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726 lock_sock_nested+0x3a/0xf0 net/core/sock.c:3492 lock_sock include/net/sock.h:1708 [inline] raw_bind+0xb1/0xab0 net/can/raw.c:435 __sys_bind+0x1ec/0x220 net/socket.c:1792 __do_sys_bind net/socket.c:1803 [inline] __se_sys_bind net/socket.c:1801 [inline] __x64_sys_bind+0x72/0xb0 net/socket.c:1801 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(sk_lock-AF_CAN); lock(rtnl_mutex); lock(sk_lock-AF_CAN); *** DEADLOCK *** 1 lock held by syz-executor.0/14110: stack backtrace: CPU: 0 PID: 14110 Comm: syz-executor.0 Not tainted 6.5.0-rc1-syzkaller-00192-g78adb4bcf99e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 check_noncircular+0x311/0x3f0 kernel/locking/lockdep.c:2195 check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x2e3d/0x5de0 kernel/locking/lockdep.c:5144 lock_acquire kernel/locking/lockdep.c:5761 [inline] lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726 lock_sock_nested+0x3a/0xf0 net/core/sock.c:3492 lock_sock include/net/sock.h:1708 [inline] raw_bind+0xb1/0xab0 net/can/raw.c:435 __sys_bind+0x1ec/0x220 net/socket.c:1792 __do_sys_bind net/socket.c:1803 [inline] __se_sys_bind net/socket.c:1801 [inline] __x64_sys_bind+0x72/0xb0 net/socket.c:1801 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd89007cb29 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd890d2a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007fd89019bf80 RCX: 00007fd89007cb29 RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fd8900c847a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd89019bf80 R15: 00007ffebf8124f8 </TASK> Fixes: ee8b94c8510c ("can: raw: fix receiver memory leak") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Ziyang Xuan <william.xuanziyang(a)huawei.com> Cc: Oliver Hartkopp <socketcan(a)hartkopp.net> Cc: stable(a)vger.kernel.org Cc: Marc Kleine-Budde <mkl(a)pengutronix.de> --- net/can/raw.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/can/raw.c b/net/can/raw.c index 2302e48829677334f8b2d74a479e5a9cbb5ce03c..ba6b52b1d7767fdd7b57d1b8e5519495340c572c 100644 --- a/net/can/raw.c +++ b/net/can/raw.c @@ -386,9 +386,9 @@ static int raw_release(struct socket *sock) list_del(&ro->notifier); spin_unlock(&raw_notifier_lock); + rtnl_lock(); lock_sock(sk); - rtnl_lock(); /* remove current filters & unregister */ if (ro->bound) { if (ro->dev) @@ -405,12 +405,13 @@ static int raw_release(struct socket *sock) ro->dev = NULL; ro->count = 0; free_percpu(ro->uniq); - rtnl_unlock(); sock_orphan(sk); sock->sk = NULL; release_sock(sk); + rtnl_unlock(); + sock_put(sk); return 0; -- 2.41.0.255.g8b1d071c50-goog

2 years, 3 months

3
3
0 0

[PATCH v2] ceph: defer stopping the mdsc delayed_work

by xiubli＠redhat.com

From: Xiubo Li <xiubli(a)redhat.com> Flushing the dirty buffer may take a long time if the Rados is overloaded or if there is network issue. So we should ping the MDSs periodically to keep alive, else the MDS will blocklist the kclient. Cc: stable(a)vger.kernel.org Cc: Venky Shankar <vshankar(a)redhat.com> URL: https://tracker.ceph.com/issues/61843 Reviewed-by: Milind Changire <mchangir(a)redhat.com> Signed-off-by: Xiubo Li <xiubli(a)redhat.com> --- V2: - Fixed a typo in commit comment, thanks Milind. fs/ceph/mds_client.c | 2 +- fs/ceph/mds_client.h | 3 ++- fs/ceph/super.c | 7 ++++--- 3 files changed, 7 insertions(+), 5 deletions(-) diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c index 65230ebefd51..70987b3c198a 100644 --- a/fs/ceph/mds_client.c +++ b/fs/ceph/mds_client.c @@ -5192,7 +5192,7 @@ static void delayed_work(struct work_struct *work) doutc(mdsc->fsc->client, "mdsc delayed_work\n"); - if (mdsc->stopping) + if (mdsc->stopping >= CEPH_MDSC_STOPPING_FLUSHED) return; mutex_lock(&mdsc->mutex); diff --git a/fs/ceph/mds_client.h b/fs/ceph/mds_client.h index 5d02c8c582fd..befbd384428e 100644 --- a/fs/ceph/mds_client.h +++ b/fs/ceph/mds_client.h @@ -400,7 +400,8 @@ struct cap_wait { enum { CEPH_MDSC_STOPPING_BEGIN = 1, - CEPH_MDSC_STOPPING_FLUSHED = 2, + CEPH_MDSC_STOPPING_FLUSHING = 2, + CEPH_MDSC_STOPPING_FLUSHED = 3, }; /* diff --git a/fs/ceph/super.c b/fs/ceph/super.c index 0a370852cf02..49fd17fbba9f 100644 --- a/fs/ceph/super.c +++ b/fs/ceph/super.c @@ -1477,7 +1477,7 @@ static int ceph_init_fs_context(struct fs_context *fc) static bool __inc_stopping_blocker(struct ceph_mds_client *mdsc) { spin_lock(&mdsc->stopping_lock); - if (mdsc->stopping >= CEPH_MDSC_STOPPING_FLUSHED) { + if (mdsc->stopping >= CEPH_MDSC_STOPPING_FLUSHING) { spin_unlock(&mdsc->stopping_lock); return false; } @@ -1490,7 +1490,7 @@ static void __dec_stopping_blocker(struct ceph_mds_client *mdsc) { spin_lock(&mdsc->stopping_lock); if (!atomic_dec_return(&mdsc->stopping_blockers) && - mdsc->stopping >= CEPH_MDSC_STOPPING_FLUSHED) + mdsc->stopping >= CEPH_MDSC_STOPPING_FLUSHING) complete_all(&mdsc->stopping_waiter); spin_unlock(&mdsc->stopping_lock); } @@ -1551,7 +1551,7 @@ static void ceph_kill_sb(struct super_block *s) sync_filesystem(s); spin_lock(&mdsc->stopping_lock); - mdsc->stopping = CEPH_MDSC_STOPPING_FLUSHED; + mdsc->stopping = CEPH_MDSC_STOPPING_FLUSHING; wait = !!atomic_read(&mdsc->stopping_blockers); spin_unlock(&mdsc->stopping_lock); @@ -1565,6 +1565,7 @@ static void ceph_kill_sb(struct super_block *s) pr_warn_client(cl, "umount was killed, %ld\n", timeleft); } + mdsc->stopping = CEPH_MDSC_STOPPING_FLUSHED; kill_anon_super(s); fsc->client->extra_mon_dispatch = NULL; -- 2.40.1

2 years, 3 months

3
4
0 0

stable-rc/linux-5.4.y build: 1 build: 0 failed, 1 passed, 2 warnings (v5.4.249-315-g2b5f78e632440)

by kernelci.org bot

stable-rc/linux-5.4.y build: 1 build: 0 failed, 1 passed, 2 warnings (v5.4.249-315-g2b5f78e632440) Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.4.y/kernel/v5.4.249-315… Tree: stable-rc Branch: linux-5.4.y Git Describe: v5.4.249-315-g2b5f78e632440 Git Commit: 2b5f78e63244061899701db2e38e46a3a7f83be6 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Built: 1 unique architecture Warnings Detected: i386: allnoconfig (gcc-10): 2 warnings Warnings summary: 1 ld: warning: creating DT_TEXTREL in a PIE 1 ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text' ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- allnoconfig (i386, gcc-10) — PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text' ld: warning: creating DT_TEXTREL in a PIE --- For more info write to <info(a)kernelci.org>

2 years, 3 months

1
0
0 0

stable-rc/linux-6.1.y build: 2 builds: 0 failed, 2 passed (v6.1.40-172-gd796cfd075afc)

by kernelci.org bot

stable-rc/linux-6.1.y build: 2 builds: 0 failed, 2 passed (v6.1.40-172-gd796cfd075afc) Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-6.1.y/kernel/v6.1.40-172-… Tree: stable-rc Branch: linux-6.1.y Git Describe: v6.1.40-172-gd796cfd075afc Git Commit: d796cfd075afc1c50fd811cd00d8844e6749641d Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Built: 1 unique architecture ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- nommu_k210_defconfig (riscv, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- rv32_defconfig (riscv, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches --- For more info write to <info(a)kernelci.org>

2 years, 3 months

1
0
0 0

[PATCH AUTOSEL 6.1 01/41] drm/amd/display: Do not set drr on pipe commit

by Sasha Levin

From: Wesley Chalmers <Wesley.Chalmers(a)amd.com> [ Upstream commit e101bf95ea87ccc03ac2f48dfc0757c6364ff3c7 ] [WHY] Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a pipe commit can cause underflow. [HOW] Move DMUB p-state delegate into optimze_bandwidth; enabling FAMS sets optimized_required. This change expects that Freesync requests are blocked when optimized_required is true. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira(a)amd.com> Signed-off-by: Wesley Chalmers <Wesley.Chalmers(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 6 ++++++ drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 7 +++++++ 2 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c index 2d49e99a152c4..7ff4a308152a0 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c @@ -2021,6 +2021,12 @@ void dcn20_optimize_bandwidth( if (hubbub->funcs->program_compbuf_size) hubbub->funcs->program_compbuf_size(hubbub, context->bw_ctx.bw.dcn.compbuf_size_kb, true); + if (context->bw_ctx.bw.dcn.clk.fw_based_mclk_switching) { + dc_dmub_srv_p_state_delegate(dc, + true, context); + context->bw_ctx.bw.dcn.clk.p_state_change_support = true; + } + dc->clk_mgr->funcs->update_clocks( dc->clk_mgr, context, diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c index a1b312483d7f1..c97d3e81a83d2 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c @@ -987,11 +987,18 @@ void dcn30_set_disp_pattern_generator(const struct dc *dc, void dcn30_prepare_bandwidth(struct dc *dc, struct dc_state *context) { + if (context->bw_ctx.bw.dcn.clk.fw_based_mclk_switching) { + dc->optimized_required = true; + context->bw_ctx.bw.dcn.clk.p_state_change_support = false; + } + if (dc->clk_mgr->dc_mode_softmax_enabled) if (dc->clk_mgr->clks.dramclk_khz <= dc->clk_mgr->bw_params->dc_mode_softmax_memclk * 1000 && context->bw_ctx.bw.dcn.clk.dramclk_khz > dc->clk_mgr->bw_params->dc_mode_softmax_memclk * 1000) dc->clk_mgr->funcs->set_max_memclk(dc->clk_mgr, dc->clk_mgr->bw_params->clk_table.entries[dc->clk_mgr->bw_params->clk_table.num_entries - 1].memclk_mhz); dcn20_prepare_bandwidth(dc, context); + + dc_dmub_srv_p_state_delegate(dc, false, context); } -- 2.39.2

2 years, 3 months

2
41
0 0

[PATCH] riscv: Implement missing huge_ptep_get

by Petko Manolov

From: Alexandre Ghiti <alexghiti(a)rivosinc.com> huge_ptep_get must be reimplemented in order to go through all the PTEs of a NAPOT region: this is needed because the HW can update the A/D bits of any of the PTE that constitutes the NAPOT region. Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page") Signed-off-by: Alexandre Ghiti <alexghiti(a)rivosinc.com> Reviewed-by: Andrew Jones <ajones(a)ventanamicro.com> Link: https://lore.kernel.org/r/20230428120120.21620-2-alexghiti@rivosinc.com Cc: stable(a)vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer(a)rivosinc.com> Signed-off-by: Petko Manolov <petko.manolov(a)konsulko.com> --- arch/riscv/include/asm/hugetlb.h | 3 +++ arch/riscv/mm/hugetlbpage.c | 24 ++++++++++++++++++++++++ 2 files changed, 27 insertions(+) diff --git a/arch/riscv/include/asm/hugetlb.h b/arch/riscv/include/asm/hugetlb.h index fe6f23006641..ce1ebda1a49a 100644 --- a/arch/riscv/include/asm/hugetlb.h +++ b/arch/riscv/include/asm/hugetlb.h @@ -36,6 +36,9 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, pte_t pte, int dirty); +#define __HAVE_ARCH_HUGE_PTEP_GET +pte_t huge_ptep_get(pte_t *ptep); + pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, vm_flags_t flags); #define arch_make_huge_pte arch_make_huge_pte diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c index 238d00bdac14..e0ef56dc57b9 100644 --- a/arch/riscv/mm/hugetlbpage.c +++ b/arch/riscv/mm/hugetlbpage.c @@ -3,6 +3,30 @@ #include <linux/err.h> #ifdef CONFIG_RISCV_ISA_SVNAPOT +pte_t huge_ptep_get(pte_t *ptep) +{ + unsigned long pte_num; + int i; + pte_t orig_pte = ptep_get(ptep); + + if (!pte_present(orig_pte) || !pte_napot(orig_pte)) + return orig_pte; + + pte_num = napot_pte_num(napot_cont_order(orig_pte)); + + for (i = 0; i < pte_num; i++, ptep++) { + pte_t pte = ptep_get(ptep); + + if (pte_dirty(pte)) + orig_pte = pte_mkdirty(orig_pte); + + if (pte_young(pte)) + orig_pte = pte_mkyoung(orig_pte); + } + + return orig_pte; +} + pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, -- 2.39.2

2 years, 3 months

2
2
0 0

[PATCH AUTOSEL 4.14 1/9] drm/radeon: Fix integer overflow in radeon_cs_parser_init

by Sasha Levin

From: hackyzh002 <hackyzh002(a)gmail.com> [ Upstream commit f828b681d0cd566f86351c0b913e6cb6ed8c7b9c ] The type of size is unsigned, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: hackyzh002 <hackyzh002(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/radeon/radeon_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index 1ae31dbc61c64..5e61abb3dce5c 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -265,7 +265,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data) { struct drm_radeon_cs *cs = data; uint64_t *chunk_array_ptr; - unsigned size, i; + u64 size; + unsigned i; u32 ring = RADEON_CS_RING_GFX; s32 priority = 0; -- 2.39.2

2 years, 3 months

2
1
0 0

Re: [PATCH v8 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

by Andi Shyti

Hi Nirmoy, > static int mtl_dummy_pipe_control(struct i915_request *rq) > { > /* Wa_14016712196 */ > if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) || > - IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) { > - u32 *cs; > - > - /* dummy PIPE_CONTROL + depth flush */ > - cs = intel_ring_begin(rq, 6); > - if (IS_ERR(cs)) > - return PTR_ERR(cs); > - cs = gen12_emit_pipe_control(cs, > - 0, > - PIPE_CONTROL_DEPTH_CACHE_FLUSH, > - LRC_PPHWSP_SCRATCH_ADDR); > - intel_ring_advance(rq, cs); > - } > + IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) > + return gen12_emit_pipe_control_cs(rq, 0, > + PIPE_CONTROL_DEPTH_CACHE_FLUSH, > + LRC_PPHWSP_SCRATCH_ADDR); > > Don't think this will get backported to 5.8+. I think mtl introduced after > that. > > If that is not an issue for rest of the series and then to be honest I don't think I fully understood the stable policies, as in this series only two are the patches that are really fixing things and the rest are only support. In this case I think this will produce a conflict that will be eventually fixed (... I guess!). > Reviewed-by: Nirmoy Das <nirmoy.das(a)intel.com> Thanks, Andi

2 years, 3 months

2
1
0 0

stable-rc/linux-4.19.y build: 2 builds: 0 failed, 2 passed, 6 warnings (v4.19.288-219-g690c38297b4b9)

by kernelci.org bot

stable-rc/linux-4.19.y build: 2 builds: 0 failed, 2 passed, 6 warnings (v4.19.288-219-g690c38297b4b9) Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.288-2… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.288-219-g690c38297b4b9 Git Commit: 690c38297b4b9c17176226953c3c7ce9d4e938bb Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Built: 2 unique architectures Warnings Detected: mips: 32r2el_defconfig (gcc-10): 1 warning x86_64: x86_64_defconfig (gcc-10): 5 warnings Warnings summary: 2 fs/ext4/ioctl.c:583:7: warning: assignment to ‘int’ from ‘struct super_block *’ makes integer from pointer without a cast [-Wint-conversion] 1 ld: warning: creating DT_TEXTREL in a PIE 1 ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text' 1 drivers/gpu/drm/drm_edid.o: warning: objtool: validate_displayid.constprop.0()+0x6a: return with modified stack frame 1 drivers/gpu/drm/drm_edid.o: warning: objtool: validate_displayid.constprop.0()+0x0: stack state mismatch: cfa1=7+112 cfa2=7+8 ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- 32r2el_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: fs/ext4/ioctl.c:583:7: warning: assignment to ‘int’ from ‘struct super_block *’ makes integer from pointer without a cast [-Wint-conversion] -------------------------------------------------------------------------------- x86_64_defconfig (x86_64, gcc-10) — PASS, 0 errors, 5 warnings, 0 section mismatches Warnings: fs/ext4/ioctl.c:583:7: warning: assignment to ‘int’ from ‘struct super_block *’ makes integer from pointer without a cast [-Wint-conversion] drivers/gpu/drm/drm_edid.o: warning: objtool: validate_displayid.constprop.0()+0x6a: return with modified stack frame drivers/gpu/drm/drm_edid.o: warning: objtool: validate_displayid.constprop.0()+0x0: stack state mismatch: cfa1=7+112 cfa2=7+8 ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text' ld: warning: creating DT_TEXTREL in a PIE --- For more info write to <info(a)kernelci.org>

2 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2023