1. 29 3月, 2011 1 次提交
  2. 22 3月, 2011 1 次提交
  3. 19 3月, 2011 1 次提交
    • B
      ARM: OMAP2+: Fix warnings for GPMC interrupt · 77aded2f
      Balaji T K 提交于
      Commit db97eb7d
      (omap: gpmc: enable irq mode in gpmc) enabled interrupts for
      GPMC (General Purpose Memory Controller). However, looks like
      this patch only works on omap3. Fix the issues to avoid warnings
      on omap4 during the boot.
      
      GPMC: number of chip select is 8, CS0 to CS7. One less IRQ
      allocated throws below warning at boot:
      
      [    0.429290] Trying to install type control for IRQ409
      [    0.429290] Trying to set irq flags for IRQ409
      
      Resolve following warning messages in boot when irq chip is not set:
      
      [    0.429229] Trying to install interrupt handler for IRQ402
      [    0.429229] Trying to install interrupt handler for IRQ403
      [    0.429229] Trying to install interrupt handler for IRQ404
      [    0.429260] Trying to install interrupt handler for IRQ405
      [    0.429260] Trying to install interrupt handler for IRQ406
      [    0.429260] Trying to install interrupt handler for IRQ407
      [    0.429290] Trying to install interrupt handler for IRQ408
      
      Resolve following warning in OMAP4:
      [    0.429290] gpmc: irq-20 could not claim: err -22
      Signed-off-by: NBalaji T K <balajitk@ti.com>
      [tony@atomide.com: combined patches into one, updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      77aded2f
  4. 16 3月, 2011 1 次提交
  5. 15 3月, 2011 3 次提交
  6. 12 3月, 2011 1 次提交
  7. 11 3月, 2011 5 次提交
  8. 10 3月, 2011 6 次提交
  9. 09 3月, 2011 1 次提交
  10. 08 3月, 2011 4 次提交
  11. 03 3月, 2011 1 次提交
    • M
      arm: omap: fix section mismatch warning · 790ab7e9
      Ming Lei 提交于
      WARNING: arch/arm/plat-omap/built-in.o(.data+0x6d4): Section mismatch in reference from the variable omap_driver to the function .init.text:omap_cpu_init()
      The variable omap_driver references
      the function __init omap_cpu_init()
      If the reference is valid then annotate the
      variable with __init* or __refdata (see linux/init.h) or name the variable:
      *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      790ab7e9
  12. 02 3月, 2011 4 次提交
    • R
      OMAP2+: omap_device/clock: Do not expect an entry in clkdev for opt_clks · da0653fe
      Rajendra Nayak 提交于
      The _add_optional_clock_alias function expects an entry
      already existing in the clkdev table in the form of
      <dev-id=NULL, con-id=role> which might not be the case
      always.
      
      Instead, just check if an entry already exists in clkdev
      in the <dev-id=dev_name, con-id=role> form, else go ahead
      and add one.
      
      Remove any assumption of an entry already existing in clkdev
      table in any form.
      
      Since this means, adding a new entry in clkdev if it does
      not already exist, and not really adding an 'alias',
      also rename the function name
      (s/_add_optional_clock_alias/_add_optional_clock_clkdev)
      to reflect this.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Reported-by: NSumit Semwal <sumit.semwal@ti.com>
      Cc: Sumit Semwal <sumit.semwal@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Partha Basak <p-basak2@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      da0653fe
    • 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
  13. 01 3月, 2011 8 次提交
  14. 28 2月, 2011 1 次提交
  15. 26 2月, 2011 2 次提交
    • R
      OMAP4: DPLL: Add dpll api to control GATE_CTRL · 97f67898
      Rajendra Nayak 提交于
      On OMAP4, the dpll post divider outputs (MX outputs)
      along with clockout_x2 output provide a way to allow/deny
      hardware level autogating.
      Allowing autoidle would mean that the hw would autogate
      this clock when there is no dependency for it.
      Denying idle would mean that this clock output will be
      forced to stay enabled.
      
      Add dpll api's to read/allow/deny idle control
      for these dpll mx postdividers.
      
      NOTE: The gatectrl bit set to 0 allows gatectrl,
      and the bit set to 1 denies gatectrl.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: moved OMAP4-specific DPLL control code to
       mach-omap2/dpll44xx.c; added some documentation for CLOCK_CLKOUTX2]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      97f67898
    • P
      OMAP2+: clock: autoidle as many clocks as possible if CONFIG_OMAP_RESET_CLOCKS · b80b956d
      Paul Walmsley 提交于
      Attempt to enable autoidle for as many clocks as possible in the
      OMAP2+-common CONFIG_OMAP_RESET_CLOCKS code.  Currently, this only
      enables DPLL autoidle for OMAP3/4 DPLLs; but future patches will
      enable autoidle for other clocks and the OMAP2 DPLL/APLLs.
      
      In the long run, we should probably get rid of
      CONFIG_OMAP_RESET_CLOCKS, and unconditionally run the code that it
      selects.  Otherwise, the state of the clock tree won't match the
      hardware state - this could result in clocks being enabled or disabled
      unpredictably.
      
      Based on a patch by Rajendra Nayak <rnayak@ti.com> that did this in
      the pm34xx.c/pm44xx.c code.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      b80b956d