1. 05 8月, 2015 1 次提交
  2. 22 7月, 2015 11 次提交
    • H
      dm: Export device_remove_children / device_unbind_children · bb52b367
      Hans de Goede 提交于
      These functions are useful to remove all children from an usb bus before
      rescanning the bus. Give them a better name and export them.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NSimon Glass <sjg@chromium.org>
      bb52b367
    • S
      dm: Add platform data advice and admonishment · 97f3ee34
      Simon Glass 提交于
      We should guide people more strongly towards device tree to avoid the
      proliferation of platform data structures. Add documentation to the driver
      model README, and also the platform data header file.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      97f3ee34
    • S
      dm: Add a clock uclass · f26c8a8e
      Simon Glass 提交于
      Clocks are an important feature of platforms and have become increasing
      complex with time. Most modern SoCs have multiple PLLs and dozens of clock
      dividers which distribute clocks to on-chip peripherals.
      
      Some SoC implementations have a clock API which is private to that SoC family,
      e.g. Tegra and Exynos. This is useful but it would be better to have a
      common API that can be understood and used throughout U-Boot.
      
      Add a simple clock API as a starting point. It supports querying and setting
      the rate of a clock. Each clock is a device. To reduce memory and processing
      overhead the concept of peripheral clocks is provided. These do not need to
      be explicit devices - it is possible to write a driver that can adjust the
      I2C clock (for example) without an explicit I2C clock device. This can
      dramatically reduce the number of devices (and associated overhead) in a
      complex SoC.
      
      Clocks are referenced by a number, and it is expected that SoCs will define
      that numbering themselves via an enum.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      f26c8a8e
    • S
      dm: Add a system reset uclass · f9917454
      Simon Glass 提交于
      It is common for system reset to be available at multiple levels in modern
      hardware. For example, an SoC may provide a reset option, and a board may
      provide its own reset for reasons of security or thoroughness. It is useful
      to be able to model this hardware without hard-coding the behaviour in the
      SoC or board. Also there is a distinction sometimes between resetting just
      the CPU (leaving GPIO state alone) and resetting all the PMICs, just cutting
      power.
      
      To achieve this, add a simple system reset uclass. It allows multiple devices
      to provide reset functionality and provides a way to walk through them,
      requesting a particular reset type until is it provided.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      f9917454
    • S
      dm: Add support for RAM drivers · 6c51df68
      Simon Glass 提交于
      Add support for a driver which sets up DRAM and can return information about
      the amount of RAM available. This is a first step towards moving RAM init
      to driver model.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      6c51df68
    • S
      dm: mmc: Add an MMC uclass · e7ecf7cb
      Simon Glass 提交于
      Add basic support for MMC, providing a uclass which can set up an MMC
      device. This allows MMC drivers to move to using driver model.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      e7ecf7cb
    • S
      dm: Add support for LEDs · 5917112c
      Simon Glass 提交于
      Add a simple uclass for LEDs, so that these can be controlled by the device
      tree and activated when needed. LEDs are referred to by their label.
      
      This implementation requires a driver for each type of LED (e.g GPIO, I2C).
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      5917112c
    • S
      dm: Add support for generic system controllers (syscon) · 57251285
      Simon Glass 提交于
      Many SoCs have a number of system controllers which are dealt with as a
      group by a single driver. It is a pain to have to add lots of compatible
      strings and/or separate drivers for each. Instead we can identify the
      controllers by a number and request the address of the one we want.
      
      Add a simple implementation of this which can be used by SoC driver code.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      57251285
    • S
      dm: core: Correct device_get_child_by_of_offset() parameter · 132f9bfc
      Simon Glass 提交于
      This parameter is named 'seq' but should be named 'of_offset'.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      132f9bfc
    • S
      dm: core: Add a function to find any device from device tree · 2693047a
      Simon Glass 提交于
      In some rare cases it is useful to be able to locate a device given a device
      tree node offset. An example is when you have an alias that points to a node
      and you want to find the associated device. The device may be SPI, MMC or
      something else, but you don't need to know the uclass to find it.
      
      Add a function to do a global search for a device, given its device tree
      offset.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      2693047a
    • S
      dm: Move the tree/uclass dump code into its own file · 304fbef1
      Simon Glass 提交于
      In SPL it is sometimes useful to be able to obtain a dump of the current
      driver model state. Since commands are not available, provide a way to
      directly call the functions to output this information.
      
      Adjust the existing commands to use these functions.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      304fbef1
  3. 04 6月, 2015 1 次提交
  4. 21 5月, 2015 2 次提交
  5. 15 5月, 2015 2 次提交
    • P
      dm: regulator: add implementation of driver model regulator uclass · af41e8db
      Przemyslaw Marczak 提交于
      This commit introduces the implementation of dm regulator API.
      Device tree support allows for auto binding. And by the basic
      uclass operations, it allows to driving the devices in a common
      way. For detailed informations, please look into the header file.
      
      Core files:
      - drivers/power/regulator-uclass.c - provides regulator common functions api
      - include/power/regulator.h - define all structures required by the regulator
      
      Changes:
      - new uclass-id: UCLASS_REGULATOR
      - new config: CONFIG_DM_REGULATOR
      Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
      Acked-by: NSimon Glass <sjg@chromium.org>
      af41e8db
    • P
      dm: pmic: add implementation of driver model pmic uclass · 4d9057e8
      Przemyslaw Marczak 提交于
      This commit introduces the PMIC uclass implementation.
      It allows providing the basic I/O interface for PMIC devices.
      For the multi-function PMIC devices, this can be used as I/O
      parent device, for each IC's interface. Then, each PMIC particular
      function can be provided by the child device's operations, and the
      child devices will use its parent for read/write by the common API.
      
      Core files:
      - 'include/power/pmic.h'
      - 'drivers/power/pmic/pmic-uclass.c'
      
      The old pmic framework is still kept and is independent.
      
      For more detailed informations, please look into the header file.
      
      Changes:
      - new uclass-id: UCLASS_PMIC
      - new config: CONFIG_DM_PMIC
      Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
      Acked-by: NSimon Glass <sjg@chromium.org>
      4d9057e8
  6. 14 5月, 2015 2 次提交
  7. 06 5月, 2015 1 次提交
  8. 30 4月, 2015 2 次提交
  9. 23 4月, 2015 10 次提交
  10. 19 4月, 2015 8 次提交