Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2025-02-18 06:58:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/sysreset/sysreset-uclass.c

181 lines
3.2 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style 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>
2018-05-06 17:58:06 -04:00
// SPDX-License-Identifier: GPL-2.0+
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
/*
* Copyright (C) 2015 Google, Inc
* Written by Simon Glass <sjg@chromium.org>
*/
sysreset: Tidy up a few comments and logging Some comments are incorrect or missing pieces. Fix these and use logging to print the error. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 12:22:45 -06:00
#define LOG_CATEGORY UCLASS_SYSRESET
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
#include <common.h>
command: Remove the cmd_tbl_t typedef We should not use typedefs in U-Boot. They cannot be used as forward declarations which means that header files must include the full header to access them. Drop the typedef and rename the struct to remove the _s suffix which is now not useful. This requires quite a few header-file additions. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 11:40:03 -06:00
#include <command.h>
common: Move reset_cpu() to the CPU header Move this function out of common.h and into a relevant header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2019-12-28 10:45:01 -07:00
#include <cpu_func.h>
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
#include <dm.h>
#include <errno.h>
sysreset: Use a shorter error with SPL Use a minimal error message to save space. Sort the header files while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-23 08:11:14 -07:00
#include <hang.h>
#include <log.h>
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
#include <regmap.h>
sysreset: Use a shorter error with SPL Use a minimal error message to save space. Sort the header files while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-23 08:11:14 -07:00
#include <spl.h>
#include <sysreset.h>
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
#include <dm/device-internal.h>
#include <dm/lists.h>
#include <dm/root.h>
common: Drop linux/delay.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 11:40:11 -06:00
#include <linux/delay.h>
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
#include <linux/err.h>
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-10-30 21:38:53 -06:00
#include <asm/global_data.h>
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
int sysreset_request(struct udevice *dev, enum sysreset_t type)
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
{
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
struct sysreset_ops *ops = sysreset_get_ops(dev);
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
if (!ops->request)
return -ENOSYS;
return ops->request(dev, type);
}
sysreset: Add get_status method 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>
2018-08-06 10:23:32 +02:00
int sysreset_get_status(struct udevice *dev, char *buf, int size)
{
struct sysreset_ops *ops = sysreset_get_ops(dev);
if (!ops->get_status)
return -ENOSYS;
return ops->get_status(dev, buf, size);
}
sysreset: Add a way to find the last reset We have a method to return the last reset as a string for humans, but not a method that allows it to be used programmatically. Add a new method that returns the last reset as an enum. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 12:22:46 -06:00
int sysreset_get_last(struct udevice *dev)
{
struct sysreset_ops *ops = sysreset_get_ops(dev);
if (!ops->get_last)
return -ENOSYS;
return ops->get_last(dev);
}
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
int sysreset_walk(enum sysreset_t type)
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
{
struct udevice *dev;
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
int ret = -ENOSYS;
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
while (ret != -EINPROGRESS && type < SYSRESET_COUNT) {
for (uclass_first_device(UCLASS_SYSRESET, &dev);
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
dev;
uclass_next_device(&dev)) {
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
ret = sysreset_request(dev, type);
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
if (ret == -EINPROGRESS)
break;
}
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
type++;
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
}
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
return ret;
}
sysreset: Add a way to find the last reset We have a method to return the last reset as a string for humans, but not a method that allows it to be used programmatically. Add a new method that returns the last reset as an enum. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 12:22:46 -06:00
int sysreset_get_last_walk(void)
{
struct udevice *dev;
int value = -ENOENT;
for (uclass_first_device(UCLASS_SYSRESET, &dev);
dev;
uclass_next_device(&dev)) {
int ret;
ret = sysreset_get_last(dev);
if (ret >= 0) {
value = ret;
break;
}
}
return value;
}
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
void sysreset_walk_halt(enum sysreset_t type)
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
{
int ret;
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
ret = sysreset_walk(type);
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
/* Wait for the reset to take effect */
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
if (ret == -EINPROGRESS)
mdelay(100);
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
/* Still no reset? Give up */
sysreset: Use a shorter error with SPL Use a minimal error message to save space. Sort the header files while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-23 08:11:14 -07:00
if (spl_phase() <= PHASE_SPL)
log_err("no sysreset\n");
else
log_err("System reset not supported on this platform\n");
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
hang();
}
/**
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
* reset_cpu() - calls sysreset_walk(SYSRESET_WARM)
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
*/
reset: Remove addr parameter from reset_cpu() Historically, the reset_cpu() function had an `addr` parameter which was meant to pass in an address of the reset vector location, where the CPU should reset to. This feature is no longer used anywhere in U-Boot as all reset_cpu() implementations now ignore the passed value. Generic code has been added which always calls reset_cpu() with `0` which means this feature can no longer be used easily anyway. Over time, many implementations seem to have "misunderstood" the existence of this parameter as a way to customize/parameterize the reset (e.g. COLD vs WARM resets). As this is not properly supported, the code will almost always not do what it is intended to (because all call-sites just call reset_cpu() with 0). To avoid confusion and to clean up the codebase from unused left-overs of the past, remove the `addr` parameter entirely. Code which intends to support different kinds of resets should be rewritten as a sysreset driver instead. This transformation was done with the following coccinelle patch: @@ expression argvalue; @@ - reset_cpu(argvalue) + reset_cpu() @@ identifier argname; type argtype; @@ - reset_cpu(argtype argname) + reset_cpu(void) { ... } Signed-off-by: Harald Seiler <hws@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-15 16:47:52 +01:00
void reset_cpu(void)
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
{
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
sysreset_walk_halt(SYSRESET_WARM);
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
}
dm: sysreset: Add a Kconfig option for the 'reset' command sysreset uclass driver provides an implementation of 'reset' command using the sysreset_ APIs unconditionally. It also supports the 'poweroff' command using the sysreset_ APIs, but under a Kconfig option CONFIG_SYSRESET_CMD_POWEROFF. Let's do the same for the 'reset' command, by introducing a new Kconfig option CONFIG_SYSRESET_CMD_RESET, and set it to on by default, to allow a board that don't have a sysreset reset driver yet, but have a sysreset poweroff driver to compile without any issue. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-02-25 17:22:52 +08:00
#if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET)
command: Remove the cmd_tbl_t typedef We should not use typedefs in U-Boot. They cannot be used as forward declarations which means that header files must include the full header to access them. Drop the typedef and rename the struct to remove the _s suffix which is now not useful. This requires quite a few header-file additions. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 11:40:03 -06:00
int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
{
sysreset: provide type of reset in do_reset cmd Add additional param for reset cmd, which provides type of reset. Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
2021-04-01 02:01:55 +03:00
enum sysreset_t reset_type = SYSRESET_COLD;
if (argc > 2)
return CMD_RET_USAGE;
if (argc == 2 && argv[1][0] == '-' && argv[1][1] == 'w') {
reset_type = SYSRESET_WARM;
}
dm: sysreset: Add a standard message when doing reset It's good to print a message when doing reset. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-07-19 03:07:31 -07:00
printf("resetting ...\n");
dm: sysreset: wait after reset message In our Python tests we expect to see the word "resetting". It may be truncated if we reset before the serial console buffer is transferred. Wait for 100 ms between the "resetting ..." message and the actual reset like we do when powering off. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-07-29 12:13:41 +02:00
mdelay(100);
dm: sysreset: Add a standard message when doing reset It's good to print a message when doing reset. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-07-19 03:07:31 -07:00
sysreset: provide type of reset in do_reset cmd Add additional param for reset cmd, which provides type of reset. Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
2021-04-01 02:01:55 +03:00
sysreset_walk_halt(reset_type);
dm: reset: Allow reset_walk() to return 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>
2015-07-06 12:54:27 -06:00
return 0;
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
}
dm: sysreset: Add a Kconfig option for the 'reset' command sysreset uclass driver provides an implementation of 'reset' command using the sysreset_ APIs unconditionally. It also supports the 'poweroff' command using the sysreset_ APIs, but under a Kconfig option CONFIG_SYSRESET_CMD_POWEROFF. Let's do the same for the 'reset' command, by introducing a new Kconfig option CONFIG_SYSRESET_CMD_RESET, and set it to on by default, to allow a board that don't have a sysreset reset driver yet, but have a sysreset poweroff driver to compile without any issue. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-02-25 17:22:52 +08:00
#endif
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
sysreset: move stm32mp sysreset poweroff implementation to sysreset uclass This is a generic implementation. Add CONFIG_SYSRESET_CMD_POWEROFF to signal when we need it. Enable it from the STPMIC1 config and in sandbox. The config flag is transitionary, that is it can be removed after all poweroff implementations use sysreset, and just have CMD_POWEROFF depend on sysreset. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-05-16 21:48:42 +00:00
#if IS_ENABLED(CONFIG_SYSRESET_CMD_POWEROFF)
command: Remove the cmd_tbl_t typedef We should not use typedefs in U-Boot. They cannot be used as forward declarations which means that header files must include the full header to access them. Drop the typedef and rename the struct to remove the _s suffix which is now not useful. This requires quite a few header-file additions. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 11:40:03 -06:00
int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
sysreset: move stm32mp sysreset poweroff implementation to sysreset uclass This is a generic implementation. Add CONFIG_SYSRESET_CMD_POWEROFF to signal when we need it. Enable it from the STPMIC1 config and in sandbox. The config flag is transitionary, that is it can be removed after all poweroff implementations use sysreset, and just have CMD_POWEROFF depend on sysreset. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-05-16 21:48:42 +00:00
{
int ret;
puts("poweroff ...\n");
mdelay(100);
ret = sysreset_walk(SYSRESET_POWER_OFF);
if (ret == -EINPROGRESS)
mdelay(1000);
/*NOTREACHED when power off*/
return CMD_RET_FAILURE;
}
#endif
sysreset: dm: Support manual relocation for sysreset Relocate sysreset ops as was done by: "dm: Add support for all targets which requires MANUAL_RELOC" (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-07-12 10:36:07 +02:00
static int sysreset_post_bind(struct udevice *dev)
{
#if defined(CONFIG_NEEDS_MANUAL_RELOC)
struct sysreset_ops *ops = sysreset_get_ops(dev);
static int reloc_done;
if (!reloc_done) {
if (ops->request)
ops->request += gd->reloc_off;
reloc_done++;
}
#endif
return 0;
}
Rename reset to sysreset 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>
2016-05-12 12:03:35 -06:00
UCLASS_DRIVER(sysreset) = {
.id = UCLASS_SYSRESET,
.name = "sysreset",
sysreset: dm: Support manual relocation for sysreset Relocate sysreset ops as was done by: "dm: Add support for all targets which requires MANUAL_RELOC" (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-07-12 10:36:07 +02:00
.post_bind = sysreset_post_bind,
dm: Add a system reset uclass 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>
2015-06-23 15:39:13 -06:00
};
Reference in a new issue Copy permalink