[RFC] dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation

[Simon Glass]

Hi Jonas,

On Thu, 17 Aug 2023 at 00:25, Jonas Karlman <jonas at kwiboo.se> wrote:
>
> Hi Simon,
>
> On 2023-08-17 00:29, Simon Glass wrote:
> > Hi Jonas,
> >
> > On Tue, 8 Aug 2023 at 20:03, Simon Glass <sjg at chromium.org> wrote:
> >>
> >> Hi Jonas,
> >>
> >> On Sat, 5 Aug 2023 at 07:32, Jonas Karlman <jonas at kwiboo.se> wrote:
> >>>
> >>> Devices for nodes with e.g. bootph-pre-ram are initialized three times.
> >>> 1. At SPL stage (always bind and probe only if used)
> >>> 2. At U-Boot proper pre-reloc (always bind and probe)
> >>> 3. At U-Boot proper normal (always bind and probe only if used)
> >>>
> >>> Change ofnode_pre_reloc to report a node with bootph-pre-ram/sram prop
> >>> with a pre-reloc status only after U-Boot proper pre-relocation stage.
> >>> This prevents the device from being probed at U-Boot proper pre-reloc.
> >>>
> >>> Signed-off-by: Jonas Karlman <jonas at kwiboo.se>
> >>> ---
> >>> I am not sure if U-Boot proper pre-reloc behaves like this by design and
> >>> if there is some other way to signal that a device should not be probed
> >>> during U-Boot proper pre-reloc stage if it has been probed at SPL stage.
> >>>
> >>> For my use-case I added bootph-pre-ram prop to my RK8xx device node to
> >>> make the PMIC usable in SPL. However, I have no need for this device to
> >>> probe at U-Boot proper pre-reloc stage just after jumping out of TF-A.
> >>> And moments later bind and probe yet again at U-Boot proper normal stage.
> >>>
> >>> The bootph-pre-ram prop was used to have the device usable in SPL, else
> >>> I could have used bootph-all or added bootph-some-ram prop to indicate
> >>> use at U-Boot proper pre-reloc stage.
> >>
> >> This is changing how things work...we really need to have something
> >> explicit to use this new behaviour. Perhaps we can augment the binding
> >> in some way?
> >
> > I had another look at this. The binding seems to be silent on this
> > point, so I believe this patch is correct.
>
> I agree, the documentation for binding and also for driver model make
> this a little bit unclear:
>
> """
> ... Only drivers marked with DM_FLAG_PRE_RELOC or the device tree
> ‘bootph-all’ property are initialised prior to relocation. ...
>
> ...
>
> It is possible to limit this to specific relocation steps, by using the
> more specialized ‘bootph-pre-ram’ and ‘bootph-pre-sram’ flags in the
> device tree node. For U-Boot proper you can use ‘bootph-some-ram’ which
> means that it will be processed (and a driver bound) in U-Boot proper
> prior to relocation, but will not be available in SPL or TPL.
> """
>
> However the documentation for ofnode_pre_reloc contradict this a little:
>
> """
> There are 4 settings currently in use
> - bootph-some-ram: U-Boot proper pre-relocation only
> - bootph-all: all phases
> Existing platforms only use it to indicate nodes needed in
> SPL. Should probably be replaced by bootph-pre-ram for new platforms.
> - bootph-pre-ram: SPL and U-Boot pre-relocation
> - bootph-pre-sram: TPL and U-Boot pre-relocation
> """
>
> Should I send a v2 of this and drop the "and U-Boot pre-relocation" from
> function doc comment? And do we need a new Kconfig option to enable or
> opt-out of this new/changed/fixed behavior?

Yes it needs doc updates but I don't think a new Kconfig option is
warranted at this point. We just need to clearly document how these
options are used.

Regards,
SImon