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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 C7427C48BD1 for ; Fri, 11 Jun 2021 22:53:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 969D9613E9 for ; Fri, 11 Jun 2021 22:53:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229753AbhFKWzI (ORCPT ); Fri, 11 Jun 2021 18:55:08 -0400 Received: from mail-0201.mail-europe.com ([51.77.79.158]:37249 "EHLO mail-02.mail-europe.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229572AbhFKWzI (ORCPT ); Fri, 11 Jun 2021 18:55:08 -0400 Date: Fri, 11 Jun 2021 22:52:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=connolly.tech; s=protonmail; t=1623451987; bh=fjFhRBqsOMJIOFq5irzqk4jp+YHV9ZfbwpQyNsv9rEI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=meYCXpzUnzUoy7PJ0AyijARNqbPUIkIZaMewrBIEbW9oJr2BC+u1X08jgWPxecdGn 18O3k7vNvPNreVwazUIlgXqo3/zwCI5I057sfT9JeLrD/s99chIfCoDB1qKBVQNIP2 jiFfJsm69wa3V/p2Zg/pZkkWwXkDcAFP+7bSBrbo= To: Saravana Kannan From: Caleb Connolly Cc: Rob Clark , John Stultz , Amit Pundir , Bjorn Andersson , Douglas Anderson , Stephen Boyd , linux-arm-msm , dmitry.baryshkov@linaro.org Reply-To: Caleb Connolly Subject: Re: fw_devlink breakage on SDM845 / a630 with DSI displays Message-ID: <8c46f015-117a-790c-a788-13b4850bdd02@connolly.tech> In-Reply-To: References: <968c8e20-82ef-cc3d-c809-f38d801699c8@connolly.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi all, This issue is still occurring on -rc5, breaking display output on the OnePlus 6, 6T and PocoPhone F1 unless fw_devlink=3Dpermissive is set. I'm not quite sure how I should go about debugging and resolving this, I'd greatly appreciate any ideas / recommendations as I would really like to make sure 5.13 doesn't release with broken displays on these devices. Thanks, On 20/05/2021 1:17 am, Caleb Connolly wrote: > > > On 20/05/2021 1:06 am, Saravana Kannan wrote: >> On Wed, May 19, 2021 at 3:43 PM Caleb Connolly wro= te: >>> >>> Hi Saravana, >>> >>> On 19/05/2021 10:52 pm, Saravana Kannan wrote: >>>> On Wed, May 19, 2021 at 8:36 AM Rob Clark wrote: >>>>> >>>>> + some more folks and msm list.. >>>>> >>>>> I suppose I didn't hit this because CONFIG_FBDEV_EMULATION is not >>>>> normally enabled for CrOS.. but I'm not really to familiar with >>>>> fw_devlink >>>>> >>>>> BR, >>>>> -R >>>>> >>>>> On Wed, May 19, 2021 at 8:26 AM Caleb Connolly = wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Since -rc1 I've been hit by some DRM breakage in freedreno which hap= pens >>>>>> when fw_devlink=3Don. It seems to cause some clocks (rcg) to get stu= ck and >>>>>> break DSI displays, here's a full log from the OnePlus 6: >>>>>> https://paste.ubuntu.com/p/8kPx4nFGF5/ (that is with >>>>>> "deferred_probe_timeout") The PocoPhone F1 also seems to be affected= by >>>>>> this. >>>>>> >>>>>> The display will still come up after pressing the power button a few >>>>>> times, although it will be incredibly slow. >>>>>> >>>>>> It's worth noting that the issue only happens with >>>>>> CONFIG_FBDEV_EMULATION is enabled, I've previously required this to = see >>>>>> kernel logs during boot and general boot splash with postmarketOS. >>>>>> Without it the display will be stuck on the bootloader splash until = I >>>>>> press the power button and cause it to update once UI (like Phosh) h= as >>>>>> started (though this has been the case for quite some time). >>>>>> >>>>>> I'd appreciate any help with debugging / resolving this issue, I'm >>>>>> afraid I haven't been able to determine much from some brief digging= . >>>>>> >>>> >>>> Hi Caleb, >>>> >>>> Is this a device that's supported upstream? If so, can you please >>>> point me to the DTS file that corresponds to this board? >>> The DTS can be found in >>> arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi (the two devices >>> "enchilada" and "fajita" share almost all hardware in common). >>>> >>>> Also, can you please change all the dev_dbg to dev_info in these >>>> functions and give me the full boot log? >>>> device_link_add() >>>> device_links_check_suppliers() >>> I've uploaded a log here: https://paste.ubuntu.com/p/8ynFgRWbYW/ >>> For reference, the same but with fw_devlink=3Dpermissive: >>> https://paste.ubuntu.com/p/F2853CphHb/ >>>> >>>> Can you also tell what device are not probing with fw_devlink=3Don tha= t >>>> might be probing with fw_devlink=3Dpermissive? >>> The devices in question are ae00000.mdss, ae94000.dsi and ae01000.mdp. >>>> You should be able to compare //devices_deferred to figure th= at out. >>> devices_deferred is empty for me, >> >> So, ae00000.mdss, ae94000.dsi and ae01000.mdp are probing for =3Don and >> =3Dpermissive? >> >> That's interesting. So maybe fw_devlink is somehow changing the probe >> order that's causing this? AFAIK, fw_devlink shouldn't cause changes >> to probe order (it used to, but I've fixed them all). > Yeah, they always successfully probe, it seems like fw_devlink is > exposing some racy behaviour somewhere. > > The issue happens when initialising the display for framebuffer device > emulation - with framebuffer emulation disabled it all mostly works as > expected. With the caveat that there is nothing on the display until the > device has finished booting AND the user causes a refresh by pressing > the power button a few times. > > Perhaps this early framebuffer driver is causing confusion as it has > different dependencies than the main driver? >> >>> however device_component contains >>> (only) the following: >>> oneplus6:/home/user# cat /sys/kernel/debug/device_component/ae00000.mds= s >>> master name status >>> ------------------------------------------------------------- >>> ae00000.mdss bound >>> >>> device name status >>> ------------------------------------------------------------- >>> ae01000.mdp bound >>> ae94000.dsi bound >>> 5000000.gpu bound >> >> Sorry, I have no context on this and how to interpret it. I kinda know >> a little about the component framework, but not much. Is this file the >> same for =3Don and =3Dpermissive? > Apologies, I assumed it had something to do with fw_devlink. It's the > same for both cases yeah. >> >> -Saravana >> > -- Kind Regards, Caleb