Skip to content
Snippets Groups Projects
  1. Aug 02, 2017
  2. May 10, 2017
  3. Mar 17, 2017
  4. Feb 17, 2017
  5. Jan 28, 2017
    • maxims@google.com's avatar
      aspeed: Add basic ast2500-specific drivers and configuration · 14e4b149
      maxims@google.com authored
      
      Clock Driver
      
      This driver is ast2500-specific and is not compatible with earlier
      versions of this chip. The differences are not that big, but they are
      in somewhat random places, so making it compatible with ast2400 is not
      worth the effort at the moment.
      
      SDRAM MC driver
      
      The driver is very ast2500-specific and is completely incompatible
      with previous versions of the chip.
      
      The memory controller is very poorly documented by Aspeed in the
      datasheet, with any mention of the whole range of registers missing. The
      initialization procedure has been basically taken from Aspeed SDK, where
      it is implemented in assembly. Here it is rewritten in C, with very limited
      understanding of what exactly it is doing.
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      14e4b149
  6. Jan 10, 2017
  7. Sep 21, 2016
  8. Aug 15, 2016
  9. Aug 05, 2016
  10. Jun 19, 2016
    • Stephen Warren's avatar
      clk: convert API to match reset/mailbox style · 135aa950
      Stephen Warren authored
      
      The following changes are made to the clock API:
      * The concept of "clocks" and "peripheral clocks" are unified; each clock
        provider now implements a single set of clocks. This provides a simpler
        conceptual interface to clients, and better aligns with device tree
        clock bindings.
      * Clocks are now identified with a single "struct clk", rather than
        requiring clients to store the clock provider device and clock identity
        values separately. For simple clock consumers, this isolates clients
        from internal details of the clock API.
      * clk.h is split so it only contains the client/consumer API, whereas
        clk-uclass.h contains the provider API. This aligns with the recently
        added reset and mailbox APIs.
      * clk_ops .of_xlate(), .request(), and .free() are added so providers
        can customize these operations if needed. This also aligns with the
        recently added reset and mailbox APIs.
      * clk_disable() is added.
      * All users of the current clock APIs are updated.
      * Sandbox clock tests are updated to exercise clock lookup via DT, and
        clock enable/disable.
      * rkclk_get_clk() is removed and replaced with standard APIs.
      
      Buildman shows no clock-related errors for any board for which buildman
      can download a toolchain.
      
      test/py passes for sandbox (which invokes the dm clk test amongst
      others).
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      135aa950
  11. May 25, 2016
  12. Feb 14, 2016
  13. Feb 01, 2016
  14. Jan 22, 2016
  15. Dec 01, 2015
  16. Sep 03, 2015
  17. Jul 21, 2015
    • Simon Glass's avatar
      dm: test: Add tests for the clk uclass · 6a1c7cef
      Simon Glass authored
      
      Add tests of each API call using a sandbox clock device.
      
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      6a1c7cef
    • 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>
      f26c8a8e
  18. Apr 30, 2015
Loading