summaryrefslogtreecommitdiff
path: root/include/dm/uclass.h
diff options
context:
space:
mode:
authorSimon Glass <sjg@chromium.org>2014-07-23 06:55:12 -0600
committerSimon Glass <sjg@chromium.org>2014-07-23 14:07:25 +0100
commit5a66a8ff86d923367ca9a1f6168e976fbde27391 (patch)
tree429ae5e3e439c59972c845673ee3d48ef23d416e /include/dm/uclass.h
parent4e8bc211703d3c93689367745e8c07dc22c68dfc (diff)
downloadu-boot-imx-5a66a8ff86d923367ca9a1f6168e976fbde27391.zip
u-boot-imx-5a66a8ff86d923367ca9a1f6168e976fbde27391.tar.gz
u-boot-imx-5a66a8ff86d923367ca9a1f6168e976fbde27391.tar.bz2
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>
Diffstat (limited to 'include/dm/uclass.h')
-rw-r--r--include/dm/uclass.h31
1 files changed, 31 insertions, 0 deletions
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index afd9923..48ae242 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -106,6 +106,22 @@ int uclass_get(enum uclass_id key, struct uclass **ucp);
int uclass_get_device(enum uclass_id id, int index, struct udevice **devp);
/**
+ * uclass_get_device_by_seq() - Get a uclass device based on an ID and sequence
+ *
+ * If an active device has this sequence it will be returned. If there is no
+ * such device then this will check for a device that is requesting this
+ * sequence.
+ *
+ * The device is probed to activate it ready for use.
+ *
+ * @id: ID to look up
+ * @seq: Sequence number to find (0=first)
+ * @devp: Returns pointer to device (there is only one for each seq)
+ * @return 0 if OK, -ve on error
+ */
+int uclass_get_device_by_seq(enum uclass_id id, int seq, struct udevice **devp);
+
+/**
* uclass_first_device() - Get the first device in a uclass
*
* @id: Uclass ID to look up
@@ -124,6 +140,21 @@ int uclass_first_device(enum uclass_id id, struct udevice **devp);
int uclass_next_device(struct udevice **devp);
/**
+ * uclass_resolve_seq() - Resolve a device's sequence number
+ *
+ * On entry dev->seq is -1, and dev->req_seq may be -1 (to allocate a
+ * sequence number automatically, or >= 0 to select a particular number.
+ * If the requested sequence number is in use, then this device will
+ * be allocated another one.
+ *
+ * Note that the device's seq value is not changed by this function.
+ *
+ * @dev: Device for which to allocate sequence number
+ * @return sequence number allocated, or -ve on error
+ */
+int uclass_resolve_seq(struct udevice *dev);
+
+/**
* uclass_foreach_dev() - Helper function to iteration through devices
*
* This creates a for() loop which works through the available devices in