1. 11 Jan, 2017 1 commit
    • Masahiro Yamada's avatar
      mmc: move more driver config options to Kconfig · 1d2c0506
      Masahiro Yamada authored
      Move (and rename) the following CONFIG options to Kconfig:
        CONFIG_MXC_MMC      (renamed to CONFIG_MMC_MXC)
        CONFIG_MXS_MMC      (renamed to CONFIG_MMC_MXS)
        CONFIG_SUNXI_MMC    (renamed to CONFIG_MMC_SUNXI)
      They are the same option names as used in Linux.
      This commit was created as follows:
      [1] Rename the options with the following command:
      find . -name .git -prune -o ! -path ./scripts/config_whitelist.txt \
      -type f -print | xargs sed -i -e '
      [2] Commit the changes
      [3] Create entries in driver/mmc/Kconfig.
          (copied from Linux)
      [4] Move the options with the following command
      tools/moveconfig.py -y -r HEAD \
      [5] Sort and align drivers/mmc/Makefile for readability
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarMarek Vasut <marex@denx.de>
  2. 27 Sep, 2016 1 commit
    • Stephen Warren's avatar
      ARM: tegra: fix ULPI PHY on Ventana and Seaboard · 6dca554f
      Stephen Warren authored
      Commit ce02a71c
       "tegra: dts: Sync tegra20 device tree files with
      Linux" enabled the ULPI USB port on Ventana, but made no attempt to ensure
      that U-Boot code could handle this. In practice, various code is missing,
      and various configuration options are not enabled, which causes U-Boot to
      hang when attempting to initialize this USB port. This patch enables ULPI
      PHY support on Ventana, and adds the required pinmux setup for the port to
      operate. Note that Ventana is so similar to Seaboard that this change is
      made in the Seaboard board file, which is shared with Ventana.
      Seaboard also has the ULPI USB port wired up in hardware, although to an
      internal port that often doesn't have anything attached to it. However,
      the DT nodes for the USB controller and PHY had different status property
      values, so the port was not initialized by U-Boot. Fix this inconsistency,
      and enable the ULPI port, just like in the Linux kernel DT. This likewise
      requires enabling ULPI support in the Seaboard defconfig.
      Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
  3. 01 Sep, 2016 1 commit
  4. 15 Aug, 2016 3 commits
  5. 21 Jul, 2016 1 commit
  6. 31 May, 2016 2 commits
  7. 04 May, 2016 1 commit
  8. 28 Jan, 2016 1 commit
    • Stephen Warren's avatar
      ARM: tegra: rm Jetson TK1 PMIC GPIO programming · 7fb82986
      Stephen Warren authored
      The PMIC is configured such that its GPIOs have the correct configuration
      at power-up, so no programming is required.
      In fact, the current programming is actively wrong, since:
      (a) the AS3722 driver configures the GPIO to be an output before setting
      its output value, which causes a 0v glitch on the output.
      (b) the AS3722 driver configures the GPIO to drive a high voltage from its
      VSUP_GPIO power source rather than its VDD_GPIO_LV power source, so the pin
      drives 5V not 1.8V as desired.
      Solve these problems by removing the code which configures the PMIC GPIOs.
      Note that this patch was tested directly on top of v2016.01; since then,
      commit 96350f72
       "dm: tegra: net: Convert tegra boards to driver model
      for Ethernet" prevents PCIe from being initialized. Alternatively, simply
      revert that commit to get PCIe Ethernet working again, then apply this
      patch to test.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
  9. 19 Jan, 2016 1 commit
  10. 12 Jan, 2016 1 commit
  11. 12 Nov, 2015 2 commits
  12. 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>
  13. 02 Oct, 2015 1 commit
  14. 16 Sep, 2015 1 commit
  15. 06 Aug, 2015 4 commits
  16. 05 Aug, 2015 2 commits
  17. 28 Jul, 2015 1 commit
  18. 27 Jul, 2015 1 commit
  19. 09 Jun, 2015 2 commits
  20. 13 May, 2015 6 commits
  21. 30 Mar, 2015 1 commit
  22. 04 Mar, 2015 3 commits
    • Simon Glass's avatar
      dm: tegra: Enable driver model in SPL and adjust the GPIO driver · bdfb3416
      Simon Glass authored
      Use the full driver model GPIO and serial drivers in SPL now that these are
      supported. Since device tree is not available they will use platform data.
      Remove the special SPL GPIO function as it is no longer needed.
      This is all in one commit to maintain bisectability.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Stephen Warren's avatar
      ARM: tegra: import latest Jetson TK1 pinmux · c1fe92fe
      Stephen Warren authored
      Syseng has revamped the Jetson TK1 pinmux spreadsheet, basing the content
      completely on correct configuration for the board/schematic, rather than
      the previous version which was based on the bare minimum changes relative
      to another reference board.
      The new spreadsheet sets TRISTATE for any input-only pins. This only works
      correctly if the global CLAMP bit is not set, so the Jetson TK1 board code
      has been adjusted accordingly. Apparently syseng have changed their mind
      since the previous advice that this needed to be set:-/
      This content comes from Jetson_TK1_customer_pinmux.xlsm (v09) downloaded
      from https://developer.nvidia.com/hardware-design-and-development
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
    • Stephen Warren's avatar
      ARM: tegra: support running in non-secure mode · 73c38934
      Stephen Warren authored
      When the CPU is in non-secure (NS) mode (when running U-Boot under a
      secure monitor), certain actions cannot be taken, since they would need
      to write to secure-only registers. One example is configuring the ARM
      architectural timer's CNTFRQ register.
      We could support this in one of two ways:
      1) Compile twice, once for secure mode (in which case anything goes) and
         once for non-secure mode (in which case certain actions are disabled).
         This complicates things, since everyone needs to keep track of
         different U-Boot binaries for different situations.
      2) Detect NS mode at run-time, and optionally skip any impossible actions.
         This has the advantage of a single U-Boot binary working in all cases.
      (2) is not possible on ARM in general, since there's no architectural way
      to detect secure-vs-non-secure. However, there is a Tegra-specific way to
      detect this.
      This patches uses that feature to detect secure vs. NS mode on Tegra, and
      uses that to:
      * Skip the ARM arch timer initialization.
      * Set/clear an environment variable so that boot scripts can take
        different action depending on which mode the CPU is in. This might be
        something like:
        if CPU is secure:
          load secure monitor code into RAM.
          boot secure monitor.
          secure monitor will restart (a new copy of) U-Boot in NS mode.
          execute normal boot process
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
  23. 30 Jan, 2015 2 commits