| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
The current reset API implements a method to reset the entire system.
In the near future, I'd like to introduce code that implements the device
tree reset bindings; i.e. the equivalent of the Linux kernel's reset API.
This controls resets to individual HW blocks or external chips with reset
signals. It doesn't make sense to merge the two APIs into one since they
have different semantic purposes. Resolve the naming conflict by renaming
the existing reset API to sysreset instead, so the new reset API can be
called just reset.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Add a new reset_walk_halt() function to cause a reset and then halt on
failure. The reset_walk() function returns an error code.
This is needed for testing since otherwise U-Boot will halt in the middle
of a test.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
It is common for system reset to be available at multiple levels in modern
hardware. For example, an SoC may provide a reset option, and a board may
provide its own reset for reasons of security or thoroughness. It is useful
to be able to model this hardware without hard-coding the behaviour in the
SoC or board. Also there is a distinction sometimes between resetting just
the CPU (leaving GPIO state alone) and resetting all the PMICs, just cutting
power.
To achieve this, add a simple system reset uclass. It allows multiple devices
to provide reset functionality and provides a way to walk through them,
requesting a particular reset type until is it provided.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
