An error occurred fetching the project authors.
  1. 03 Sep, 2009 1 commit
  2. 25 Jul, 2009 2 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
    • 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
  3. 20 Jun, 2009 4 commits
  4. 28 May, 2009 1 commit
  5. 16 May, 2009 1 commit
  6. 12 May, 2009 4 commits
  7. 19 Feb, 2009 1 commit
    • Russell King's avatar
      [ARM] omap: add support for bypassing DPLLs · c0bf3132
      Russell King authored
      This roughly corresponds with OMAP commits: 7d06c48d, 3241b19e,
      88b5d9b6, 18a55008, 9c909ac9, 5c6497bc, 8b1f0bd4, 2ac1da8c.
      
      For both OMAP2 and OMAP3, we note the reference and bypass clocks in
      the DPLL data structure.  Whenever we modify the DPLL rate, we first
      ensure that both the reference and bypass clocks are enabled.  Then,
      we decide whether to use the reference and DPLL, or the bypass clock
      if the desired rate is identical to the bypass rate, and program the
      DPLL appropriately.  Finally, we update the clock's parent, and then
      disable the unused clocks.
      
      This keeps the parents correctly balanced, and more importantly ensures
      that the bypass clock is running whenever we reprogram the DPLL.  This
      is especially important because the procedure for reprogramming the DPLL
      involves switching to the bypass clock.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      c0bf3132
  8. 14 Feb, 2009 1 commit
  9. 08 Feb, 2009 21 commits
  10. 02 Feb, 2009 1 commit
  11. 11 Dec, 2008 2 commits
  12. 06 Sep, 2008 1 commit