1. 25 Jul, 2009 8 commits
    • Paul Walmsley's avatar
      OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB · 3c82e229
      Paul Walmsley authored
      Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
      USBHOST, and HSOTGUSB devices.  These devices are both interconnect
      initiators and targets.  Without this patch, clk_enable()s on clocks for
      these modules can be very high latency (potentially up to ~200
      milliseconds) and message such as the following are generated:
      
          Clock usbhost_48m_fck didn't enable in 100000 tries
      
      Two bugs are fixed by this patch.  First, OMAP hardware only supports
      target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
      should not wait for these clocks to enable.  So, split the appropriate
      clocks into ES1 and ES2+ variants, so that kernels running on ES1
      devices won't try to wait.
      
      Second, the current heuristic in omap2_clk_dflt_find_idlest() will
      fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
      is the same as the CM_*CLKEN bit, which is false[1].  Fix by
      implementing custom clkops .find_idlest function pointers for the
      appropriate clocks that return the correct slave IDLEST bit shift.
      
      This was originally fixed in the linux-omap kernel during 2.6.29 in a
      slightly different manner[2][3].
      
      In the medium-term future, all of the module IDLEST code will
      eventually be moved to the omap_hwmod code.
      
      Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
      
          http://marc.info/?l=linux-omap&m=124306184903679&w=2
      
      ...
      
      1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
         DSS case).
      
      2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
      
      3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.htmlSigned-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Jarkko Nikula <jhnikula@gmail.com>
      3c82e229
    • Paul Walmsley's avatar
      OMAP2 clock: 2430 I2CHS uses non-standard CM_IDLEST register · 3dc21975
      Paul Walmsley authored
      OMAP2430 I2CHS CM_IDLEST bits are in CM_IDLEST1_CORE, but the CM_*CLKEN bits
      are in CM_{I,F}CLKEN2_CORE [1].  Fix by implementing a custom clkops
      .find_idlest function to return the correct slave IDLEST register.
      
      ...
      
      1. OMAP2430 Multimedia Device Package-on-Package (POP) Silicon Revision 2.1
         (Rev. V) Technical Reference Manual, tables 4-99 and 4-105.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      3dc21975
    • Paul Walmsley's avatar
      OMAP2/3 clock: split, rename omap2_wait_clock_ready() · 72350b29
      Paul Walmsley authored
      Some OMAP2/3 hardware modules have CM_IDLEST attributes that are not
      handled by the current omap2_wait_clock_ready() code.  In preparation
      for patches that fix the unusual devices, rename the function
      omap2_wait_clock_ready() to omap2_wait_module_ready() and split it
      into three parts:
      
      1. A clkops-specific companion clock return function (by default,
         omap2_clk_dflt_find_companion())
      
      2. A clkops-specific CM_IDLEST register address and bit shift return
         function (by default, omap2_clk_dflt_find_idlest())
      
      3. Code to wait for the CM to indicate that the module is ready
         (omap2_cm_wait_idlest())
      
      Clocks can now specify their own custom find_companion() and find_idlest()
      functions; used in subsequent patches.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      72350b29
    • Rajendra Nayak's avatar
      OMAP3 SDRC: Move the clk stabilization delay to the right place · df56556e
      Rajendra Nayak authored
      The clock stabilization delay post a M2 divider change is needed
      even before a SDRC interface clock re-enable and not only before
      jumping back to SDRAM.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      df56556e
    • Rajendra Nayak's avatar
      OMAP3 SDRC: Fix freeze when scaling CORE dpll to < 83Mhz · 8ff120e5
      Rajendra Nayak authored
      This patch fixes a bug in the CORE dpll scaling sequence which was
      errouneously clearing some bits in the SDRC DLLA CTRL register and
      hence causing a freeze.  The issue was observed only on platforms
      which scale CORE dpll to < 83Mhz and hence program the DLL in fixed
      delay mode.
      
      Issue reported by Limei Wang <E12499@motorola.com>, with debugging
      assistance from Richard Woodruff <r-woodruff2@ti.com> and Girish
      Ghongdemath <girishsg@ti.com>.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Cc: Limei Wang <E12499@motorola.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: Girish Ghongdemath <girishsg@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      [paul@pwsan.com: updated patch description to include collaboration credits]
      8ff120e5
    • Paul Walmsley's avatar
      OMAP2/3 SDRC: don't set SDRC_POWER.PWDENA on boot · 75f251e3
      Paul Walmsley authored
      Stop setting SDRC_POWER.PWDENA on boot.  There is a nasty erratum
      (34xx erratum 1.150) that can cause memory corruption if PWDENA is
      enabled.
      
      Based originally on a patch from Samu P. Onkalo <samu.p.onkalo@nokia.com>.
      
      Tested on BeagleBoard rev C2.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Samu P. Onkalo <samu.p.onkalo@nokia.com>
      75f251e3
    • Jean Pihet's avatar
      OMAP3: Setup MUX settings for SDRC CKE signals · 9fb97412
      Jean Pihet authored
      This patches ensures the MUX settings are correct for the SDRC
      CKE signals to SDRAM. This allows the self-refresh to work when
      2 chip-selects are in use.
      
      A warning is thrown away in case the initial muxing is incorrect,
      in order to track faulty or old-dated bootloaders.
      Note: The CONFIG_OMAP_MUX and CONFIG_OMAP_MUX_WARNINGS options
      must be enabled for the mux code to have effect.
      Signed-off-by: default avatarJean Pihet <jpihet@mvista.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      9fb97412
    • Jean Pihet's avatar
      OMAP3 SDRC: add support for 2 SDRAM chip selects · 58cda884
      Jean Pihet authored
      Some OMAP3 boards (Beagle Cx, Overo, RX51, Pandora) have 2
      SDRAM parts connected to the SDRC.
      
      This patch adds the following:
      - add a new argument of type omap_sdrc_params struct*
      to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
      - adapted the OMAP boards files to the new prototype of
      omap2_init_common_hw
      - add the SDRC 2nd CS registers offsets defines
      - adapt the sram sleep code to configure the SDRC for the 2nd CS
      
      Note: If the 2nd param to omap2_init_common_hw is NULL, then the
      parameters are not programmed into the SDRC CS1 registers
      
      Tested on 3430 SDP and Beagleboard rev C2 and B5, with
      suspend/resume and frequency changes (cpufreq).
      Signed-off-by: default avatarJean Pihet <jpihet@mvista.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      58cda884
  2. 23 Jul, 2009 1 commit
  3. 22 Jul, 2009 31 commits