Skip to content
Snippets Groups Projects
  1. Mar 04, 2015
  2. Dec 18, 2014
  3. Dec 11, 2014
    • Simon Glass's avatar
      dm: i2c: tegra: Convert to driver model · b0e6ef46
      Simon Glass authored
      
      This converts all Tegra boards over to use driver model for I2C. The driver
      is adjusted to use driver model and the following obsolete CONFIGs are
      removed:
      
         - CONFIG_SYS_I2C_INIT_BOARD
         - CONFIG_I2C_MULTI_BUS
         - CONFIG_SYS_MAX_I2C_BUS
         - CONFIG_SYS_I2C_SPEED
         - CONFIG_SYS_I2C
      
      This has been tested on:
      - trimslice (no I2C)
      - beaver
      - Jetson-TK1
      
      It has not been tested on Tegra 114 as I don't have that board.
      
      Acked-by: default avatarHeiko Schocher <hs@denx.de>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      b0e6ef46
  4. Sep 25, 2014
  5. Aug 18, 2014
    • Stephen Warren's avatar
      ARM: tegra: enable DFU too · 39446bce
      Stephen Warren authored
      
      Enable DFU protocol support (via the "dfu" command) on Tegra boards where
      USB device/gadget mode is enabled.
      
      Note that for DFU to operate correctly on Tegra, we still need some DFU
      fixes/enhancements that are going through the DFU -> USB trees. However,
      the code builds just fine without those changes, and applying this patch
      now will allow both sets of patches to meet in the main U-Boot tree much
      more quickly.
      
      In order to run test/dfu/dfu_gadget_test.sh, you would need to add the
      following to the board configuration:
      
      CONFIG_EXT4_WRITE
      CONFIG_CMD_EXT4_WRITE
      
      However, I haven't enabled those here, since I believe the main use-case
      for DFU on Tegra is raw flash writing, rather than filesystem access, so
      we don't need the additional code-size hit. However, I could be persuaded
      otherwise! We should probably add a separate test script for raw flash
      access.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      39446bce
  6. Jun 05, 2014
  7. May 13, 2014
    • Stephen Warren's avatar
      ARM: tegra: use a CPU freq that all SKUs can support · 2364e151
      Stephen Warren authored
      U-Boot on Tegra30 currently selects a main CPU frequency that cannot be
      supported at all on some SKUs, and needs higher VDD_CPU/VDD_CORE values
      on some others. This can result in unreliable operation of the main CPUs.
      
      Resolve this by switching to a CPU frequency that can be supported by any
      SKU. According to the following link, the maximum supported CPU frequency
      of the slowest Tegra30 SKU is 600MHz:
      
      repo http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary
      
      
      branch l4t/l4t-r16-r2
      path arch/arm/mach-tegra/tegra3_dvfs.c
      table cpu_dvfs_table[]
      
      According to that same table, the minimum VDD_CPU required to operate at
      that frequency across all SKUs is 1.007V. Given the adjustment resolution
      of the TPS65911 PMIC that's used on all Tegra30-based boards we support,
      we'll end up using 1.0125V instead.
      
      At that VDD_CPU, tegra3_get_core_floor_mv() in that same file dictates
      that VDD_CORE must be at least 1.2V on all SKUs. According to
      tegra_core_speedo_mv() (in tegra3_speedo.c in the same source tree),
      that voltage is safe for all SKUs.
      
      An alternative would be to port much of the code from tegra3_dvfs.c and
      tegra3_speedo.c in the kernel tree mentioned above. That's more work
      than I want to take on right now.
      
      While all the currently supported boards use the same regulator chip for
      VDD_CPU, different types of regulators are used for VDD_CORE. Hence, we
      add some small conditional code to select how VDD_CORE is programmed. If
      this becomes more complex in the future as new boards are added, or we
      end up adding code to detect the SoC SKU and dynamically determine the
      allowed frequency and required voltages, we should probably make this a
      runtime call into a function provided by the board file and/or relevant
      PMIC driver.
      
      Cc: Alban Bedel <alban.bedel@avionic-design.de>
      Cc: Marcel Ziswiler <marcel@ziswiler.com>
      Cc: Bard Liao <bardliao@realtek.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      2364e151
  8. Mar 04, 2014
  9. Jul 23, 2013
  10. Jul 11, 2013
  11. Jun 13, 2013
  12. Apr 15, 2013
  13. Mar 25, 2013
  14. Mar 14, 2013
  15. Feb 11, 2013
  16. Jan 16, 2013
Loading