Certain boards come in different variations by way of utilizing daughter
boards, for example. These boards might contain additional chips, which
are added to the main board's busses, e.g. I2C.
The device tree support for such boards would either, quite naturally,
employ the overlay mechanism to add such chips to the tree, or would use
one large default device tree, and delete the devices that are actually
not present.
Regardless of approach, even on the U-Boot level, a modification of the
device tree is a prerequisite to have such modular families of boards
supported properly.
Therefore, we add an option to make the U-Boot device tree (the actual
copy later used by the driver model) writeable, and add a callback
method that allows boards to modify the device tree at an early stage,
at which, hopefully, also the application of device tree overlays will
be possible.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Right now the u-boot,dm-pre-reloc flag will make each marked node
always appear in both spl and tpl. But systems needing an additional
tpl might have special constraints for each, like the spl needing to
be very tiny.
So introduce two additional flags to mark nodes for only spl or tpl
environments and introduce a function dm_fdt_pre_reloc to automate
the necessary checks in code instances checking for pre-relocation
flags.
The behaviour of the original flag stays untouched and still marks
a node for both spl and tpl.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
