1. 01 10月, 2011 1 次提交
  2. 16 9月, 2011 1 次提交
    • K
      OMAP: omap_device: when building return platform_device instead of omap_device · 3528c58e
      Kevin Hilman 提交于
      All of the device init and device driver interaction with omap_device
      is done using platform_device pointers.  To make this more explicit,
      have omap_device return a platform_device pointer instead of an
      omap_device pointer.
      
      All current users of the omap_device pointer were only using it to get
      at the platform_device pointer or struct device pointer, so fixing all
      of the users was trivial.
      
      This also makes it more difficult for device init code to directly
      access members of struct omap_device, and allows for easier changing
      of omap_device internals.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      3528c58e
  3. 04 7月, 2011 1 次提交
  4. 01 6月, 2011 2 次提交
  5. 31 3月, 2011 1 次提交
  6. 02 3月, 2011 3 次提交
  7. 23 2月, 2011 1 次提交
  8. 09 10月, 2010 1 次提交
    • P
      OMAP: control: move plat-omap/control.h to mach-omap2/control.h · 4814ced5
      Paul Walmsley 提交于
      Only OMAP2+ platforms have the System Control Module (SCM) IP block.
      In the past, we've kept the SCM header file in plat-omap.  This has
      led to abuse - device drivers including it; includes being added that
      create implicit dependencies on OMAP2+ builds; etc.
      
      In response, move the SCM headers into mach-omap2/.
      
      As part of this, remove the direct SCM access from the OMAP UDC
      driver.  It was clearly broken.  The UDC code needs an indepth review for
      use on OMAP2+ chips.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Cory Maccarrone <darkstar6262@gmail.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      4814ced5
  9. 02 10月, 2010 2 次提交
  10. 28 9月, 2010 2 次提交
  11. 11 8月, 2010 1 次提交
  12. 21 5月, 2010 2 次提交
  13. 16 2月, 2010 7 次提交
  14. 11 2月, 2010 1 次提交
  15. 23 11月, 2009 2 次提交
  16. 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
  17. 23 9月, 2009 4 次提交
  18. 10 8月, 2009 1 次提交
  19. 23 6月, 2009 1 次提交
  20. 29 5月, 2009 1 次提交
    • D
      ARM: OMAP3: mmc-twl4030 uses regulator framework · b583f26d
      David Brownell 提交于
      Decouple the HSMMC glue from the twl4030 as the only
      regulator provider, using the regulator framework instead.
      This makes the glue's "mmc-twl4030" name become a complete
      misnomer ... this code could probably all migrate into the
      HSMMC driver now.
      
      Tested on 3430SDP (SD and low-voltage MMC) and Beagle (SD),
      plus some other boards (including Overo) after they were
      converted to set up MMC regulators properly.
      
      Eventually all boards should just associate a regulator with
      each MMC controller they use.  In some cases (Overo MMC2 and
      Pandora MMC3, at least) that would be a fixed-voltage regulator
      with no real software control.  As a temporary hack (pending
      regulator-next updates to make the "fixed.c" regulator become
      usable) there's a new ocr_mask field for those boards.
      
      Patch updated with a fix for disabling vcc_aux by
      Adrian Hunter <adrian.hunter@nokia.com>
      
      Cc: Pierre Ossman <drzeus-list@drzeus.cx>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b583f26d
  21. 25 3月, 2009 1 次提交
  22. 24 3月, 2009 3 次提交