Skip to content
Snippets Groups Projects
  1. May 14, 2014
    • Du, Wenkai's avatar
      i2c: designware: Mask all interrupts during i2c controller enable · 47bb27e7
      Du, Wenkai authored
      
      There have been "i2c_designware 80860F41:00: controller timed out" errors
      on a number of Baytrail platforms. The issue is caused by incorrect value in
      Interrupt Mask Register (DW_IC_INTR_MASK)  when i2c core is being enabled.
      This causes call to __i2c_dw_enable() to immediately start the transfer which
      leads to timeout. There are 3 failure modes observed:
      
      1. Failure in S0 to S3 resume path
      
      The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start
      the first transaction after resuming from system sleep, TX_EMPTY interrupt
      is already unmasked because of the hardware default.
      
      2. Failure in normal operational path
      
      This failure happens rarely and is hard to reproduce. Debug trace showed that
      DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant
      TX_EMPTY was unmasked.
      
      3. Failure in S3 to S0 suspend path
      
      This failure also happens rarely and is hard to reproduce. Adding debug trace
      that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR
      call trace we could conclude TX_EMPTY was unmasked when problem occurred.
      
      The patch masks all interrupts before the controller is enabled to resolve the
      faulty DW_IC_INTR_MASK conditions.
      
      Signed-off-by: default avatarWenkai Du <wenkai.du@intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      [wsa: improved the comment and removed typo in commit msg]
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      47bb27e7
  2. Mar 09, 2014
  3. Jan 13, 2014
  4. Nov 15, 2013
  5. Sep 27, 2013
  6. Aug 28, 2013
    • Mika Westerberg's avatar
      i2c: designware: make HCNT/LCNT values configurable · defc0b2f
      Mika Westerberg authored
      
      The DesignWare I2C controller has high count (HCNT) and low count (LCNT)
      registers for each of the I2C speed modes (standard and fast). These
      registers are programmed based on the input clock speed in the driver.
      
      The current code calculates these values based on the input clock speed and
      tries hard to meet the I2C bus timing requirements. This could result
      non-optimal values with regarding to the bus speed. For example on Intel
      BayTrail we get bus speed of 315.41kHz which is ~20% slower than we would
      expect (400kHz) in fast mode (even though the timing requirements are met).
      
      This patch makes it possible for the platform code to pass more optimal
      HCNT/LCNT values to the core driver if they are known beforehand. If these
      are not set we use the calculated and more conservative values.
      
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarShinya Kuribayashi <skuribay@pobox.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      defc0b2f
  7. Aug 07, 2013
  8. Jun 26, 2013
  9. Jun 15, 2013
    • Christian Ruppert's avatar
      i2c: designware: fix race between subsequent xfers · 38d7fade
      Christian Ruppert authored
      
      The designware block is not always properly disabled in the case of
      transfer errors. Interrupts from aborted transfers might be handled
      after the data structures for the following transfer are initialised but
      before the hardware is set up. This can corrupt the data structures to
      the point that the system is stuck in an infinite interrupt loop (where
      FIFOs are never emptied because dev->msg_read_idx == dev->msgs_num).
      
      This patch cleanly disables the designware-i2c hardware at the end of
      every transfer, be it successful or not.
      
      Signed-off-by: default avatarChristian Ruppert <christian.ruppert@abilis.com>
      [wsa: extended the comment]
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      38d7fade
  10. Jun 12, 2013
  11. May 17, 2013
    • Mika Westerberg's avatar
      i2c: designware: always clear interrupts before enabling them · 2a2d95e9
      Mika Westerberg authored
      
      If the I2C bus is put to a low power state by an ACPI method it might pull
      the SDA line low (as its power is removed). Once the bus is put to full
      power state again, the SDA line is pulled back to high. This transition
      looks like a STOP condition from the controller point-of-view which sets
      STOP detected bit in its status register causing the driver to fail
      subsequent transfers.
      
      Fix this by always clearing all interrupts before we start a transfer.
      
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      2a2d95e9
    • Josef Ahmad's avatar
      i2c: designware: fix RX FIFO overrun · e6f34cea
      Josef Ahmad authored
      
      i2c_dw_xfer_msg() pushes a number of bytes to transmit/receive
      to/from the bus into the TX FIFO.
      For master-rx transactions, the maximum amount of data that can be
      received is calculated depending solely on TX and RX FIFO load.
      
      This is racy - TX FIFO may contain master-rx data yet to be
      processed, which will eventually land into the RX FIFO. This
      data is not taken into account and the function may request more
      data than the controller is actually capable of storing.
      
      This patch ensures the driver takes into account the outstanding
      master-rx data in TX FIFO to prevent RX FIFO overrun.
      
      Signed-off-by: default avatarJosef Ahmad <josef.ahmad@linux.intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      e6f34cea
  12. Apr 15, 2013
  13. Jan 28, 2013
  14. Jan 22, 2013
  15. Oct 05, 2012
  16. Sep 10, 2012
    • Axel Lin's avatar
      i2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y · e68bb91b
      Axel Lin authored
      
      This patch adds config I2C_DESIGNWARE_CORE in Kconfig, and let
      I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI select I2C_DESIGNWARE_CORE.
      
      Because both I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI can be built as
      built-in or module, we also need to export the functions in i2c-designware-core.
      
      This fixes below build error when CONFIG_I2C_DESIGNWARE_PLATFORM=y &&
      CONFIG_I2C_DESIGNWARE_PCI=y:
      
        LD      drivers/i2c/busses/built-in.o
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_clear_int':
      i2c-designware-core.c:(.text+0xa10): multiple definition of `i2c_dw_clear_int'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x928): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_init':
      i2c-designware-core.c:(.text+0x178): multiple definition of `i2c_dw_init'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x90): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `dw_readl':
      i2c-designware-core.c:(.text+0xe8): multiple definition of `dw_readl'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x0): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_isr':
      i2c-designware-core.c:(.text+0x724): multiple definition of `i2c_dw_isr'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x63c): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer':
      i2c-designware-core.c:(.text+0x4b0): multiple definition of `i2c_dw_xfer'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c8): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_is_enabled':
      i2c-designware-core.c:(.text+0x9d4): multiple definition of `i2c_dw_is_enabled'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8ec): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `dw_writel':
      i2c-designware-core.c:(.text+0x124): multiple definition of `dw_writel'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer_msg':
      i2c-designware-core.c:(.text+0x2e8): multiple definition of `i2c_dw_xfer_msg'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x200): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_enable':
      i2c-designware-core.c:(.text+0x9c8): multiple definition of `i2c_dw_enable'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8e0): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_read_comp_param':
      i2c-designware-core.c:(.text+0xa24): multiple definition of `i2c_dw_read_comp_param'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x93c): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable':
      i2c-designware-core.c:(.text+0x9dc): multiple definition of `i2c_dw_disable'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8f4): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_func':
      i2c-designware-core.c:(.text+0x710): multiple definition of `i2c_dw_func'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x628): first defined here
      drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable_int':
      i2c-designware-core.c:(.text+0xa18): multiple definition of `i2c_dw_disable_int'
      drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x930): first defined here
      make[3]: *** [drivers/i2c/busses/built-in.o] Error 1
      make[2]: *** [drivers/i2c/busses] Error 2
      make[1]: *** [drivers/i2c] Error 2
      make: *** [drivers] Error 2
      
      Signed-off-by: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Tested-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: stable@vger.kernel.org [3.2+]
      e68bb91b
  17. May 12, 2012
  18. Oct 29, 2011
  19. Sep 15, 2011
  20. Mar 31, 2011
  21. Mar 30, 2010
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      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: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  22. Mar 06, 2010
  23. Dec 09, 2009
Loading