summaryrefslogtreecommitdiff
path: root/include/dm
Commit message (Collapse)AuthorAgeLines
* 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>
* dm: Add support for generic system controllers (syscon)Simon Glass2015-07-21-0/+1
| | | | | | | | | | | Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Correct device_get_child_by_of_offset() parameterSimon Glass2015-07-21-1/+1
| | | | | | This parameter is named 'seq' but should be named 'of_offset'. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Add a function to find any device from device treeSimon Glass2015-07-21-0/+14
| | | | | | | | | | | | 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>
* dm: Move the tree/uclass dump code into its own fileSimon Glass2015-07-21-0/+6
| | | | | | | | | | In SPL it is sometimes useful to be able to obtain a dump of the current driver model state. Since commands are not available, provide a way to directly call the functions to output this information. Adjust the existing commands to use these functions. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Sort the uclass IDs after the tegra/PMIC additionSimon Glass2015-06-04-5/+3
| | | | | | | | Tidy up the sort order again. Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Joe Hershberger <joe.hershberger@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
* test: dm: Move the dm tests over to the ut commandJoe Hershberger2015-05-21-11/+0
| | | | | | | | Unify the command for running unit tests further by moving the "dm test" command over to "ut dm". Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
* test: Generalize the unit test frameworkJoe Hershberger2015-05-21-135/+7
| | | | | | | | | Separate the ability to define tests and assert status of test functions from the dm tests so they can be used more consistently throughout all tests. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* dm: regulator: add implementation of driver model regulator uclassPrzemyslaw Marczak2015-05-14-0/+1
| | | | | | | | | | | | | | | | | | 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>
* dm: pmic: add implementation of driver model pmic uclassPrzemyslaw Marczak2015-05-14-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | This commit introduces the PMIC uclass implementation. It allows providing the basic I/O interface for PMIC devices. For the multi-function PMIC devices, this can be used as I/O parent device, for each IC's interface. Then, each PMIC particular function can be provided by the child device's operations, and the child devices will use its parent for read/write by the common API. Core files: - 'include/power/pmic.h' - 'drivers/power/pmic/pmic-uclass.c' The old pmic framework is still kept and is independent. For more detailed informations, please look into the header file. Changes: - new uclass-id: UCLASS_PMIC - new config: CONFIG_DM_PMIC Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: video: Add a uclass for display portSimon Glass2015-05-13-0/+1
| | | | | | | | | eDP (Embedded DisplayPort) is a standard widely used in laptops to drive LCD panels. Add a uclass for this which supports a few simple operations. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
* dm: core: Sort the uclassesSimon Glass2015-05-13-16/+16
| | | | | | | Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* dm: rtc: Add a uclass for real-time clocksSimon Glass2015-05-05-0/+1
| | | | | | | | | Add a uclass for real-time clocks which support getting the current time, setting it and resetting the chip to a known-working state. Some RTCs have additional registers which can be used to store settings, so also provide an interface to these. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Implement a CPU uclassSimon Glass2015-04-29-0/+1
| | | | | | | | | | It is useful to be able to keep track of the available CPUs in a multi-CPU system. This uclass is mostly intended for use with SMP systems. The uclass provides methods for getting basic information about each CPU. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* dm: core: Add a function to bind a driver for a device tree nodeSimon Glass2015-04-29-0/+16
| | | | | | | | Some device tree nodes do not have compatible strings but do require drivers. This is pretty rare, and somewhat unfortunate. Add a function to permit creation of a driver for any device tree node. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Remove unbind operations when not requiredSimon Glass2015-04-23-0/+8
| | | | | | | | The CONFIG_DM_DEVICE_REMOVE option takes out code related to removing devices. It should also remove the 'unbind' code since if we cannot remove we probably don't need to unbind. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: precise comments for get/find device by namePrzemyslaw Marczak2015-04-22-2/+2
| | | | | | | | | | | | The functions: - uclass_find_device_by_name() - uclass_get_device_by_name() searches the required device for the exactly given name. This patch, presice this fact for both function's comments. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: remove type 'static' of function uclass_get_device_tail()Przemyslaw Marczak2015-04-22-3/+18
| | | | | | | | | | | Uclass API provides a few functions for get/find the device. To provide a complete function set of uclass-internal functions, for use by the drivers, the function uclass_get_device_tail() should be non-static. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: device: add function: dev_get_uclass_name()Przemyslaw Marczak2015-04-22-0/+10
| | | | | | | | | | | | | This commit extends the driver model device's API by function: - dev_get_uclass_name() And this function returns the device's uclass driver name if: - given dev pointer, is non_NULL otherwise, the NULL pointer is returned. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: device: add function: dev_get_driver_ops()Przemyslaw Marczak2015-04-22-0/+11
| | | | | | | | | | | | | | This commit extends the driver model device's API by function: - dev_get_driver_ops() And this function returns the device's driver's operations if given: - dev pointer, is non-NULL - dev->driver->ops pointer, is non-NULL in other case the, the NULL pointer is returned. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: uclass: add function: uclass_get_device_by_name()Przemyslaw Marczak2015-04-22-0/+15
| | | | | | | | | | | | | | | | | | | | | | This commit extends the driver model uclass's API by function: - uclass_get_device_by_name() And this function returns the device if: - uclass with given ID, exists, - device with exactly given name(dev->name), exists, - device probe, doesn't return an error. The returned device is activated and ready to use. Note: This function returns the first device, which name is equal to the given one. This means, that using this function you must assume, that the device name is unique in the given uclass's ID device list. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: uclass: add function: uclass_find_device_by_name()Przemyslaw Marczak2015-04-22-23/+38
| | | | | | | | | | | | | | | | | | | | | | | | This commit extends the driver model uclass's API by function: - uclass_find_device_by_name() And this function returns the device if: - uclass with given ID, exists, - device with exactly given name(dev->name), exists. The returned device is not activated - need to be probed before use. Note: This function returns the first device, which name is equal to the given one. This means, that using this function you must assume, that the device name is unique in the given uclass's ID device list. uclass-internal.h: cleanup - move the uclass_find_device_by_seq() declaration and description, near the other uclass_find*() functions. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* dm: test: Add tests for device's uclass platform dataPrzemyslaw Marczak2015-04-22-0/+20
| | | | | | | | | | | | | | | | | | | | | This test introduces new test structure type:dm_test_perdev_uc_pdata. The structure consists of three int values only. For the test purposes, three pattern values are defined by enum, starting with TEST_UC_PDATA_INTVAL1. This commit adds two test cases for uclass platform data: - Test: dm_test_autobind_uclass_pdata_alloc - this tests if: * uclass driver sets: .per_device_platdata_auto_alloc_size field * the devices's: dev->uclass_platdata is non-NULL - Test: dm_test_autobind_uclass_pdata_valid - this tests: * if the devices's: dev->uclass_platdata is non-NULL * the structure of type 'dm_test_perdev_uc_pdata' allocated at address pointed by dev->uclass_platdata. Each structure field, should be equal to proper pattern data, starting from .intval1 == TEST_UC_PDATA_INTVAL1. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-11-05 08:23:55 +0000