24 May, 2014

9 commits

  • The omap_hw_init_context function (and assorted helpers) is the same for
    all OMAP-derived parts as when CHSETTINGS are used, that's the same and
    our DDR base is also always the same. In order to make this common we
    simply need to update the names of the define for DDR address space
    which is also common.

    Cc: Sricharan R.
    Cc: Lokesh Vutla
    Signed-off-by: Tom Rini
    Reviewed-by: Lokesh Vutla

    Tom Rini
     
  • Efuse register addresses are wrongly programmed.
    Fixing the same.

    Signed-off-by: Lokesh Vutla
    Acked-by: Tom Rini

    Lokesh Vutla
     
  • DRA72 has 1GB connected to EMIF1 only. Updating the details.
    And also enable WA for BUG0039 only if corresponding EMIF is present.

    Signed-off-by: Lokesh Vutla
    Acked-by: Tom Rini

    Lokesh Vutla
     
  • Adding the prcm, dplls, control module hooks for DRA72x.

    Signed-off-by: Lokesh Vutla
    Acked-by: Tom Rini

    Lokesh Vutla
     
  • TPS65917 is used in DRA722 evm. Update the address offsets accordingly.

    Signed-off-by: Lokesh Vutla
    Signed-off-by: Keerthy
    Acked-by: Tom Rini

    Keerthy
     
  • Add silicon ID code for DRA722 silicon.

    Signed-off-by: Lokesh Vutla
    Acked-by: Tom Rini

    Lokesh Vutla
     
  • GPMC controller on TI's OMAP SoC is general purpose controller to interface
    with different types of external devices like;
    - parallel NOR flash
    - parallel NAND flash
    - OneNand flash
    - SDR RAM
    - Ethernet Devices like LAN9220

    Though GPMC configurations may be different for each platform depending on
    clock-frequency and external device interfacing with controller. But
    initialization sequence remains common across all platfoms.

    Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c
    files into single omap-common/mem-common.c

    However, actual platforms specific register config values are still sourced
    from corresponding platform specific headers like;
    AM33xx: arch/arm/include/asm/arch-am33xx/mem.h
    OMAP3: arch/arm/include/asm/arch-omap3/mem.h
    OMAP4: arch/arm/include/asm/arch-omap4/mem.h
    OMAP4: arch/arm/include/asm/arch-omap5/mem.h

    Also, CONFIG_xx passed by board-profile decide config for which set of macros
    need to be used for initialization
    CONFIG_NAND: initialize GPMC for NAND device
    CONFIG_NOR: initialize GPMC for NOR device
    CONFIG_ONENAND: initialize GPMC for ONENAND device

    Signed-off-by: Pekon Gupta
    [trini: define GPMC_SIZE_256M for omap3]
    Signed-off-by: Tom Rini

    pekon gupta
     
  • This patch moves platform specific information for GPMC and ELM controller
    into separate header files, so that any derivative devices do not mess other
    header files.

    Platform specific information added into arch-xx/../hardware.h
    - CPU related platform specific details like base-address of GPMC and ELM

    Platform specific information added into arch-xx/../mem.h
    - Generic configs for GPMC and ELM initialization.
    - Hardware parameters or constrains specific to GPMC and ELM IP like;
    number of max number of chip-selects available

    Signed-off-by: Pekon Gupta

    pekon gupta
     
  • This patch moves platform specific information for GPMC and ELM controller
    into separate header files, so that any derivative devices do not mess other
    header files.

    Platform specific information added into arch-xx/../hardware.h
    - CPU related platform specific details like base-address of GPMC and ELM

    Platform specific information added into arch-xx/../mem.h
    - Generic configs for GPMC and ELM initialization.
    - Hardware parameters or constrains specific to GPMC and ELM IP like;
    number of max number of chip-selects available

    Signed-off-by: Pekon Gupta

    pekon gupta
     

20 May, 2014

1 commit


17 May, 2014

6 commits


16 May, 2014

2 commits


15 May, 2014

8 commits


14 May, 2014

9 commits

  • Add CKOBUFFER_CLK_EN bit mask enabling FREF_XTAL_CLK clock.

    Signed-off-by: Dmitry Lifshitz

    Dmitry Lifshitz
     
  • Add UART4 base address.

    Signed-off-by: Dmitry Lifshitz

    Dmitry Lifshitz
     
  • Signed-off-by: Yegor Yefremov

    Yegor Yefremov
     
  • 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
    Cc: Marcel Ziswiler
    Cc: Bard Liao
    Signed-off-by: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • The HW-defined procedure for booting Tegra requires that
    CLAMP_INPUTS_WHEN_TRISTATED be enabled before programming the pinmux.
    Add a function to the pinmux driver to allow boards to do this.

    Signed-off-by: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • The HW-defined procedure for booting Tegra requires that some pins be
    set up as GPIOs immediately at boot in order to avoid glitches on those
    pins, when the pinmux is programmed. Add a feature to the GPIO driver
    which executes a GPIO configuration table. Board files will use this to
    implement the correct HW initialization procedure.

    Signed-off-by: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • Define enum PMUX_FUNC_DEFAULT, which indicates that a table entry passed
    to pinmux_config_pingrp()/pinmux_config_pingrp_table() shouldn't change
    the mux option in HW.

    For pins that will be used as GPIOs, the mux option is irrelevant, so we
    simply don't want to define any mux option in the pinmux initialization
    table.

    Signed-off-by: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • The register writes performed by arch/arm/cpu/arm720t/tegra30/cpu.c
    enable_cpu_power_rail() set the voltage to 1.0V not 1.4V as the comment
    implies. Fix the comment.

    Signed-off-by: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • If CONFIG_API is ever to be enabled on Tegra, this define must be set,
    since api/api_storage.c uses it.

    A couple of annoyting things about CONFIG_SYS_MMC_MAX_DEVICE

    1) It isn't documented in README. The same is true for a lot of similar
    defines used by api_storage.c.

    2) It doesn't represent MAX_DEVICE but rather NUM_DEVICES, since the
    valid values are 0..n-1 not 0..n.

    However, I this patch does not address those shortcomings.

    Signed-off-by: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     

13 May, 2014

5 commits