| 3d1957f0 | 03-Aug-2015 |
Simon Glass <sjg@chromium.org> |
dm: i2c: Add support for multiplexed I2C buses
Add a new I2C_MUX uclass. Devices in this class can multiplex between
several I2C buses, selecting them one at a time for use by the system.
The multip
dm: i2c: Add support for multiplexed I2C buses
Add a new I2C_MUX uclass. Devices in this class can multiplex between
several I2C buses, selecting them one at a time for use by the system.
The multiplexing mechanism is left to the driver to decide - it may be
controlled by GPIOs, for example.
The uclass supports only two methods: select() and deselect().
The current mux state is expected to be stored in the mux itself since
it is the only thing that knows how to make things work. The mux can
record the current state and then avoid switching unless it is necessary.
So select() can be skipped if the mux is already in the correct state.
Also deselect() can be made a nop if required.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 97f3ee34 | 06-Jul-2015 |
Simon Glass <sjg@chromium.org> |
dm: Add platform data advice and admonishment
We should guide people more strongly towards device tree to avoid the
proliferation of platform data structures. Add documentation to the driver
model R
dm: Add platform data advice and admonishment
We should guide people more strongly towards device tree to avoid the
proliferation of platform data structures. Add documentation to the driver
model README, and also the platform data header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| f26c8a8e | 23-Jun-2015 |
Simon Glass <sjg@chromium.org> |
dm: Add a clock uclass
Clocks are an important feature of platforms and have become increasing
complex with time. Most modern SoCs have multiple PLLs and dozens of clock
dividers which distribute cl
dm: Add a clock uclass
Clocks are an important feature of platforms and have become increasing
complex with time. Most modern SoCs have multiple PLLs and dozens of clock
dividers which distribute clocks to on-chip peripherals.
Some SoC implementations have a clock API which is private to that SoC family,
e.g. Tegra and Exynos. This is useful but it would be better to have a
common API that can be understood and used throughout U-Boot.
Add a simple clock API as a starting point. It supports querying and setting
the rate of a clock. Each clock is a device. To reduce memory and processing
overhead the concept of peripheral clocks is provided. These do not need to
be explicit devices - it is possible to write a driver that can adjust the
I2C clock (for example) without an explicit I2C clock device. This can
dramatically reduce the number of devices (and associated overhead) in a
complex SoC.
Clocks are referenced by a number, and it is expected that SoCs will define
that numbering themselves via an enum.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| f9917454 | 23-Jun-2015 |
Simon Glass <sjg@chromium.org> |
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 res
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>
show more ...
|
| 2693047a | 23-Jun-2015 |
Simon Glass <sjg@chromium.org> |
dm: core: Add a function to find any device from device tree
In some rare cases it is useful to be able to locate a device given a device
tree node offset. An example is when you have an alias that
dm: core: Add a function to find any device from device tree
In some rare cases it is useful to be able to locate a device given a device
tree node offset. An example is when you have an alias that points to a node
and you want to find the associated device. The device may be SPI, MMC or
something else, but you don't need to know the uclass to find it.
Add a function to do a global search for a device, given its device tree
offset.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| af41e8db | 20-Apr-2015 |
Przemyslaw Marczak <p.marczak@samsung.com> |
dm: regulator: add implementation of driver model regulator uclass
This commit introduces the implementation of dm regulator API.
Device tree support allows for auto binding. And by the basic
uclass
dm: regulator: add implementation of driver model regulator uclass
This commit introduces the implementation of dm regulator API.
Device tree support allows for auto binding. And by the basic
uclass operations, it allows to driving the devices in a common
way. For detailed informations, please look into the header file.
Core files:
- drivers/power/regulator-uclass.c - provides regulator common functions api
- include/power/regulator.h - define all structures required by the regulator
Changes:
- new uclass-id: UCLASS_REGULATOR
- new config: CONFIG_DM_REGULATOR
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|