Lines Matching refs:device
240 This function looks up a device for the demo uclass. Given a device
241 number we can find the device because all devices have registered with
244 The device is automatically activated ready for use by uclass_get_device().
246 Now that we have the device we can do things like:
252 this particular device may use one or other of them.
315 The methods a device can provide are documented in the device.h header.
318 bind - make the driver model aware of a device (bind it to its driver)
319 unbind - make the driver model forget the device
320 ofdata_to_platdata - convert device tree data to platdata - see later
321 probe - make a device ready for use
322 remove - remove a device so it cannot be used until probed again
324 The sequence to get a device to work is bind, ofdata_to_platdata (if using
325 device tree) and probe.
335 *** Unless you have a good reason not to use device tree (the main one
337 *** the cut-down device tree and libfdt libraries) you should stay away
341 It provides the board-specific information to start up a device.
343 Why is this information not just stored in the device driver itself? The
344 idea is that the device driver is generic, and can in principle operate on
345 any board that has that type of device. For example, with modern
361 a device, but needs to know where it is, any variant/option information and
370 - the I2C speed to use for an I2C device
371 - the number of GPIOs available in a GPIO device
404 While platdata is useful, a more flexible way of providing device data is
405 by using device tree. In U-Boot you should use this where possible. Avoid
409 With device tree we replace the above code with the following device tree
419 the board file, we put these in the device tree. This approach allows a lot
421 (e,g. with the same SoC) just by using different device trees. An added
422 benefit is that the Linux device tree can be used, thus further simplifying
434 the device tree node for this device and place it in dev->platdata. Thus
435 when the probe method is called later (to set up the device ready for use)
448 The driver model tree is intended to mirror that of the device tree. The
449 root driver is at device tree offset 0 (the root node, '/'), and its
471 line for I2C and SPI buses, and the device names for serial ports (serial0,
474 device in its uclass, so no two devices within a particular uclass can have
484 Each device can request a sequence number. If none is required then the
485 device will be automatically allocated the next available sequence number.
487 To specify the sequence number in the device tree an alias is typically
496 which requests serial device 2 will obtain this device.
511 Device sequence numbers are resolved when a device is probed. Before then
521 A common use of driver model is to implement a bus, a device which provides
549 The bus device wants to store this address and some other information such
550 as the bus speed for each device.
552 To achieve this, the bus device can use dev->parent_platdata in each of its
555 the bus device or uclass can allocate the space itself before the child
556 device is probed.
563 the per-child platform data from the device tree and set it up for the child.
571 that it is connected to a bus. The same child device may even be used on two
572 different bus types. As an example. the 'flash' device shown above may also
584 bus methods. In the third example the device is not on a bus, and therefore
586 device defines child methods. These would be used for *its* children, and
588 that the flash device is connetced to. The act of attaching a device to a
589 parent device which is a bus, causes the device to start behaving like a
590 bus device, regardless of its own views on the matter.
592 The uclass for the device can also contain data private to that uclass.
593 But note that each device on the bus may be a memeber of a different
602 Here are the stages that a device goes through in driver model. Note that all
604 a device then it will not be called. A simple device may have very few
616 - Scan through the device tree definitions. U-Boot looks at top-level
617 nodes in the the device tree. It looks at the compatible string in each node
622 For each device that is discovered, U-Boot then calls device_bind() to create a
623 new device, initializes various core fields of the device object such as name,
624 uclass & driver, initializes any optional fields of the device object that are
630 activated (except for the root device). Each bound device that was created
632 in that declaration. For a bound device created from the device tree,
633 platdata will be NULL, but of_offset will be the offset of the device tree
634 node that caused the device to be created. The uclass is set correctly for
635 the device.
637 The device's bind() method is permitted to perform simple actions, but
638 should not scan the device tree node, not initialise hardware, nor set up
649 When a device needs to be used, U-Boot activates it, by following these
652 a. If priv_auto_alloc_size is non-zero, then the device-private space
653 is allocated for the device and zeroed. It will be accessible as
656 and known before the device is probed).
659 is allocated. This is only useful for device tree operation, since
661 U_BOOT_DEVICE() declaration. The space is allocated for the device and
664 c. If the device's uclass specifies a non-zero per_device_auto_alloc_size,
666 stored in the device, but it is uclass data. owned by the uclass driver.
667 It is possible for the device to access it.
669 d. If the device's immediate parent specifies a per_child_auto_alloc_size
671 device to keep track of things related to the child. For example a USB
676 e. All parent devices are probed. It is not possible to activate a device
677 unless its predecessors (all the way up to the root device) are activated.
681 f. The device's sequence number is assigned, either the requested one
686 called to convert the device tree data into platform data. This should
689 After this point, the device works the same way whether it was bound
690 using a device tree node or U_BOOT_DEVICE() structure. In either case,
696 to do all the device tree decoding in ofdata_to_platdata() rather than
701 h. The device's probe() method is called. This should do anything that
702 is required by the device to get it going. This could include checking
710 about this device)
716 i. The device is marked 'activated'
719 cause the uclass to do some housekeeping to record the device as
724 The device is now activated and can be used. From now until it is removed
725 all of the above structures are accessible. The device appears in the
726 uclass's list of devices (so if the device is in UCLASS_GPIO it will appear
727 as a device in the GPIO uclass). This is the 'running' state of the device.
731 When the device is no-longer required, you can call device_remove() to
735 cause the uclass to do some housekeeping to record the device as
738 b. All the device's children are removed. It is not permitted to have
739 an active child device with a non-active parent. This means that
742 c. The device's remove() method is called. At this stage nothing has been
745 intended that the device be completely inactive at this point, For U-Boot
749 d. The device memory is freed (platform data, private data, uclass data,
754 a device instantiated using the device tree data, the platform data will
765 e. The device sequence number is set to -1, meaning that it no longer
766 has an allocated sequence. If the device is later reactivated and that
769 by this device will no longer exist (think of SPI bus 2 being removed
772 f. The device is marked inactive. Note that it is still bound, so the
773 device structure itself is not freed at this point. Should the device be
778 The device is unbound. This is the step that actually destroys the device.
780 the device does not exist and its memory has be deallocated.
811 - Built in device tree support, to avoid the need for platdata
824 drivers marked with DM_FLAG_PRE_RELOC or the device tree
835 device pointers, but this is not currently implemented (the root device