common: Move autoprobe out to board init

Rather than doing autoprobe within the driver model code, move it out to
the board-init code. This makes it clear that it is a separate step from
binding devices.

For now this is always done twice, before and after relocation, but we
should discuss whether it might be possible to drop the post-relocation
probe.

For boards with SPL, the autoprobe is still done there as well.

Note that with this change, autoprobe happens after the
EVT_DM_POST_INIT_R/F events are sent, rather than before.

Link: https://lore.kernel.org/u-boot/20240626235717.272219-1-marex@denx.de/

Signed-off-by: Simon Glass <sjg@chromium.org>

doc/develop/driver-model/design.rst

@@ -842,6 +842,23 @@ steps (see device_probe()):
       cause the uclass to do some housekeeping to record the device as
       activated and 'known' by the uclass.
 
+For some platforms, certain devices must be probed to get the platform into
+a working state. To help with this, drivers marked with DM_FLAG_PROBE_AFTER_BIND
+will be probed immediately after all devices are bound. For now, this happens in
+SPL, before relocation and after relocation. See the call to ``dm_autoprobe()``
+for where this is done.
+
+The auto-probe feature is tricky because it bypasses the normal ordering of
+probing. General, if device A (e.g. video) needs device B (e.g. clock), then
+A's probe() method uses ``clk_get_by_index()`` and B is probed before A. But
+A is only probed when it is used. Therefore care should be taken when using
+auto-probe, limiting it to devices which truly are essential, such as power
+domains or critical clocks.
+
+See here for more discussion of this feature:
+
+:Link: https://patchwork.ozlabs.org/project/uboot/patch/20240626235717.272219-1-marex@denx.de/
+
 Running stage
 ^^^^^^^^^^^^^