summaryrefslogtreecommitdiff
path: root/include/reset.h
AgeCommit message (Collapse)Author
2017-07-28reset: add reset_release_all()Patrice Chotard
Add reset_release_all() method which Assert/Free an array of resets signal that has been previously successfully requested by reset_get_by_*() Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-07-28reset: add reset_request()Patrice Chotard
This is needed in error path to assert previously deasserted reset by using a saved reset_ctl reference. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-09-24reset: add no-op stubs for optional reset controlMasahiro Yamada
My motivation for this patch is to make reset control handling optional for generic drivers. I want to add reset control to drivers/usb/host/ehci-generic.c, but it is used by several platforms, some will implement a reset controller driver, some will not. Add no-op stubs in order to avoid link error for drivers that implement reset controlling, but still it is optional. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-19Add a reset driver framework/uclassStephen Warren
A reset controller is a hardware module that controls reset signals that affect other hardware modules or chips. This patch defines a standard API that connects reset clients (i.e. the drivers for devices affected by reset signals) to drivers for reset controllers/providers. Initially, DT is the only supported method for connecting the two. The DT binding specification (reset.txt) was taken from Linux kernel v4.5's Documentation/devicetree/bindings/reset/reset.txt. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-05-27Rename reset to sysresetStephen Warren
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>
2015-07-21dm: reset: Allow reset_walk() to returnSimon Glass
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-21dm: Add a system reset uclassSimon Glass
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>