Eric Lee / smarc-uboot

04 Feb, 2014

12 commits

  • a73ca4789   mmc: tegra: support Tegra124 ... Browse Code »

    Tegra124's MMC controller is very similar to earlier SoC generations,
    and can be supported by the same driver.

    However, there are some non-backwards-compatible HW differences, and
    hence a new DT compatible value must be used to describe the HW. This
    patch updates the driver to support that new compatible value.

    That said, the HW differences are only relevant when enabling certain
    high-performance transfer modes. Since the driver is currently very
    simple and doesn't enable those modes, we don't actually need to address
    any of these HW differences in the code yet, hence the simple nature of
    this patch.

    Signed-off-by: Stephen Warren
    Acked-by: Pantelis Antoniou
    Tested-by: Thierry Reding
    Acked-by: Simon Glass
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • b9dd6215c   ARM: tegra: don't exceed AVP limits when configuring PLLP ... Browse Code »

    Based on the Tegra TRM, the system clock (which is the AVP clock) can
    run up to 275MHz. On power on, the default sytem clock source is set to
    PLLP_OUT0. In function clock_early_init(), PLLP_OUT0 will be set to
    408MHz which is beyond system clock's upper limit.

    The fix is to set the system clock to CLK_M before initializing PLLP,
    and then switch back to PLLP_OUT4, which has an appropriate divider
    configured, after PLLP has been configured

    Implement this logic in new function tegra30_set_up_pllp(),
    which sets up PLLP and all PLLP_OUT* dividers, and handles the AVP
    clock switching. Remove the duplicate PLLP setup from pllx_set_rate()
    and adjust_pllp_out_freqs().

    Signed-off-by: Jimmy Zhang
    [swarren, significantly refactored the change]
    Signed-off-by: Stephen Warren
    Reviewed-by: Thierry Reding
    Tested-by: Thierry Reding
    Acked-by: Thierry Reding
    Signed-off-by: Tom Warren

    Jimmy Zhang
     
  • 9399e540c   ARM: tegra: amend pmc.h for Tegra114+ ... Browse Code »

    Tegra114 and later's PMC module removes the pwrgate_timer_on register
    and replaces it with a clamp_status register. Adjust pmc.h to reflect
    this, and update any code affected by the change.

    The cpu.c change in this patch was extracted from a much larger patch
    by Jimmy Zhang. The pmc.h change was written from scratch, but inspired
    by related changes made by Tom Warren.

    There could well be other differences in the PMC register set for chips
    after Tegra20/30. However, they don't affect the code in U-Boot at
    present, so I haven't attempted an exhaustive update of pmc.h.

    Signed-off-by: Stephen Warren
    Reviewed-by: Thierry Reding
    Acked-by: Thierry Reding
    Tested-by: Thierry Reding
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • c82014daf   ARM: tegra: implement MASK_BITS_31_29 ... Browse Code »

    Some clock sources have 3-bit muxes in bits 31:29. Implement core
    support for this mux field.

    Signed-off-by: Tom Warren
    [swarren, extracted from a larger patch by Tom]
    Signed-off-by: Stephen Warren
    Reviewed-by: Thierry Reding
    Tested-by: Thierry Reding
    Acked-by: Thierry Reding
    Signed-off-by: Tom Warren

    Tom Warren
     
  • 04b8e8e74   ARM: tegra: MASK_BITS_ no longer needs specific values ... Browse Code »

    Since all code that sets or interprets MASK_BITS_* now uses the enums
    to define/compare the values, there is no need for MASK_BITS_* to have
    a specific integer value. In fact, having a specific integer value may
    encourage people to hard-code those values, or interpret the values in
    incorrect ways.

    As such, remove the logic that assigns a specific value to the enum
    values in order to make it completely clear that it's just an enum, not
    something that directly represents some integer value.

    Signed-off-by: Stephen Warren
    Reviewed-by: Thierry Reding
    Tested-by: Thierry Reding
    Acked-by: Thierry Reding
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • 54d2e1829   ARM: tegra: use MASK_BITS_* macros everywhere ... Browse Code »

    Not all code that set or interpreted "mux_bits" was using the named
    macros, but rather some was simply using hard-coded integer constants.
    This makes it hard to determine which pieces of code are affected by
    changes to those constants.

    Replace the integer constants with the equivalent macro definitions so
    that everything is nicely tied together.

    Note that I'm not convinced all the code was using the correct integer
    constants, and hence I'm not convinced that all the code is now using
    the desired macros. However, this change is a purely mechanical
    replacement and should have no functional change. Fixing any bugs will
    come later, separately.

    Signed-off-by: Stephen Warren
    Reviewed-by: Thierry Reding
    Tested-by: Thierry Reding
    Acked-by: Thierry Reding
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • 9cb0c6dc6   ARM: tegra: rename OUT_CLK_SOURCE_* ... Browse Code »

    OUT_CLK_SOURCE_ are currently named after the number of bits the mask
    they represent includes. However, bit count is not the only possible
    variable; bit position may also vary. Rename OUT_CLK_SOURCE_ to
    OUT_CLK_SOURCE_31_30_ and OUT_CLK_SOURCE4_ to OUT_CLK_SOURCE_31_28 to
    more completely describe exactly what they represent, without having to
    go look up the definitions.

    Signed-off-by: Stephen Warren
    Reviewed-by: Thierry Reding
    Tested-by: Thierry Reding
    Acked-by: Thierry Reding
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • 5916a36ee   ARM: tegra: rename MASK_BITS_29_28 to MASK_BITS_31_28 ... Browse Code »

    The only place where the MASK_BITS_* values are used is in
    adjust_periph_pll(), which interprets the value 4 (old MASK_BITS_29_28,
    new MASK_BITS_31_28) as being associated with mask OUT_CLK_SOURCE4_MASK,
    i.e. bits 31:28. Rename the MASK_BITS_ macro to reflect how it's actually
    implemented.

    Note that no Tegra clock register actually uses all of bits 31:28 as
    the mux field. Rather, bits 30:28, 29:28, or 28 are used. However, in
    those cases, nothing is stored in the bits above the mux field, so it's
    safe to pretend that the mux field extends all the way to the end of the
    register. As such, the U-Boot clock driver is currently a bit lazy, and
    doesn't distinguish between 31:28, 30:28, 29:28 and 28; it just lumps
    them all together and pretends they're all 31:28. This patch doesn't
    cause this issue; it was pre-existing. Hopefully, future patches will
    clean this up.

    Signed-off-by: Stephen Warren
    Reviewed-by: Thierry Reding
    Tested-by: Thierry Reding
    Acked-by: Thierry Reding
    Signed-off-by: Tom Warren

    Stephen Warren
     
  • 0b01b53aa   ARM: tegra: deduplicate MASK_BITS_xxx clock mux enum ... Browse Code »

    The enum used to define the set of register bits used to represent a
    clock's input mux, MUX_BITS_*, is defined separately for each SoC at
    present. Move this definition to a common location to ease fixing up
    some issues with the definition, and the code that uses it.

    Signed-off-by: Tom Warren
    [swarren, extracted from a larger patch by Tom]
    Signed-off-by: Stephen Warren
    Reviewed-by: Thierry Reding
    Tested-by: Thierry Reding
    Acked-by: Thierry Reding
    Signed-off-by: Tom Warren

    Tom Warren
     
  • 09266b270   ARM: tegra: clear $usb_need_init each boot ... Browse Code »

    $usb_need_init prevents "usb start" from being run multiple times for
    each boot attempt, i.e. once for USB storage, another for PXE, and
    another for DHCP. However, the flag that's used to determine when to run
    "usb start" is never cleared, so a subsequent "boot" command will never
    probe for a freshly plugged in USB device. Fix this so that new USB
    devices will be probed once per boot attempt.

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

    Stephen Warren
     
  • b9b53a60a   ARM: tegra: set env vars to indicate Cardhu A04 support ... Browse Code »

    The U-Boot "cardhu" build supports only revision 4 of the Cardhu board
    and later compatible revisions. Hence, set $board_name in the default
    environment to "cardhu-a04" rather than just "cardhu".

    The Linux kernel has separate DTs for Cardhu A02 and A04, although the
    former isn't really supported any more. Consequently, the kernel DT file
    that matches the U-Boot cardhu build is "tegra30-cardhu-a04.dtb" rather
    than "tegra30-cardhu.dtb". Set the $fdtfile default environment variable
    to reflect this.

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

    Stephen Warren
     
  • 86b657878   ARM: tegra: accept any SKU ID for most chips ... Browse Code »

    For Tegra20, the SKU ID actually impacts how U-Boot programs the chip,
    and hence we need to explicitly know about each and every SKU ID in order
    to operate correctly.

    However, for Tegra30/114, this isn't the case. Rather than forcing each
    new user with a different SKU to manually add their SKU ID into the code,
    simply accept any SKU ID.

    If U-Boot ever starts e.g. programming maximal CPU clocks etc., we'll
    need to undo this, or make the default case map to conservative defaults,
    but for now it's likely the path to least support cost.

    Reported-by: Olof Johansson
    Signed-off-by: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     

29 Jan, 2014

1 commit

28 Jan, 2014

1 commit

27 Jan, 2014

2 commits

  • 0876703cf   boards.cfg: Keep the entries sorted ... Browse Code »

    Run "tools/reformat.py -i -d '-' -s 8 boards0.cfg && mv boards0.cfg boards.cfg"
    in order to keep the entries sorted.

    Signed-off-by: Fabio Estevam

    Fabio Estevam
     
  • 7395398ad   board_r - fixup functions table after relocation ... Browse Code »

    This is only required for "PIC" relocation and doesn't apply to modern
    "PIE" relocation which does data relocation as well as code.

    "init_sequence_r" is just an array that consists of compile-time
    adresses of init functions. Since this is basically an array of integers
    (pointers to "void" to be more precise) it won't be modified during
    relocation - it will be just copied to new location as it is.

    As a consequence on execution after relocation "initcall_run_list" will
    be jumping to pre-relocation addresses. As long as we don't overwrite
    pre-relocation memory area init calls are executed correctly. But still
    it is dangerous because after relocation we don't expect initially used
    memory to stay untouched.

    Cc: Tom Rini
    Cc: Masahiro Yamada
    Cc: Doug Anderson
    Cc: Thomas Langer
    Cc: Albert ARIBAUD
    Acked-by: Simon Glass
    Signed-off-by: Alexey Brodkin

    Alexey Brodkin
     

25 Jan, 2014

24 commits