1. 19 Jul, 2016 1 commit
  2. 12 Jul, 2016 1 commit
  3. 20 May, 2016 1 commit
  4. 15 Mar, 2016 1 commit
  5. 24 Feb, 2016 4 commits
  6. 12 Jan, 2016 1 commit
  7. 18 Nov, 2015 2 commits
  8. 16 Nov, 2015 2 commits
  9. 22 Oct, 2015 1 commit
  10. 13 Sep, 2015 5 commits
  11. 11 Sep, 2015 1 commit
  12. 02 Sep, 2015 2 commits
  13. 13 Aug, 2015 1 commit
  14. 05 Aug, 2015 1 commit
  15. 02 Aug, 2015 4 commits
  16. 27 Jul, 2015 1 commit
    • Paul Kocialkowski's avatar
      omap-common: Common boot code OMAP3 support and cleanup · 60c7c30a
      Paul Kocialkowski authored
      This introduces OMAP3 support for the common omap boot code, as well as a
      major cleanup of the common omap boot code.
      First, the omap_boot_parameters structure becomes platform-specific, since its
      definition differs a bit across omap platforms. The offsets are removed as well
      since it is U-Boot's coding style to use structures for mapping such kind of
      data (in the sense that it is similar to registers). It is correct to assume
      that romcode structure encoding is the same as U-Boot, given the description
      of these structures in the TRMs.
      The original address provided by the bootrom is passed to the U-Boot binary
      instead of a duplicate of the structure stored in global data. This allows to
      have only the relevant (boot device and mode) information stored in global data.
      It is also expected that the address where the bootrom stores that information
      is not overridden by the U-Boot SPL or U-Boot.
      The save_omap_boot_params is expected to handle all special cases where the data
      provided by the bootrom cannot be used as-is, so that spl_boot_device and
      spl_boot_mode only return the data from global data.
      All of this is only relevant when the U-Boot SPL is used. In cases it is not,
      save_boot_params should fallback to its weak (or board-specific) definition.
      save_omap_boot_params should not be called in that context either.
      Signed-off-by: default avatarPaul Kocialkowski <contact@paulk.fr>
  17. 10 Jul, 2015 1 commit
  18. 13 May, 2015 1 commit
  19. 18 Apr, 2015 2 commits
    • Joe Hershberger's avatar
      net: cosmetic: Name ethaddr variables consistently · 0adb5b76
      Joe Hershberger authored
      Use "_ethaddr" at the end of variables and drop CamelCase.
      Make constant values actually 'const'.
      Signed-off-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
    • Masahiro Yamada's avatar
      dm: select CONFIG_DM* options · 58d423b8
      Masahiro Yamada authored
      As mentioned in the previous commit, adding default values in each
      Kconfig causes problems because it does not co-exist with the
      "depends on" syntax.  (Please note this is not a bug of Kconfig.)
      We should not do so unless we have a special reason.  Actually,
      for CONFIG_DM*, we have no good reason to do so.
      Generally, CONFIG_DM is not a user-configurable option.  Once we
      convert a driver into Driver Model, the board only works with Driver
      Model, i.e. CONFIG_DM must be always enabled for that board.
      So, using "select DM" is more suitable rather than allowing users to
      modify it.  Another good thing is, Kconfig warns unmet dependencies
      for "select" syntax, so we easily notice bugs.
      Actually, CONFIG_DM and other related options have been added
      without consistency: some into arch/*/Kconfig, some into
      board/*/Kconfig, and some into configs/*_defconfig.
      This commit prefers "select" and cleans up the following issues.
      [1] Never use "CONFIG_DM=n" in defconfig files
      It is really rare to add "CONFIG_FOO=n" to disable CONFIG options.
      It is more common to use "# CONFIG_FOO is not set".  But here, we
      do not even have to do it.
      Less than half of OMAP3 boards have been converted to Driver Model.
      Adding the default values to arch/arm/cpu/armv7/omap3/Kconfig is
      weird.  Instead, add "select DM" only to appropriate boards, which
      eventually eliminates "CONFIG_DM=n", etc.
      [2] Delete redundant CONFIGs
      Sandbox sets CONFIG_DM in arch/sandbox/Kconfig and defines it again
      in configs/sandbox_defconfig.
      Likewise, OMAP3 sets CONFIG_DM arch/arm/cpu/armv7/omap3/Kconfig and
      defines it also in omap3_beagle_defconfig and devkit8000_defconfig.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  20. 24 Feb, 2015 1 commit
  21. 12 Feb, 2015 1 commit
  22. 29 Jan, 2015 5 commits