Add i2c support for the on-board PLD found on some Kontron embedded
modules.

Originally-From: Michael Brunner <michael.brunner@kontron.com>
Signed-off-by: NKevin Strasser <kevin.strasser@linux.intel.com>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There has long been a syntax problem in iop3xx_i2c_wait_event() which
has been somehow hidden by the macros in <linux/wait.h>.  After some
recent cleanup/rework of the wait_event_* helpers, the bug has come
out from hiding and now results in build failure:

/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c: In function 'iop3xx_i2c_wait_event':
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:143: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:157: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:213: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:291: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:551: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:565: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:764: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:778: error: expected ')' b

Fix by removing stray ';'
Signed-off-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch makes the SDA hold time configurable through device tree.
Signed-off-by: NChristian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: NPierrick Hascoet <pierrick.hascoet@abilis.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com> for arch/arc bits
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This commit adds checking whether clock-frequency property acquisition
has succeeded. If not, the frequency is set to 100kHz by default.

The Device Tree binding documentation is updated accordingly.

Based on the intials patches from Zbigniew Bodek
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NZbigniew Bodek <zbb@semihalf.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Allow udev to autoload the module when booting with device-tree
Signed-off-by: NArnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The driver returns -ENODEV as error code if it did not get an ACK
from the device. Per Documentation/i2c/fault-codes, it should
return -ENXIO.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch adds the i801 SMBus Controller DeviceIDs for the Intel Coleto Creek PCH.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

We've been lucky not to have any interrupts fire during the suspend
path, otherwise we would have unpredictable behaviour in the kernel.

Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.

This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.

Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.

I've checked that interrupts in the i2c controller are still enabled
after writting 0 to the I2C_IRQENABLE_SET register. With this patch
interrupts are disabled in the omap_i2c_runtime_suspend() function.

Patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
tag: v3.10-rc2

Verified on OMAP4430.
Signed-off-by: NOleksandr Dmytryshyn <oleksandr.dmytryshyn@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

On OLPC XO-1.75 (MMP2), a WARN_ON() was occurring during boot
since the clock being enabled by i2c-pxa had not been prepared.

Use clk_prepare_enable() to ensure that the prepare operation
has taken place, and use clk_disable_unprepare() in the matching
shutdown paths.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The Nomadik I2C was using a local atomic counter to number
the I2C adapters. This does not work on configurations where
you also add, say a GPIO bit-banged adapter to the system.
They will start to conflict about being adapter 0.

There is no reason to use the numbered adapter function, and
the semantic effect on systems with only Nomadik I2C blocks
will be none - instead of increasing the number atomically
in the driver itself, it is done in the I2C core.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The Nomadik I2C block was introduced with the Nomadik STn8815
SoC (the STn8810 incidentally is identical to the one named
i2c-stu300.c). However as developments have only been tested
on the DB8500 family, it was not properly working with the
STn8815 anymore.

Rectify this by adding some vendor variant data in the same
manner as other PrimeCells, and switch code path depending
on version.

Tested on the S8815 Nomadik dongle.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add the compatible string for the Allwinner A10 i2c controller and the
associated register layout.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The Allwinner i2c controller uses the same logic as the Marvell one, but
with slightly different register offsets.

Introduce a structure that will be passed by either the pdata or
associated to the compatible strings, and that holds the various
registers that might be needed.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

These macros make it more comprehensive to access to useful masked and
shifted area of the various registers used.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch adds support for the I2C bus controllers found on Wondermedia
8xxx-series SoCs. Only master-mode is supported.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
[wsa: fixed one macro to shift 8 instead of 16]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

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: NChristian Ruppert <christian.ruppert@abilis.com>
[wsa: extended the comment]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

TWI transfer interrupts may be lost when system is heavily handling other
interrupts, while current transfer handler depends on each accurate interrupt
and misses some data in this case. Because there are 2 2-byte FIFOs in blackfin
TWI controller, the occurrence of the data loss can be reduced by reading till
the RX FIFO is empty and writing till the TX FIFO is full.
Reported-by: NBob Maris <mail@maris-ee.eu>
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If a process receives signal while it is waiting for I2C transfer to
complete, an error is returned to the caller and the transfer is aborted.
This can cause the driver to fail subsequent transfers. Also according to
commit d295a86e (i2c: mv64xxx: work around signals causing I2C
transactions to be aborted) I2C drivers aren't supposed to abort
transactions on signals.

To prevent this switch to use wait_for_completion_timeout() instead of
wait_for_completion_interruptible_timeout() in the designware I2C driver.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NChristian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Since commit ab78029e (drivers/pinctrl: grab default handles from device core),
we can rely on device core for handling pinctrl.

So remove devm_pinctrl_get_select_default() from the driver.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Since commit ab78029e (drivers/pinctrl: grab default handles from device core),
we can rely on device core for handling pinctrl.

So remove devm_pinctrl_get_select_default() from the driver.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Asking for a multi-part message to be handled by this driver is racy; it
has been observed that the following sequence is possible with this
driver:

	- send start
	- send address + write
	- send data
	- send (repeated) start
	- send address + write
	- send (repeated) start
	- send address + read
	- unrecoverable bus hang (except by system reset)

The problem is that the interrupt handling sees the next event after the
first repeated start is sent - the IFLG bit is set in the register even
though INTEN is disabled.

Let's fix this by moving all of the message processing into interrupt
context, rather than having it partly in IRQ and partly in process
context.  This allows us to move immediately to the next message in the
interrupt handler and get on with the transfer, rather than incuring a
couple of scheduling switches to get the next message.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move mv64xxx_i2c_prepare_for_io() higher up in the driver to avoid a
future forward declaration for this function.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

As this driver does not advertise protocol mangling support
(I2C_FUNC_PROTOCOL_MANGLING is not set), having code to act on
I2C_M_NOSTART is illogical, and in any case isn't supportable on
anything but the first message - which makes no sense.  Remove
the I2C_M_NOSTART code.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Propagate the error code from request_irq() rather than ignoring it
entirely.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

As we're changing to using devm_* APIs to fix various problems
in this driver, lets also do devm_kzalloc() while we're here too.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This driver forgets to use clk_put().  Rather than adding clk_put(),
lets instead use devm_clk_get() to obtain this clock so that it's
automatically handled on cleanup.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Eliminate reg_base_p and reg_size, mv64xxx_i2c_unmap_regs() and an
unchecked ioremap() return from this driver by using the devm_*
API for requesting and ioremapping resources.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

mv64xxx_i2c_map_regs() already returns an error code, so lets
propagate that to mv64xxx_i2c_probe()'s caller.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Moorestown support is removed from kernel and Medfield is supported by
i2c-designware-pci. But i2c-intel-mid is still in upstream and community
resources are wasted to maintain it.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NBarry Song <Baohua.Song@csr.com>

Do not use interruptible waits in an I2C driver; if a process uses
signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can
cause the I2C driver to abort a transaction in progress by another
driver, which can cause that driver to fail.  I2C drivers are not
expected to abort transactions on signals.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Duplicate the feature bits documentation in modinfo, as not every user
will read the driver's source code or documentation file.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This is the same controller as on Intel Lynxpoint but the ACPI ID is
different (8086F41). Add support for this.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

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: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

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: NJosef Ahmad <josef.ahmad@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

The TX_FIFO register is 10 bits wide.  The lower 8 bits are the data to be
written, while the upper two bits are flags to indicate stop/start.

The driver apparently attempted to optimize write access, by only writing a
byte in those cases where the stop/start bits are zero.  However, we have
seen cases where the lower byte is duplicated onto the upper byte by the
hardware, which causes inadvertent stop/starts.

This patch changes the write access to the transmit FIFO to always be 16 bits
wide.

Signed off by: Steven A. Falco <sfalco@harris.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

HZ based value is better than a magic number.
Signed-off-by: NEunbong Song <eunb.song@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I've been debugging the abnormal operation of i2c on octeon. If a process is
terminated by signal in the middle of i2c operation, next i2c read operation
which is done by another process was failed. So i changed to ignore signal in
the middle of i2c operation. After that the problem was not reproduced.
Signed-off-by: NEunbong Song <eunb.song@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>