Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 1月, 2013 3 次提交
  3. 21 1月, 2013 1 次提交
    • M
      i2c: mxs: Fix misuse init_completion · 85de7fac
      由 Marek Vasut 提交于 
      The init_completion() call does reinit not only the variable carrying
the flag that the completion finished, but also initialized the
waitqueue associated with the completion. On the contrary, the
INIT_COMPLETION() call only reinits the flag.

In case there was anything still stuck in the waitqueue, subsequent call
to init_completion() would be able to create possible race condition. This
patch uses the proper function and moves init_completion() into .probe() call
of the driver, to be issued only once.

Note that such scenario is impossible, since two threads can never enter the
mxs_i2c_xfer_msg(), since whole this section is protected by mutex in I2C core.
This by no means allows this issue to exit though.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      85de7fac
  5. 23 12月, 2012 1 次提交
  7. 17 12月, 2012 3 次提交
  9. 28 11月, 2012 1 次提交
  11. 25 11月, 2012 3 次提交
  13. 23 11月, 2012 5 次提交
  15. 20 11月, 2012 1 次提交
  17. 19 11月, 2012 5 次提交
  19. 17 11月, 2012 2 次提交
    • A
      i2c: ocores: Add support for the GRLIB port of the controller and use function... · a000b8c1
      由 Andreas Larsson 提交于 
      i2c: ocores: Add support for the GRLIB port of the controller and use function pointers for getreg and setreg functions

The registers in the GRLIB port of the controller are 32-bit and in big endian
byte order. The PRELOW and PREHIGH registers are merged into one register. The
subsequent registers have their offset decreased accordingly. Hence the register
access needs to be handled in a non-standard manner using custom getreg and
setreg functions.

Add setreg and getreg functions for different register widths and let oc_setreg
and oc_getreg use function pointers to call the appropriate functions.

A type is added as the data of the of match table entries. A new entry with a
different compatible string is added to the table. The type of that entry
triggers usage of the custom grlib functions by setting the setreg and getreg
function pointers.
Signed-off-by: NAndreas Larsson <andreas@gaisler.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      a000b8c1
    • A
      i2c: ocores: Add irq support for sparc · f5f35a92
      由 Andreas Larsson 提交于 
      Add sparc support by using platform_get_irq instead of platform_get_resource.
There are no platform resources of type IORESOURCE_IRQ for sparc, but
platform_get_irq works for sparc. In the non-sparc case platform_get_irq
internally uses platform_get_resource.
Signed-off-by: NAndreas Larsson <andreas@gaisler.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      f5f35a92
  21. 16 11月, 2012 12 次提交
    • S
      i2c: omap: Move the remove constraint · 1ab36045
      由 Shubhrajyoti D 提交于 
      Currently we just queue the transfer and release the
qos constraints, however we do not wait for the transfer
to complete to release the constraint. Move the remove
constraint after the bus busy as we are sure that the
transfers are completed by then.
Acked-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      1ab36045
    • 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
    • S
      i2c: i2c-sh_mobile: fix spurious transfer request timed out · 29fb08c3
      由 Shinya Kuribayashi 提交于 
      Ensure that any of preceding register write operations to the I2C
hardware block reached the module, and the write data is reflected
in the registers, before leaving the interrupt handler.

Otherwise, we'll suffer from spurious WAIT interrupts that lead to
'Transfer request timed out' message, and the transaction failed.
Reported-by: NTeppei Kamijou <teppei.kamijou.yb@renesas.com>
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      29fb08c3
    • S
      i2c: i2c-sh_mobile: support I2C hardware block with a faster operating clock · ebd5ac16
      由 Shinya Kuribayashi 提交于 
      On newer SH-/R-Mobile SoCs, a clock supply to the I2C hardware block,
which is used to generate the SCL clock output, is getting faster than
before, while on the other hand, the SCL clock control registers, ICCH
and ICCL, stay unchanged in 9-bit-wide (8+1).

On such silicons, the internal SCL clock counter gets incremented every
2 clocks of the operating clock.

This patch makes it configurable through platform data.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      ebd5ac16
    • S
      i2c: i2c-sh_mobile: optimize ICCH/ICCL values according to I2C bus speed · 23a61291
      由 Shinya Kuribayashi 提交于 
      ICCH/ICCL values is supposed to be calculated/optimized to strictly meet
the timing specs required by the I2C standard. The resulting I2C bus
speed does not matter at all, if it's less than 100 or 400 kHz.

With this change, sh_mobile_i2c_icch() is virtually identical to
sh_mobile_i2c_iccl(), but they're providing good descriptions of
SH-/R-Mobile I2C hardware spec, and I'd leave them as separated.

Also fix a typo in the comment, print icch/iccl values at probe, etc.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>

[wsa: squashed two patches for bisectability]
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      23a61291
    • S
      i2c: i2c-sh_mobile: calculate clock parameters at driver probing time · 7b0e6292
      由 Shinya Kuribayashi 提交于 
      Currently SCL clock parameters (ICCH/ICCL) are calculated in
activate_ch(), which gets called every time sh_mobile_i2c_xfer() is
processed, while each I2C bus speed is system-defined and in general
those parameters do not have to be updated over I2C transactions.

The only reason I could see having it transaction-time is to adjust
ICCH/ICCL values according to the operating frequency of the I2C
hardware block, in the face of DFS (Dynamic Frequency Scaling).

However, this won't be necessary.

The operating frequency of the I2C hardware block can change _even_
in the middle of I2C transactions.  There is no way to prevent it
from happening, and I2C hardware block can work with such dynamic
frequency change, of course.

Another is that ICCH/ICCL clock parameters optimized for the faster
operating frequency, can also be applied to the slower operating
frequency, as long as slave devices work.  However, the converse is
not true.  It would violate SCL timing specs of the I2C standard.

What we can do now is to calculate the ICCH/ICCL clock parameters
according to the fastest operating clock of the I2C hardware block.
And if that's the case, that calculation should be done just once
at driver-module-init time.

This patch moves ICCH/ICCL calculating part from activate_ch() into
sh_mobile_i2c_init(), and call it from sh_mobile_i2c_probe().

Note that sh_mobile_i2c_init() just prepares clock parameters using
the clock rate and platform data provided, but does _not_ make any
hardware I/O accesses.  We don't have to care about run-time PM
maintenance here.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      7b0e6292
  23. 15 11月, 2012 3 次提交