summaryrefslogtreecommitdiff
path: root/include/dm
Commit message (Collapse)AuthorAgeLines
...
* dm: video: test: Add tests for the video uclassSimon Glass2016-01-20-0/+8
| | | | | | | | | Add tests that check that the video console is working correcty. Also check that text output produces the expected result. Test coverage includes character output, wrapping and scrolling. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
* dm: video: Add a uclass for the text consoleSimon Glass2016-01-20-0/+1
| | | | | | | | | | | | The existing LCD/video interface suffers from conflating the bitmap display with text output on that display. As a result the implementation is more complex than it needs to me. We can support multiple text console drivers. Create a separate uclass to support this, with its own API. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
* dm: video: Add a video uclassSimon Glass2016-01-20-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | U-Boot has separate code for LCDs and 'video' devices. Both now use a very similar API thanks to earlier work by Nikita Kiryanov. With the driver- model conversion we should unify these into a single uclass. Unfortunately there are different features supported by each. This implementation provides for a common set of features which should serve most purposes. The intent is to support: - bitmap devices with 8, 16 and 32 bits per pixel - text console wih white on black or vice versa - rotated text console - bitmap display (BMP format) More can be added as additional boards are ported over to use driver model for video. The name 'video' is chosen for the uclass since it is more generic than LCD. Another option would be 'display' but that would introduce a third concept to U-Boot which seems like the wrong approach. The existing LCD and video init functions are not needed now, so this uclass makes no attempt to implement them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
* serial: lpc32xx hsuart: port driver to driver modelVladimir Zapolskiy2016-01-13-0/+18
| | | | | | | | The change ports NXP LPC32xx 14-clock UART device driver to driver model. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* dm: core: Add a new api to get indexed device addressMugunthan V N2016-01-13-0/+11
| | | | | | | | | Add new api to get device address based on index. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Acked-by: Jagan Teki <jteki@openedev.com> [Rebased on master] Signed-off-by: Jagan Teki <jteki@openedev.com>
* dm: core: Add option to configure an offset for the address translationStefan Roese2016-01-12-0/+21
| | | | | | | | | | | | Some platforms need to ability to configure an offset to the standard addresses extracted from the device-tree. This patch allows this by adding a function to DM to configure this offset (if needed). Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Fixed space before tab: Signed-off-by: Simon Glass <sjg@chromium.org>
* stm32: Convert serial driver to DMKamil Lulko2015-12-12-0/+16
| | | | | | Signed-off-by: Kamil Lulko <kamil.lulko@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* Revert "dm: Export device_remove_children / device_unbind_children"Simon Glass2015-11-19-26/+0
| | | | | | This reverts commit bb52b367f6ca4a3a918e77737f4ff6a1089912d9. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Add safe device iteration macrosSimon Glass2015-11-19-0/+27
| | | | | | Add iteration macros which support unbinding a device within the loop. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: usb: Add support for USB keyboards with driver modelSimon Glass2015-11-19-0/+1
| | | | | | | | Switch USB keyboards over to use driver model instead of scanning with the horrible usb_get_dev_index() function. This involves creating a new uclass for keyboards, although so far there is no API. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: implement a MTD uclassThomas Chou2015-11-12-0/+1
| | | | | | | | | | | | Implement a Memory Technology Device (MTD) uclass. It should include most flash drivers in the future. Though no uclass ops are defined yet, the MTD ops could be used. The NAND flash driver is based on MTD. The CFI flash and SPI flash support MTD, too. It should make sense to convert them to MTD uclass. Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
* dm: adc: add simple ADC uclass implementationPrzemyslaw Marczak2015-11-02-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds: - new uclass id: UCLASS_ADC - new uclass driver: drivers/adc/adc-uclass.c The new uclass's API allows for ADC operation on: * single-channel with channel selection by a number * multti-channel with channel selection by bit mask ADC uclass's functions: * single-channel: - adc_start_channel() - start channel conversion - adc_channel_data() - get conversion data - adc_channel_single_shot() - start/get conversion data * multi-channel: - adc_start_channels() - start selected channels conversion - adc_channels_data() - get conversion data - adc_channels_single_shot() - start/get conversion data for channels selected by bit mask * general: - adc_stop() - stop the conversion - adc_vdd_value() - positive reference Voltage value with polarity [uV] - adc_vss_value() - negative reference Voltage value with polarity [uV] - adc_data_mask() - conversion data bit mask The device tree can provide below constraints/properties: - vdd-polarity-negative: if true: Vdd = vdd-microvolts * (-1) - vss-polarity-negative: if true: Vss = vss-microvolts * (-1) - vdd-supply: phandle to Vdd regulator's node - vss-supply: phandle to Vss regulator's node And optional, checked only if the above corresponding, doesn't exist: - vdd-microvolts: positive reference Voltage [uV] - vss-microvolts: negative reference Voltage [uV] Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
* Merge git://git.denx.de/u-boot-dmTom Rini2015-10-27-56/+63
|\
| * dm: core: Tidy up comments in device.hSimon Glass2015-10-23-3/+16
| | | | | | | | | | | | | | Correct a few nits found in a recent review. Expand the comments in dev_get_driver_data() to make it clearer. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: core: Remove a comment about dropping per_child_auto_alloc_sizeSimon Glass2015-10-23-4/+0
| | | | | | | | | | | | | | This has proven useful and we no-longer intend to remove it. Drop the comment. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: core: Tidy up devres commentsSimon Glass2015-10-23-26/+24
| | | | | | | | | | | | | | | | Adjust the devres comments to be consistent with the rest of the file, and add one for the struct udevice member. Also rename the 'p' parameter to 'ptr' to avoid single-character names. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: core: Fix device flag whitespaceSimon Glass2015-10-23-5/+5
| | | | | | | | | | | | Line up the flag values in the code for easier readability. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: core: Adjust device.h header file orderSimon Glass2015-10-23-13/+13
| | | | | | | | | | | | Move a few functions around so that the ordering is consistent. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: Rename dev_get_parentdata() to dev_get_parent_priv()Simon Glass2015-10-23-5/+5
| | | | | | | | | | | | | | | | The current name is inconsistent with other driver model data access functions. Rename it and fix up all users. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
* | dm: implement a Miscellaneous uclassThomas Chou2015-10-23-0/+1
| | | | | | | | | | | | | | | | | | Implement a Miscellaneous uclass with generic read or write operations. This class is used only for those do not fit other more general classes. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Acked-by: Simon Glass <sjg@chromium.org>
* | dm: implement a Timer uclassThomas Chou2015-10-23-0/+1
|/ | | | | | | Implement a Timer uclass to work with lib/time.c. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Acked-by: Simon Glass <sjg@chromium.org>
* drivers: Introduce a simplified remoteproc frameworkNishanth Menon2015-10-22-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many System on Chip(SoC) solutions are complex with multiple processors on the same die dedicated to either general purpose of specialized functions. Many examples do exist in today's SoCs from various vendors. Typical examples are micro controllers such as an ARM M3/M0 doing a offload of specific function such as event integration or power management or controlling camera etc. Traditionally, the responsibility of loading up such a processor with a firmware and communication has been with a High Level Operating System(HLOS) such as Linux. However, there exists classes of products where Linux would need to expect services from such a processor or the delay of Linux and operating system being able to load up such a firmware is unacceptable. To address these needs, we need some minimal capability to load such a system and ensure it is started prior to an Operating System(Linux or any other) is started up. NOTE: This is NOT meant to be a solve-all solution, instead, it tries to address certain class of SoCs and products that need such a solution. A very simple model is introduced here as part of the initial support that supports microcontrollers with internal memory (no MMU, no execution from external memory, or specific image format needs). This basic framework can then (hopefully) be extensible to other complex SoC processor support as need be. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: pci: Add an inline API to test if a device is on a PCI busBin Meng2015-09-16-0/+11
| | | | | | | | Introduce device_is_on_pci_bus() which can be utilized by driver to test if a device is on a PCI bus. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* pinctrl: Add the concept of peripheral IDsSimon Glass2015-09-02-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
* pinctrl: add pin control uclass supportMasahiro Yamada2015-08-31-0/+229
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: allow device_bind() to not return a device pointerMasahiro Yamada2015-08-31-4/+4
| | | | | | | | This is useful when we want to bind a device, but do not need the pointer to the device. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: tpm: Add a uclass for Trusted Platform ModulesSimon Glass2015-08-31-0/+1
| | | | | | | | | | | | | | Add a new uclass for TPMs which uses almost the same TIS (TPM Interface Specification) as is currently implemented. Since init() is handled by the normal driver model probe() method, we don't need to implement that. Also rename the transfer method to xfer() which is a less clumbsy name. Once all drivers and users are converted to driver model we can remove the old code. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Christophe Ricard<christophe-h.ricard@st.com> Reviewed-by: Heiko Schocher <hs@denx.de>
* dm: simplify uclass_foreach_dev() implementationMasahiro Yamada2015-08-31-7/+2
| | | | | | | | This can be simply written with list_for_each_entry(), maybe this macro was not necessary in the first place. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
* serial: uniphier: drop platform data supportMasahiro Yamada2015-08-31-18/+0
| | | | | | | | | | This driver is enabled only for UniPhier SoCs and ARCH_UNIPHIER now selects OF_CONTROL and SPL_OF_CONTROL. This driver no longer needs to support platform data configuration. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* of: clean up OF_CONTROL ifdef conditionalsMasahiro Yamada2015-08-18-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We have flipped CONFIG_SPL_DISABLE_OF_CONTROL. We have cleansing devices, $(SPL_) and CONFIG_IS_ENABLED(), so we are ready to clear away the ugly logic in include/fdtdec.h: #ifdef CONFIG_OF_CONTROL # if defined(CONFIG_SPL_BUILD) && !defined(SPL_OF_CONTROL) # define OF_CONTROL 0 # else # define OF_CONTROL 1 # endif #else # define OF_CONTROL 0 #endif Now CONFIG_IS_ENABLED(OF_CONTROL) is the substitute. It refers to CONFIG_OF_CONTROL for U-boot proper and CONFIG_SPL_OF_CONTROL for SPL. Also, we no longer have to cancel CONFIG_OF_CONTROL in include/config_uncmd_spl.h and scripts/Makefile.spl. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
* dm: drop CONFIG_DM_DEVICE_REMOVE from uncmd listMasahiro Yamada2015-08-18-7/+7
| | | | | | | | | | | | | | | We do not want to compile the DM remove code for SPL. Currently, we undef it in include/config_uncmd_spl.h (for C files) and in scripts/Makefile.uncmd_spl (for Makefiles). This is really ugly. This commit demonstrates how we can deprecate those two files. Use $(SPL_) for the entry in the Makfile and CONFIG_IS_ENABLED() in C files. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* dm: core: Fix a typo in the uclass_get_device_by_name() commentSimon Glass2015-08-06-1/+1
| | | | | | | This function comment has a typo. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* dm: core: Add a way to set a device nameSimon Glass2015-08-06-0/+15
| | | | | | | | | | Some devices are bound entirely by probing and do not have the benefit of a device tree to give them a name. This is very common with PCI and USB. In most cases this is fine, but we should add an official way to set a device name. This should be called in the device's bind() method. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* devres: add debug command to dump device resourcesMasahiro Yamada2015-08-06-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This new command can dump all device resources associated to each device. The fields in every line shows: - The address of the resource - The size of the resource - The name of the release function - The stage in which the resource has been acquired (BIND/PROBE) Currently, there is no driver using devres, but if such drivers are implemented, the output of this command should look like this: => dm devres - root_driver - soc - extbus - serial@54006800 bfb541e8 (8 byte) devm_kmalloc_release BIND bfb54440 (4 byte) devm_kmalloc_release PROBE bfb54460 (4 byte) devm_kmalloc_release PROBE - serial@54006900 bfb54270 (8 byte) devm_kmalloc_release BIND - gpio@55000000 - i2c@58780000 bfb5bce8 (12 byte) devm_kmalloc_release PROBE bfb5bd10 (4 byte) devm_kmalloc_release PROBE - eeprom bfb54418 (12 byte) devm_kmalloc_release BIND Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
* devres: make Devres optional with CONFIG_DEVRESMasahiro Yamada2015-08-06-0/+95
| | | | | | | | | | | | | | | | | Currently, Devres requires additional 16 byte for each allocation, which is not so insignificant in some cases. Add CONFIG_DEVRES to make this framework optional. If the option is disabled, devres functions fall back to non-managed variants. For example, devres_alloc() to kzalloc(), devm_kmalloc() to kmalloc(), etc. Because devres_head is also surrounded by an ifdef conditional, there is no memory overhead when CONFIG_DEVRES is disabled. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Suggested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* devres: add devm_kmalloc() and friends (managed memory allocators)Masahiro Yamada2015-08-06-0/+44
| | | | | | | | | | | devm_kmalloc() is identical to kmalloc() except that the memory allocated with it is managed and will be automatically released when the device is removed/unbound. Likewise for the other variants. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
* devres: introduce Devres (Managed Device Resource) frameworkMasahiro Yamada2015-08-06-0/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In U-Boot's driver model, memory is basically allocated and freed in the core framework. So, low level drivers generally only have to specify the size of needed memory with .priv_auto_alloc_size, .platdata_auto_alloc_size, etc. Nevertheless, some drivers still need to allocate/free memory on their own in case they cannot statically know the necessary memory size. So, I believe it is reasonable enough to port Devres into U-boot. Devres, which originates in Linux, manages device resources for each device and automatically releases them on driver detach. With devres, device resources are guaranteed to be freed whether initialization fails half-way or the device gets detached. The basic idea is totally the same to that of Linux, but I tweaked it a bit so that it fits in U-Boot's driver model. In U-Boot, drivers are activated in two steps: binding and probing. Binding puts a driver and a device together. It is just data manipulation on the system memory, so nothing has happened on the hardware device at this moment. When the device is really used, it is probed. Probing initializes the real hardware device to make it really ready for use. So, the resources acquired during the probing process must be freed when the device is removed. Likewise, what has been allocated in binding should be released when the device is unbound. The struct devres has a member "probe" to remember when the resource was allocated. CONFIG_DEBUG_DEVRES is also supported for easier debugging. If enabled, debug messages are printed each time a resource is allocated/freed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: add DM_FLAG_BOUND flagMasahiro Yamada2015-08-06-0/+3
| | | | | | | | | | | | Currently, we only have DM_FLAG_ACTIVATED to indicate the device status, but we still cannot know in which stage is in progress, binding or probing. This commit introduces a new flag, DM_FLAG_BOUND, which is set when the device is really bound, and cleared when it is unbound. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Support address translation for simple-busSimon Glass2015-08-06-0/+12
| | | | | | | | The 'ranges' property can be used to specify a translation from the system address to the bus address. Add support for this using the dev_get_addr() function, which devices should use to find their address. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: video: Add support for video bridgesSimon Glass2015-08-05-0/+1
| | | | | | | | | A video bridge typically converts video from one format to another, e.g. DisplayPort to LVDS. Add driver model support for these with a simple interface to control activation and backlight. The uclass supports GPIO control of power and reset lines. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: i2c: Add support for multiplexed I2C busesSimon Glass2015-08-05-0/+1
| | | | | | | | | | | | | | | | | 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>
* dm: core: Support finding a device by phandleSimon Glass2015-08-05-0/+17
| | | | | | | | | It is common for one node to reference another via a phandle. Add support for obtaining an attached device by this method. As an example, a node may have a 'power-supply' property which references a regulator, allowing the driver to turn on its power. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Add a return value comment to device_get_child()Simon Glass2015-08-05-1/+3
| | | | | | | At present this function does not specify its return value. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* dm: Export device_remove_children / device_unbind_childrenHans de Goede2015-07-21-0/+26
| | | | | | | | These functions are useful to remove all children from an usb bus before rescanning the bus. Give them a better name and export them. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Add platform data advice and admonishmentSimon Glass2015-07-21-0/+9
| | | | | | | | 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>
* dm: Add a clock uclassSimon Glass2015-07-21-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* dm: Add a system reset uclassSimon Glass2015-07-21-0/+1
| | | | | | | | | | | | | | | | 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>
* dm: Add support for RAM driversSimon Glass2015-07-21-0/+1
| | | | | | | | Add support for a driver which sets up DRAM and can return information about the amount of RAM available. This is a first step towards moving RAM init to driver model. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: mmc: Add an MMC uclassSimon Glass2015-07-21-0/+1
| | | | | | | Add basic support for MMC, providing a uclass which can set up an MMC device. This allows MMC drivers to move to using driver model. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Add support for LEDsSimon Glass2015-07-21-0/+1
| | | | | | | | | Add a simple uclass for LEDs, so that these can be controlled by the device tree and activated when needed. LEDs are referred to by their label. This implementation requires a driver for each type of LED (e.g GPIO, I2C). Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-11-09 10:32:46 +0000