Hi, On Mon, Jul 13, 2020 at 7:11 AM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > On Fri, Jul 10, 2020 at 5:02 PM Douglas Anderson <dianders@xxxxxxxxxxxx> wrote: > > > > I found that if I ever had a little mistake in my kernel config, > > or device tree, or graphics driver that my system would sit in a loop > > at bootup trying again and again and again. An example log was: > > Why do we care about optimizing the error case? It actually results in a _fully_ infinite loop. That is: if anything small causes a component of DRM to fail to probe then the whole system doesn't boot because it just loops trying to probe over and over again. The messages I put in the commit message are printed over and over and over again. > > msm ae00000.mdss: bound ae01000.mdp (ops 0xffffffe596e951f8) > > msm_dsi ae94000.dsi: ae94000.dsi supply gdsc not found, using dummy regulator > > msm_dsi_manager_register: failed to register mipi dsi host for DSI 0 > > [drm:ti_sn_bridge_probe] *ERROR* could not find any panel node > > ... > > > > I finally tracked it down where this was happening: > > - msm_pdev_probe() is called. > > - msm_pdev_probe() registers drivers. Registering drivers kicks > > off processing of probe deferrals. > > - component_master_add_with_match() could return -EPROBE_DEFER. > > making msm_pdev_probe() return -EPROBE_DEFER. > > - When msm_pdev_probe() returned the processing of probe deferrals > > happens. > > - Loop back to the start. > > > > It looks like we can fix this by marking "mdss" as a "simple-bus". > > I have no idea if people consider this the right thing to do or a > > hack. Hopefully it's the right thing to do. :-) > > It's a simple test. Do the child devices have any dependency on the > parent to probe and/or function? If so, not a simple-bus. Great! You can see in the earlier patch in the series that the very first thing that happens when the parent device probes is that it calls devm_of_platform_populate(). That means no dependencies, right? So that means it's fine/correct to add "simple-bus" here? > > Once I do this I notice that my boot gets marginally faster (you > > don't need to probe the sub devices over and over) and also if I > > Can you quantify that? I'd say < 100 us. I can try to quantify more if needed, but it wasn't the point of this patch. > Have you run with devlinks enabled. You need a command line option to > enable. That too should reduce deferred probes. Ah, good idea! I will try it. However, even with devlinks, if there is any chance of deferred probes then we need a fix like this. The point of the patch isn't about speeding things up but about avoiding an infinite loop at bootup due to a small bug. > > have a problem it doesn't loop forever (on my system it still > > gets upset about some stuck clocks in that case, but at least I > > can boot up). > > Deferred probe only runs when a device is added, so it's not like it > is continually running. If you don't mind looking at the code patch, see: https://lore.kernel.org/r/20200710160131.4.I358ea82de218ea5f4406572ade23f5e121297555@changeid/ Specifically you can see that each time we try to probe we were calling of_platform_populate(). That appeared to be enough to trigger things. -Doug
