- 04 May, 2016 6 commits
-
-
Antti Palosaari authored
The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the i2c accesses unlocked. But add a mutex so that firmware commands are still serialized. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Peter Rosin authored
The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use ordinary regmap_write accesses. This also happens to fix the deadlock described in http://patchwork.ozlabs.org/patch/584776/ authored by Adriana Reus <adriana.reus@intel.com> and submitted by Daniel Baluta <daniel.baluta@intel.com> ----------8<---------- iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock This deadlock occurs if the accel/gyro and the sensor on the auxiliary I2C (in my setup it's an ak8975) are working at the same time. Scenario: T1 T2 ==== ==== inv_mpu6050_read_fifo aux sensor op (eg. ak8975_read_raw) | | mutex_lock(&indio_dev->mlock) i2c_transfer | | i2c transaction i2c adapter lock | | i2c adapter lock i2c_mux_master_xfer | inv_mpu6050_select_bypass | mutex_lock(&indio_dev->mlock) When we operate on an mpu sensor the order of locking is mpu lock followed by the i2c adapter lock. However, when we operate the auxiliary sensor the order of locking is the other way around. ... ----------8<---------- The reason this patch fixes the deadlock is that T2 does not grab the i2c adapter lock until the very end (and grabs the newfangled i2c mux lock where it previously grabbed the i2c adapter lock). Acked-by:
Jonathan Cameron <jic23@kernel.org> Acked-by:
Daniel Baluta <daniel.baluta@intel.com> Tested-by:
Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by:
-
Peter Rosin authored
Signed-off-by:
-
Peter Rosin authored
With a i2c topology like the following GPIO ---| ------ BAT1 | v / I2C -----+----------+---- MUX | \ EEPROM ------ BAT2 there is a locking problem with the GPIO controller since it is a client on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1) will lock the whole i2c bus prior to attempting to switch the mux to the correct i2c segment. In the above case, the GPIO device is an I/O expander with an i2c interface, and since the GPIO subsystem knows nothing (and rightfully so) about the lockless needs of the i2c mux code, this results in a deadlock when the GPIO driver issues i2c transfers to modify the mux. So, observing that while it is needed to have the i2c bus locked during the actual MUX update in order to avoid random garbage on the slave side, it is not strictly a must to have it locked over the whole sequence of a full select-transfer-deselect mux client operation. The mux itself needs to be locked, so transfers to clients behind the mux are serialized, and the mux needs to be stable during all i2c traffic (otherwise individual mux slave segments might see garbage, or worse). Introduce this new locking concept as "mux-locked" muxes, and call the pre-existing mux locking scheme "parent-locked". Modify the i2c mux locking so that muxes that are "mux-locked" locks only the muxes on the parent adapter instead of the whole i2c bus when there is a transfer to the slave side of the mux. This lock serializes transfers to the slave side of the muxes on the parent adapter. Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved gpio/pinctrl devices have a parent that is an i2c adapter in the same adapter tree that is muxed, and request a "mux-locked mux" if that is the case. Modify the select-transfer-deselect code for "mux-locked" muxes so that each of the select-transfer-deselect ops locks the mux parent adapter individually. Signed-off-by: -
Peter Rosin authored
Instead of checking for i2c parent adapters for every lock/unlock, simply override the locking for muxes to always lock/unlock the parent adapter directly. Signed-off-by:
-
Peter Rosin authored
Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and unlock_bus ops in the adapter. These funcs/ops take an additional flags argument that indicates for what purpose the adapter is locked. There are two flags, I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT, but they are both implemented the same. For now. Locking the root adapter means that the whole bus is locked, locking the segment means that only the current bus segment is locked (i.e. i2c traffic on the parent side of a mux is still allowed even if the child side of the mux is locked). Also support a trylock_bus op (but no function to call it, as it is not expected to be needed outside of the i2c core). Implement i2c_lock_adapter/i2c_unlock_adapter in terms of the new locking scheme (i.e. lock with the I2C_LOCK_ROOT_ADAPTER flag). Locking the root adapter and locking the segment is the same thing for all root adapters (e.g. in the normal case of a simple topology with no i2c muxes). The two locking variants are also the same for traditional muxes (aka parent-locked muxes). These muxes traverse the tree, locking each level as they go until they reach the root. This patch is preparatory for a later patch in the series introducing mux-locked muxes, which behave differently depending on the requested locking. Since all current users are using i2c_lock_adapter, which is a wrapper for I2C_LOCK_ROOT_ADAPTER, we only need to annotate the calls that will not need to lock the root adapter for mux-locked muxes. I.e. the instances that needs to use I2C_LOCK_SEGMENT instead of i2c_lock_adapter/I2C_LOCK_ROOT_ADAPTER. Those instances are in the i2c_transfer and i2c_smbus_xfer functions, so that mux-locked muxes can single out normal i2c accesses to its slave side and adjust the locking for those accesses. Signed-off-by:
-
- 27 Apr, 2016 6 commits
-
-
Masahiro Yamada authored
Just in case. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Thomas Petazzoni authored
When clock support was added to the i2c-mv64xxx, not all clk functions had stubs when for !CONFIG_HAVE_CLK configurations. However, nowadays, both "struct clk" and all the clock framework functions have stubs when CONFIG_HAVE_CLK is not enabled, so it no longer makes sense to carry such compile-time conditionals in the driver. This commit was compile tested on both ARM64 (which has both CONFIG_OF=y and CONFIG_HAVE_CLK=y) and PowerPC c2k_defconfig (which has CONFIG_OF=y, CONFIG_HAVE_CLK disabled, and the i2c-mv64xxx driver enabled). The only non-trivial change is in the mv64xxx_of_config() function, which was returning -ENODEV unconditionally if CONFIG_HAVE_CLK was disabled. Simply removing this condition works fine because the first test done by the function is to verify if drv_data->clk points to a valid clock, and if it doesn't, we return -ENODEV. When CONFIG_HAVE_CLK is disabled, devm_clk_get() unconditionally returns NULL, so mv64xxx_of_config() will return -ENODEV when no clock is provided, which is the intended behavior. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Thomas Petazzoni authored
Instead of separately calling clk_prepare()/clk_enable(), use clk_prepare_enable(), and instead of calling clk_disable()/clk_unprepare(), use clk_disable_unprepare(). Those handy shortcuts have been introduced specifically to simplify the numerous call sites were both functions were called in sequence. Signed-off-by:
-
Thomas Petazzoni authored
If a clock is registered by a platform driver and not by the OF_CLK_DECLARE() mechanism, it might show up after the first attempt to probe i2c-mv64xxx. In order to solve this, we need to handle -EPROBE_PREFER as a special return value of devm_clk_get(), and return the same error code from probe(). This gives us three situations: - There is no reference to a clock in the DT. In this case, devm_clk_get() returns an error that is not -EPROBE_DEFER (something like -ENODEV), and we continue the probing without enabling the clock. - There is a reference to the clock in the DT, and the clock is ready. devm_clk_get() returns a valid reference to the clock, and we prepare/enable it. - There is a reference to the clock in the DT, but the clock is not ready. devm_clk_get() returns -EPROBE_DEFER, and we exit from probe() with the same error code so that probe() is tried again later. This is needed for Marvell Armada 7K/8K, where the clock driver is a platform driver. Signed-off-by:
-
Thomas Petazzoni authored
The new ARM64 Marvell Armada 7K/8K SoC family is using the same I2C controller as the 32-bits Marvell EBU SoCs, so this commit allows mv64xxx to be enabled when ARCH_MVEBU=y. Signed-off-by:
-
David Daney authored
CN3860 does not interrupt the CPU when the i2c status changes. If we get a timeout, and see the status has in fact changed, we know we have this problem, and drop back to polling. Signed-off-by:
David Daney <ddaney@caviumnetworks.com> Signed-off-by:
Jan Glauber <jglauber@cavium.com> Signed-off-by:
-
- 26 Apr, 2016 4 commits
-
-
Javier Martinez Canillas authored
The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either built-in or as a module, use that macro instead of open coding the same. Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
-
Oleksij Rempel authored
Documentation/timers/timers-howto.txt recommends to use usleep_range on delays > 10usec. According to my test results with Neonode zForce touchscreen driver, usleep_range indeed reduces CPU load. Stats collected with "./perf record -a -g -F 1000 sleep 10" i2c-imx with udelay(50): 34.19% 0.00% irq/220-Neonode [kernel.kallsyms] [k] irq_thread ---irq_thread |--33.75%--irq_thread_fn | |--19.27%--0x7f08a878 | | i2c_master_recv | | i2c_transfer | | __i2c_transfer | | i2c_imx_xfer | | |--11.71%--i2c_imx_trx_complete | | |--5.70%--i2c_imx_start <<<<---------------- | | | |--5.38%--__timer_const_udelay | | | | __timer_delay | | | | --5.07%--read_current_timer i2c-imx with usleep_range(50,100) 29.08% 0.00% irq/220-Neonode [kernel.kallsyms] [k] irq_thread ---irq_thread |--28.89%--irq_thread_fn | |--17.21%--0x7f08a878 | | i2c_master_recv | | |--17.14%--i2c_transfer | | | __i2c_transfer | | | i2c_imx_xfer | | | |--14.29%--i2c_imx_trx_complete | | | |--1.42%--i2c_imx_start <<<<---------- | | | | |--0.71%--usleep_range | | | | |--0.53%--i2c_imx_bus_busy Signed-off-by:Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
Dirk Behme <dirk.behme@de.bosch.com> Reviewed-by:
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by:
-
Peter Swain authored
There is a race between the TWSI interrupt and the condition that is required before proceeding: Low-level: interrupt flag bit must be set High-level controller: valid bit must be clear If the interrupt comes too early and the condition is not met the wait will time out, and the transfer is aborted leading to very poor performance. To avoid this race retry for the condition ~80 µs later. The retry is avoided on the very first invocation of wait_event_timeout() (which tests the condition before entering the wait and is therefore always wrong in this case). EEPROM reads on 100kHz i2c now measure ~5.2kB/s, about 1/2 what's achievable, and much better than the worst-case 100 bytes/sec before. While at it remove the debug print from the low-level wait function. Signed-off-by:
Peter Swain <pswain@cavium.com> Signed-off-by:
-
Jan Glauber authored
Zero-length message support (SMBUS QUICK or i2c) never worked with the Octeon hardware. Disable SMBUS QUICK support and bail out in case of a zero-length i2c request. After this change 'i2c-detect -q' will return an error on Octeon but the previously reported results were wrong anyway. Signed-off-by:
-
- 25 Apr, 2016 10 commits
-
-
Javier Martinez Canillas authored
The clk_prepare_enable() function can fail so check the return value and propagate the error in case of a failure. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Javier Martinez Canillas authored
The driver not always prints the error code in case of a failure but this information can be very useful for debugging. So let's print if available. Signed-off-by:
-
Krzysztof Kozlowski authored
Improve the readability by: - fixing indentation, - switching to proper block comments, - removing spurious blank lines, - checkpatch: void function return statements are not generally useful, - checkpatch: braces {} are not necessary for any arm of this statement, - checkpatch: missing a blank line after declarations. Signed-off-by: -
Krzysztof Kozlowski authored
Cleanup the weird function-level comments and remove obvious documentation for probe/remove. Signed-off-by:
-
Krzysztof Kozlowski authored
If during probe() the s3c24xx_i2c_init() failed, the clock was left in disabled but prepared state. Signed-off-by:
-
Jan Glauber authored
cn78xx has a different interrupt architecture, so we have to manage the interrupts differently. Signed-off-by:
-
David Daney authored
Use High-Level Controller (HLC) when possible. The HLC can read/write up to 8 bytes and is completely optional. The most important difference of the HLC is that it only requires one interrupt for a transfer (up to 8 bytes) where the low-level read/write requires 2 interrupts plus one interrupt per transferred byte. Since the interrupts are costly using the HLC improves the performance. Also, the HLC provides improved error handling. Signed-off-by:
-
Peter Swain authored
Add helper function that reads back a value after writing to make sure the write is finished and use it in octeon_i2c_write_int(). Signed-off-by:
-
Jan Glauber authored
Switch to the i2c bus recovery framework using generic SCL recovery. If this fails try to reset the hardware. The recovery is triggered during START on timeout of the interrupt or failure to reach the START / repeated-START condition. The START function is moved to xfer and while at it remove the xfer debug message (i2c core already provides a debug message for this). Signed-off-by:
-
Jan Glauber authored
Introduce a function that checks for valid status codes depending on the phase of a transmit or receive. Also add all existing status codes and improve error handling for various states. The Octeon TWSI has an "assert acknowledge" bit (TWSI_CTL_AAK) that is required to be set in master receive mode until the last byte is requested. The state check needs to consider if this bit was set. Signed-off-by:
-
- 24 Apr, 2016 5 commits
-
-
Axel Lin authored
Use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS to simplify the code. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Reviewed-by:
-
Axel Lin authored
Use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS to simplify the code. Signed-off-by:
-
Wolfram Sang authored
smatch rightfully says: drivers/i2c/muxes/i2c-mux-pinctrl.c:175 i2c_mux_pinctrl_probe() warn: inconsistent indenting Signed-off-by:
-
Sebastian Andrzej Siewior authored
The lock is taken while reading two registers. On RT the first lock is taken in hard irq where it might sleep and in the threaded irq. The threaded irq runs in oneshot mode so the hard irq does not run until the thread the completes so there is no reason to grab the lock. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> [grygorii.strashko@ti.com: drop locking from isr completely and remove lock field from struct omap_i2c_dev] Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Irina Tirdea authored
Share the ACPI companion for the platform device with the i2c adapter, so that the adapter has access to the properties defined in ACPI tables. Signed-off-by:
Irina Tirdea <irina.tirdea@intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
- 22 Apr, 2016 9 commits
-
-
Peter Rosin authored
All i2c mux users are using an explicit i2c mux core, drop support for implicit i2c mux cores. Signed-off-by:
-
Peter Rosin authored
Allocate an explicit i2c mux core to handle parent and child adapters etc. Update the select op to be in terms of the i2c mux core instead of the child adapter. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Peter Rosin authored
Allocate an explicit i2c mux core to handle parent and child adapters etc. Update the select op to be in terms of the i2c mux core instead of the child adapter. Tested-by:
-
Peter Rosin authored
Allocate an explicit i2c mux core to handle parent and child adapters etc. Update the select/deselect ops to be in terms of the i2c mux core instead of the child adapter. Tested-by:
-
Peter Rosin authored
Allocate an explicit i2c mux core to handle parent and child adapters etc. Update the select/deselect ops to be in terms of the i2c mux core instead of the child adapter. Tested-by:
-
Peter Rosin authored
Allocate an explicit i2c mux core to handle parent and child adapters etc. Update the select op to be in terms of the i2c mux core instead of the child adapter. Tested-by:
-
Peter Rosin authored
Allocate an explicit i2c mux core to handle parent and child adapters etc. Update the select op to be in terms of the i2c mux core instead of the child adapter. Tested-by:
-
Peter Rosin authored
Allocate an explicit i2c mux core to handle parent and child adapters etc. Update the select/deselect ops to be in terms of the i2c mux core instead of the child adapter. Acked-by:
-
Peter Rosin authored
Allocate an explicit i2c mux core to handle parent and child adapters etc. Update the select/deselect ops to be in terms of the i2c mux core instead of the child adapter. Signed-off-by:
-
