1. 13 5月, 2009 9 次提交
    • A
      OMAP3 clock: lessen amount of noisy messages · 0db4e825
      Artem Bityutskiy 提交于
      On our system we see the following messages:
      
      Disabling unused clock "gpt2_ick"
      Disabling unused clock "gpt3_ick"
      Disabling unused clock "gpt4_ick"
      Disabling unused clock "gpt5_ick"
      ...
      
      The messages have KERN_INFO level and if you have serial
      console, they normally go there. I do not think it is good
      idea to print that much stuff there. Moreover, messages
      are not properly prefixed and for mortals it is not
      immeadietly clear where they come from.
      
      Let's give them debugging level instead.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      [paul@pwsan.com: trimmed debugging output in patch description]
      0db4e825
    • P
      OMAP3 clock: use pr_debug() rather than pr_info() in some clock change code · b7aee4bf
      Paul Walmsley 提交于
      The CORE DPLL M2 frequency change code should use pr_debug(), not
      pr_info(), for its debug messages.  Same with
      omap2_clksel_round_rate_div().  While here, convert a few printk(KERN_ERR ..
      into pr_err().
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b7aee4bf
    • P
      OMAP3 clock: only unlock SDRC DLL if SDRC clk < 83MHz · 4519c2bf
      Paul Walmsley 提交于
      According to the 34xx TRM Rev. K section 11.2.4.4.11.1 "Purpose of the
      DLL/CDL Module," the SDRC delay-locked-loop can be locked at any SDRC
      clock frequency from 83MHz to 166MHz.  CDP code unconditionally
      unlocked the DLL whenever shifting to a lower SDRC speed, but this
      seems unnecessary and error-prone, as the DLL is no longer able to
      compensate for process, voltage, and temperature variations.  Instead,
      only unlock the DLL when the SDRC clock rate would be less than 83MHz.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4519c2bf
    • P
      OMAP3 SRAM: renumber registers to make space for argument passing · b2abb271
      Paul Walmsley 提交于
      Renumber registers in omap3_sram_configure_core_dpll() assembly code to
      make space for additional parameters.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b2abb271
    • P
      OMAP3 SDRC: initialize SDRC_POWER at boot · 98cfe5ab
      Paul Walmsley 提交于
      Initialize SDRC_POWER to a known-good setting when the kernel boots.
      Necessary since some bootloaders don't initialize SDRC_POWER properly.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      98cfe5ab
    • P
      OMAP3 SRAM: clear the SDRC PWRENA bit during SDRC frequency change · fa0406a8
      Paul Walmsley 提交于
      Clear the SDRC_POWER.PWRENA bit before putting the SDRAM into self-refresh
      mode.  This prevents the SDRC from attempting to power off the SDRAM,
      which can cause the system to hang.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      fa0406a8
    • P
      OMAP3 clock: add interconnect barriers to CORE DPLL M2 change · d75d9e73
      Paul Walmsley 提交于
      Where necessary, add interconnect barriers to force posted writes to
      complete before continuing.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d75d9e73
    • P
      OMAP3 SRAM: add ARM barriers to omap3_sram_configure_core_dpll · 69d4255b
      Paul Walmsley 提交于
      Add more barriers in the SRAM CORE DPLL M2 divider change code.
      
      - Add a DSB SY after the function's entry point to flush all cached
        and buffered writes and wait for the interconnect to claim that they
        have completed[1].  The idea here is to force all delayed write
        traffic going to the SDRAM to at least post to the L3 interconnect
        before continuing.  If these writes are allowed to occur after the
        SDRC is idled, the writes will not be acknowledged and the ARM will
        stall.
      
        Note that in this case, it does not matter if the writes actually
        complete to the SDRAM - it is only necessary for the writes to leave
        the ARM itself.  If the writes are posted by the interconnect when
        the SDRC goes into idle, the writes will be delayed until the SDRC
        returns from idle[2].  If the SDRC is in the middle of a write when
        it is requested to enter idle, the SDRC will not acknowledge the
        idle request until the writes complete to the SDRAM.[3]
      
        The old-style DMB in sdram_in_selfrefresh is now superfluous, so,
        remove it.
      
      - Add an ISB before the function's exit point to prevent the ARM from
        speculatively executing into SDRAM before the SDRAM is enabled[4].
      
      ...
      
      1. ARMv7 ARM (DDI 0406A) A3-47, A3-48.
      
      2. Private communication with Richard Woodruff <r-woodruff2@ti.com>.
      
      3. Private communication with Richard Woodruff <r-woodruff2@ti.com>.
      
      4. ARMv7 ARM (DDI 0406A) A3-48.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      69d4255b
    • P
      OMAP3 SRAM: mark OCM RAM as Non-cacheable Normal memory · d9295746
      Paul Walmsley 提交于
      Mark the SRAM (aka OCM RAM) as Non-cacheable Normal memory[1].  This
      is to prevent the ARM from evicting existing cache lines to SDRAM
      while code is executing from the SRAM.  Necessary since one of the
      primary uses for the SRAM is to hold the code and data for the CORE
      DPLL M2 divider reprogramming code, which must execute while the SDRC
      is idled.  If the ARM attempts to write cache lines back to the while
      the SRAM code is running, the ARM will stall[2].
      
      TI deals with this problem in the CDP kernel by marking the SRAM as
      Strongly-ordered memory.
      
      Tero Kristo <tero.kristo@nokia.com> caught a bug in an earlier version of
      this patch - thanks Tero.
      
      ...
      
      1. ARMv7 ARM (DDI 0406A) pp. A3-30, A3-31, B3-32.
      
      2. Private communication with Richard Woodruff <r-woodruff2@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tero Kristo <tero.kristo@nokia.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      d9295746
  2. 12 5月, 2009 11 次提交
  3. 11 5月, 2009 9 次提交
  4. 10 5月, 2009 11 次提交