Re: fw_devlink breakage on SDM845 / a630 with DSI displays

[Saravana Kannan <saravanak@google.com>]

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
>