1. 02 3月, 2011 3 次提交
    • K
      OMAP: adapt hsmmc to hwmod framework · 4621d5f8
      Kishore Kadiyala 提交于
      OMAP2420 platform consists of mmc block as in omap1 and not the
      hsmmc block as present in omap2430, omap3, omap4 platforms.
      Removing all base address macro defines except keeping one for OMAP2420 and
      adapting only hsmmc device registration and driver to hwmod framework.
      
      Changes involves:
      1) Remove controller reset in devices.c which is taken care of
         by hwmod framework.
      2) Using omap-device layer to register device and utilizing data from
         hwmod data file for base address, dma channel number, Irq_number,
         device attribute.
      3) Update the driver to use dev_attr to find whether controller
         supports dual volt cards
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Reviewed-by: NBalaji T K <balajitk@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      CC: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      4621d5f8
    • K
      OMAP: hwmod data: Add dev_attr and use in the host driver · 6ab8946f
      Kishore Kadiyala 提交于
      Add a device attribute to hwmod data of omap2430, omap3, omap4.
      Currently the device attribute holds information regarding dual volt MMC card
      support by the controller which will be later passed to the host driver via
      platform data.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Acked-by: Benoit Cousson<b-cousson@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      6ab8946f
    • A
      omap: mmc: split out init for 2420 · e08016d0
      Anand Gadiyar 提交于
      The MMC controller on the OMAP2420 is different from those
      on the OMAP2430, OMAP3 and OMAP4 families - all of the latter
      are identical. The one on the OMAP2420 is closer to that
      on OMAP1 chips.
      
      Currently, the n8x0 is the only OMAP2420 platform supported
      in mainline which registers the MMC controller. Upcoming
      changes to register the controllers using hwmod data are
      potentially invasive. To reduce the risk, separate out the
      2420 controller registration from the common init function
      and update its only user. Also seperating out mux settings
      for OMAP2420.
      Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
      Cc: Chris Ball <cjb@laptop.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e08016d0
  2. 01 3月, 2011 3 次提交
    • P
      OMAP2+: sdrc: fix compile break on OMAP4-only config on current omap-for-linus · d6b5d01b
      Paul Walmsley 提交于
      On non-OMAP2 and non-OMAP3 kernel configs, turn omap2_sdrc_init() into
      a no-op.  Otherwise, compilation breaks on an OMAP4-only config with
      the current omap-for-linus branch:
      
      arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_devices':
      ../mach-omap2/io.c:421: undefined reference to `omap2_sdrc_init'
      
      Thanks to Sergei Shtylyov <sshtylyov@mvista.com> for suggesting the use
      of a empty static inline function rather than a macro.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Sergei Shtylyov <sshtylyov@mvista.com>
      [tony@atomide.com: updated not to use __init for inline omap2_sdrc_init]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d6b5d01b
    • P
      OMAP2+: hwmod: add ability to setup individual hwmods · a2debdbd
      Paul Walmsley 提交于
      Add omap_hwmod_setup_one(), which is intended for use early in boot to
      selectively setup the hwmods needed for system clocksources and
      clockevents, and any other hwmod that is needed in early boot.
      omap_hwmod_setup_all() can then be called later in the boot process.
      The point is to minimize the amount of code that needs to be run
      early.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      a2debdbd
    • P
      OMAP2+: hwmod: rename some init functions · 550c8092
      Paul Walmsley 提交于
      Rename omap_hwmod_init() to omap_hwmod_register().  Rename
      omap_hwmod_late_init() to omap_hwmod_setup_all().  Also change all of
      the callers to reflect the new names.  While here, update some
      copyrights.
      
      Suggested by Tony Lindgren <tony@atomide.com>.
      
      N.B. The comment in mach-omap2/serial.c may no longer be correct, given
           recent changes in init order.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      550c8092
  3. 28 2月, 2011 1 次提交
  4. 23 2月, 2011 3 次提交
  5. 18 2月, 2011 12 次提交
  6. 17 2月, 2011 4 次提交
  7. 15 2月, 2011 3 次提交
  8. 10 2月, 2011 1 次提交
  9. 28 1月, 2011 3 次提交
  10. 20 1月, 2011 2 次提交
  11. 19 1月, 2011 1 次提交
    • P
      OMAP: counter_32k: init clocksource as part of machine timer init · d8328f3b
      Paul Walmsley 提交于
      After commit dc548fbb ("ARM: omap: convert
      sched_clock() to use new infrastructure"), OMAPs that use the 32KiHz
      "synchronization timer" as their clocksource crash during boot:
      
      [    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
      [    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [    0.000000] pgd = c0004000
      [    0.000000] [00000000] *pgd=00000000
      [    0.000000] Internal error: Oops: 80000005 [#1] SMP
      [    0.000000] last sysfs file:
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Tainted: G        W    (2.6.37-07734-g2467802 #7)
      [    0.000000] PC is at 0x0
      [    0.000000] LR is at sched_clock_poll+0x2c/0x3c
      [    0.000000] pc : [<00000000>]    lr : [<c0060b74>]    psr: 600001d3
      [    0.000000] sp : c058bfd0  ip : c058a000  fp : 00000000
      [    0.000000] r10: 00000000  r9 : 411fc092  r8 : 800330c8
      [    0.000000] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
      [    0.000000] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 00000000
      [    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      [    0.000000] Control: 10c53c7f  Table: 8000404a  DAC: 00000017
      
      This is due to the recent ARM init_sched_clock() changes and the late
      initialization of the counter_32k clock source.  More information here:
      
         http://marc.info/?l=linux-omap&m=129513468605208&w=2
      
      Fix by initializing the counter_32k clocksource during the machine timer
      initialization.
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: NThomas Weber <weber@corscience.de>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d8328f3b
  12. 10 1月, 2011 4 次提交