It's useful to have the reset status of the SoC printed out during reset
(e.g. to learn whether the reset was caused by software or a watchdog).
As a first step to implement this, add a get_status method to the
sysreset class, which enables the caller to get printable information
about the reset status (akin to get_desc in the CPU uclass).
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Relocate sysreset ops as was done by:
"dm: Add support for all targets which requires MANUAL_RELOC"
(sha1: 484fdf5ba0)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
The DM version of do_reset has been issuing a warm-reset, which (on
some platforms keeps GPIOs and other parts of the platform active).
This may cause unintended behaviour, as calling do_reset usually
indicates a desire to reset the board/platform and not just the CPU.
This changes do_reset to always request a COLD reset.
Note that programmatic uses can still invoke a WARM reset through
reset_cpu() or using sysreset_walk().
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Create drivers/sysreset and move sysreset-uclass and all sysreset
drivers there.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
The current reset API implements a method to reset the entire system.
In the near future, I'd like to introduce code that implements the device
tree reset bindings; i.e. the equivalent of the Linux kernel's reset API.
This controls resets to individual HW blocks or external chips with reset
signals. It doesn't make sense to merge the two APIs into one since they
have different semantic purposes. Resolve the naming conflict by renaming
the existing reset API to sysreset instead, so the new reset API can be
called just reset.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Add a new reset_walk_halt() function to cause a reset and then halt on
failure. The reset_walk() function returns an error code.
This is needed for testing since otherwise U-Boot will halt in the middle
of a test.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is common for system reset to be available at multiple levels in modern
hardware. For example, an SoC may provide a reset option, and a board may
provide its own reset for reasons of security or thoroughness. It is useful
to be able to model this hardware without hard-coding the behaviour in the
SoC or board. Also there is a distinction sometimes between resetting just
the CPU (leaving GPIO state alone) and resetting all the PMICs, just cutting
power.
To achieve this, add a simple system reset uclass. It allows multiple devices
to provide reset functionality and provides a way to walk through them,
requesting a particular reset type until is it provided.
Signed-off-by: Simon Glass <sjg@chromium.org>
Mario Six
Bin Meng
Michal Simek
Tom Rini
Philipp Tomsich
Max Filippov
Simon Glass
Stephen Warren