1. 12 12月, 2009 6 次提交
    • M
      omap3: cm-t35: add mux initialization · edc961a2
      Mike Rapoport 提交于
      CM-T35 can be assembled with different set of peripherals thus making
      certain interfaces available to user as GPIOs or dedicated pins. Because
      of it CM-T35 bootloader sets up mux configuration only for pins
      necessary to boot the system and the rest of the mux configuration is
      done by the kernel. Besides, having mux configuration in the kernel
      allows to minimize dependancy on bootloader.
      Signed-off-by: NMike Rapoport <mike@compulab.co.il>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      edc961a2
    • G
      omap3: Board file of Always Innovating OMAP3-based Touch Book · 7a079cab
      Gregoire Gentil 提交于
      Board file of Always Innovating OMAP3-based Touch Book
      Signed-off-by: NGregoire Gentil <gregoire@gentil.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7a079cab
    • T
      omap: mux: Add 36xx CBP package support · 662c8b55
      Tony Lindgren 提交于
      Add 36xx CBP package support
      
      Cc: Benoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      662c8b55
    • T
      omap: mux: Add new style init functions to omap3 board-*.c files · ca5742bd
      Tony Lindgren 提交于
      Add new style mux init functions to omap3 board-*.c files
      
      So far Beagle has been confirmed to be a CBB package,
      and CM-T35 a CUS package.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ca5742bd
    • 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