1. 23 2月, 2011 1 次提交
    • K
      i2c-omap: fix static suspend vs. runtime suspend · adf6e079
      Kevin Hilman 提交于
      When runtime PM is enabled, each OMAP i2c device is suspended after
      each i2c xfer.  However, there are two cases when the static suspend
      methods must be used to ensure the devices are suspended:
      
      1) runtime PM is disabled, either at compile time or dynamically
          via /sys/devices/.../power/control.
      2) an i2c client driver uses i2c during it's suspend callback, thus
         leaving the i2c driver active (NOTE: runtime suspend transitions are
         disabled during system suspend, so i2c activity during system
         suspend will runtime resume the device, but not runtime (re)suspend it.)
      
      Since the actual work to suspend the device is handled by the
      subsytem, call the bus methods to take care of it.
      
      NOTE: This takes care of a known suspend problem on OMAP3 where the
      TWL RTC driver does i2c xfers during its suspend path leaving the i2c
      driver in an active state (since runtime suspend transistions are
      disabled.)
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      adf6e079
  2. 04 1月, 2011 1 次提交
  3. 21 12月, 2010 1 次提交
  4. 10 11月, 2010 1 次提交
  5. 22 9月, 2010 1 次提交
  6. 20 5月, 2010 6 次提交
  7. 20 4月, 2010 1 次提交
    • M
      i2c-omap: fix OOPS in omap_i2c_unidle() during probe · 7c6bd201
      Mika Westerberg 提交于
      Commit d84d3ea3 added register shift to allow
      also 16-bit register access. However, omap_i2c_unidle() is called before these
      are set which causes the following OOPS:
      
          Unhandled fault: alignment exception (0x801) at 0xfa070009
          Internal error: : 801 [#1]
          last sysfs file:
          Modules linked in:
          CPU: 0    Not tainted  (2.6.34-rc2-00052-gae6be51e #3)
          PC is at omap_i2c_unidle+0x44/0x138
          LR is at trace_hardirqs_on_caller+0x158/0x18c
          pc : [<c01cd2c4>]    lr : [<c00743f8>]    psr: 20000013
          sp : cfc2bf10  ip : 00000009  fp : 00000000
          r10: 00000000  r9 : 00000000  r8 : c0378560
          r7 : c0378b88  r6 : c0378558  r5 : cfcadc00  r4 : cfcadc00
          r3 : 00000009  r2 : fa070000  r1 : 00000000  r0 : 00000000
          Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
          Control: 10c5387f  Table: 80004019  DAC: 00000017
          Process swapper (pid: 1, stack limit = 0xcfc2a2e8)
          Stack: (0xcfc2bf10 to 0xcfc2c000)
          bf00:                                     c0372cf8 c027225c 00000000 c0a69678
          bf20: cfc3e508 c0500898 c0378560 c0378560 c0500898 cfcac8c0 c04fc280 c017d4f4
          bf40: c0378560 c017c63c c0378560 c0378594 c0500898 cfcac8c0 c04fc280 c017c754
          bf60: 00000000 c017c6f4 c0500898 c017beac cfc16a5c cfc3fd94 c0023448 c0500898
          bf80: c0500898 c017b7d4 c032dc7f 00000093 cfc28d40 c0023448 00000000 c0500898
          bfa0: 00000000 00000000 00000000 c017ca48 c0023448 00000000 c001d274 00000000
          bfc0: 00000000 c002b344 00000031 00000000 00000000 00000192 00000000 c0023448
          bfe0: 00000000 00000000 00000000 c0008578 00000000 c002c304 ffdfffff ffffffff
          [<c01cd2c4>] (omap_i2c_unidle+0x44/0x138) from [<c027225c>] (omap_i2c_probe+0x1a4/0x398)
          [<c027225c>] (omap_i2c_probe+0x1a4/0x398) from [<c017d4f4>] (platform_drv_probe+0x18/0x1c)
          [<c017d4f4>] (platform_drv_probe+0x18/0x1c) from [<c017c63c>] (driver_probe_device+0xc0/0x178)
          [<c017c63c>] (driver_probe_device+0xc0/0x178) from [<c017c754>] (__driver_attach+0x60/0x84)
          [<c017c754>] (__driver_attach+0x60/0x84) from [<c017beac>] (bus_for_each_dev+0x44/0x74)
          [<c017beac>] (bus_for_each_dev+0x44/0x74) from [<c017b7d4>] (bus_add_driver+0x9c/0x218)
          [<c017b7d4>] (bus_add_driver+0x9c/0x218) from [<c017ca48>] (driver_register+0xa8/0x130)
          [<c017ca48>] (driver_register+0xa8/0x130) from [<c002b344>] (do_one_initcall+0x5c/0x1b8)
          [<c002b344>] (do_one_initcall+0x5c/0x1b8) from [<c0008578>] (kernel_init+0x90/0x144)
          [<c0008578>] (kernel_init+0x90/0x144) from [<c002c304>] (kernel_thread_exit+0x0/0x8)
          Code: e5942004 e3a0c009 e1a0331c e3a01000 (e18210b3)
          ---[ end trace 1b75b31a2719ed1c ]---
      
      This patch moves register shift setting before any register accesses are done.
      Signed-off-by: NMika Westerberg <ext-mika.1.westerberg@nokia.com>
      Cc: Cory Maccarrone <darkstar6262@gmail.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      7c6bd201
  8. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  9. 08 3月, 2010 2 次提交
    • U
      i2c: move i2c_omap's probe function to .devinit.text · 1139aea9
      Uwe Kleine-König 提交于
      A pointer to omap_i2c_probe is passed to the core via
      platform_driver_register and so the function must not disappear when the
      .init sections are discarded.  Otherwise (if also having HOTPLUG=y)
      unbinding and binding a device to the driver via sysfs will result in an
      oops as does a device being registered late.
      
      An alternative to this patch is using platform_driver_probe instead of
      platform_driver_register plus removing the pointer to the probe function
      from the struct platform_driver.
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Cc: Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: chandra shekhar <x0044955@ti.com>
      Cc: Jason P Marini <jason.marini@gmail.com>
      Cc: Syed Mohammed Khasim  <x0khasim@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@nokia.com>
      Cc: Juha Yrjola <juha.yrjola@solidboot.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1139aea9
    • C
      i2c: omap: Add support for 16-bit registers · d84d3ea3
      Cory Maccarrone 提交于
      The current i2c-omap driver is set up for 32-bit registers, which
      corresponds to most OMAP devices.  However, OMAP730/850 based
      devices use a 16-bit register size.
      
      This change modifies the driver to perform a runtime CPU type check
      to determine the register sizes, and uses a bit shift of either 1
      or 2 bits to compute the proper register sizes for all registers.
      Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      d84d3ea3
  10. 24 12月, 2009 2 次提交
    • M
      i2c-omap: OMAP3: Fix I2C lockup during timeout/error cases · 57eb81b1
      Manjunatha GK 提交于
      Current OMAP3 I2C driver code does not follow the correct sequence for soft
      reset. Due to this, lock up issues are reported during timeout/error cases.
      
      This patch fixes above issue by disabling I2C controller as per OMAP3430 TRM
      for soft reset. As per TRM, I2C controller needs to be disabled as a first
      step during soft reset.
      
      Here is correct soft reset sequence:
      a. Ensure that the module is disabled
      (clear the I2Ci.I2C_CON[15] I2C_EN bit to 0).
      b. Set the I2Ci.I2C_SYSC[1] SRST bit to 1.
      c. Enable the module by setting I2Ci.I2C_CON[15] I2C_EN bit to 1.
      d. Check the I2Ci.I2C_SYSS[0] RDONE bit until it is set to 1 to
      indicate the software reset is complete.
      
      Tested on Zoom2, Zoom3, 3430SDP and 3630SDP
      Signed-off-by: NManjunatha GK <manjugk@ti.com>
      Signed-off-by: George, Harith<harith@ti.com>
      Acked-by: Varadarajan, Charu Latha<charu@ti.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      57eb81b1
    • C
      i2c-omap: Don't write IE state in unidle if 0 · 07ac31f6
      Cory Maccarrone 提交于
      Commit ef871432... (i2c-omap: OMAP3: PM: (re)init for every transfer
      to support off-mode) introduced a change which make the dev->iestate
      contents be written to the OMAP_I2C_IE_REG every time omap_i2c_unidle
      is called.  Previously, the state was only written if it wasn't equal
      to zero.
      
      In omap_i2c_probe, omap_i2c_unidle() is called prior to omap_i2c_init(),
      in which case dev->iestate has not yet been initialized and will be set
      to zero.  Having this value written to the registers causes deadlock
      while booting.
      
      As such, this change restores the original functionality.
      Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      07ac31f6
  11. 09 12月, 2009 1 次提交
    • R
      i2c-omap: OMAP3: PM: (re)init for every transfer to support off-mode · ef871432
      Rajendra Nayak 提交于
      Because of OMAP off-mode, powerdomain can go off when I2C is idle.
      Save enough state, and do a re-init for each transfer.
      
      Additional save/restore state added by Jagadeesh Bhaskar Pakaravoor
      (SYSC_REG) and Aaro Koskinen (wakeup sources.)
      
      Also, The OMAP3430 TRM states:
      
      "During active mode (I2Ci.I2C_CON[15] I2C_EN bit is set to 1), make no
      changes to the I2Ci.I2C_SCLL and I2Ci.I2C_SCLH registers.  Changes may
      result in unpredictable behavior."
      
      Hence, the I2C_EN bit should be clearer when modifying these
      registers. Please note that clearing the entire I2C_CON register to
      disable the I2C module is safe, because the I2C_CON register is
      re-configured for each transfer.
      Signed-off-by: NJouni Hogander <jouni.hogander@nokia.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Cc: Jagadeesh Bhaskar Pakaravoor <j-pakaravoor@ti.com>
      Cc: Aaro Koskinen <aaro.koskinen@nokia.com>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Hu Tao <taohu@motorola.com>
      Cc: Xiaolong Chen <A21785@motorola.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      ef871432
  12. 21 8月, 2009 3 次提交
  13. 30 7月, 2009 4 次提交
  14. 15 7月, 2009 1 次提交
  15. 22 6月, 2009 1 次提交
    • T
      i2c-omap: Fix build breaking typo cpu_is_omap_2430 · ff0f2426
      Tony Lindgren 提交于
      Hi Ben,
      
      Can you please queue this fix?
      
      Thanks,
      
      Tony
      
      >From ffe2b2cdf6283770b70a197e3748c6b40a1006be Mon Sep 17 00:00:00 2001
      From: Tony Lindgren <tony@atomide.com>
      Date: Wed, 17 Jun 2009 13:14:23 +0300
      Subject: [PATCH] i2c-omap: Fix build breaking typo in cpu_is_omap_2430
      
      Commit 84bf2c86 introduced a typo, it should be cpu_is_omap2430
      instead. The typo was probably caused by a mismerge.
      
      Without this patch all omaps fail to build with:
      error: implicit declaration of function 'cpu_is_omap_2430'
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      ff0f2426
  16. 17 6月, 2009 1 次提交
    • L
      i2c: Use resource_size macro · c6ffddea
      Linus Walleij 提交于
      This replace all instances in the i2c busses tree of
      res->end - res->start + 1 with the handy macro resource_size(res)
      from ioport.h (coming in from platform_device.h).
      
      This was created with a simple
      sed -i -e 's/\([a-z]*\)->end *- *[a-z]*->start *+ *1/resource_size(\1)/g'
      
      Then manually replacing the PXA redefiniton of the same kind
      of macro manually. Recompiled some ARM defconfigs I could find to
      make a rough test so it shouldn't break anything, though I
      couldn't see exactly which configs you need for all the drivers.
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      c6ffddea
  17. 13 6月, 2009 2 次提交
  18. 09 2月, 2009 3 次提交
  19. 17 12月, 2008 1 次提交
  20. 22 11月, 2008 6 次提交