summaryrefslogtreecommitdiff
path: root/drivers/core/uclass.c
Commit message (Collapse)AuthorAgeLines
* dm: core: Add a way to find a device by its driverSimon Glass2016-07-25-0/+20
| | | | | | | | | Some SoCs have a single clock device. Provide a way to find it given its driver name. This is handled by the linker so will fail if the name is not found, avoiding strange errors when names change and do not match. It is also faster than a string comparison. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Add uclass_first_device_err() to return a valid deviceSimon Glass2016-03-14-0/+13
| | | | | | | | A common pattern is to call uclass_first_device() and then check if it actually returns a device. Add a new function which does this, returning an error if there are no devices in that uclass. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Export uclass_find_device_by_of_offset()Simon Glass2016-01-21-2/+2
| | | | | | | | It is sometimes useful to be able to find a device before probing it, perhaps to set up some platform data for it. Allow finding by of_offset also. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Call uclass post_bind() after the driver's bind() methodSimon Glass2016-01-20-5/+0
| | | | | | | | | | | | | | | | | At present the uclass's post_bind() method is called before the driver's bind() method. This means that the uclass cannot use any of the information set up by the driver. Move it later in the sequence to permit this. This is an ordering change which is always fairly major in nature. The main impact is that devices which have children will not see them appear in their bind() method. From what I can see, existing drivers do not look at their children in the bind() method, so this should be safe. Conceptually this change seems to result in a 'more correct' ordering, since the uclass (which is broader than the device) gets the last word. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* dm: core: Provide uclass_find_device_by_phandle() only when neededSimon Glass2016-01-20-0/+4
| | | | | | | This function cannot be used unless support is enabled for device tree control. Adjust the code to reflect that. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Remove unnecessary codes in uclass_pre_remove_device()Bin Meng2015-10-29-7/+0
| | | | | | | | dev->uclass->uc_drv->per_device_auto_alloc_size is to be freed in device_free(), so is dev->seq. Remove these unnecessary codes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Improve handling of a missing uclassSimon Glass2015-09-02-1/+6
| | | | | | | | | | | | | | | When a uclass definition is missing, no drivers in that uclass can operate. This can happen if a board has a strange collection of options (e.g. the driver is enabled but the uclass is not). Unfortunately this is very confusing at present. Starting up driver model results in a -ENOENT error, which is pretty generic. Quite a big of digging is needed to get to the root cause. To help with this, change the error to a very strange one with no other users in U-Boot. Also add a debug message. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: drop CONFIG_DM_DEVICE_REMOVE from uncmd listMasahiro Yamada2015-08-18-2/+2
| | | | | | | | | | | | | | | 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: Support finding a device by phandleSimon Glass2015-08-05-0/+42
| | | | | | | | | 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: core: Check for empty list in uclass_find_device()Simon Glass2015-08-05-0/+2
| | | | | | | | This function needs to check the list has entries before traversing it. Fix this bug. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* dm: change dm_warn() message into debug() in uclass_add()Masahiro Yamada2015-07-21-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The command "dm uclass" tries to display all the UClasses, but some of them might be disabled by Kconfig. The function do_dm_dump_uclass() iterates over all the UClass IDs and calls uclass_get() for each of them. Then, it displays annoying message "Cannot find uclass for id ..." every time it fails to get the UClass. As a result, we get much noisier log for the "dm uclass" command. => dm uclass uclass 0: root - * root_driver @ bfb54028, seq 0, (req -1) Cannot find uclass for id 1: please add the UCLASS_DRIVER() ... Cannot find uclass for id 2: please add the UCLASS_DRIVER() ... Cannot find uclass for id 3: please add the UCLASS_DRIVER() ... Cannot find uclass for id 4: please add the UCLASS_DRIVER() ... Cannot find uclass for id 5: please add the UCLASS_DRIVER() ... Cannot find uclass for id 6: please add the UCLASS_DRIVER() ... This commit suppresses these warnings. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: Correct bug introduced in uclass_first/next_device()Simon Glass2015-04-28-0/+5
| | | | | | | | | | | | | | These functions now rely on uclass_find_first/next_device() and assume that they will either return failure (-ve error code) or a device. In fact, coming to the end of a list is not considered failure and they return 0 in that case. The logic to deal with this was replaced in commit acb9ca2a with just using uclass_get_device_tail(). Add back the missing logic. This bug was caught by unit tests but since they were broken for other reasons at the time, this was not noticed. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Remove unbind operations when not requiredSimon Glass2015-04-23-0/+4
| | | | | | | | 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: Handle recursive unbinding of uclass devicesSimon Glass2015-04-22-2/+10
| | | | | | | | | | | | Since a device can have children in the same uclass as itself, we need to handle unbinding carefully: we must allow that unbinding a device in a uclass may cause another device in the same uclass to be unbound. Adjust the code to cope. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com> Tested-by: Joe Hershberger <joe.hershberger@ni.com>
* dm: core: remove type 'static' of function uclass_get_device_tail()Przemyslaw Marczak2015-04-22-11/+1
| | | | | | | | | | | 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: uclass: add function: uclass_get_device_by_name()Przemyslaw Marczak2015-04-22-0/+11
| | | | | | | | | | | | | | | | | | | | | | 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-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | 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: core: add internal functions for getting the device without probePrzemyslaw Marczak2015-04-22-25/+34
| | | | | | | | | | | | | | | | This commit extends the uclass-internal functions by: - uclass_find_first_device() - uclass_find_next_device() For both functions, the returned device is not probed. After some cleanup, the above functions are called by: - uclass_first_device() - uclass_next_device() for which, the returned device is probed. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: Add a uclass pre_probe() method for devicesSimon Glass2015-04-16-1/+9
| | | | | | | | | | | | Some uclasses want to set up a device before it is probed. Add a method for this. An example is with PCI, where a PCI uclass wants to set up its private data for later use. This allows the device's uclass() method to make calls whcih use that data (for example, read PCI memory regions from device tree, set up bus numbers). Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Allow uclass to set up a device's child before it is probedSimon Glass2015-01-29-0/+13
| | | | | | | | | Some buses need to set up their devices before they can be used. This setup may well be common to all buses in a particular uclass. Support a common pre-probe method for the uclass, called before any bus devices are probed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* dm: core: Allow the uclass to set up a device's child after bindingSimon Glass2015-01-29-5/+16
| | | | | | | | | | | | For buses, after a child is bound, allow the uclass to perform some processing. This can be used to figure out the address of the child (e.g. the chip select for SPI slaves) so that it is ready to be probed. This avoids bus drivers having to repeat the same process, which really should be done by the uclass, since it is common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* dm: do not check the existence of uclass operationMasahiro Yamada2014-10-22-4/+0
| | | | | | | | | | | | | | | | | | The function uclass_add() checks uc_drv->ops as follows: if (uc_drv->ops) { dm_warn("No ops for uclass id %d\n", id); return -EINVAL; } It seems odd because it warns "No ops" when uc_drv->ops has non-NULL pointer. (Looks opposite.) Anyway, most of UCLASS_DRIVER entries have no .ops member. This check makes no sense. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Avoid accessing uclasses before they are readySimon Glass2014-07-23-0/+2
| | | | | | Don't allow access to uclasses before they have been initialised. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Allow a device to be found by its FDT offsetSimon Glass2014-07-23-0/+35
| | | | | | | | Each device that was bound from a device tree has an node that caused it to be bound. Add functions that find and return a device based on a device tree offset. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Introduce device sequence numberingSimon Glass2014-07-23-0/+78
| | | | | | | | | | | | | | | | | | | | | | | | | In U-Boot it is pretty common to number devices from 0 and access them on the command line using this numbering. While it may come to pass that we will move away from this numbering, the possibility seems remote at present. Given that devices within a uclass will have an implied numbering, it makes sense to build this into driver model as a core feature. The cost is fairly small in terms of code and data space. With each uclass having numbered devices we can ask for SPI port 0 or serial port 1 and receive a single device. Devices typically request a sequence number using aliases in the device tree. These are resolved when the device is probed, to deal with conflicts. Sequence numbers need not be sequential and holes are permitted. At present there is no support for sequence numbers using static platform data. It could easily be added to 'struct driver_info' if needed, but it seems better to add features as we find a use for them, and the use of -1 to mean 'no sequence' makes the default value somewhat painful. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Move uclass error checking/probing into a functionSimon Glass2014-07-23-6/+22
| | | | | | Several functions will use this same pattern, so bring it into a function. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Cast away the const-ness of the global_data pointerSimon Glass2014-06-20-1/+1
| | | | | | | In a very few cases we need to adjust the driver model root device, such as when setting it up at initialisation. Add a macro to make this easier. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: rename device struct to udeviceHeiko Schocher2014-05-27-15/+16
| | | | | | | | | | | | using UBI and DM together leads in compiler error, as both define a "struct device", so rename "struct device" in include/dm/device.h to "struct udevice", as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux "struct device" Signed-off-by: Heiko Schocher <hs@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Marek Vasut <marex@denx.de>
* dm: Add base driver model supportSimon Glass2014-03-04-0/+285
Add driver model functionality for generic board. This includes data structures and base code for registering devices and uclasses (groups of devices with the same purpose, e.g. all I2C ports will be in the same uclass). The feature is enabled with CONFIG_DM. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
generated by cgit v1.1 at 2024-11-02 02:21:11 +0000