1. 12 12月, 2009 2 次提交
    • T
      omap: mux: Add new style pin multiplexing data for 34xx · ddaa912a
      Tony Lindgren 提交于
      Add new style mux data for 34xx. This should also
      work with 3630 easily by adding the processor subset
      and ball data.
      
      Note that this data is __initdata, and gets optimized
      out except for the GPIO pins if CONFIG_OMAP_MUX
      is not set.
      
      Also note that this data uses omap3630 naming for
      the SDMMC registers instead of 34xx naming with just
      MMC.
      
      Cc: Benoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ddaa912a
    • P
      OMAP3: SDRC: Place SDRC AC timing and MR changes in CORE DVFS SRAM code behind Kconfig · 18862cbe
      Paul Walmsley 提交于
      The code that reprograms the SDRC memory controller during CORE DVFS,
      mach-omap2/sram34xx.S:omap3_sram_configure_core_dpll(), does not
      ensure that all L3 initiators are prevented from accessing the SDRAM
      before modifying the SDRC AC timing and MR registers.  This can cause
      memory to be corrupted or cause the SDRC to enter an unpredictable
      state.  This patch places that code behind a Kconfig option,
      CONFIG_OMAP3_SDRC_AC_TIMING for now, and adds a note explaining what
      is going on.  Ideally the code can be added back in once supporting
      code is present to ensure that other initiators aren't touching the
      SDRAM.  At the very least, these registers should be reprogrammable
      during kernel init to deal with buggy bootloaders.  Users who know
      that all other system initiators will not be touching the SDRAM can
      also re-enable this Kconfig option.
      
      This is a modification of a patch originally written by Rajendra Nayak
      <rnayak@ti.com> (the original is at http://patchwork.kernel.org/patch/51927/).
      Rather than removing the code completely, this patch just comments it out.
      
      Thanks to Benoît Cousson <b-cousson@ti.com> and Christophe Sucur
      <c-sucur@ti.com> for explaining the technical basis for this and for
      explaining what can be done to make this path work in future code.
      Thanks to Richard Woodruff <r-woodruff2@ti.com>, Nishanth Menon
      <nm@ti.com>, and Olof Johansson <olof@lixom.net> for their comments.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Christophe Sucur <c-sucur@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: Nishanth Menon <nm@ti.com>
      Cc: Olof Johansson <olof@lixom.net>
      18862cbe
  2. 02 12月, 2009 1 次提交
  3. 26 11月, 2009 4 次提交
  4. 23 11月, 2009 1 次提交
  5. 23 10月, 2009 1 次提交
  6. 29 8月, 2009 2 次提交
  7. 29 5月, 2009 3 次提交
  8. 24 3月, 2009 2 次提交
  9. 11 12月, 2008 1 次提交
  10. 10 10月, 2008 1 次提交
  11. 09 10月, 2008 3 次提交
  12. 21 9月, 2007 2 次提交
  13. 09 5月, 2007 2 次提交
  14. 27 6月, 2006 1 次提交
  15. 03 4月, 2006 1 次提交
  16. 10 11月, 2005 1 次提交
    • T
      [ARM] 3145/1: OMAP 3a/5: Add support for omap24xx · 1dbae815
      Tony Lindgren 提交于
      Patch from Tony Lindgren
      
      This patch adds support for omap24xx series of processors.
      The files live in arch/arm/mach-omap2, and share common
      files with omap15xx and omap16xx processors in
      arch/arm/plat-omap.
      
      Omap24xx support was originally added for 2.6.9 by TI.
      This code was then improved and integrated to share common
      code with omap15xx and omap16xx processors by various
      omap developers, such as Paul Mundt, Juha Yrjola, Imre Deak,
      Tony Lindgren, Richard Woodruff, Nishant Menon, Komal Shah
      et al.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1dbae815