summaryrefslogtreecommitdiff
path: root/doc/driver-model
Commit message (Collapse)AuthorAgeLines
* dm: core: Replace of_offset with accessorSimon Glass2017-02-08-3/+3
| | | | | | | | | At present devices use a simple integer offset to record the device tree node associated with the device. In preparation for supporting a live device tree, which uses a node pointer instead, refactor existing code to access this field through an inline function. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Add timeline and guide for porting I2C driversSimon Glass2016-12-05-0/+56
| | | | | | | | | | | Add a README with a brief guide to porting i2c drivers over to use driver model. Add a timeline also. All I2C drivers should be converted by the end of June 2017. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
* serial: Drop the s3c24x0 serial driverSimon Glass2016-12-04-1/+0
| | | | | | | | This is not used by any boards. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: David Müller <d.mueller@elsoft.ch> Reviewed-by: Jagan Teki <jagan@openedev.com>
* serial: Update docs to indicate mcfuart supports DM_SERIALSimon Glass2016-12-04-1/+0
| | | | | | This driver was converted so we should remove it from the list. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Update the of-platdata README for the new featuresSimon Glass2016-07-14-34/+76
| | | | | | | | Revise the content based on the v2 additions. This is kept as a separate patch to avoid confusing those who have already reviewed the v1 series. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Tom Rini <trini@konsulko.com>
* dm: Add a README for of-platdataSimon Glass2016-07-14-0/+268
| | | | | | Add documentation on how this works, including the benefits and drawbacks. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: allow setting driver_data before/during bindStephen Warren2016-05-26-9/+14
| | | | | | | | | | | This will allow a driver's bind function to use the driver data. One example is the Tegra186 GPIO driver, which instantiates child devices for each of its GPIO ports, yet supports two different HW instances each with a different set of ports, and identified by the udevice_id .data field. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
* doc: driver-model: Update dm tests run using test.pyJagan Teki2016-04-14-101/+128
| | | | | | | | | | Since all the tests are implemented in pytest infrastructure, So update the dm tests with the same instead of ./test/dm/test-dm.sh Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Jagan Teki <jteki@openedev.com>
* dm: Remove ARM dcc from the listMichal Simek2016-02-24-1/+0
| | | | | | | Remove ARM Debug communication channel driver from the list of not converted drivers to DM. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* dm: Update on current serial driver statusSimon Glass2016-02-08-10/+4
| | | | | | Update the README to reflect the current status. Signed-off-by: Simon Glass <sjg@chromium.org>
* serial: uartlite: Move driver to DMMichal Simek2016-01-27-1/+0
| | | | | | | Enable SPL DM too. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Thomas Chou <thomas@wytron.com.tw>
* serial: lpuart: Add driver model serial supportBin Meng2016-01-20-1/+0
| | | | | | | | This adds driver model support to lpuart serial driver. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Tested-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
* serial-howto: remove altera_jtag_uart and altera_uart from the listThomas Chou2015-12-19-2/+0
| | | | | | | | Since both altera_jtag_uart and altera_uart are converted to driver model, remove them from the list of drivers remaining to convert. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Reviewed-by: Chin Liang See <clsee@altera.com>
* stm32: Convert serial driver to DMKamil Lulko2015-12-12-1/+0
| | | | | | Signed-off-by: Kamil Lulko <kamil.lulko@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* dm: Add timeline and guide for porting serial driversSimon Glass2015-11-20-0/+58
| | | | | | | | | | Add a README with a brief guide to porting serial drivers over to use driver model. Add a timeline also. All serial drivers should be converted by the end of January 2016. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Rename dev_get_parentdata() to dev_get_parent_priv()Simon Glass2015-10-23-2/+2
| | | | | | | | 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>
* drivers: Introduce a simplified remoteproc frameworkNishanth Menon2015-10-22-0/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Document binding of pci device driversBin Meng2015-08-26-3/+68
| | | | | | | Document how pci devices are bound to device drivers. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* doc: dm: Update pci-info.txt for pci supportBin Meng2015-08-05-3/+3
| | | | | | | Correct two typos and mention how pci bus will be probed. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Add platform data advice and admonishmentSimon Glass2015-07-21-2/+15
| | | | | | | | 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>
* doc: driver-model: pmic-framework.txt - cleanupPrzemyslaw Marczak2015-05-14-11/+9
| | | | | | | | | This commit cleanups the PMIC framework documentation. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on sandbox: Tested-by: Simon Glass <sjg@chromium.org>
* doc: driver-model: pmic and regulator uclass documentationPrzemyslaw Marczak2015-05-14-0/+142
| | | | | | | | Since this framework is still under the construction, the main documentation is kept in the header files. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Update the README to reflect the current test outputSimon Glass2015-04-22-8/+50
| | | | | | | | There are a lot more tests now. To avoid confusion add the updated test output to the driver model README. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
* dm: usb: Add a README for driver modelSimon Glass2015-04-18-0/+415
| | | | | | | Add some documentation describing how USB is implemented with USB. This might make things easier for people to understand. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: pci: Add a uclass for PCISimon Glass2015-04-16-0/+70
| | | | | | | | | | | Add a uclass for PCI controllers and a generic one for PCI devices. Adjust the 'pci' command and the existing PCI support to work with this new uclass. Keep most of the compatibility code in a separate file so that it can be removed one day. TODO: Add more header file comments to the new parts of pci.h Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Expand and complete Kconfig in drivers/Simon Glass2015-02-12-2/+2
| | | | | | | | Expand the help messages for each driver. Add missing Kconfig for I2C, SPI flash and thermal. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* dm: Update documentation for new bus featuresSimon Glass2015-01-29-13/+63
| | | | | | Now that we have new bus features, update README.txt and the SPI docs to explain these. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Add a flag to control sequence numberingSimon Glass2015-01-29-38/+13
| | | | | | | | | | | | | | | | 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: Set device tree node for root deviceSimon Glass2015-01-29-0/+4
| | | | | | | The root device corresponds to the root device tree node, so set this up. Also add a few notes to the documentation. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: README: recommend u-boot.dtb to try driver-model on sandboxMasahiro Yamada2015-01-05-2/+2
| | | | | | | | | To enjoy driver-model on sandbox, using device tree is recommended. While we are here, change sandbox_config to sandbox_defconfig too. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
* dm: Update documentation to include CONFIG_DM... optionsSimon Glass2014-11-21-10/+34
| | | | | | | Add documentation for the various driver model options that are now available. Signed-off-by: Simon Glass <sjg@chromium.org>
* test: dm: Add additional GPIO testsSimon Glass2014-10-23-1/+4
| | | | | | Add tests for gpio_requestf() and for memory leaks. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: gpio: Add gpio_requestf() helper for printf() stringsSimon Glass2014-10-23-1/+2
| | | | | | | Add a helper which permits a printf()-style format string for the requester string. Signed-off-by: Simon Glass <sjg@chromium.org>
* test: dm: Update GPIO tests for new gpio_request() methodSimon Glass2014-10-23-2/+23
| | | | | | | Now that gpio_request() is handled by the uclass, updates the tests accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: spi: Add documentation on how to convert over SPI driversSimon Glass2014-10-22-0/+594
| | | | | | | | This README is intended to help maintainers move their SPI drivers over to driver model. It works through the required steps with an example. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
* dm: core: Add a clarifying comment on struct udevice's seq memberSimon Glass2014-10-22-1/+3
| | | | | | | The sequence number is unique within the uclass, so state this clearly. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
* dm: core: Add functions for iterating through device childrenSimon Glass2014-10-22-1/+2
| | | | | | | | Buses need to iterate through their children in some situations. Add a few functions to make this easy. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
* dm: Add child_pre_probe() and child_post_remove() methodsSimon Glass2014-07-23-1/+67
| | | | | | | | | | | 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-23-8/+17
| | | | | | | | | | | | | 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-23-1/+2
| | | | | | | | | | | | | | | | | 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-23-1/+5
| | | | | | | | | | | | | | 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-23-1/+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-1/+2
| | | | | | | | 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-6/+95
| | | | | | | | | | | | | | | | | | | | | | | | | 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-12/+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: Expand and improve the device lifecycle docsSimon Glass2014-06-20-7/+213
| | | | | | | | | The lifecycle of a device is an important part of driver model. Add to the existing documentation and clarify it. Reported-by: Jon Loeliger <jdl@jdl.com> 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>
* docs: driver-model: Fix spellingChris Packham2014-06-11-5/+5
| | | | Signed-off-by: Chris Packham <judge.packham@gmail.com>
* dm: rename device struct to udeviceHeiko Schocher2014-05-27-4/+4
| | | | | | | | | | | | 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: Remove old driver model documentationSimon Glass2014-03-04-3662/+0
| | | | | | | | | | | This documentation pertains to the planned implementation of driver model in U-Boot for each subsystem, but it has not been superseded. It is probably better to have this documentation in the source code for each subsystem where possible, so that docbook will pick it up. Where this does not make sense, new documentation can be placed in some suitable file in doc/driver-model. Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-11-02 12:59:58 +0000