Re: [Freedreno] [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
> -Original Message-
> From: Mark Yacoub
> Sent: Saturday, March 25, 2023 12:57 AM
> To: Kandpal, Suraj
> Cc: quic_khs...@quicinc.com; linux-arm-...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; freedreno@lists.freedesktop.org;
> devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; intel-
> g...@lists.freedesktop.org; quic_sbill...@quicinc.com;
> konrad.dyb...@somainline.org; Souza, Jose ;
> bjorn.anders...@linaro.org; krzysztof.kozlowski...@linaro.org;
> hbh...@gmail.com; Vasut, Marek ; Dixit, Ashutosh
> ; s...@poorly.run; abhin...@codeaurora.org;
> javi...@redhat.com; Murthy, Arun R ; Lisovskiy,
> Stanislav ; agr...@kernel.org;
> quic_jessz...@quicinc.com; Nautiyal, Ankit K ;
> Nikula, Jani ; De Marchi, Lucas
> ; quic_abhin...@quicinc.com;
> swb...@chromium.org; robh...@kernel.org;
> christophe.jail...@wanadoo.fr; max...@cerno.tech; Vivi, Rodrigo
> ; johan+lin...@kernel.org;
> tvrtko.ursu...@linux.intel.com; anders...@kernel.org;
> diand...@chromium.org; Sharma, Swati2 ;
> Navare, Manasi D ; tzimmerm...@suse.de;
> Modem, Bhanuprakash ;
> dmitry.barysh...@linaro.org; seanp...@chromium.org
> Subject: Re: [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable return
> codes
>
> On Thu, Mar 23, 2023 at 3:18 AM Kandpal, Suraj
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Kandpal, Suraj
> > > Sent: Friday, March 10, 2023 1:55 PM
> > > To: Mark Yacoub ;
> quic_khs...@quicinc.com;
> > > linux-arm-...@vger.kernel.org; dri-de...@lists.freedesktop.org;
> > > freedreno@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; intel-...@lists.freedesktop.org
> > > Cc: quic_sbill...@quicinc.com; konrad.dyb...@somainline.org; Souza,
> > > Jose ; bjorn.anders...@linaro.org;
> > > krzysztof.kozlowski...@linaro.org; hbh...@gmail.com; Vasut, Marek
> > > ; Dixit, Ashutosh ;
> > > s...@poorly.run; abhin...@codeaurora.org; javi...@redhat.com;
> > > Murthy, Arun R ; Lisovskiy, Stanislav
> > > ; agr...@kernel.org;
> > > quic_jessz...@quicinc.com; Nautiyal, Ankit K
> > > ; Nikula, Jani ;
> > > De Marchi, Lucas ;
> > > quic_abhin...@quicinc.com; swb...@chromium.org;
> robh...@kernel.org;
> > > christophe.jail...@wanadoo.fr; max...@cerno.tech; Vivi, Rodrigo
> > > ; johan+lin...@kernel.org;
> > > tvrtko.ursu...@linux.intel.com; anders...@kernel.org;
> > > diand...@chromium.org; Sharma, Swati2 ;
> > > Navare, Manasi D ;
> tzimmerm...@suse.de;
> > > Modem, Bhanuprakash ;
> > > dmitry.barysh...@linaro.org; seanp...@chromium.org
> > > Subject: RE: [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable
> > > return codes
> > >
> > > > Subject: [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable
> > > > return codes
> > > >
> > > > From: Sean Paul
> > > >
> > > > The shim functions return error codes, but they are discarded in
> > > > intel_hdcp.c. This patch plumbs the return codes through so they
> > > > are properly handled.
> > > >
> > > > Acked-by: Jani Nikula
> > > > Reviewed-by: Rodrigo Vivi
> > > > Signed-off-by: Sean Paul
> > > > Signed-off-by: Mark Yacoub
> > > > Link:
> > > >
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456
> > > > -7-
> > > > s...@poorly.run #v1
> > > > Link:
> > > >
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-
> > > > 7-
> > > > s...@poorly.run #v2
> > > > Link:
> > > >
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916
> > > > -7-
> > > > s...@poorly.run #v3
> > > > Link:
> > > >
> > >
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845
> > > -
> > > > 7-s...@poorly.run #v4
> > > > Link:
> > > >
> > >
> https://patchwork.freedesktop.org/patch/msgid/20220411204741.1074308
> > > -
> > > > 7-s...@poorly.run #v5
> > > >
> > > > Changes in v2:
> > > > -None
> > > > Changes in v3:
> > > > -None
> > > > Changes in v4:
> > > > -None
> > > > Changes in v5:
> > > > -None
> > > > Changes in v6:
> > > > -Rebased
> > > >
> > > > ---
> > > > .../drm/i915/display/intel_display_debugfs.c | 9 +++-
> > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
> > > > drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
> > > > 3 files changed, 37 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > index 7c7253a2541c..13a4153bb76e 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > @@ -492,6 +492,7 @@ static void intel_panel_info(struct seq_file
> > > > *m, static void intel_hdcp_info(struct seq_file *m,
> > > > struct intel_connector *intel_connector)
> > > > {
> > > > + int ret;
> > > > bool hdcp_cap, hdcp2_cap;
> > > >
> > > > if (!intel_connector->hdcp.shim) { @@ -499,8 +500,12 @@ static
> > > > void intel_hdcp_info(struct seq_file *m,
> > > > goto out;
> > > > }
> > > >
Re: [Freedreno] [PATCH v2 17/23] PM / QoS: Fix constraints alloc vs reclaim locking
On Mon, Mar 27, 2023 at 10:53 AM Rafael J. Wysocki wrote:
>
> On Mon, Mar 20, 2023 at 3:45 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > In the process of adding lockdep annotation for drm GPU scheduler's
> > job_run() to detect potential deadlock against shrinker/reclaim, I hit
> > this lockdep splat:
> >
> >==
> >WARNING: possible circular locking dependency detected
> >6.2.0-rc8-debug+ #558 Tainted: GW
> >--
> >ring0/125 is trying to acquire lock:
> >ffd6d6ce0f28 (dev_pm_qos_mtx){+.+.}-{3:3}, at:
> > dev_pm_qos_update_request+0x38/0x68
> >
> >but task is already holding lock:
> >ff8087239208 (>active_lock){+.+.}-{3:3}, at:
> > msm_gpu_submit+0xec/0x178
> >
> >which lock already depends on the new lock.
> >
> >the existing dependency chain (in reverse order) is:
> >
> >-> #4 (>active_lock){+.+.}-{3:3}:
> > __mutex_lock+0xcc/0x3c8
> > mutex_lock_nested+0x30/0x44
> > msm_gpu_submit+0xec/0x178
> > msm_job_run+0x78/0x150
> > drm_sched_main+0x290/0x370
> > kthread+0xf0/0x100
> > ret_from_fork+0x10/0x20
> >
> >-> #3 (dma_fence_map){}-{0:0}:
> > __dma_fence_might_wait+0x74/0xc0
> > dma_resv_lockdep+0x1f4/0x2f4
> > do_one_initcall+0x104/0x2bc
> > kernel_init_freeable+0x344/0x34c
> > kernel_init+0x30/0x134
> > ret_from_fork+0x10/0x20
> >
> >-> #2 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
> > fs_reclaim_acquire+0x80/0xa8
> > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > __kmem_cache_alloc_node+0x60/0x1cc
> > __kmalloc+0xd8/0x100
> > topology_parse_cpu_capacity+0x8c/0x178
> > get_cpu_for_node+0x88/0xc4
> > parse_cluster+0x1b0/0x28c
> > parse_cluster+0x8c/0x28c
> > init_cpu_topology+0x168/0x188
> > smp_prepare_cpus+0x24/0xf8
> > kernel_init_freeable+0x18c/0x34c
> > kernel_init+0x30/0x134
> > ret_from_fork+0x10/0x20
> >
> >-> #1 (fs_reclaim){+.+.}-{0:0}:
> > __fs_reclaim_acquire+0x3c/0x48
> > fs_reclaim_acquire+0x54/0xa8
> > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > __kmem_cache_alloc_node+0x60/0x1cc
> > kmalloc_trace+0x50/0xa8
> > dev_pm_qos_constraints_allocate+0x38/0x100
> > __dev_pm_qos_add_request+0xb0/0x1e8
> > dev_pm_qos_add_request+0x58/0x80
> > dev_pm_qos_expose_latency_limit+0x60/0x13c
> > register_cpu+0x12c/0x130
> > topology_init+0xac/0xbc
> > do_one_initcall+0x104/0x2bc
> > kernel_init_freeable+0x344/0x34c
> > kernel_init+0x30/0x134
> > ret_from_fork+0x10/0x20
> >
> >-> #0 (dev_pm_qos_mtx){+.+.}-{3:3}:
> > __lock_acquire+0xe00/0x1060
> > lock_acquire+0x1e0/0x2f8
> > __mutex_lock+0xcc/0x3c8
> > mutex_lock_nested+0x30/0x44
> > dev_pm_qos_update_request+0x38/0x68
> > msm_devfreq_boost+0x40/0x70
> > msm_devfreq_active+0xc0/0xf0
> > msm_gpu_submit+0x10c/0x178
> > msm_job_run+0x78/0x150
> > drm_sched_main+0x290/0x370
> > kthread+0xf0/0x100
> > ret_from_fork+0x10/0x20
> >
> >other info that might help us debug this:
> >
> >Chain exists of:
> > dev_pm_qos_mtx --> dma_fence_map --> >active_lock
> >
> > Possible unsafe locking scenario:
> >
> > CPU0CPU1
> >
> > lock(>active_lock);
> > lock(dma_fence_map);
> > lock(>active_lock);
> > lock(dev_pm_qos_mtx);
> >
> > *** DEADLOCK ***
> >
> >3 locks held by ring0/123:
> > #0: ff8087251170 (>lock){+.+.}-{3:3}, at:
> > msm_job_run+0x64/0x150
> > #1: ffd00b0e57e8 (dma_fence_map){}-{0:0}, at:
> > msm_job_run+0x68/0x150
> > #2: ff8087251208 (>active_lock){+.+.}-{3:3}, at:
> > msm_gpu_submit+0xec/0x178
> >
> >stack backtrace:
> >CPU: 6 PID: 123 Comm: ring0 Not tainted 6.2.0-rc8-debug+ #559
> >Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
> >Call trace:
> > dump_backtrace.part.0+0xb4/0xf8
> > show_stack+0x20/0x38
> > dump_stack_lvl+0x9c/0xd0
> > dump_stack+0x18/0x34
> > print_circular_bug+0x1b4/0x1f0
> > check_noncircular+0x78/0xac
> > __lock_acquire+0xe00/0x1060
> > lock_acquire+0x1e0/0x2f8
> > __mutex_lock+0xcc/0x3c8
> > mutex_lock_nested+0x30/0x44
> > dev_pm_qos_update_request+0x38/0x68
> > msm_devfreq_boost+0x40/0x70
> > msm_devfreq_active+0xc0/0xf0
> > msm_gpu_submit+0x10c/0x178
> > msm_job_run+0x78/0x150
> > drm_sched_main+0x290/0x370
> >
Re: [Freedreno] [PATCH v10 00/15] dma-fence: Deadline awareness
On Wed, Mar 8, 2023 at 10:53 AM Rob Clark wrote: > > From: Rob Clark > > This series adds a deadline hint to fences, so realtime deadlines > such as vblank can be communicated to the fence signaller for power/ > frequency management decisions. > > This is partially inspired by a trick i915 does, but implemented > via dma-fence for a couple of reasons: > > 1) To continue to be able to use the atomic helpers > 2) To support cases where display and gpu are different drivers > > This iteration adds a dma-fence ioctl to set a deadline (both to > support igt-tests, and compositors which delay decisions about which > client buffer to display), and a sw_sync ioctl to read back the > deadline. IGT tests utilizing these can be found at: I read through the series and didn't spot anything. Have a rather weak Reviewed-by: Matt Turner Thanks!
Re: [Freedreno] [PATCH v2 17/23] PM / QoS: Fix constraints alloc vs reclaim locking
On Mon, Mar 20, 2023 at 3:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> In the process of adding lockdep annotation for drm GPU scheduler's
> job_run() to detect potential deadlock against shrinker/reclaim, I hit
> this lockdep splat:
>
>==
>WARNING: possible circular locking dependency detected
>6.2.0-rc8-debug+ #558 Tainted: GW
>--
>ring0/125 is trying to acquire lock:
>ffd6d6ce0f28 (dev_pm_qos_mtx){+.+.}-{3:3}, at:
> dev_pm_qos_update_request+0x38/0x68
>
>but task is already holding lock:
>ff8087239208 (>active_lock){+.+.}-{3:3}, at:
> msm_gpu_submit+0xec/0x178
>
>which lock already depends on the new lock.
>
>the existing dependency chain (in reverse order) is:
>
>-> #4 (>active_lock){+.+.}-{3:3}:
> __mutex_lock+0xcc/0x3c8
> mutex_lock_nested+0x30/0x44
> msm_gpu_submit+0xec/0x178
> msm_job_run+0x78/0x150
> drm_sched_main+0x290/0x370
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
>-> #3 (dma_fence_map){}-{0:0}:
> __dma_fence_might_wait+0x74/0xc0
> dma_resv_lockdep+0x1f4/0x2f4
> do_one_initcall+0x104/0x2bc
> kernel_init_freeable+0x344/0x34c
> kernel_init+0x30/0x134
> ret_from_fork+0x10/0x20
>
>-> #2 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
> fs_reclaim_acquire+0x80/0xa8
> slab_pre_alloc_hook.constprop.0+0x40/0x25c
> __kmem_cache_alloc_node+0x60/0x1cc
> __kmalloc+0xd8/0x100
> topology_parse_cpu_capacity+0x8c/0x178
> get_cpu_for_node+0x88/0xc4
> parse_cluster+0x1b0/0x28c
> parse_cluster+0x8c/0x28c
> init_cpu_topology+0x168/0x188
> smp_prepare_cpus+0x24/0xf8
> kernel_init_freeable+0x18c/0x34c
> kernel_init+0x30/0x134
> ret_from_fork+0x10/0x20
>
>-> #1 (fs_reclaim){+.+.}-{0:0}:
> __fs_reclaim_acquire+0x3c/0x48
> fs_reclaim_acquire+0x54/0xa8
> slab_pre_alloc_hook.constprop.0+0x40/0x25c
> __kmem_cache_alloc_node+0x60/0x1cc
> kmalloc_trace+0x50/0xa8
> dev_pm_qos_constraints_allocate+0x38/0x100
> __dev_pm_qos_add_request+0xb0/0x1e8
> dev_pm_qos_add_request+0x58/0x80
> dev_pm_qos_expose_latency_limit+0x60/0x13c
> register_cpu+0x12c/0x130
> topology_init+0xac/0xbc
> do_one_initcall+0x104/0x2bc
> kernel_init_freeable+0x344/0x34c
> kernel_init+0x30/0x134
> ret_from_fork+0x10/0x20
>
>-> #0 (dev_pm_qos_mtx){+.+.}-{3:3}:
> __lock_acquire+0xe00/0x1060
> lock_acquire+0x1e0/0x2f8
> __mutex_lock+0xcc/0x3c8
> mutex_lock_nested+0x30/0x44
> dev_pm_qos_update_request+0x38/0x68
> msm_devfreq_boost+0x40/0x70
> msm_devfreq_active+0xc0/0xf0
> msm_gpu_submit+0x10c/0x178
> msm_job_run+0x78/0x150
> drm_sched_main+0x290/0x370
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
>other info that might help us debug this:
>
>Chain exists of:
> dev_pm_qos_mtx --> dma_fence_map --> >active_lock
>
> Possible unsafe locking scenario:
>
> CPU0CPU1
>
> lock(>active_lock);
> lock(dma_fence_map);
> lock(>active_lock);
> lock(dev_pm_qos_mtx);
>
> *** DEADLOCK ***
>
>3 locks held by ring0/123:
> #0: ff8087251170 (>lock){+.+.}-{3:3}, at: msm_job_run+0x64/0x150
> #1: ffd00b0e57e8 (dma_fence_map){}-{0:0}, at:
> msm_job_run+0x68/0x150
> #2: ff8087251208 (>active_lock){+.+.}-{3:3}, at:
> msm_gpu_submit+0xec/0x178
>
>stack backtrace:
>CPU: 6 PID: 123 Comm: ring0 Not tainted 6.2.0-rc8-debug+ #559
>Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
>Call trace:
> dump_backtrace.part.0+0xb4/0xf8
> show_stack+0x20/0x38
> dump_stack_lvl+0x9c/0xd0
> dump_stack+0x18/0x34
> print_circular_bug+0x1b4/0x1f0
> check_noncircular+0x78/0xac
> __lock_acquire+0xe00/0x1060
> lock_acquire+0x1e0/0x2f8
> __mutex_lock+0xcc/0x3c8
> mutex_lock_nested+0x30/0x44
> dev_pm_qos_update_request+0x38/0x68
> msm_devfreq_boost+0x40/0x70
> msm_devfreq_active+0xc0/0xf0
> msm_gpu_submit+0x10c/0x178
> msm_job_run+0x78/0x150
> drm_sched_main+0x290/0x370
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
> The issue is that dev_pm_qos_mtx is held in the runpm suspend/resume (or
> freq change) path, but it is also held across allocations that could
> recurse into shrinker.
>
> Solve this by changing dev_pm_qos_constraints_allocate() into a function
> that can be called unconditionally before
Re: [Freedreno] [PATCH v14 14/14] drm/msm/dp: set self refresh aware based on PSR support
Quoting Bjorn Andersson (2023-03-26 09:35:56) > On Sun, Mar 26, 2023 at 09:27:23AM -0700, Bjorn Andersson wrote: > > On Thu, Mar 02, 2023 at 10:03:17PM +0530, Vinod Polimera wrote: > > > For the PSR to kick in, self_refresh_aware has to be set. > > > Initialize it based on the PSR support for the eDP interface. > > > > > > > When I boot my sc8280xp devices (CRD and X13s) to console with this > > patch included I get a login prompt, and then there are no more screen > > updates. > > > > Switching virtual terminal (ctrl+alt+fN) causes the screen to redraw. > > > > Blindly login in and launching Wayland works and from then on screen > > updates works as expected. > > > > Switching from Wayland to another virtual terminal causes the problem to > > re-appear, no updates after the initial refresh, switching back go the > > Wayland-terminal crashed the machine. > > > > Also, trying to bring the eDP-screen back from DPMS gives me: > > <3>[ 2355.218099] [drm:dp_catalog_ctrl_set_pattern_state_bit [msm]] *ERROR* > set state_bit for link_train=1 failed > <3>[ 2355.218926] [drm:dp_ctrl_setup_main_link [msm]] *ERROR* link training > #1 failed. ret=-110 > <3>[ 2355.262859] [drm:dp_catalog_ctrl_set_pattern_state_bit [msm]] *ERROR* > set state_bit for link_train=1 failed > <3>[ 2355.263600] [drm:dp_ctrl_setup_main_link [msm]] *ERROR* link training > #1 failed. ret=-110 > <3>[ 2355.305211] [drm:dp_catalog_ctrl_set_pattern_state_bit [msm]] *ERROR* > set state_bit for link_train=1 failed > <3>[ 2355.305955] [drm:dp_ctrl_setup_main_link [msm]] *ERROR* link training > #1 failed. ret=-110 > <3>[ 2355.345250] [drm:dp_catalog_ctrl_set_pattern_state_bit [msm]] *ERROR* > set state_bit for link_train=1 failed > <3>[ 2355.346026] [drm:dp_ctrl_setup_main_link [msm]] *ERROR* link training > #1 failed. ret=-110 > <3>[ 2355.405650] [drm:dp_display_process_hpd_high [msm]] *ERROR* failed to > complete DP link training > <3>[ 2355.668988] [drm:dpu_encoder_phys_vid_wait_for_commit_done:488] [dpu > error]vblank timeout > <3>[ 2355.669030] [drm:dpu_kms_wait_for_commit_done:510] [dpu error]wait for > commit done returned -110 > <3>[ 2355.699989] [drm:dpu_encoder_frame_done_timeout:2398] [dpu error]enc35 > frame done timeout > > And then the machine just resets. > I saw similar behavior on ChromeOS after we picked the PSR patches into our kernel. I suspect it's the same problem. I switched back and forth between VT2 and the OOBE screen with ctrl+alt+forward and that showed what I typed on the virtual terminal after switching back and forth. It's like the redraw only happens once on the switch and never again. I switched back and forth enough times that it eventually crashed the kernel and rebooted. This was on CRD (sc7280-herobrine-crd.dts). There's an animation on the OOBE screen that is working though, so perhaps PSR is working with the chrome compositor but not the virtual terminal? I haven't investigated.
