15 Sep, 2017

1 commit

  • Rather than naming the phandle struct according to the number of cells it
    uses (e.g. struct phandle_2_cell) name it according to the number of
    arguments it has (e.g. struct phandle_1_arg). This is a more intuitive
    naming.

    Signed-off-by: Simon Glass
    Tested-by: Kever Yang

    Simon Glass
     

04 Sep, 2017

2 commits

  • Add some documentation for the live device tree support in U-Boot. This
    was missing from the initial series.

    Signed-off-by: Simon Glass
    Suggested-by: Lukasz Majewski
    Reviewed-by: Łukasz Majewski

    Simon Glass
     
  • The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
    code, with #ifdefs and different code paths. We should try to move over to
    this soon so we can drop the old code.

    Set a deadline of 9 months for this work, rounded up to the next release.

    Signed-off-by: Simon Glass
    Reviewed-by: Tom Rini

    Simon Glass
     

12 Jul, 2017

1 commit


23 Mar, 2017

1 commit

  • Certain boards come in different variations by way of utilizing daughter
    boards, for example. These boards might contain additional chips, which
    are added to the main board's busses, e.g. I2C.

    The device tree support for such boards would either, quite naturally,
    employ the overlay mechanism to add such chips to the tree, or would use
    one large default device tree, and delete the devices that are actually
    not present.

    Regardless of approach, even on the U-Boot level, a modification of the
    device tree is a prerequisite to have such modular families of boards
    supported properly.

    Therefore, we add an option to make the U-Boot device tree (the actual
    copy later used by the driver model) writeable, and add a callback
    method that allows boards to modify the device tree at an early stage,
    at which, hopefully, also the application of device tree overlays will
    be possible.

    Signed-off-by: Mario Six
    Reviewed-by: Simon Glass
    Signed-off-by: Stefan Roese

    mario.six@gdsys.cc
     

17 Mar, 2017

1 commit

  • Right now the u-boot,dm-pre-reloc flag will make each marked node
    always appear in both spl and tpl. But systems needing an additional
    tpl might have special constraints for each, like the spl needing to
    be very tiny.

    So introduce two additional flags to mark nodes for only spl or tpl
    environments and introduce a function dm_fdt_pre_reloc to automate
    the necessary checks in code instances checking for pre-relocation
    flags.

    The behaviour of the original flag stays untouched and still marks
    a node for both spl and tpl.

    Signed-off-by: Heiko Stuebner
    Reviewed-by: Simon Glass
    Tested-by: Kever Yang

    Heiko Stübner
     

08 Feb, 2017

1 commit

  • At present devices use a simple integer offset to record the device tree
    node associated with the device. In preparation for supporting a live
    device tree, which uses a node pointer instead, refactor existing code to
    access this field through an inline function.

    Signed-off-by: Simon Glass

    Simon Glass
     

05 Dec, 2016

3 commits


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