Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-18 10:48:51 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/sysreset/sysreset-uclass.c

164 lines
2.9 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 21:58:06 +00: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 21:39:13 +00: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 18:22:45 +00: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 21:39:13 +00: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 17:40:03 +00: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 17:45:01 +00:00
#include <cpu_func.h>
common: Move hang() to the same header as panic() At present panic() is in the vsprintf.h header file. That does not seem like an obvious choice for hang(), even though it relates to panic(). So let's put hang() in its own header. Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Migrate a few more files] Signed-off-by: Tom Rini <trini@konsulko.com>
2019-12-28 17:45:07 +00:00
#include <hang.h>
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 17:40:05 +00:00
#include <log.h>
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 18:03:35 +00:00
#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 21:39:13 +00:00
#include <dm.h>
#include <errno.h>
#include <regmap.h>
#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 17:40:11 +00: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 21:39:13 +00:00
#include <linux/err.h>
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 18:03:35 +00: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 21:39:13 +00: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 18:03:35 +00: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 21:39:13 +00: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 08:23:32 +00: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 18:22:46 +00: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 18:03:35 +00: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 21:39:13 +00: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 18:54:27 +00: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 21:39:13 +00: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 18:03:35 +00: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 18:54:27 +00: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 18:03:35 +00: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 21:39:13 +00: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 18:54:27 +00: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 21:39:13 +00: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 18:54:27 +00: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 18:22:46 +00: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 18:03:35 +00: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 18:54:27 +00: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 18:03:35 +00: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 18:54:27 +00: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 21:39:13 +00: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 18:54:27 +00: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 21:39:13 +00:00
/* Still no reset? Give up */
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 18:22:45 +00:00
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 21:39:13 +00: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 18:03:35 +00: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 21:39:13 +00:00
*/
void reset_cpu(ulong addr)
{
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 18:03:35 +00: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 18:54:27 +00:00
}
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 17:40:03 +00: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 18:54:27 +00:00
{
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 10:07:31 +00:00
printf("resetting ...\n");
dm: reset: have the reset-command perform a COLD reset 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>
2017-11-24 17:37:58 +00:00
sysreset_walk_halt(SYSRESET_COLD);
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 18:54:27 +00: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 21:39:13 +00: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 17:40:03 +00: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 08:36:07 +00: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 18:03:35 +00: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 08:36:07 +00: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 21:39:13 +00:00
};
Reference in a new issue Copy permalink