From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E441C3F2D1 for ; Thu, 5 Mar 2020 08:14:53 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E37AF2073D for ; Thu, 5 Mar 2020 08:14:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=onstation.org header.i=@onstation.org header.b="okSj8k7l" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E37AF2073D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=onstation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2525A6EB80; Thu, 5 Mar 2020 08:14:39 +0000 (UTC) Received: from onstation.org (onstation.org [52.200.56.107]) by gabe.freedesktop.org (Postfix) with ESMTPS id 31A3B89BF5 for ; Wed, 4 Mar 2020 10:00:34 +0000 (UTC) Received: from localhost (c-98-239-145-235.hsd1.wv.comcast.net [98.239.145.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: masneyb) by onstation.org (Postfix) with ESMTPSA id B96993E8F4; Wed, 4 Mar 2020 10:00:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=onstation.org; s=default; t=1583316033; bh=QUHm+FaJ6wpp4KgeHpumi7B+7h8KKtl6vzaRMOuv5e0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=okSj8k7lKiNY0iqjMycZyla+48SxpL51eXVth0h0YB/Pcf5vdGTBhUI3wwsDhTxHF AfGst9kPLpioFL7IQlePs/4E9habqo5igAPGkkg26qiVSZzr+bbWiKFY3lt4dk5buo LOfD88aegwcy0+4wEKPBCeS5hfX5HlHge5QRxWa8= Date: Wed, 4 Mar 2020 05:00:32 -0500 From: Brian Masney To: Jonathan Marek Subject: Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7 Message-ID: <20200304100032.GA18958@onstation.org> References: <20200303031335.GA7208@onstation.org> <8f47109f-796e-8cd5-d05e-8cdf2d0665ed@marek.ca> <836f8308-b648-52ff-aa71-448ff0130931@marek.ca> <20200303122643.GA10088@onstation.org> <20200304021624.GA16870@onstation.org> <20200304025354.GA17518@onstation.org> <30e32ce4-d958-6cb9-e0f7-8de9377562ce@marek.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <30e32ce4-d958-6cb9-e0f7-8de9377562ce@marek.ca> X-Mailman-Approved-At: Thu, 05 Mar 2020 08:14:30 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dri-devel@lists.freedesktop.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Mar 03, 2020 at 10:04:56PM -0500, Jonathan Marek wrote: > If I have time to kill over the weekend I'll do a new rebase of my Nexus 5 > patches (my last rebase was back in August on 5.2, and the panel was work= ing > correctly at 60Hz back then). That would be great if you have time to look at the panel. My out-of-tree patches for this phone are at https://github.com/masneyb/linux/commits/v5.5-nexus5. A high-level description of those patches are on the cover letter: https://github.com/masneyb/nexus-5-upstream/blob/master/out-of-tree-patches= /upstream-patches/v5.5/0000-cover-letter.patch A description of what works and what I've done upstream for this device is described at: https://masneyb.github.io/nexus-5-upstream/ Brian > = > Looked at it again and it does look like your glmark was vsynced (glmark > explicitly disables vsync so I guess you have it force-enabled) since the > results are all 26-27 (X works a bit differently and gets double the > framerate somehow?) > = > On 3/3/20 9:53 PM, Brian Masney wrote: > > On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote: > > > modetest should be printing "freq: 60.0Hz", so definitely something w= rong > > > there. Though I guess you have another problem since I would expect t= he > > > patch to drop it to 30 and not 13.5. > > > = > > > (FYI glmark-x11 isn't vsynced which is why I specifically mentioned > > > glmark-drm) > > = > > I tried compiling the drm variant and it was complaining about some > > missing dependencies that I didn't see in Alpine Linux. I didn't try too > > hard since I'm a bit short on time at this point since I'm starting a > > new job on Monday and I have another side project that I want to finish > > before then. > > = > > I suspect that the issue is caused by the introduction of the async > > commit support in the MSM driver that introduced the ping/pong timeouts. > > I'll try in a few weeks or so reverting those patches and see if that > > affects the speed. > > = > > I'm still ok with Ville's patch going in given the existing slow state. > > There's no clear path forward right now for the autocommit patch that I > > linked to earlier in this thread. :( > > = > > Brian > > = > > > = > > > On 3/3/20 9:16 PM, Brian Masney wrote: > > > > On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote: > > > > > What Xorg prints doesn't mean anything. I don't think there will = be errors > > > > > in dmesg, you need to run something that does pageflips as fast a= s possible > > > > > and see that the refresh rate is still 60. (modetest with -v, glm= ark-drm are > > > > > examples) > > > > = > > > > I assume that you mean modetest from > > > > https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ? > > > > Here's the modeset connector information: > > > > = > > > > id encoder status name size (mm) modes encoders > > > > 32 31 connected DSI-1 62x110 1 31 > > > > modes: > > > > index name refresh (Hz) hdisp hss hse htot vdisp vss vse = vtot) > > > > #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 1500= 00 > > > > flags: ; type: preferred, driver > > > > = > > > > And the page flip results... > > > > = > > > > $ modetest -v -s 32:1080x1920 > > > > trying to open device 'msm'...done > > > > setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50 > > > > failed to set gamma: Function not implemented > > > > freq: 13.50Hz > > > > freq: 13.51Hz > > > > freq: 13.51Hz > > > > = > > > > It's the same results with and without Ville's patch. > > > > = > > > > Here's the beginning of the glmark2 results with the x11-gl flavor: > > > > = > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > glmark2 2017.07 > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > OpenGL Information > > > > GL_VENDOR: freedreno > > > > GL_RENDERER: FD330 > > > > GL_VERSION: 3.1 Mesa 20.0.0-devel > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > [build] use-vbo=3Dfalse: FPS: 26 FrameTime: 38.462 ms > > > > [build] use-vbo=3Dtrue: FPS: 26 FrameTime: 38.462 ms > > > > [texture] texture-filter=3Dnearest: FPS: 26 FrameTime: 38.462 ms > > > > [texture] texture-filter=3Dlinear: FPS: 26 FrameTime: 38.462 ms > > > > [texture] texture-filter=3Dmipmap: FPS: 27 FrameTime: 37.037 ms > > > > [shading] shading=3Dgouraud: FPS: 27 FrameTime: 37.037 ms > > > > [shading] shading=3Dblinn-phong-inf: FPS: 27 FrameTime: 37.037 ms > > > > [shading] shading=3Dphong: FPS: 27 FrameTime: 37.037 ms > > > > [shading] shading=3Dcel: FPS: 26 FrameTime: 38.462 ms > > > > [bump] bump-render=3Dhigh-poly: FPS: 27 FrameTime: 37.037 ms > > > > [bump] bump-render=3Dnormals: FPS: 27 FrameTime: 37.037 ms > > > > [bump] bump-render=3Dheight: FPS: 27 FrameTime: 37.037 ms > > > > [effect2d] kernel=3D0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 = ms > > > > [effect2d] kernel=3D1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTi= me: > > > > 38.462 ms > > > > [pulsar] light=3Dfalse:quads=3D5:texture=3Dfalse: FPS: 26 FrameTime= : 38.462 ms > > > > [desktop] blur-radius=3D5:effect=3Dblur:passes=3D1:separable=3Dtrue= :windows=3D4: > > > > FPS: 26 FrameTime: 38.462 ms > > > > [desktop] effect=3Dshadow:windows=3D4: FPS: 27 FrameTime: 37.037 ms > > > > ... > > > > = > > > > Brian > > > > = > > > > = > > > > > = > > > > > On 3/3/20 7:26 AM, Brian Masney wrote: > > > > > > On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote: > > > > > > > Another thing: did you verify that the panel still runs at 60= hz (and not > > > > > > > dropping frames to 30hz)? IIRC that was the behavior with low= er clock. > > > > > > = > > > > > > Yes, the panel is running at 60 HZ according to the Xorg log wi= th > > > > > > Ville's patch applied: > > > > > > = > > > > > > modeset(0): Modeline "1080x1920"x60.0 125.50 1080 1082= 1084 1086 > > > > > > 1920 1922 1924 1926 (115.6 kHz eP) > > > > > > = > > > > > > I verified there's no underflow errors in dmesg. > > > > > > = > > > > > > If I recall correctly, the clock speeds that was in your tree w= as set > > > > > > too low for the gpu_opp_table (that wouldn't cause this issue),= but I > > > > > > seem to recall there were some other clock speed mismatches. The > > > > > > bandwidth requests weren't set on the RPM as well, so maybe that > > > > > > contributed to the problem. That's done upstream with the msm89= 74 > > > > > > interconnect driver: > > > > > > = > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/tree/drivers/interconnect/qcom/msm8974.c > > > > > > = > > > > > > There's a separate known issue with 'pp done time out' errors t= hat > > > > > > occur on the framebuffer that started upstream several months a= go with > > > > > > the introduction of async commit support in the MSM driver. I t= ried > > > > > > working around this by enabling the autorefresh feature but it'= s not > > > > > > fully working yet and I hit a dead end since there's no docs av= ailable > > > > > > publicly for this. The grim details are at: > > > > > > = > > > > > > https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@ons= tation.org/ > > > > > > = > > > > > > So I'm still OK with Ville's patch going in. > > > > > > = > > > > > > Brian > > > > > > = > > > > > > = > > > > > > > = > > > > > > > On 3/2/20 10:28 PM, Jonathan Marek wrote: > > > > > > > > = > > > > > > > > On 3/2/20 10:13 PM, Brian Masney wrote: > > > > > > > > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek = wrote: > > > > > > > > > > Hi, > > > > > > > > > > = > > > > > > > > > > This is a command mode panel and the the msm/mdp5 drive= r uses > > > > > > > > > > the vrefresh > > > > > > > > > > field for the actual refresh rate, while the dotclock f= ield is > > > > > > > > > > used for the > > > > > > > > > > DSI clocks. The dotclock needed to be a bit higher than > > > > > > > > > > necessary otherwise > > > > > > > > > > the panel would not work. > > > > > > > > > > = > > > > > > > > > > If you want to get rid of the separate clock/vrefresh f= ields there would > > > > > > > > > > need to be some changes to msm driver. > > > > > > > > > > = > > > > > > > > > > (note I hadn't made the patch with upstreaming in mind,= the > > > > > > > > > > 150000 value is > > > > > > > > > > likely not optimal, just something that worked, this is= something that > > > > > > > > > > should have been checked with the downstream driver) > > > > > > > > > = > > > > > > > > > Is this the right clock frequency in the downstream MSM 3= .4 kernel that > > > > > > > > > you're talking about? > > > > > > > > > = > > > > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/a= rch/arm/mach-msm/clock-8974.c#L3326 > > > > > > > > > = > > > > > > > > > = > > > > > > > > = > > > > > > > > No, I'm talking about the DSI clock (the driver for it is in > > > > > > > > drm/msm/dsi/). For a command mode panel the front/back porc= hes aren't > > > > > > > > relevant, but the dsi pixel/byte clock need to be a bit hig= her than > > > > > > > > 1920x1080x60. Since 125498 is a little higher than 124416 t= hat might be > > > > > > > > enough (there is also rounding of the clock values to consi= der). > > > > > > > > = > > > > > > > > > I don't see any obvious clock values in the downstream co= mmand mode > > > > > > > > > panel configuration: > > > > > > > > > = > > > > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/a= rch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591 > > > > > > > > > = > > > > > > > > > = > > > > > > > > > Anyways, I tried Ville's patch with the framebuffer, kmsc= ube, and X11 > > > > > > > > > and everything appears to be working fine. You can add my= Tested-by if > > > > > > > > > you end up applying this. > > > > > > > > > = > > > > > > > > > Tested-by: Brian Masney > > > > > > > > > = > > > > > > > > > Brian > > > > > > > > > = > > > > > > > > > = > > > > > > > > > > On 3/2/20 3:34 PM, Ville Syrjala wrote: > > > > > > > > > > > From: Ville Syrj=E4l=E4 > > > > > > > > > > > = > > > > > > > > > > > The currently listed dotclock disagrees with the curr= ently > > > > > > > > > > > listed vrefresh rate. Change the dotclock to match th= e vrefresh. > > > > > > > > > > > = > > > > > > > > > > > Someone tell me which (if either) of the dotclock or = vreresh is > > > > > > > > > > > correct? > > > > > > > > > > > = > > > > > > > > > > > Cc: Jonathan Marek > > > > > > > > > > > Cc: Brian Masney > > > > > > > > > > > Cc: Linus Walleij > > > > > > > > > > > Signed-off-by: Ville Syrj=E4l=E4 > > > > > > > > > > > --- > > > > > > > > > > > =A0=A0 drivers/gpu/drm/panel/panel-simple.c | 2 +- > > > > > > > > > > > =A0=A0 1 file changed, 1 insertion(+), 1 deletion(= -) > > > > > > > > > > > = > > > > > > > > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c > > > > > > > > > > > b/drivers/gpu/drm/panel/panel-simple.c > > > > > > > > > > > index b24fdf239440..f958d8dfd760 100644 > > > > > > > > > > > --- a/drivers/gpu/drm/panel/panel-simple.c > > > > > > > > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c > > > > > > > > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_= dsi > > > > > > > > > > > panasonic_vvx10f004b00 =3D { > > > > > > > > > > > =A0=A0 }; > > > > > > > > > > > =A0=A0 static const struct drm_display_mode lg_acx= 467akm_7_mode =3D { > > > > > > > > > > > -=A0=A0=A0 .clock =3D 150000, > > > > > > > > > > > +=A0=A0=A0 .clock =3D 125498, > > > > > > > > > > > =A0=A0=A0=A0=A0=A0 .hdisplay =3D 1080, > > > > > > > > > > > =A0=A0=A0=A0=A0=A0 .hsync_start =3D 1080 + 2, > > > > > > > > > > > =A0=A0=A0=A0=A0=A0 .hsync_end =3D 1080 + 2 + 2, > > > > > > > > > > > = _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel