> -----Original Message----- > From: Stephen Boyd <swboyd@xxxxxxxxxxxx> > Sent: Monday, March 27, 2023 9:58 PM > To: Bjorn Andersson <andersson@xxxxxxxxxx>; Vinod Polimera (QUIC) > <quic_vpolimer@xxxxxxxxxxx> > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx; linux-arm-msm@xxxxxxxxxxxxxxx; > freedreno@xxxxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; robdclark@xxxxxxxxx; dianders@xxxxxxxxxxxx; > Kalyan Thota (QUIC) <quic_kalyant@xxxxxxxxxxx>; > dmitry.baryshkov@xxxxxxxxxx; Kuogee Hsieh (QUIC) > <quic_khsieh@xxxxxxxxxxx>; Vishnuvardhan Prodduturi (QUIC) > <quic_vproddut@xxxxxxxxxxx>; Bjorn Andersson (QUIC) > <quic_bjorande@xxxxxxxxxxx>; Abhinav Kumar (QUIC) > <quic_abhinavk@xxxxxxxxxxx>; Sankeerth Billakanti (QUIC) > <quic_sbillaka@xxxxxxxxxxx> > Subject: Re: [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. I was able to reproduce the issue where in virtual terminal, I don't see any screen refresh despite typing in. In the VT mode, I see that PSR is entered, but despite typing in there are no atomic commits triggered, hence the last buffer was always refreshed. Queries from my side to Rob & Doug: 1) In VT mode, does the framework operates in single buffer mode without any commit for new updates ? 2) if above is true then, how does driver know if the framework operates in single buffer mode, to make any appropriate action 3) what is the expected behavior with the driver here ? should it return atomic_check failure, for single buffer mode operation or, it should exit PSR ? 4) is there any HINT passed down to the driver so that we can bank on it and act accordingly? Thanks, Vinod P.
