Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-12 14:23:00 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/sysreset/sysreset-uclass.c

99 lines
1.8 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>
*/
#include <common.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>
#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);
}
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;
}
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 */
reset: Drop the reset failure message This adds to code size and is not needed, since hang() will print a message. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-05-14 20:02:54 +00:00
debug("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
}
int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
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: 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