summaryrefslogtreecommitdiff
path: root/test/dm/test-fdt.c
Commit message (Collapse)AuthorAgeLines
* test: Generalize the unit test frameworkJoe Hershberger2015-05-21-8/+8
| | | | | | | | | 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: core: Allow uclass to set up a device's child before it is probedSimon Glass2015-01-29-0/+7
| | | | | | | | | 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: Add a flag to control sequence numberingSimon Glass2015-01-29-4/+5
| | | | | | | | | | | | | | | | At present we try to use the 'reg' property and device tree aliases to give devices a sequence number. The 'reg' property is often actually a memory address, so the sequence numbers thus-obtained are not useful. It would be better if the devices were just sequentially numbered in that case. In fact neither I2C nor SPI use this feature, so drop it. Some devices need us to look up an alias to number them within the uclass. Add a flag to control this, so it is not done unless it is needed. Adjust the tests to test this new behaviour. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* dm: core: Allocate platform data when binding a deviceSimon Glass2015-01-29-2/+2
| | | | | | | | | | | | When using allocated platform data, allocate it when we bind the device. This makes it possible to fill in this information before the device is probed. This fits with the platform data model (when not using device tree), since platform data exists at bind-time. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* dm: Provide a function to scan child FDT nodesSimon Glass2014-07-23-25/+38
| | | | | | | | | | | | | | 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: Allow a device to be found by its FDT offsetSimon Glass2014-07-23-0/+30
| | | | | | | | 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-1/+53
| | | | | | | | | | | | | | | | | | | | | | | | | 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: Allow drivers to be marked 'before relocation'Simon Glass2014-07-23-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Use an explicit expect value in core testsSimon Glass2014-07-23-5/+8
| | | | | | | Rather than reusing the 'reg' property, use an explicit property for the expected ping value used in testing. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Rename struct device_id to udevice_idSimon Glass2014-06-20-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-27-5/+5
| | | | | | | | | | | | 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 basic testsSimon Glass2014-03-04-0/+144
Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>