Commit graph

10 commits

Author SHA1 Message Date
Simon Glass
83c7e434c9 dm: core: Allow uclass to set up a device's child before it is probed
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>
2015-01-29 17:09:56 -07:00
Simon Glass
081f2fcbd9 dm: core: Allow the uclass to set up a device's child after binding
For buses, after a child is bound, allow the uclass to perform some
processing. This can be used to figure out the address of the child (e.g.
the chip select for SPI slaves) so that it is ready to be probed.

This avoids bus drivers having to repeat the same process, which really
should be done by the uclass, since it is common.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-01-29 17:09:56 -07:00
Masahiro Yamada
29a1bedbf3 dm: do not check the existence of uclass operation
The function uclass_add() checks uc_drv->ops as follows:

        if (uc_drv->ops) {
                dm_warn("No ops for uclass id %d\n", id);
                return -EINVAL;
        }

It seems odd because it warns "No ops" when uc_drv->ops has
non-NULL pointer.  (Looks opposite.)

Anyway, most of UCLASS_DRIVER entries have no .ops member.
This check makes no sense.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
2014-10-22 10:32:16 -06:00
Simon Glass
c910e2e2da dm: Avoid accessing uclasses before they are ready
Don't allow access to uclasses before they have been initialised.

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
9ca296a1b0 dm: Move uclass error checking/probing into a function
Several functions will use this same pattern, so bring it into a function.

Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 14:07:25 +01: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
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
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