1. 16 2月, 2010 1 次提交
  2. 14 12月, 2009 1 次提交
  3. 12 12月, 2009 3 次提交
  4. 23 11月, 2009 3 次提交
  5. 12 11月, 2009 1 次提交
  6. 10 11月, 2009 1 次提交
  7. 26 10月, 2009 1 次提交
  8. 21 10月, 2009 1 次提交
    • T
      omap: headers: Move remaining headers from include/mach to include/plat · ce491cf8
      Tony Lindgren 提交于
      Move the remaining headers under plat-omap/include/mach
      to plat-omap/include/plat. Also search and replace the
      files using these headers to include using the right path.
      
      This was done with:
      
      #!/bin/bash
      mach_dir_old="arch/arm/plat-omap/include/mach"
      plat_dir_new="arch/arm/plat-omap/include/plat"
      headers=$(cd $mach_dir_old && ls *.h)
      omap_dirs="arch/arm/*omap*/ \
      drivers/video/omap \
      sound/soc/omap"
      other_files="drivers/leds/leds-ams-delta.c \
      drivers/mfd/menelaus.c \
      drivers/mfd/twl4030-core.c \
      drivers/mtd/nand/ams-delta.c"
      
      for header in $headers; do
      	old="#include <mach\/$header"
      	new="#include <plat\/$header"
      	for dir in $omap_dirs; do
      		find $dir -type f -name \*.[chS] | \
      			xargs sed -i "s/$old/$new/"
      	done
      	find drivers/ -type f -name \*omap*.[chS] | \
      		xargs sed -i "s/$old/$new/"
      	for file in $other_files; do
      		sed -i "s/$old/$new/" $file
      	done
      done
      
      for header in $(ls $mach_dir_old/*.h); do
      	git mv $header $plat_dir_new/
      done
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ce491cf8
  9. 20 10月, 2009 1 次提交
  10. 25 9月, 2009 1 次提交
  11. 04 9月, 2009 1 次提交
    • P
      OMAP2/3 board-*.c files: read bootloader configuration earlier · b3c6df3a
      Paul Walmsley 提交于
      Most board-*.c files read configuration data from the bootloader in
      their .init_machine() function.  This needs to happen earlier, at some
      point before omap2_init_common_hw() is called.  This is because a
      future patch will use the bootloader serial console port information
      to enable the UART clocks earlier, immediately after omap2_clk_init().
      This is in turn necessary since otherwise clock tree usecounts on
      clocks like dpll4_m2x2_ck will be bogus, which can cause the
      currently-active console UART clock to be disabled during boot.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b3c6df3a
  12. 29 8月, 2009 2 次提交
  13. 25 7月, 2009 2 次提交
    • J
      OMAP3: Setup MUX settings for SDRC CKE signals · 9fb97412
      Jean Pihet 提交于
      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: NJean Pihet <jpihet@mvista.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      9fb97412
    • J
      OMAP3 SDRC: add support for 2 SDRAM chip selects · 58cda884
      Jean Pihet 提交于
      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: NJean Pihet <jpihet@mvista.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      58cda884
  14. 29 5月, 2009 2 次提交
  15. 24 4月, 2009 1 次提交
    • P
      OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c files · f248076c
      Paul Walmsley 提交于
      Add a function omap2_gp_clockevent_set_gptimer() for board-*.c files
      to use in .init_irq functions to configure the system tick GPTIMER.
      Practical choices at this point are GPTIMER1 or GPTIMER12.  Both of
      these timers are in the WKUP powerdomain, and so are unaffected by
      chip power management.  GPTIMER1 can use sys_clk as a source, for
      applications where a high-resolution timer is more important than
      power management.  GPTIMER12 has the special property that it has the
      secure 32kHz oscillator as its source clock, which may be less prone
      to glitches than the off-chip 32kHz oscillator.  But on HS devices, it
      may not be available for Linux use.
      
      It appears that most boards are fine with GPTIMER1, but BeagleBoard
      should use GPTIMER12 when using a 32KiHz timer source, due to hardware bugs
      in revisions B4 and below.  Modify board-omap3beagle.c to use GPTIMER12.
      
      This patch originally used a Kbuild config option to select the GPTIMER,
      but was changed to allow this to be specified in board-*.c files, per
      Tony's request.
      
      Kalle Vallo <kalle.valo@nokia.com> found a bug in an earlier version of
      this patch - thanks Kalle.
      
      Tested on Beagle rev B4 ES2.1, with and without CONFIG_OMAP_32K_TIMER, and
      3430SDP.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Cc: Kalle Valo <kalle.valo@nokia.com>
      f248076c
  16. 24 3月, 2009 2 次提交
  17. 05 3月, 2009 1 次提交
  18. 09 2月, 2009 1 次提交
    • P
      [ARM] OMAP2 SDRC: add SDRAM timing parameter infrastructure · 87246b75
      Paul Walmsley 提交于
      For a given SDRAM clock rate, SDRAM chips require memory controllers
      to use a specific set of timing minimums and maximums to transfer data
      reliably.  These parameters can be different for different memory chips
      and can also potentially vary by board.
      
      This patch adds the infrastructure for board-*.c files to pass this
      timing data to the SDRAM controller init function.  The timing data is
      specified in an 'omap_sdrc_params' structure, in terms of SDRC
      controller register values.  An array of these structs, one per SDRC
      target clock rate, is passed by the board-*.c file to
      omap2_init_common_hw().
      
      This patch does not define the values for different memory chips, nor
      does it use the values for anything; those will come in subsequent patches.
      
      linux-omap source commit is bc84ecfc795c2d1c5cda8da4127cf972f488a696.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      87246b75
  19. 15 1月, 2009 1 次提交
  20. 11 12月, 2008 1 次提交
  21. 09 10月, 2008 1 次提交