1. 20 8月, 2013 1 次提交
  2. 18 5月, 2013 1 次提交
  3. 09 4月, 2013 1 次提交
    • J
      i2c: s3c2410: Add SMBus emulation for block read · 85747311
      Jaemin Yoo 提交于
      SMBus read and write are supported by the emulation layer of i2c
      framework if the controller doesn't have SMBus features.
      
      I2C_M_RECV_LEN flag is used to let i2c drivers know rx length is not
      yet determined but will be read to the first byte in rx buffer.
      
      s3c2410 doesn't handle this flag. So only one byte is read from slave.
      There fore following two features are added to the driver code.
      
      1. skip rx length check if I2C_M_RECV_LEN is set and the length is 1.
      2. add actual bytes to the rx length after reading first bytes if
         I2C_M_RECV_LEN.
      
      I2C_M_RECV_LEN is only set for SMBus command. So this code does not
      affect legacy codes which only use i2c command for s3c2410.
      Signed-off-by: NJaemin Yoo <jmin.yoo@samsung.com>
      Tested-by: NPrasanna Kumar <prasanna.ps@samsung.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      85747311
  4. 24 3月, 2013 2 次提交
  5. 28 1月, 2013 5 次提交
  6. 25 1月, 2013 1 次提交
  7. 23 11月, 2012 1 次提交
  8. 19 11月, 2012 4 次提交
  9. 16 11月, 2012 7 次提交
    • D
      i2c: s3c2410: do not special case HDMIPHY stuck bus detection · 79f678ed
      Daniel Kurtz 提交于
      Commit "i2c-s3c2410: Add HDMIPHY quirk for S3C2440" added support for
      HDMIPHY with some special handling in s3c24xx_i2c_set_master:
      
      "due to unknown reason (probably HW bug in HDMIPHY and/or the controller)
      a transfer fails to finish. The controller hangs after sending the last
      byte, the workaround for this bug is resetting the controller after each
      transfer"
      
      The "unknown reason" was that the proper sequence for generating a STOP
      condition wasn't being followed as per the datasheet. Since this is fixed
      by "PATCH: i2c-s3c2410: do not generate STOP for QUIRK_HDMIPHY buses",
      remove the special handling.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      79f678ed
    • D
      i2c: s3c2410: use exponential back off while polling for bus idle · fe724bf9
      Daniel Kurtz 提交于
      Usually, the i2c controller has finished emitting the i2c STOP before the
      driver reaches the bus idle polling loop.  Optimize for this most common
      case by reading IICSTAT first and potentially skipping the loop.
      
      If the cpu is faster than the hardware, we wait for bus idle in a polling
      loop.  However, since the duration of one iteration of the loop is
      dependent on cpu freq, and this i2c IP is used on many different systems,
      use a time based loop timeout (5 ms).
      
      We would like very low latencies to detect bus idle for the normal
      'fast' case.  However, if a device is slow to release the bus for some
      reason, it could hold off the STOP generation for up to several
      milliseconds.  Rapidly polling for bus idle would seriously load the CPU
      while waiting for it to release the bus.  So, use a partial exponential
      backoff as a compromise between idle detection latency and cpu load.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      fe724bf9
    • D
      i2c: s3c2410: do not generate STOP for QUIRK_HDMIPHY · 0da2e776
      Daniel Kurtz 提交于
      The datasheet says that the STOP sequence should be:
       1) I2CSTAT.5 = 0	- Clear BUSY (or 'generate STOP')
       2) I2CCON.4 = 0	- Clear IRQPEND
       3) Wait until the stop condition takes effect.
       4*) I2CSTAT.4 = 0 	- Clear TXRXEN
      
      Where, step "4*" is only for buses with the "HDMIPHY" quirk.
      
      However, after much experimentation, it appears that:
       a) normal buses automatically clear BUSY and transition from
          Master->Slave when they complete generating a STOP condition.
          Therefore, step (3) can be done in doxfer() by polling I2CCON.4
          after starting the STOP generation here.
       b) HDMIPHY bus does neither, so there is no way to do step 3.
          There is no indication when this bus has finished generating STOP.
      
      In fact, we have found that as soon as the IRQPEND bit is cleared in
      step 2, the HDMIPHY bus generates the STOP condition, and then immediately
      starts transferring another data byte, even though the bus is supposedly
      stopped.  This is presumably because the bus is still in "Master" mode,
      and its BUSY bit is still set.
      
      To avoid these extra post-STOP transactions on HDMI phy devices, we just
      disable Serial Output on the bus (I2CSTAT.4 = 0) directly, instead of
      first generating a proper STOP condition.  This should float SDA & SCK
      terminating the transfer.  Subsequent transfers start with a proper START
      condition, and proceed normally.
      
      The HDMIPHY bus is an internal bus that always has exactly two devices,
      the host as Master and the HDMIPHY device as the slave. Skipping the STOP
      condition has been tested on this bus and works.
      
      Also, since we disable the bus directly from the isr, we can skip the bus
      idle polling loop at the end of doxfer().
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      0da2e776
    • D
      i2c: s3c2410: grab adapter lock while changing i2c clock · 9bcd04bf
      Daniel Kurtz 提交于
      We probably don't want to change I2C frequency while a transfer is in
      progress.  The current implementation grabs a spinlock, but that only
      protected the writes to IICCON when starting a message, it didn't protect
      against clock changes in the middle of a transaction.
      
      Note: The i2c-core already grabs the adapter lock before calling
      s3c24xx_i2c_doxfer(), which ensures that only one caller is issuing a
      xfer at a time. This means it is not necessary to disable interrupts
      (spin_lock_irqsave) when changing frequencies, since there won't be
      any i2c interrupts if there is no on-going xfer.
      
      Lastly, i2c_lock_adapter() may cause the cpufreq_transition to sleep if
      if a xfer is in progress, but this is ok since cpufreq notifiers are
      called in a kernel thread, and there are already cases where it could
      sleep, such as when using i2c to update the output of a voltage
      regulator.
      
      Note: the cpufreq part of this change has no functional affect on
      	exynos, where the i2c clock is independent of the cpufreq.
      	But, there is a slight perfomance boost since we no longer need to
      	lock/unlock an additional spinlock.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      9bcd04bf
    • T
      i2c: s3c2410: Add support for pinctrl · 2693ac69
      Tomasz Figa 提交于
      This patch adds support for pin configuration using pinctrl subsystem
      to the i2c-s3c2410 driver.
      Signed-off-by: NTomasz Figa <t.figa@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      2693ac69
    • M
      i2c: s3c2410: Convert to devm_request_and_ioremap() · a72ad456
      Mark Brown 提交于
      A small code saving and less error handling to worry about.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      a72ad456
    • M
      i2c: s3c2410: Refactor ifdefs for PM_SLEEP · 2935e0e0
      Mark Brown 提交于
      Use the PM_SLEEP ifdef for system suspend and resume. This is partly
      in preparation for adding runtime operations and partly because a user
      may in theory choose to enable runtime suspend but not system suspend.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      2935e0e0
  10. 06 10月, 2012 1 次提交
  11. 19 9月, 2012 1 次提交
    • A
      ARM: samsung: move platform_data definitions · 436d42c6
      Arnd Bergmann 提交于
      Platform data for device drivers should be defined in
      include/linux/platform_data/*.h, not in the architecture
      and platform specific directories.
      
      This moves such data out of the samsung include directories
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: "Wolfram Sang (embedded platforms)" <w.sang@pengutronix.de>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Bryan Wu <bryan.wu@canonical.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
      Cc: Chris Ball <cjb@laptop.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Sangbeom Kim <sbkim73@samsung.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Cc: linux-samsung-soc@vger.kernel.org
      436d42c6
  12. 13 7月, 2012 2 次提交
  13. 30 5月, 2012 1 次提交
  14. 12 5月, 2012 3 次提交
  15. 08 3月, 2012 2 次提交
  16. 18 12月, 2011 2 次提交
  17. 29 10月, 2011 3 次提交
  18. 28 6月, 2011 2 次提交