linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saravana Kannan <saravanak@google.com>
To: Caleb Connolly <caleb@connolly.tech>
Cc: Rob Clark <robdclark@gmail.com>,
	John Stultz <john.stultz@linaro.org>,
	Amit Pundir <amit.pundir@linaro.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Douglas Anderson <dianders@chromium.org>,
	Stephen Boyd <swboyd@chromium.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	dmitry.baryshkov@linaro.org
Subject: Re: fw_devlink breakage on SDM845 / a630 with DSI displays
Date: Wed, 16 Jun 2021 12:49:48 -0700	[thread overview]
Message-ID: <CAGETcx-zz3BzwfLESoV2Jx6cJvS3xjc=nFJkUKYX3atOVui5Rw@mail.gmail.com> (raw)
In-Reply-To: <8c46f015-117a-790c-a788-13b4850bdd02@connolly.tech>

On Fri, Jun 11, 2021 at 3:53 PM Caleb Connolly <caleb@connolly.tech> wrote:
>
> Hi all,
>
> This issue is still occurring on -rc5, breaking display output on the
> OnePlus 6, 6T and PocoPhone F1 unless fw_devlink=permissive 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.

Since (as you mentioned earlier) no device probe itself is getting
blocked permanently by fw_devlink=on, this seems like a race condition
between the drivers. I'd suggest using initcall_debug=1 and enabling
any other logs you need in drivers/base/dd.c to see what order the
devices probe between the working and not-working case. That'd be a
good place to start. Once you identify any ordering difference, we
should have a better idea of what might need fixing.

-Saravana
P.S: You are mixing top posting and inline replies. Please try not to do that.

>
> 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 <caleb@connolly.tech> wrote:
> >>>
> >>> Hi Saravana,
> >>>
> >>> On 19/05/2021 10:52 pm, Saravana Kannan wrote:
> >>>> On Wed, May 19, 2021 at 8:36 AM Rob Clark <robdclark@gmail.com> 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 <caleb@connolly.tech> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Since -rc1 I've been hit by some DRM breakage in freedreno which happens
> >>>>>> when fw_devlink=on. It seems to cause some clocks (rcg) to get stuck 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) has
> >>>>>> 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=permissive:
> >>> https://paste.ubuntu.com/p/F2853CphHb/
> >>>>
> >>>> Can you also tell what device are not probing with fw_devlink=on that
> >>>> might be probing with fw_devlink=permissive?
> >>> The devices in question are ae00000.mdss, ae94000.dsi and ae01000.mdp.
> >>>> You should be able to compare /<debugfs>/devices_deferred to figure that out.
> >>> devices_deferred is empty for me,
> >>
> >> So, ae00000.mdss, ae94000.dsi and ae01000.mdp are probing for =on and
> >> =permissive?
> >>
> >> 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.mdss
> >>> 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 =on and =permissive?
> > Apologies, I assumed it had something to do with fw_devlink. It's the
> > same for both cases yeah.
> >>
> >> -Saravana
> >>
> >
>
> --
> Kind Regards,
> Caleb
>

  reply	other threads:[~2021-06-16 19:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <aff4807e-e554-2e32-5789-dfaf65128a8e@connolly.tech>
2021-05-19 15:40 ` Rob Clark
2021-05-19 21:52   ` Saravana Kannan
2021-05-19 22:42     ` Caleb Connolly
2021-05-20  0:06       ` Saravana Kannan
2021-05-20  0:17         ` Caleb Connolly
2021-06-11 22:52         ` Caleb Connolly
2021-06-16 19:49           ` Saravana Kannan [this message]
2021-05-19 22:00   ` Dmitry Baryshkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGETcx-zz3BzwfLESoV2Jx6cJvS3xjc=nFJkUKYX3atOVui5Rw@mail.gmail.com' \
    --to=saravanak@google.com \
    --cc=amit.pundir@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=caleb@connolly.tech \
    --cc=dianders@chromium.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=robdclark@gmail.com \
    --cc=swboyd@chromium.org \
    --subject='Re: fw_devlink breakage on SDM845 / a630 with DSI displays' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).