15 Jul, 2016

2 commits


27 May, 2016

1 commit

  • 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
    Acked-by: Simon Glass

    Stephen Warren
     

15 Apr, 2016

1 commit


25 Feb, 2016

1 commit


08 Feb, 2016

1 commit


27 Jan, 2016

1 commit


21 Jan, 2016

1 commit


19 Dec, 2015

1 commit


13 Dec, 2015

1 commit


21 Nov, 2015

1 commit


23 Oct, 2015

2 commits

  • The current name is inconsistent with other driver model data access
    functions. Rename it and fix up all users.

    Signed-off-by: Simon Glass
    Reviewed-by: Joe Hershberger

    Simon Glass
     
  • 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
    Signed-off-by: Nishanth Menon
    Acked-by: Simon Glass

    Nishanth Menon
     

26 Aug, 2015

1 commit


05 Aug, 2015

1 commit


22 Jul, 2015

1 commit


15 May, 2015

2 commits


23 Apr, 2015

1 commit


19 Apr, 2015

1 commit


17 Apr, 2015

1 commit

  • 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

    Simon Glass
     

13 Feb, 2015

1 commit


30 Jan, 2015

3 commits

  • Now that we have new bus features, update README.txt and the SPI docs to
    explain these.
    Signed-off-by: Simon Glass

    Simon Glass
     
  • 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
    Reviewed-by: Masahiro Yamada

    Simon Glass
     
  • 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

    Simon Glass
     

06 Jan, 2015

1 commit


21 Nov, 2014

1 commit


24 Oct, 2014

3 commits


23 Oct, 2014

3 commits


23 Jul, 2014

7 commits

  • 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

    Simon Glass
     
  • 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

    Simon Glass
     
  • 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

    Simon Glass
     
  • 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

    Simon Glass
     
  • Don't allow access to uclasses before they have been initialised.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • 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

    Simon Glass
     
  • 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

    Simon Glass