1. 10 Nov, 2015 1 commit
    • Tom Rini's avatar
      Various Makefiles: Add SPDX-License-Identifier tags · da58dec8
      Tom Rini authored
      After consulting with some of the SPDX team, the conclusion is that
      Makefiles are worth adding SPDX-License-Identifier tags too, and most of
      ours have one.  This adds tags to ones that lack them and converts a few
      that had full (or in one case, very partial) license blobs into the
      equivalent tag.
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
  2. 02 Nov, 2015 1 commit
    • Przemyslaw Marczak's avatar
      dm: adc: add simple ADC uclass implementation · 5decbf53
      Przemyslaw Marczak authored
      This commit adds:
      - new uclass id: UCLASS_ADC
      - new uclass driver: drivers/adc/adc-uclass.c
      The new uclass's API allows for ADC operation on:
      * single-channel with channel selection by a number
      * multti-channel with channel selection by bit mask
      ADC uclass's functions:
      * single-channel:
        - adc_start_channel()        - start channel conversion
        - adc_channel_data()         - get conversion data
        - adc_channel_single_shot()  - start/get conversion data
      * multi-channel:
        - adc_start_channels()       - start selected channels conversion
        - adc_channels_data()        - get conversion data
        - adc_channels_single_shot() - start/get conversion data for channels
                                       selected by bit mask
      * general:
        - adc_stop()      - stop the conversion
        - adc_vdd_value() - positive reference Voltage value with polarity [uV]
        - adc_vss_value() - negative reference Voltage value with polarity [uV]
        - adc_data_mask() - conversion data bit mask
      The device tree can provide below constraints/properties:
      - vdd-polarity-negative: if true: Vdd = vdd-microvolts * (-1)
      - vss-polarity-negative: if true: Vss = vss-microvolts * (-1)
      - vdd-supply:            phandle to Vdd regulator's node
      - vss-supply:            phandle to Vss regulator's node
      And optional, checked only if the above corresponding, doesn't exist:
        - vdd-microvolts:      positive reference Voltage [uV]
        - vss-microvolts:      negative reference Voltage [uV]
      Signed-off-by: default avatarPrzemyslaw Marczak <p.marczak@samsung.com>
      Cc: Simon Glass <sjg@chromium.org>
      Signed-off-by: default avatarMinkyu Kang <mk7.kang@samsung.com>
  3. 22 Oct, 2015 2 commits
    • Thomas Chou's avatar
      dm: implement a Timer uclass · c8a7ba9e
      Thomas Chou authored
      Implement a Timer uclass to work with lib/time.c.
      Signed-off-by: default avatarThomas Chou <thomas@wytron.com.tw>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
    • Nishanth Menon's avatar
      drivers: Introduce a simplified remoteproc framework · ddf56bc7
      Nishanth Menon authored
      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: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
  4. 31 Aug, 2015 1 commit
    • Masahiro Yamada's avatar
      pinctrl: add pin control uclass support · d90a5a30
      Masahiro Yamada authored
      This creates a new framework for handling of pin control devices,
      i.e. devices that control different aspects of package pins.
      This uclass handles pinmuxing and pin configuration; pinmuxing
      controls switching among silicon blocks that share certain physical
      pins, pin configuration handles electronic properties such as pin-
      biasing, load capacitance etc.
      This framework can support the same device tree bindings, but if you
      do not need full interface support, you can disable some features to
      reduce memory foot print.  Typically around 1.5KB is necessary to
      include full-featured uclass support on ARM board (CONFIG_PINCTRL +
      for example.
      We are often limited on code size for SPL.  Besides, we still have
      many boards that do not support device tree configuration.  The full
      pinctrl, which requires OF_CONTROL, does not make sense for those
      boards.  So, this framework also has a Do-It-Yourself (let's say
      simple pinctrl) interface.  With CONFIG_PINCTRL_FULL disabled, the
      uclass itself provides no systematic mechanism for identifying the
      peripheral device, applying pinctrl settings, etc.  They must be
      done in each low-level driver.  In return, you can save much memory
      footprint and it might be useful especially for SPL.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
  5. 18 Aug, 2015 8 commits
  6. 21 Jul, 2015 3 commits
    • Simon Glass's avatar
      dm: Add a clock uclass · f26c8a8e
      Simon Glass authored
      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: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: Add support for RAM drivers · 6c51df68
      Simon Glass authored
      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: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: Add support for LEDs · 5917112c
      Simon Glass authored
      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: default avatarSimon Glass <sjg@chromium.org>
  7. 30 Apr, 2015 1 commit
  8. 21 Nov, 2014 1 commit
  9. 19 Nov, 2014 1 commit
  10. 23 Oct, 2014 1 commit
  11. 24 Sep, 2014 1 commit
    • Masahiro Yamada's avatar
      kbuild: refactor some makefiles · f494e0a1
      Masahiro Yamada authored
      [1] Move driver/core/, driver/input/ and drivers/input/ entries
          from the top Makefile to drivers/Makefile
      [2] Remove the conditional by CONFIG_DM in drivers/core/Makefile
          because the whole drivers/core directory is already selected
          by CONFIG_DM in the upper level
      [3] Likewise for CONFIG_DM_DEMO in drivers/demo/Makefile
      [4] Simplify common/Makefile - both CONFIG_DDR_SPD and
          CONFIG_SPD_EEPROM are boolean macros so they can directly
          select objects
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
  12. 23 Jul, 2014 1 commit
  13. 19 Jun, 2014 1 commit
  14. 17 Nov, 2013 2 commits
  15. 31 Oct, 2013 1 commit
  16. 28 Nov, 2007 2 commits
  17. 25 Nov, 2007 9 commits
  18. 24 Nov, 2007 2 commits
  19. 20 Nov, 2007 1 commit