Hi Jonas, On Thu, 17 Aug 2023 at 00:25, Jonas Karlman <jo...@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 <s...@chromium.org> wrote: > >> > >> Hi Jonas, > >> > >> On Sat, 5 Aug 2023 at 07:32, Jonas Karlman <jo...@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 <jo...@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
