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: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Zbigniew Bodek <zbb@semihalf.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allow udev to autoload the module when booting with device-tree
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Wolfram 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: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This patch adds the i801 SMBus Controller DeviceIDs for the Intel Coleto Creek PCH.
Signed-off-by: Seth Heasley <seth.heasley@intel.com>
Signed-off-by: Wolfram 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: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@ti.com>
Signed-off-by: Wolfram 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: Daniel Drake <dsd@laptop.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This reverts commit c80f52847c.
Regressions have been found and also run time based instantiation would
fail. We need more thoughts on this.
Signed-off-by: Wolfram 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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Wolfram 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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Wolfram 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: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Wolfram 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: Tony Prisk <linux@prisktech.co.nz>
[wsa: fixed one macro to shift 8 instead of 16]
Signed-off-by: Wolfram 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: Christian Ruppert <christian.ruppert@abilis.com>
[wsa: extended the comment]
Signed-off-by: Wolfram 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: Bob Maris <mail@maris-ee.eu>
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This tries to address an issue found when writing an MFD driver
for the Nomadik STw481x PMICs: as the platform is using device
tree exclusively I want to specify the driver matching like
this:
static const struct of_device_id stw481x_match[] = {
{ .compatible = "st,stw4810", },
{ .compatible = "st,stw4811", },
{},
};
static struct i2c_driver stw481x_driver = {
.driver = {
.name = "stw481x",
.of_match_table = stw481x_match,
},
.probe = stw481x_probe,
.remove = stw481x_remove,
};
However that turns out not to be possible: the I2C probe code
is written so that the probe() call is always passed a match
from i2c_match_id() using non-devicetree matches.
This is probably why most devices using device tree for I2C
clients currently will pass no .of_match_table *at all* but
instead just use .id_table from struct i2c_driver to match
the device. As you realize that means that the whole idea with
compatible strings is discarded, and that is why we find strange
device tree I2C device compatible strings like "product" instead
of "vendor,product" as you could expect.
Let's figure out how to fix this before the mess spreads. This
patch will allow probeing devices with only an of_match_table
as per above, and will pass NULL as the second argument to the
probe() function. If the driver wants to deduce secondary info
from the struct of_device_id .data field, it has to call
of_match_device() on its own match table in the probe function
device tree probe path.
If drivers define both an .of_match_table *AND* a i2c_driver
.id_table, the .of_match_table will take precedence, just
as is done in the i2c_device_match() function in i2c-core.c.
I2C devices probed from device tree should subsequently be
fixed to handle the case where of_match_table() is
used (I think none of them do that today), and platforms should
fix their device trees to use compatible strings for I2C devices
instead of setting the name to Linux device driver names as is
done in multiple cases today.
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Wolfram 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: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Wolfram 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: Wolfram 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 d295a86eab (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: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Since commit ab78029 (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: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Since commit ab78029 (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: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Wolfram 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: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Wolfram 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: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Wolfram 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: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
