1. 10 5月, 2012 2 次提交
  2. 09 5月, 2012 2 次提交
  3. 18 4月, 2012 1 次提交
    • P
      ARM: OMAP2+: clean up some cppcheck warnings · eeb3711b
      Paul Walmsley 提交于
      Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:
      
          [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero.
          [arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247
          [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used
          [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used
          [arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used
          [arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux
          [arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux
          [arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used
          [arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57
          [arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used
          [arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else.
          [arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used
          [arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used
          [arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used
          [arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354
          [arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used
          [arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used
          [arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used
          [arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used
          [arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used
      
      Some of them are pretty good catches, such as gpio.c:56 and
      usb-tusb6010.c:129.
      
      Thanks to Jarkko Nikula for some comments on the sscanf() warnings.
      It seems that the kernel sscanf() ignores the field width anyway for the
      %d format, so those changes have been dropped from this second version.
      
      Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing
      out that a variable was unnecessarily marked static in the
      board-omap3evm.c change.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Charulatha Varadarajan <charu@ti.com>
      Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com>
      Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
      Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c
      eeb3711b
  4. 17 3月, 2012 1 次提交
  5. 12 3月, 2012 2 次提交
  6. 25 2月, 2012 2 次提交
  7. 24 2月, 2012 1 次提交
    • T
      ARM: OMAP2+: Fix OMAP_HDQ_BASE build error · e3a98fe1
      Tony Lindgren 提交于
      If CONFIG_SOC_OMAP3430 is not set and CONFIG_HDQ_MASTER_OMAP
      is selected for w1 driver we get the following error:
      
      arch/arm/mach-omap2/devices.c:662:13: error:
      'OMAP_HDQ_BASE' undeclared here (not in a function)
      
      Looks like OMAP_HDQ_BASE is valid for all omaps except
      2420, so we can remove the ifdef and not register
      the device on 2420.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e3a98fe1
  8. 27 1月, 2012 1 次提交
    • J
      ARM: OMAP2+: arch/arm/mach-omap2/devices.c: introduce missing kfree · e0feca89
      Julia Lawall 提交于
      pdata needs to be freed before leaving the function in an error case.
      
      A simplified version of the semantic match that finds the problem is as
      follows: (http://coccinelle.lip6.fr)
      
      // <smpl>
      @r exists@
      local idexpression x;
      statement S;
      identifier f1;
      position p1,p2;
      expression *ptr != NULL;
      @@
      
      x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
      ...
      if (x == NULL) S
      <... when != x
           when != if (...) { <+...x...+> }
      x->f1
      ...>
      (
       return \(0\|<+...x...+>\|ptr\);
      |
       return@p2 ...;
      )
      
      @script:python@
      p1 << r.p1;
      p2 << r.p2;
      @@
      
      print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e0feca89
  9. 16 1月, 2012 1 次提交
  10. 14 12月, 2011 1 次提交
  11. 05 12月, 2011 1 次提交
  12. 05 11月, 2011 1 次提交
    • P
      ARM: OMAP2+: devices: Fixes for McPDM · 927dbbb2
      Peter Ujfalusi 提交于
      Commit f718e2c0 (ARM: OMAP2+: devices:
      Remove all omap_device_pm_latency structures) removed these structures.
      Commit 3528c58e (OMAP: omap_device:
      when building return platform_device instead of omap_device) now
      returns platform_device instead of omap_device.
      
      Fix up the omap-mcpdm init function since this part comes via sound
      tree, and there has been changes regarding to hwmod/omap_device_build.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      CC: Benoit Cousson <b-cousson@ti.com>
      CC: Kevin Hilman <khilman@ti.com>
      [tony@atomide.com: updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      927dbbb2
  13. 05 10月, 2011 2 次提交
  14. 22 9月, 2011 1 次提交
  15. 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
  16. 08 8月, 2011 1 次提交
  17. 05 7月, 2011 1 次提交
  18. 01 6月, 2011 1 次提交
  19. 31 3月, 2011 1 次提交
  20. 22 3月, 2011 4 次提交
  21. 19 3月, 2011 1 次提交
  22. 09 3月, 2011 2 次提交
  23. 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: hsmmc: Move mux configuration to hsmmc.c · d8d0a61c
      Kishore Kadiyala 提交于
      Moving the definition of mux setting API from devices.c to hsmmc.c
      and renaming it from "omap2_mmc_mux" to "omap_hsmmc_mux".
      Also calling "omap_hsmmc_mux" from omap2_hsmmc_init.
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Cc: Chris Ball <cjb@laptop.org
      Cc: Tony Lindgren <tony@atomide.com
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d8d0a61c
    • 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
  24. 25 2月, 2011 1 次提交
  25. 18 2月, 2011 2 次提交
  26. 28 1月, 2011 1 次提交
  27. 07 1月, 2011 1 次提交
    • N
      omap2+: wdt: trivial sparse fixes · a9b365bd
      Nishanth Menon 提交于
      omap2_wd_timer_disable is declared in wdtimer.h and used by hwmod
      function pointers for usage, the header inclusion is necessary
      to ensure that the prototype and function remains consistent.
      omap_wdt_latency is passed as a pointer and does not need global scope
      
      Fixes sparse warnings:
      arch/arm/mach-omap2/devices.c:981:31: warning: symbol 'omap_wdt_latency' was not declared. Should it be static?
      arch/arm/mach-omap2/wd_timer.c:27:5: warning: symbol 'omap2_wd_timer_disable' was not declared. Should it be static?
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a9b365bd
  28. 22 12月, 2010 1 次提交
    • P
      OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism · ff2516fb
      Paul Walmsley 提交于
      The OMAP watchdog timer IP blocks require a specific set of register
      writes to occur before they will be disabled[1], even if the device
      clocks appear to be disabled in the CM_*CLKEN registers.  In the MPU
      watchdog case, failure to execute this reset sequence will eventually
      cause the watchdog to reset the OMAP unexpectedly.
      
      Previously, the code to disable this watchdog was manually called from
      mach-omap2/devices.c during device initialization.  This causes the
      watchdog to be unconditionally disabled for a portion of kernel
      initialization.  This should be controllable by the board-*.c files,
      since some system integrators will want full watchdog coverage of
      kernel initialization.  Also, the watchdog disable code was not
      connected to the hwmod shutdown code.  This means that calling
      omap_hwmod_shutdown() will not, in fact, disable the watchdog, and the
      goal of omap_hwmod_shutdown() is to be able to shutdown any on-chip
      OMAP device.
      
      To resolve the latter problem, populate the pre_shutdown pointer in
      the watchdog timer hwmod classes with a function that executes the
      watchdog shutdown sequence.  This allows the hwmod code to fully
      disable the watchdog.
      
      Then, to allow some board files to support watchdog coverage
      throughout kernel initialization, add common code to mach-omap2/io.c
      to cause the MPU watchdog to be disabled on boot unless a board file
      specifically requests it to remain enabled.  Board files can do this
      by changing the watchdog timer hwmod's postsetup state between the
      omap2_init_common_infrastructure() and omap2_init_common_devices()
      function calls.
      
      1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. ZH
         [SWPU222H], Section 16.4.3.6, "Start/Stop Sequence for WDTs (Using
         WDTi.WSPR Register)"
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Charulatha Varadarajan <charu@ti.com>
      ff2516fb