Commit graph

169 commits

Author SHA1 Message Date
Simon Glass
57d92753d4 dm: Add a uclass for serial devices
Serial devices support simple byte input/output and a few operations to find
out whether data is available. Add a basic uclass for serial devices to be
used by drivers that are converted to driver model.

Signed-off-by: Simon Glass <sjg@chromium.org>
2014-09-10 13:00:00 -06:00
Simon Glass
1f359e3611 dm: Adjust lists_bind_fdt() to return the bound device
Allow the caller to find out the device that was bound in response to this
call.

Signed-off-by: Simon Glass <sjg@chromium.org>
2014-09-10 12:59:59 -06:00
Simon Glass
bb58503d80 dm: Add dm_scan_other() to locate board-specific devices
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>
2014-07-23 14:08:37 +01:00
Simon Glass
a327dee0f4 dm: Add child_pre_probe() and child_post_remove() methods
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>
2014-07-23 14:08:37 +01:00
Simon Glass
e59f458de6 dm: Introduce per-child data for devices
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>
2014-07-23 14:08:37 +01:00
Simon Glass
997c87bb0b dm: Add functions to access a device's children
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>
2014-07-23 14:08:37 +01:00
Simon Glass
1ca7e2062b dm: Provide a function to scan child FDT nodes
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>
2014-07-23 14:08:36 +01:00
Simon Glass
0040b94429 dm: Tidy up some header file comments
Fix up the style of a few comments and add/clarify a few others.

Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 14:07:26 +01:00
Simon Glass
f4cdead24a dm: Allow a device to be found by its FDT offset
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>
2014-07-23 14:07:25 +01:00
Simon Glass
5a66a8ff86 dm: Introduce device sequence numbering
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>
2014-07-23 14:07:25 +01:00
Simon Glass
ab7cd62790 dm: Support driver model prior to relocation
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>
2014-07-23 14:07:24 +01:00
Simon Glass
00606d7e39 dm: Allow drivers to be marked 'before relocation'
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>
2014-07-23 14:07:24 +01:00
Simon Glass
9adbd7a116 dm: Provide a way to shut down driver model
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>
2014-07-23 14:07:24 +01:00
Simon Glass
f2bc6fc331 dm: Tidy up four minor code nits
There is a spelling mistake and two functions are missing comments
altogether. Also the flags declaration is correct, but doesn't follow
style. Finally, the uclass_get_device() function has some errors in
its documentation.

Fix these problems.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
2014-06-20 11:56:50 -06:00
Simon Glass
89876a55a6 dm: Cast away the const-ness of the global_data pointer
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>
2014-06-20 11:55:49 -06:00
Simon Glass
ae7f451308 dm: Rename struct device_id to udevice_id
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>
2014-06-20 11:55:18 -06:00
Heiko Schocher
54c5d08a09 dm: rename device struct to udevice
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>
2014-05-27 10:21:32 -04:00
Simon Glass
2e7d35d2a6 dm: Add basic tests
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>
2014-03-04 12:15:29 -05:00
Simon Glass
6494d708bf dm: Add base driver model support
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>
2014-03-04 12:15:29 -05:00