summaryrefslogtreecommitdiffstats
path: root/drivers/core
Commit message (Collapse)AuthorAgeFilesLines
* kconfig: add blank Kconfig filesMasahiro Yamada2014-09-241-0/+0
| | | | | | | | This would be useful to start moving various config options. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* dm: avoid dev->req_seq overflowRobert Baldyga2014-09-231-0/+2
| | | | | | | | | | | | | Since dev->req_seq value is initialized from "reg" property of fdt node, there is posibility, that address value contained in fdt is greater than INT_MAX, and then value in dev->req_seq is negative which led to probe() fail. This patch fix this problem by ensuring that req_seq is positive, unless it's one of errno codes. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: Allow device_bind() to used without CONFIG_OF_CONTROLSimon Glass2014-09-231-2/+5
| | | | | | | | The sequence number support in driver model requires device tree control. It should be skipped if CONFIG_OF_CONTROL is not defined, and should not require functions from fdtdec. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Adjust lists_bind_fdt() to return the bound deviceSimon Glass2014-09-102-4/+8
| | | | | | | Allow the caller to find out the device that was bound in response to this call. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Add dm_scan_other() to locate board-specific devicesSimon Glass2014-07-231-0/+8
| | | | | | | | Some boards will have devices which are not in the device tree and do not have platform data. They may be programnatically created, for example. Add a hook which boards can use to bind those devices early in boot. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Improve errors and warnings in lists_bind_fdt()Simon Glass2014-07-231-3/+13
| | | | | | | Add a debug message for when a device tree node has no driver. Also reword the warning when a device fails to bind, which was misleading. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Add child_pre_probe() and child_post_remove() methodsSimon Glass2014-07-231-1/+15
| | | | | | | | | | | Some devices (particularly bus devices) must track their children, knowing when a new child is added so that it can be set up for communication on the bus. Add a child_pre_probe() method to provide this feature, and a corresponding child_post_remove() method. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Introduce per-child data for devicesSimon Glass2014-07-231-0/+26
| | | | | | | | | | | | | Some device types can have child devices and want to store information about them. For example a USB flash stick attached to a USB host controller would likely use this space. The controller can hold information about the USB state of each of its children. The data is stored attached to the child device in the 'parent_priv' member. It can be auto-allocated by dm when the child is probed. To do this, add a per_child_auto_alloc_size value to the parent driver. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Add functions to access a device's childrenSimon Glass2014-07-231-0/+93
| | | | | | | | | | | | | | | | | Devices can have childen that can be addressed by a simple index, the sequence number or a device tree offset. Add functions to access a child in each of these ways. The index is typically used as a fallback when the sequence number is not available. For example we may use a serial UART with sequence number 0 as the console, but if no UART has sequence number 0, then we can fall back to just using the first UART (index 0). The device tree offset function is useful for buses, where they want to locate one of their children. The device tree can be scanned to find the offset of each child, and that offset can then find the device. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Provide a function to scan child FDT nodesSimon Glass2014-07-231-15/+18
| | | | | | | | | | | | | | At present only root nodes in the device tree are scanned for devices. But some devices can have children. For example a SPI bus may have several children for each of its chip selects. Add a function which scans subnodes and binds devices for each one. This can be used for the root node scan also, so change it. A device can call this function in its bind() or probe() methods to bind its children. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Avoid accessing uclasses before they are readySimon Glass2014-07-231-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-231-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-232-0/+106
| | | | | | | | | | | | | | | | | | | | | | | | | 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-231-6/+22
| | | | | | Several functions will use this same pattern, so bring it into a function. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Support driver model prior to relocationSimon Glass2014-07-231-0/+25
| | | | | | | Initialise devices marked 'pre-reloc' and make them available prior to relocation. Note that this requires pre-reloc malloc() to be available. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Allow drivers to be marked 'before relocation'Simon Glass2014-07-233-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Driver model currently only operates after relocation is complete. In this state U-Boot typically has a small amount of memory available. In adding support for driver model prior to relocation we must try to use as little memory as possible. In addition, on some machines the memory has not be inited and/or the CPU is not running at full speed or the data cache is off. These can reduce execution performance, so the less initialisation that is done before relocation the better. An immediately-obvious improvement is to only initialise drivers which are actually going to be used before relocation. On many boards the only such driver is a serial UART, so this provides a very large potential benefit. Allow drivers to mark themselves as 'pre-reloc' which means that they will be initialised prior to relocation. This can be done either with a driver flag or with a 'dm,pre-reloc' device tree property. To support this, the various dm scanning function now take a 'pre_reloc_only' parameter which indicates that only drivers marked pre-reloc should be bound. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Provide a way to shut down driver modelSimon Glass2014-07-231-0/+8
| | | | | | | Add a new method which removes and unbinds all drivers. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marek Vasut <marex@denx.de>
* dm: Make sure that the root device is probedSimon Glass2014-07-231-0/+3
| | | | | | | | | The root device should be probed just like any other device. The effect of this is to mark the device as activated, so that it can be removed (along with its children) if required. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marek Vasut <marex@denx.de>
* dm: add missing includesJeroen Hofstee2014-07-182-0/+2
| | | | | | | | | | lists.c / root.c do not include their own header and they could potentially implement a different function. Therefore actually include the headers. cc: sjg@chromium.org Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Cast away the const-ness of the global_data pointerSimon Glass2014-06-202-4/+4
| | | | | | | 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: Add missing header files in lists and rootSimon Glass2014-06-202-0/+2
| | | | | | | These files don't compile in some architectures. Fix it by adding the missing headers. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Rename struct device_id to udevice_idSimon Glass2014-06-201-1/+1
| | | | | | | It is best to avoid having any occurence of 'struct device' in driver model, so rename to achieve this. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: rename device struct to udeviceHeiko Schocher2014-05-274-36/+37
| | | | | | | | | | | | 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-046-0/+934
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>
OpenPOWER on IntegriCloud