I do not have any non-serial output devices, so a
print_pre_console_buffer(PRE_CONSOLE_FLUSHPOINT2_EVERYTHING_BUT_SERIAL)
does nothing for me.

However, I was manually inspected the pre-console buffer using md.b,
and I noticed that the early part of it was repeated. The reason is
that the first call of print_pre_console_buffer(), from
console_init_f(), ends up invoking puts() with the contents of the
buffer at that point, and puts() at that point ends up in the else
branch of

	if (gd->flags & GD_FLG_DEVINIT) {
		/* Send to the standard output */
		fputs(stdout, s);
	} else {
		/* Send directly to the handler */
		pre_console_puts(s);
		serial_puts(s);
	}

so indeed the contents is added again.

That can be somewhat confusing (both when reading the buffer manually,
but also if it did actually come out on some device). So disable all
use of the pre-console buffer while print_pre_console_buffer() is
emitting it.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

With dm-tag feature, any U-Boot subsystem is allowed to associate
arbitrary number of data with a particular udevice. This can been
see as expanding "struct udevice" without modifying the definition.

As a first user, UEFI subsystem makes use of tags to associate
an efi_disk object with a block device.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Drop the Kconfigs which are not used and all references to them. In
particular, this drops CONFIG_VIDEO to avoid confusion and allow us to
eventually rename CONFIG_DM_VIDEO to CONFIG_VIDEO.

Also drop the prototype for video_get_info_str() which is no-longer used.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>

Add a way to create and dispatch events without needing to allocate
memory. Also add a way to 'spy' on events, thus allowing 'hooks' to be
created.

Use a linker list for static events, which we can use to replace functions
like arch_cpu_init_f(). Allow an EVENT_DEBUG option which makes it
easier to see what is going on at runtime, but uses more code space.

Dynamic events allow the creation of a spy at runtime. This is not always
necessary, but can be enabled with EVENT_DYNAMIC if needed.

A 'test' event is the only option for now.

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

Allow this to be used on any arch. Also convert to using macros so that
we can check the CONFIG option in C code.

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

Keep track of where the devicetree came from, so we can report this later.

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

Refactor the code to drop the #ifdefs for this feature.

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

A board can have and make use of more than one watchdog device, say
one built into the SOC and an external gpio-petted one. Having
wdt-uclass only handle the first is both a little arbitrary and
unexpected.

So change initr_watchdog() so we visit (probe) all DM watchdog
devices, and call the init_watchdog_dev helper for each.

Similarly let watchdog_reset() loop over the whole uclass - each
having their own ratelimiting metadata, and a separate "is this device
running" flag.

This gets rid of the watchdog_dev member of struct global_data.  We
do, however, still need the GD_FLG_WDT_READY set in
initr_watchdog(). This is because watchdog_reset() can get called
before DM is ready, and I don't think we can call uclass_get() that
early.

The current code just returns 0 if "getting" the first device fails -
that can of course happen because there are no devices, but it could
also happen if its ->probe call failed. In keeping with that, continue
with the handling of the remaining devices even if one fails to
probe. This is also why we cannot use uclass_probe_all().

If desired, it's possible to later add a per-device "u-boot,autostart"
boolean property, so that one can do CONFIG_WATCHDOG_AUTOSTART
per-device.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

First, we convert CONFIG_SYS_I2C_LEGACY to Kconfig.  Next, as you cannot
have SYS_I2C_LEGACY and DM_I2C at the same time, introduce
CONFIG_SPL_SYS_I2C_LEGACY so that we can enable the legacy option only
in SPL.  Finally, for some PowerPC cases we also need
CONFIG_TPL_SYS_I2C_LEGACY support.  Convert all of the existing users to
one or more symbols.

Signed-off-by: Tom Rini <trini@konsulko.com>

It is quite confusing that CONFIG_SYS_I2C selects the legacy I2C and
CONFIG_DM_I2C selects the current I2C. The deadline to migrate I2C is less
than a year away.

Also we want to have a CONFIG_I2C for U-Boot proper just like we have
CONFIG_SPL_I2C for SPL, so we can simplify the Makefile rules.

Rename this symbol so it is clear it is going away.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>