commit 331dcf421c upstream.
If the i2c device is already runtime suspended, if qup_i2c_suspend is
executed during suspend-to-idle or suspend-to-ram it will result in the
following splat:
WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90
Modules linked in:
CPU: 3 PID: 1593 Comm: bash Tainted: G W 4.8.0-rc3 #14
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
PC is at clk_core_unprepare+0x80/0x90
LR is at clk_unprepare+0x28/0x40
pc : [<ffff0000086eecf0>] lr : [<ffff0000086f0c58>] pstate: 60000145
Call trace:
clk_core_unprepare+0x80/0x90
qup_i2c_disable_clocks+0x2c/0x68
qup_i2c_suspend+0x10/0x20
platform_pm_suspend+0x24/0x68
...
This patch fixes the issue by executing qup_i2c_pm_suspend_runtime
conditionally in qup_i2c_suspend.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 463e8f845c upstream.
The cached value of the last selected channel prevents retries on the
next call, even on failure to update the selected channel. Fix that.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 371a015344 upstream.
the eg20t driver call request_irq() function before the pch_base_address,
base address of i2c controller's register, is assigned an effective value.
there is one possible scenario that an interrupt which isn't inside eg20t
arrives immediately after request_irq() is executed when i2c controller
shares an interrupt number with others. since the interrupt handler
pch_i2c_handler() has already active as shared action, it will be called
and read its own register to determine if this interrupt is from itself.
At that moment, since base address of i2c registers is not remapped
in kernel space yet,so the INT handler will access an illegal address
and then a error occurs.
Signed-off-by: Yadi.hu <yadi.hu@windriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 7dd91d52a8 upstream.
There is the only failure path in efm32_i2c_probe(),
where clk_disable_unprepare() is missed.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: 1b5b23718b ("i2c: efm32: new bus driver")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 10ff4c5239 upstream.
The exynos5 I2C controller driver always prepares and enables a clock
before using it and then disables unprepares it when the clock is not
used anymore.
But this can cause a possible ABBA deadlock in some scenarios since a
driver that uses regmap to access its I2C registers, will first grab
the regmap lock and then the I2C xfer function will grab the prepare
lock when preparing the I2C clock. But since the clock driver also
uses regmap for I2C accesses, preparing a clock will first grab the
prepare lock and then the regmap lock when using the regmap API.
An example of this happens on the Exynos5422 Odroid XU4 board where a
s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
share the same I2C regmap.
The possible deadlock is reported by the kernel lockdep:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
*** DEADLOCK ***
Fix it by leaving the code prepared on probe and use {en,dis}able in
the I2C transfer function.
This patch is similar to commit 34e81ad5f0 ("i2c: s3c2410: fix ABBA
deadlock by keeping clock prepared") that fixes the same bug in other
driver for an I2C controller found in Samsung SoCs.
Reported-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit bba61f50f7 upstream.
According to the datasheets the n factor for dividing the tclk is
2 to the power n on Allwinner SoCs, not 2 to the power n + 1 as it is
on other mv64xxx implementations.
I've contacted Allwinner about this and they have confirmed that the
datasheet is correct.
This commit fixes the clk-divider calculations for Allwinner SoCs
accordingly.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 0729a04977 upstream.
Commit 00d8689b85 ("i2c: mv64xxx: rework offload support to fix
several problems") completely reworked the offload support, but left a
debugging-related "return false" at the beginning of the
mv64xxx_i2c_can_offload() function. This has the unfortunate consequence
that offloading is in fact never used, which wasn't really the
intention.
This commit fixes that problem by removing the bogus "return false".
Fixes: 00d8689b85 ("i2c: mv64xxx: rework offload support to fix several problems")
Signed-off-by: Hezi Shahmoon <hezi@marvell.com>
[Thomas: reworked commit log and title.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 56d4b8a24c upstream.
ACPI SSCN/FMCN methods were originally added because then the platform can
provide the most accurate HCNT/LCNT values to the driver. However, this
seems not to be true for Dell Inspiron 7348 where using these causes the
touchpad to fail in boot:
i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
i2c_designware INT3433:00: controller timed out
The values received from ACPI are (in fast mode):
HCNT: 72
LCNT: 160
this translates to following timings (input clock is 100MHz on Broadwell):
tHIGH: 720 ns (spec min 600 ns)
tLOW: 1600 ns (spec min 1300 ns)
Bus period: 2920 ns (assuming 300 ns tf and tr)
Bus speed: 342.5 kHz
Both tHIGH and tLOW are within the I2C specification.
The calculated values when ACPI parameters are not used are (in fast mode):
HCNT: 87
LCNT: 159
which translates to:
tHIGH: 870 ns (spec min 600 ns)
tLOW: 1590 ns (spec min 1300 ns)
Bus period 3060 ns (assuming 300 ns tf and tr)
Bus speed 326.8 kHz
These values are also within the I2C specification.
Since both ACPI and calculated values meet the I2C specification timing
requirements it is hard to say why the touchpad does not function properly
with the ACPI values except that the bus speed is higher in this case (but
still well below the max 400kHz).
Solve this by adding DMI quirk to the driver that disables using ACPI
parameters on this particulare machine.
Reported-by: Pavel Roskin <plroskin@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Pavel Roskin <plroskin@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 36d48fb576 upstream.
The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit eadd709f5d upstream.
The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 4f7effddf4 upstream.
The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 93563a6a71 upstream.
For TX transactions, the TXCOMP bit in the Status Register is cleared
when the first data is written into the Transmit Holding Register.
In the lines from at91_do_twi_transfer():
at91_twi_write_data_dma(dev);
at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP);
the TXCOMP interrupt may be enabled before the DMA controller has
actually started to write into the THR. In such a case, the TXCOMP bit
is still set into the Status Register so the interrupt is triggered
immediately. The driver understands that a transaction completion has
occurred but this transaction hasn't started yet. Hence the TXCOMP
interrupt is no longer enabled by at91_do_twi_transfer() but instead
by at91_twi_write_data_dma_callback().
Also, the TXCOMP bit in the Status Register in not a clear on read flag
but a snapshot of the transmission state at the time the Status
Register is read.
When a NACK error is dectected by the I2C controller, the TXCOMP, NACK
and TXRDY bits are set together to 1 in the SR. If enabled, the TXCOMP
interrupt is triggered at the same time. Also setting the TXRDY to 1
triggers the DMA controller to write the next data into the THR. Such
a write resets the TXCOMP bit to 0 in the SR. So depending on when the
interrupt handler reads the SR, it may fail to detect the NACK error
if it relies on the TXCOMP bit. The NACK bit and its interrupt should
be used instead.
For RX transactions, the TXCOMP bit in the Status Register is cleared
when the START bit is set into the Control Register. However to unify
the management of the TXCOMP bit when the DMA controller is used, the
TXCOMP interrupt is now enabled by the DMA callbacks for both TX and
RX transfers.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
This reverts commit aba636b877 which is
commit 6ada5c1e1b upstream.
This is being reverted because it fixes a regression that was introduced
in 4.0 and does not affect 3.16 kernel.
Cc: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Cc: Beata Michalska <b.michalska@samsung.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit c1c21f4e60 upstream.
Current -next fails to link an ARM allmodconfig because drivers that use
the core recovery functions can be built as modules but those functions
are not exported:
ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined!
Add exports to fix this.
Fixes: 5f9296ba21 (i2c: Add bus recovery infrastructure)
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 6ada5c1e1b upstream.
Commit 523c5b8964 ("i2c: Remove support for legacy PM") removed the PM
ops from the bus type, which causes the pm operations on the s3c2410
adapter device to fail (-ENOSUPP in rpm_callback). The adapter device
doesn't get bound to a driver and as such can't have its own pm_runtime
callbacks. Previously this was fine as the bus callbacks would have been
used, but now this can cause devices which use PM runtime and are
attached over I2C to fail to resume.
This commit fixes this issue by marking all adapter devices with
pm_runtime_no_callbacks, since they can't have any.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Beata Michalska <b.michalska@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: 523c5b8964
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit c6cbfb91b8 upstream.
master_xfer() method should return number of i2c messages transferred,
but on Rockchip we were usually returning just 1, which caused trouble
with users that actually check number of transferred messages vs.
checking for negative error codes.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit a494457270 upstream.
This reverts commit e4df3a0b62
("i2c: core: Dispose OF IRQ mapping at client removal time")
Calling irq_dispose_mapping() will destroy the mapping and disassociate
the IRQ from the IRQ chip to which it belongs. Keeping it is OK, because
existent mappings are reused properly.
Also, this commit breaks drivers using devm* for IRQ management on
OF-based systems because devm* cleanup happens in device code, after
bus's remove() method returns.
Signed-off-by: Jakub Kicinski <kubakici@wp.pl>
Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[wsa: updated the commit message with findings fromt the other bug report]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: e4df3a0b62
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 34e81ad5f0 upstream.
This patch solves deadlock between clock prepare mutex and regmap mutex reported
by Tomasz Figa in [1] by implementing solution from [2]: "always leave the clock
of the i2c controller in a prepared state".
[1] https://lkml.org/lkml/2014/7/2/171
[2] https://lkml.org/lkml/2014/7/2/207
On each i2c transfer handled by s3c24xx_i2c_xfer(), clk_prepare_enable() was
called, which calls clk_prepare() then clk_enable(). clk_prepare() takes
prepare_lock mutex before proceeding. Note that i2c transfer functions are
invoked from many places in kernel, typically with some other additional lock
held.
It may happen that function on CPU1 (e.g. regmap_update_bits()) has taken a
mutex (i.e. regmap lock mutex) then it attempts i2c communication in order to
proceed (so it needs to obtain clock related prepare_lock mutex during transfer
preparation stage due to clk_prepare() call). At the same time other task on
CPU0 wants to operate on clock (e.g. to (un)prepare clock for some other reason)
so it has taken prepare_lock mutex.
CPU0: CPU1:
clk_disable_unused() regulator_disable()
clk_prepare_lock() map->lock(map->lock_arg)
regmap_read() s3c24xx_i2c_xfer()
map->lock(map->lock_arg) clk_prepare_lock()
Implemented solution from [2] leaves i2c clock prepared. Preparation is done in
s3c24xx_i2c_probe() function. Without this patch, it is immediately unprepared
by clk_disable_unprepare() call. I've replaced this call with clk_disable() and
I've added clk_unprepare() call in s3c24xx_i2c_remove().
The s3c24xx_i2c_xfer() function now uses clk_enable() instead of
clk_prepare_enable() (and clk_disable() instead of clk_unprepare_disable()).
Signed-off-by: Paul Osmialowski <p.osmialowsk@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 00d8689b85 upstream.
Originally, the I2C controller supported by the i2c-mv64xxx driver
requires a lot of software support: an interrupt is generated at each
step of an I2C transaction (after the start bit, after sending the
address, etc.) and the driver is in charge of re-programming the I2C
controller to do the next step of the I2C transaction. This explains
the fairly complex state machine that the driver has.
On Marvell Armada XP and later processors (Armada 375, 38x, etc.), the
I2C controller was extended with a part called the "I2C Bridge", which
allows to offload the I2C transaction completely to the
hardware. Initial support for this mechanism was added in commit
930ab3d403 ("i2c: mv64xxx: Add I2C Transaction Generator support").
However, the implementation done in this commit has two related
issues, which this commit fixes by completely changing how the offload
implementation is done:
* SMBus read transfers, where there is one write to select the
register immediately followed in the same transaction by one read,
were making the processor hang. This was easier visible on the
Marvell Armada XP WRT1900AC platform using a driver for an I2C LED
controller, or on other Armada XP platforms by using a simple
'i2cget' command to read an I2C EEPROM.
* The implementation was based on the fact that the offload engine
was re-programmed to transfer each message of an I2C xfer: this
meant that each message sent with the offload engine was starting
with a normal I2C start sequence. However, the I2C subsystem
assumes that all messages belonging to the same xfer will use the
so-called "repeated start" so that the entire I2C xfer is seen as
one transfer by the I2C devices and cannot be interrupt by other
I2C masters on the same bus.
In fact, the "I2C Bridge" allows to offload three types of xfer:
- xfer of one write message
- xfer of one read message
- xfer of one write message followed by one read message
For all other situations, we have to fallback to not using the "I2C
Bridge" in order to get proper I2C semantics.
Therefore, this commit reworks the offload implementation to put it
not at the message level, but at the xfer level: in the
mv64xxx_i2c_xfer() function, we decide if the transaction can be
offloaded (in which case it is handled by the
mv64xxx_i2c_offload_xfer() function), or otherwise it is handled by
the slow path (implemented in the existing mv64xxx_i2c_execute_msg()).
This allows to simplify the state machine, which no longer needs to
have any state related to the offload implementation: the offload
implementation is now completely separated from the slow path (with
the exception of the interrupt handler, of course).
In summary:
- mv64xxx_i2c_can_offload() will analyze an I2C xfer and decided of
the "I2C Bridge" can be used to offload it or not.
- mv64xxx_i2c_offload_xfer() will actually program the "I2C Bridge"
to offload one xfer (of either one or two messages), and block
using mv64xxx_i2c_wait_for_completion() until the xfer completes.
- The interrupt handler mv64xxx_i2c_intr() is modified to push the
offload related code to a separate function,
mv64xxx_i2c_intr_offload(). It will take care of reading the
received data if needed.
This commit was tested on:
- Armada XP OpenBlocks AX3-4 (EEPROM on I2C and RTC on I2C)
- Armada XP WRT1900AC (LED controller on I2C)
- Armada XP GP (EEPROM on I2C)
Fixes: 930ab3d403 ("i2c: mv64xxx: Add I2C Transaction Generator support")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[wsa: fixed checkpatch warnings]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 12598695c2 upstream.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit ccfc866356 upstream.
commit 6d9939f651 (i2c: omap: split out [XR]DR
and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
Set) get handled. 6d9939f651 code doesn't correspond to workaround provided by
errata.
According to errata ISR must filter out spurious RDR before data read not after.
ISR must read RXSTAT to get number of bytes available to read. Because RDR
could be set while there could no data in the receive FIFO.
Restored pre 6d9939f651 way of handling errata.
Found by code review. Real impact haven't seen.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Fixes: 6d9939f651 i2c: omap: split out [XR]DR and [XR]RDY
Tested-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 681d15a0f5 upstream.
Cadence I2C controller has bug wherein it generates invalid read transactions
after timeout in master receiver mode. This driver does not use the HW
timeout and this interrupt is disabled but the feature itself cannot be
disabled. Hence, this patch writes the maximum value (0xFF) to this register.
This is one of the workarounds to this bug and it will not avoid the issue
completely but reduces the chances of error.
Signed-off-by: Vishnu Motghare <vishnum@xilinx.com>
Signed-off-by: Harini Katakam <harinik@xilinx.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 9ea359f731 upstream.
According to I2C specification the NACK should be handled as follows:
"When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then generate either a STOP condition to
abort the transfer, or a repeated START condition to start a new transfer."
[I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]
Currently the Davinci i2c driver interrupts the transfer on receipt of a
NACK but fails to send a STOP in some situations and so makes the bus
stuck until next I2C IP reset (idle/enable).
For example, the issue will happen during SMBus read transfer which
consists from two i2c messages write command/address and read data:
S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P
<--- write -----------------------> <--- read --------------------->
The I2C client device will send NACK if it can't recognize "Command Code"
and it's expected from I2C master to generate STP in this case.
But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will
not be generated.
Hence, fix it by generating Stop condition (STP) always when NACK is received.
This patch fixes Davinci I2C in the same way it was done for OMAP I2C
commit cda2109a26 ("i2c: omap: query STP always when NACK is received").
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reported-by: Hein Tibosch <hein_tibosch@yahoo.es>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 27caca9d2e upstream.
commit 1d7afc9594 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
fired again. As a result, ISR keep processing transfer after it was already
complete (from the driver code point of view).
A didn't see real impacts of the 1d7afc9, but it is really bad idea to
have ISR running on user data after transfer was complete.
It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).
According to specs (if I understood correctly), in case of NACK and AL driver
must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
NACK, AL, ARDY, and XDR (Master Transmitter Mode).
All that is done down the code under the if condition:
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...
The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
no interrupts is fired after ISR informs the rest of driver what transfer
complete.
Note: instead of removing break under NACK case, we could just replace 'break'
with 'continue' and allow NACK transfer to finish using ARDY event. I found
that NACK and ARDY bits usually set together. That case confirm TI wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK
In order if someone interested in the event traces for NACK and AL cases,
I sent them to mailing list.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit e4df3a0b62 upstream.
Clients instantiated from OF get an IRQ mapping created at device
registration time. Dispose the mapping when the client is removed.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 11cfbfb098 upstream.
iowait is for blkio [1]. I2C shouldn't use it.
[1] https://lkml.org/lkml/2014/11/3/317
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit cf27020d2f upstream.
i2cdetect -q was broken (everything was a false positive, and no transfers were
actually being sent over i2c). The way it works is by sending a 0 length write
request and checking for NACK. This patch fixes the 0 length writes and actually
sends them.
Reported-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Tested-by: Max Schwarz <max.schwarz@online.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 86b59bbfae upstream.
The runtime pm calls need to be done before populating the children via the
i2c_add_adapter call. If this is not done, a child can run into issues trying
to do i2c read/writes due to the pm_runtime_sync failing.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 979bbf7b7a upstream.
In block write mode, when encapsulating dma_buffer, first element is
'command', the rest is data buffer, so only copy actual data buffer
starting from block[1] with the size indicating by block[0].
Signed-off-by: Fan Du <fan.du@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b4a7bd7a38 upstream.
I2C_CLKDIV register descripted in the previous version of
RK3x chip manual is incorrect. Plus 1 is required.
The correct formula:
- T(SCL_HIGH) = T(PCLK) * (CLKDIVH + 1) * 8
- T(SCL_LOW) = T(PCLK) * (CLKDIVL + 1) * 8
- (SCL Divsor) = 8 * ((CLKDIVL + 1) + (CLKDIVH + 1))
- SCL = PCLK / (CLK Divsor)
It will be updated to the latest version of chip manual.
Signed-off-by: Addy Ke <addy.ke@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 938916fbb8 upstream.
Bits 8-31 of all registers reflect the value of bits 0-7 on reads and should be
0 on writes, according to the manuals. RCAR_IRQ_ACK_{RECV|SEND} macros have all
1's in bits 8-31, thus going against the manuals, so fix them.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dd318b0df2 upstream.
Sometimes the MNR and MST interrupts happen simultaneously (stop automatically
follows NACK, according to the manuals) and in such case the ID_NACK flag isn't
set since the MST interrupt handling precedes MNR and all interrupts are cleared
and disabled then, so that MNR interrupt is never noticed -- this causes NACK'ed
transfers to be falsely reported as successful. Exchanging MNR and MST handlers
fixes this issue, however the MNR bit somehow gets set again even after being
explicitly cleared, so I decided to completely suppress handling of all disabled
interrupts (which is a good thing anyway)...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 91bfe2989a upstream.
This reverts commit 150b8be3cd.
The I2C core's per-adapter locks can't protect from IRQs, so the driver still
needs a spinlock to protect the register accesses.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6721f28a26 upstream.
There is a race condition in at91_do_twi_xfer when signals arrive.
If a signal is recieved while waiting for a transfer to complete
wait_for_completion_interruptible_timeout() will return -ERESTARTSYS.
This is not handled correctly resulting in interrupts still being
enabled and a transfer being in flight when we return.
Symptoms include a range of oopses and bus lockups. Oopses can happen
when the transfer completes because the interrupt handler will corrupt
the stack. If a new transfer is started before the interrupt fires
the controller will start a new transfer in the middle of the old one,
resulting in confused slaves and a locked bus.
To avoid this, use wait_for_completion_io_timeout instead so that we
don't have to deal with gracefully shutting down the transfer and
disabling the interrupts.
Signed-off-by: Simon Lindgren <simon@aqwary.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 75b81f339c upstream.
The driver was not bound checking the received length byte to ensure it was within the
the buffer size that is allocated for SMBus blocks. This resulted in buffer overflows
whenever an invalid length byte was received.
It also failed to ensure the length byte was not zero. If it received zero, it would end up
in an infinite loop as the at91_twi_read_next_byte function returned immediately without
allowing RHR to be read to clear the RXRDY interrupt.
Tested agaisnt a SMBus compliant battery.
Signed-off-by: Marek Roszko <mark.roszko@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0ce4bc1dbd upstream.
The "clock-frequency" DT property is listed as optional, However,
the current code stores the return value of of_property_read_u32 in
the return code of mv64xxx_of_config, but then forgets to clear it
after setting the default value of "clock-frequency". It is then
passed out to the main probe function, resulting in a probe failure
when "clock-frequency" is missing.
This patch checks and then throws away the return value of
of_property_read_u32, instead of storing it and having to clear it
afterwards.
This issue was discovered after the property was removed from all
sunxi DTs.
Fixes: 4c730a06c1 ("i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not provided")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5da4309f9e upstream.
In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data
in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx
must be less than or equal 32 bytes at a time.
Tested on rk3288-pinky board, elan receive 158 bytes data.
Signed-off-by: Addy Ke <addy.ke@rock-chips.com>
Acked-by: Max Schwarz <max.schwarz@online.de>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9c5f7cad3a upstream.
If slave holds scl, I2C_IPD[7] will be set 1 by controller
for debugging. Driver must ignore it.
[ 5.752391] rk3x-i2c ff160000.i2c: unexpected irq in WRITE: 0x80
[ 5.939027] rk3x-i2c ff160000.i2c: timeout, ipd: 0x80, state: 4
Signed-off-by: Addy Ke <addy.ke@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
module.h was included twice.
Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com>
Acked-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This driver causes the following randconfig build error:
drivers/i2c/muxes/i2c-mux-pca954x.c: In function ‘pca954x_probe’:
drivers/i2c/muxes/i2c-mux-pca954x.c:204:2: error: implicit declaration
of function ‘devm_gpiod_get’ [-Werror=implicit-function-declaration]
gpio = devm_gpiod_get(&client->dev, "reset");
^
drivers/i2c/muxes/i2c-mux-pca954x.c:204:7: warning: assignment makes
pointer from integer without a cast [enabled by default]
gpio = devm_gpiod_get(&client->dev, "reset");
^
drivers/i2c/muxes/i2c-mux-pca954x.c:206:3: error: implicit declaration
of function ‘gpiod_direction_output’
[-Werror=implicit-function-declaration]
gpiod_direction_output(gpio, 0);
^
cc1: some warnings being treated as errors
make[3]: *** [drivers/i2c/muxes/i2c-mux-pca954x.o] Error 1
This is because it is getting compiled without gpiolib, so
introduce an explicit dependency.
Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes possible issue in case pdev name contains formatting characters.
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Reported-by: Kees Cook <keescook@google.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
drivers/i2c/busses/i2c-rk3x.c:610:69-70: rk3x_i2c_match is not NULL terminated at line 610
Make sure of_device_id tables are NULL terminated
Generated by: /kbuild/src/linux/scripts/coccinelle/misc/of_table.cocci
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes:
>> drivers/i2c/busses/i2c-sun6i-p2wi.c:243:10: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The P2WI controller looks like an SMBus controller which only supports byte
data transfers. But, it differs from standard SMBus protocol on several
aspects:
- it supports only one slave device, and thus drop the address field
- it adds a parity bit every 8bits of data
- only one read access is required to read a byte (instead of a write
followed by a read access in standard SMBus protocol)
- there's no Ack bit after each byte transfer
This means this bus cannot be used to interface with standard SMBus
devices (the only known device to support this interface is the AXP221
PMIC).
However the P2WI protocol is close enough to SMBus to be integrated in
the I2C subsystem (see this thread [1] for detailed reasons that led to
integrating this driver in the I2C subsystem).
[1] http://www.spinics.net/lists/linux-i2c/msg15066.html
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz <max.schwarz@online.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Pull i2c updates from Wolfram Sang:
"I2C has the following updates for 3.16:
- major cleanups to the rcar and sh_mobile drivers
- removal of nuc900 driver which had a compile error for years
- usual bunch of driver updates, bugfixes and cleanups"
* 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (44 commits)
i2c: pca954x: Fix compilation without CONFIG_GPIOLIB
i2c: mux: pca954x: Use the descriptor-based GPIO API
i2c: mpc: insert DR read in i2c_fixup()
i2c: bfin: turn to Resource-managed API in probe function
i2c: Make of_device_id array const
i2c: remove unnecessary OOM messages
i2c: designware-pci: Add Haswell PCI IDs
i2c: designware: Add runtime PM hooks
i2c: designware: Disable device on system suspend
i2c: nuc900: remove driver
i2c: imx: update i2c clock divider for each transaction
i2c: imx: fix the i2c bus hang issue when do repeat restart
i2c: rcar: update copyright and license information
i2c: rcar: janitorial cleanup after refactoring
i2c: rcar: reuse status bits as enable bits
i2c: rcar: remove spinlock
i2c: rcar: refactor status bit handling
i2c: rcar: refactor setting up msg
i2c: rcar: check bus free before first message
i2c: rcar: refactor irq state machine
...
The pca954x driver recently switched to the GPIO descriptor API without
including the correct <linux/gpio/consumer.h> header. This breaks
compilation without CONFIG_GPIOLIB.
drivers/i2c/muxes/i2c-mux-pca954x.c: In function ‘pca954x_probe’:
drivers/i2c/muxes/i2c-mux-pca954x.c:204:2: error: implicit declaration
of function ‘devm_gpiod_get’ [-Werror=implicit-function-declaration]
gpio = devm_gpiod_get(&client->dev, "reset");
^
drivers/i2c/muxes/i2c-mux-pca954x.c:204:7: warning: assignment makes
pointer from integer without a cast [enabled by default]
gpio = devm_gpiod_get(&client->dev, "reset");
^
drivers/i2c/muxes/i2c-mux-pca954x.c:206:3: error: implicit declaration
of function ‘gpiod_direction_output’
[-Werror=implicit-function-declaration]
gpiod_direction_output(gpio, 0);
^
cc1: some warnings being treated as errors
make[3]: *** [drivers/i2c/muxes/i2c-mux-pca954x.o] Error 1
Fix it by including the right header.
Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The ID-based GPIO API pushes handling of GPIO polarity to drivers.
Simplify the driver by switching to the descriptor-based GPIO API.
This also fixes a mismatch between the pca954x DT bindings that document
a "reset-gpios" property and the driver that requests a "reset-gpio"
property.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The mpc_i2c_fixup function is called when the bus is not released by a
slave. The function generates 9 pulses that should lead the slave
to release the bus.
The sequence that generates the pulses disables/enables the I2C module
that controls the blocked bus. We have found out on the P2041 SoC that
this could cause the CPU to hang (for a short delay).
To avoid this, this patch introduces a read to the I2CDR register
between the re-enablement of the I2C module in master mode and its
returning to the slave mode instead of the delay (the final delay,
between the pulses is kept), as proposed in procedure from the P2041
reference manual (16.6.2.3), and the other manuals from the mpc83xx and
mpc85xx families.
Signed-off-by: Rainer Boschung <rainer.boschung@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
