On Mon, Jul 13, 2020 at 1:25 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > On Mon, Jul 13, 2020 at 9:08 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > > > 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. > > Sounds like a bug as that's not what should happen. > > If you defer during boot (initcalls), then you'll be on the deferred > list until late_initcall and everything is retried. After > late_initcall, only devices getting added should trigger probing. But > maybe the adding and then removing a device is causing a re-trigger. > > > > > 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? > > It should. But then I reviewed the MDSS binding today and it looks > like the MDSS is the interrupt parent for at least some child devices? > yes, that is correct BR, -R
