OpenCloudOS-Kernel/drivers/i2c/busses/i2c-mv64xxx.c

1010 lines
27 KiB
C
Raw Normal View History

/*
* Driver for the i2c controller on the Marvell line of host bridges
* (e.g, gt642[46]0, mv643[46]0, mv644[46]0, and Orion SoC family).
*
* Author: Mark A. Greer <mgreer@mvista.com>
*
* 2005 (c) MontaVista, Software, Inc. This file is licensed under
* the terms of the GNU General Public License version 2. This program
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
#include <linux/kernel.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/spinlock.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/mv643xx_i2c.h>
#include <linux/platform_device.h>
#include <linux/reset.h>
#include <linux/io.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/delay.h>
#define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1)
#define MV64XXX_I2C_BAUD_DIV_N(val) (val & 0x7)
#define MV64XXX_I2C_BAUD_DIV_M(val) ((val & 0xf) << 3)
#define MV64XXX_I2C_REG_CONTROL_ACK BIT(2)
#define MV64XXX_I2C_REG_CONTROL_IFLG BIT(3)
#define MV64XXX_I2C_REG_CONTROL_STOP BIT(4)
#define MV64XXX_I2C_REG_CONTROL_START BIT(5)
#define MV64XXX_I2C_REG_CONTROL_TWSIEN BIT(6)
#define MV64XXX_I2C_REG_CONTROL_INTEN BIT(7)
/* Ctlr status values */
#define MV64XXX_I2C_STATUS_BUS_ERR 0x00
#define MV64XXX_I2C_STATUS_MAST_START 0x08
#define MV64XXX_I2C_STATUS_MAST_REPEAT_START 0x10
#define MV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
#define MV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
#define MV64XXX_I2C_STATUS_MAST_WR_ACK 0x28
#define MV64XXX_I2C_STATUS_MAST_WR_NO_ACK 0x30
#define MV64XXX_I2C_STATUS_MAST_LOST_ARB 0x38
#define MV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
#define MV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK 0x48
#define MV64XXX_I2C_STATUS_MAST_RD_DATA_ACK 0x50
#define MV64XXX_I2C_STATUS_MAST_RD_DATA_NO_ACK 0x58
#define MV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK 0xd0
#define MV64XXX_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK 0xd8
#define MV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK 0xe0
#define MV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK 0xe8
#define MV64XXX_I2C_STATUS_NO_STATUS 0xf8
/* Register defines (I2C bridge) */
#define MV64XXX_I2C_REG_TX_DATA_LO 0xc0
#define MV64XXX_I2C_REG_TX_DATA_HI 0xc4
#define MV64XXX_I2C_REG_RX_DATA_LO 0xc8
#define MV64XXX_I2C_REG_RX_DATA_HI 0xcc
#define MV64XXX_I2C_REG_BRIDGE_CONTROL 0xd0
#define MV64XXX_I2C_REG_BRIDGE_STATUS 0xd4
#define MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE 0xd8
#define MV64XXX_I2C_REG_BRIDGE_INTR_MASK 0xdC
#define MV64XXX_I2C_REG_BRIDGE_TIMING 0xe0
/* Bridge Control values */
#define MV64XXX_I2C_BRIDGE_CONTROL_WR BIT(0)
#define MV64XXX_I2C_BRIDGE_CONTROL_RD BIT(1)
#define MV64XXX_I2C_BRIDGE_CONTROL_ADDR_SHIFT 2
#define MV64XXX_I2C_BRIDGE_CONTROL_ADDR_EXT BIT(12)
#define MV64XXX_I2C_BRIDGE_CONTROL_TX_SIZE_SHIFT 13
#define MV64XXX_I2C_BRIDGE_CONTROL_RX_SIZE_SHIFT 16
#define MV64XXX_I2C_BRIDGE_CONTROL_ENABLE BIT(19)
i2c: mv64xxx: rework offload support to fix several problems 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 930ab3d403a ("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: 930ab3d403ae ("i2c: mv64xxx: Add I2C Transaction Generator support") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [wsa: fixed checkpatch warnings] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-12-12 00:33:46 +08:00
#define MV64XXX_I2C_BRIDGE_CONTROL_REPEATED_START BIT(20)
/* Bridge Status values */
#define MV64XXX_I2C_BRIDGE_STATUS_ERROR BIT(0)
/* Driver states */
enum {
MV64XXX_I2C_STATE_INVALID,
MV64XXX_I2C_STATE_IDLE,
MV64XXX_I2C_STATE_WAITING_FOR_START_COND,
MV64XXX_I2C_STATE_WAITING_FOR_RESTART,
MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_ACK,
MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_DATA,
};
/* Driver actions */
enum {
MV64XXX_I2C_ACTION_INVALID,
MV64XXX_I2C_ACTION_CONTINUE,
MV64XXX_I2C_ACTION_SEND_RESTART,
MV64XXX_I2C_ACTION_SEND_ADDR_1,
MV64XXX_I2C_ACTION_SEND_ADDR_2,
MV64XXX_I2C_ACTION_SEND_DATA,
MV64XXX_I2C_ACTION_RCV_DATA,
MV64XXX_I2C_ACTION_RCV_DATA_STOP,
MV64XXX_I2C_ACTION_SEND_STOP,
};
struct mv64xxx_i2c_regs {
u8 addr;
u8 ext_addr;
u8 data;
u8 control;
u8 status;
u8 clock;
u8 soft_reset;
};
struct mv64xxx_i2c_data {
struct i2c_msg *msgs;
int num_msgs;
int irq;
u32 state;
u32 action;
u32 aborting;
u32 cntl_bits;
void __iomem *reg_base;
struct mv64xxx_i2c_regs reg_offsets;
u32 addr1;
u32 addr2;
u32 bytes_left;
u32 byte_posn;
u32 send_stop;
u32 block;
int rc;
u32 freq_m;
u32 freq_n;
struct clk *clk;
wait_queue_head_t waitq;
spinlock_t lock;
struct i2c_msg *msg;
struct i2c_adapter adapter;
bool offload_enabled;
/* 5us delay in order to avoid repeated start timing violation */
bool errata_delay;
struct reset_control *rstc;
bool irq_clear_inverted;
/* Clk div is 2 to the power n, not 2 to the power n + 1 */
bool clk_n_base_0;
};
static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
.addr = 0x00,
.ext_addr = 0x10,
.data = 0x04,
.control = 0x08,
.status = 0x0c,
.clock = 0x0c,
.soft_reset = 0x1c,
};
static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_sun4i = {
.addr = 0x00,
.ext_addr = 0x04,
.data = 0x08,
.control = 0x0c,
.status = 0x10,
.clock = 0x14,
.soft_reset = 0x18,
};
static void
mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data *drv_data,
struct i2c_msg *msg)
{
u32 dir = 0;
drv_data->cntl_bits = MV64XXX_I2C_REG_CONTROL_ACK |
MV64XXX_I2C_REG_CONTROL_INTEN | MV64XXX_I2C_REG_CONTROL_TWSIEN;
if (msg->flags & I2C_M_RD)
dir = 1;
if (msg->flags & I2C_M_TEN) {
drv_data->addr1 = 0xf0 | (((u32)msg->addr & 0x300) >> 7) | dir;
drv_data->addr2 = (u32)msg->addr & 0xff;
} else {
drv_data->addr1 = MV64XXX_I2C_ADDR_ADDR((u32)msg->addr) | dir;
drv_data->addr2 = 0;
}
}
/*
*****************************************************************************
*
* Finite State Machine & Interrupt Routines
*
*****************************************************************************
*/
/* Reset hardware and initialize FSM */
static void
mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
{
if (drv_data->offload_enabled) {
writel(0, drv_data->reg_base + MV64XXX_I2C_REG_BRIDGE_CONTROL);
writel(0, drv_data->reg_base + MV64XXX_I2C_REG_BRIDGE_TIMING);
writel(0, drv_data->reg_base +
MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE);
writel(0, drv_data->reg_base +
MV64XXX_I2C_REG_BRIDGE_INTR_MASK);
}
writel(0, drv_data->reg_base + drv_data->reg_offsets.soft_reset);
writel(MV64XXX_I2C_BAUD_DIV_M(drv_data->freq_m) | MV64XXX_I2C_BAUD_DIV_N(drv_data->freq_n),
drv_data->reg_base + drv_data->reg_offsets.clock);
writel(0, drv_data->reg_base + drv_data->reg_offsets.addr);
writel(0, drv_data->reg_base + drv_data->reg_offsets.ext_addr);
writel(MV64XXX_I2C_REG_CONTROL_TWSIEN | MV64XXX_I2C_REG_CONTROL_STOP,
drv_data->reg_base + drv_data->reg_offsets.control);
drv_data->state = MV64XXX_I2C_STATE_IDLE;
}
static void
mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
{
/*
* If state is idle, then this is likely the remnants of an old
* operation that driver has given up on or the user has killed.
* If so, issue the stop condition and go to idle.
*/
if (drv_data->state == MV64XXX_I2C_STATE_IDLE) {
drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
return;
}
/* The status from the ctlr [mostly] tells us what to do next */
switch (status) {
/* Start condition interrupt */
case MV64XXX_I2C_STATUS_MAST_START: /* 0x08 */
case MV64XXX_I2C_STATUS_MAST_REPEAT_START: /* 0x10 */
drv_data->action = MV64XXX_I2C_ACTION_SEND_ADDR_1;
drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK;
break;
/* Performing a write */
case MV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK: /* 0x18 */
if (drv_data->msg->flags & I2C_M_TEN) {
drv_data->action = MV64XXX_I2C_ACTION_SEND_ADDR_2;
drv_data->state =
MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK;
break;
}
/* FALLTHRU */
case MV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK: /* 0xd0 */
case MV64XXX_I2C_STATUS_MAST_WR_ACK: /* 0x28 */
if ((drv_data->bytes_left == 0)
|| (drv_data->aborting
&& (drv_data->byte_posn != 0))) {
if (drv_data->send_stop || drv_data->aborting) {
drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
drv_data->state = MV64XXX_I2C_STATE_IDLE;
} else {
drv_data->action =
MV64XXX_I2C_ACTION_SEND_RESTART;
drv_data->state =
MV64XXX_I2C_STATE_WAITING_FOR_RESTART;
}
} else {
drv_data->action = MV64XXX_I2C_ACTION_SEND_DATA;
drv_data->state =
MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_ACK;
drv_data->bytes_left--;
}
break;
/* Performing a read */
case MV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK: /* 40 */
if (drv_data->msg->flags & I2C_M_TEN) {
drv_data->action = MV64XXX_I2C_ACTION_SEND_ADDR_2;
drv_data->state =
MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK;
break;
}
/* FALLTHRU */
case MV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK: /* 0xe0 */
if (drv_data->bytes_left == 0) {
drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
drv_data->state = MV64XXX_I2C_STATE_IDLE;
break;
}
/* FALLTHRU */
case MV64XXX_I2C_STATUS_MAST_RD_DATA_ACK: /* 0x50 */
if (status != MV64XXX_I2C_STATUS_MAST_RD_DATA_ACK)
drv_data->action = MV64XXX_I2C_ACTION_CONTINUE;
else {
drv_data->action = MV64XXX_I2C_ACTION_RCV_DATA;
drv_data->bytes_left--;
}
drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_DATA;
if ((drv_data->bytes_left == 1) || drv_data->aborting)
drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_ACK;
break;
case MV64XXX_I2C_STATUS_MAST_RD_DATA_NO_ACK: /* 0x58 */
drv_data->action = MV64XXX_I2C_ACTION_RCV_DATA_STOP;
drv_data->state = MV64XXX_I2C_STATE_IDLE;
break;
case MV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK: /* 0x20 */
case MV64XXX_I2C_STATUS_MAST_WR_NO_ACK: /* 30 */
case MV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK: /* 48 */
/* Doesn't seem to be a device at other end */
drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
drv_data->state = MV64XXX_I2C_STATE_IDLE;
drv_data->rc = -ENXIO;
break;
default:
dev_err(&drv_data->adapter.dev,
"mv64xxx_i2c_fsm: Ctlr Error -- state: 0x%x, "
"status: 0x%x, addr: 0x%x, flags: 0x%x\n",
drv_data->state, status, drv_data->msg->addr,
drv_data->msg->flags);
drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
mv64xxx_i2c_hw_init(drv_data);
drv_data->rc = -EIO;
}
}
static void mv64xxx_i2c_send_start(struct mv64xxx_i2c_data *drv_data)
{
drv_data->msg = drv_data->msgs;
drv_data->byte_posn = 0;
drv_data->bytes_left = drv_data->msg->len;
drv_data->aborting = 0;
drv_data->rc = 0;
i2c: mv64xxx: rework offload support to fix several problems 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 930ab3d403a ("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: 930ab3d403ae ("i2c: mv64xxx: Add I2C Transaction Generator support") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [wsa: fixed checkpatch warnings] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-12-12 00:33:46 +08:00
mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
drv_data->reg_base + drv_data->reg_offsets.control);
}
static void
mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
{
switch(drv_data->action) {
case MV64XXX_I2C_ACTION_SEND_RESTART:
/* We should only get here if we have further messages */
BUG_ON(drv_data->num_msgs == 0);
drv_data->msgs++;
drv_data->num_msgs--;
mv64xxx_i2c_send_start(drv_data);
if (drv_data->errata_delay)
udelay(5);
/*
* We're never at the start of the message here, and by this
* time it's already too late to do any protocol mangling.
* Thankfully, do not advertise support for that feature.
*/
drv_data->send_stop = drv_data->num_msgs == 1;
break;
case MV64XXX_I2C_ACTION_CONTINUE:
writel(drv_data->cntl_bits,
drv_data->reg_base + drv_data->reg_offsets.control);
break;
case MV64XXX_I2C_ACTION_SEND_ADDR_1:
writel(drv_data->addr1,
drv_data->reg_base + drv_data->reg_offsets.data);
writel(drv_data->cntl_bits,
drv_data->reg_base + drv_data->reg_offsets.control);
break;
case MV64XXX_I2C_ACTION_SEND_ADDR_2:
writel(drv_data->addr2,
drv_data->reg_base + drv_data->reg_offsets.data);
writel(drv_data->cntl_bits,
drv_data->reg_base + drv_data->reg_offsets.control);
break;
case MV64XXX_I2C_ACTION_SEND_DATA:
writel(drv_data->msg->buf[drv_data->byte_posn++],
drv_data->reg_base + drv_data->reg_offsets.data);
writel(drv_data->cntl_bits,
drv_data->reg_base + drv_data->reg_offsets.control);
break;
case MV64XXX_I2C_ACTION_RCV_DATA:
drv_data->msg->buf[drv_data->byte_posn++] =
readl(drv_data->reg_base + drv_data->reg_offsets.data);
writel(drv_data->cntl_bits,
drv_data->reg_base + drv_data->reg_offsets.control);
break;
case MV64XXX_I2C_ACTION_RCV_DATA_STOP:
drv_data->msg->buf[drv_data->byte_posn++] =
readl(drv_data->reg_base + drv_data->reg_offsets.data);
drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN;
writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_STOP,
drv_data->reg_base + drv_data->reg_offsets.control);
drv_data->block = 0;
if (drv_data->errata_delay)
udelay(5);
wake_up(&drv_data->waitq);
break;
case MV64XXX_I2C_ACTION_INVALID:
default:
dev_err(&drv_data->adapter.dev,
"mv64xxx_i2c_do_action: Invalid action: %d\n",
drv_data->action);
drv_data->rc = -EIO;
/* FALLTHRU */
case MV64XXX_I2C_ACTION_SEND_STOP:
drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN;
writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_STOP,
drv_data->reg_base + drv_data->reg_offsets.control);
drv_data->block = 0;
wake_up(&drv_data->waitq);
break;
i2c: mv64xxx: rework offload support to fix several problems 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 930ab3d403a ("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: 930ab3d403ae ("i2c: mv64xxx: Add I2C Transaction Generator support") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [wsa: fixed checkpatch warnings] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-12-12 00:33:46 +08:00
}
}
i2c: mv64xxx: rework offload support to fix several problems 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 930ab3d403a ("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: 930ab3d403ae ("i2c: mv64xxx: Add I2C Transaction Generator support") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [wsa: fixed checkpatch warnings] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-12-12 00:33:46 +08:00
static void
mv64xxx_i2c_read_offload_rx_data(struct mv64xxx_i2c_data *drv_data,
struct i2c_msg *msg)
{
u32 buf[2];
buf[0] = readl(drv_data->reg_base + MV64XXX_I2C_REG_RX_DATA_LO);
buf[1] = readl(drv_data->reg_base + MV64XXX_I2C_REG_RX_DATA_HI);
memcpy(msg->buf, buf, msg->len);
}
static int
mv64xxx_i2c_intr_offload(struct mv64xxx_i2c_data *drv_data)
{
u32 cause, status;
cause = readl(drv_data->reg_base +
MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE);
if (!cause)
return IRQ_NONE;
status = readl(drv_data->reg_base +
MV64XXX_I2C_REG_BRIDGE_STATUS);
if (status & MV64XXX_I2C_BRIDGE_STATUS_ERROR) {
drv_data->rc = -EIO;
goto out;
}
drv_data->rc = 0;
/*
* Transaction is a one message read transaction, read data
* for this message.
*/
if (drv_data->num_msgs == 1 && drv_data->msgs[0].flags & I2C_M_RD) {
mv64xxx_i2c_read_offload_rx_data(drv_data, drv_data->msgs);
drv_data->msgs++;
drv_data->num_msgs--;
}
i2c: mv64xxx: rework offload support to fix several problems 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 930ab3d403a ("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: 930ab3d403ae ("i2c: mv64xxx: Add I2C Transaction Generator support") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [wsa: fixed checkpatch warnings] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-12-12 00:33:46 +08:00
/*
* Transaction is a two messages write/read transaction, read
* data for the second (read) message.
*/
else if (drv_data->num_msgs == 2 &&
!(drv_data->msgs[0].flags & I2C_M_RD) &&
drv_data->msgs[1].flags & I2C_M_RD) {
mv64xxx_i2c_read_offload_rx_data(drv_data, drv_data->msgs + 1);
drv_data->msgs += 2;
drv_data->num_msgs -= 2;
}
out:
writel(0, drv_data->reg_base + MV64XXX_I2C_REG_BRIDGE_CONTROL);
writel(0, drv_data->reg_base +
MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE);
drv_data->block = 0;
wake_up(&drv_data->waitq);
return IRQ_HANDLED;
}
static irqreturn_t
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers Maintain a per-CPU global "struct pt_regs *" variable which can be used instead of passing regs around manually through all ~1800 interrupt handlers in the Linux kernel. The regs pointer is used in few places, but it potentially costs both stack space and code to pass it around. On the FRV arch, removing the regs parameter from all the genirq function results in a 20% speed up of the IRQ exit path (ie: from leaving timer_interrupt() to leaving do_IRQ()). Where appropriate, an arch may override the generic storage facility and do something different with the variable. On FRV, for instance, the address is maintained in GR28 at all times inside the kernel as part of general exception handling. Having looked over the code, it appears that the parameter may be handed down through up to twenty or so layers of functions. Consider a USB character device attached to a USB hub, attached to a USB controller that posts its interrupts through a cascaded auxiliary interrupt controller. A character device driver may want to pass regs to the sysrq handler through the input layer which adds another few layers of parameter passing. I've build this code with allyesconfig for x86_64 and i386. I've runtested the main part of the code on FRV and i386, though I can't test most of the drivers. I've also done partial conversion for powerpc and MIPS - these at least compile with minimal configurations. This will affect all archs. Mostly the changes should be relatively easy. Take do_IRQ(), store the regs pointer at the beginning, saving the old one: struct pt_regs *old_regs = set_irq_regs(regs); And put the old one back at the end: set_irq_regs(old_regs); Don't pass regs through to generic_handle_irq() or __do_IRQ(). In timer_interrupt(), this sort of change will be necessary: - update_process_times(user_mode(regs)); - profile_tick(CPU_PROFILING, regs); + update_process_times(user_mode(get_irq_regs())); + profile_tick(CPU_PROFILING); I'd like to move update_process_times()'s use of get_irq_regs() into itself, except that i386, alone of the archs, uses something other than user_mode(). Some notes on the interrupt handling in the drivers: (*) input_dev() is now gone entirely. The regs pointer is no longer stored in the input_dev struct. (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does something different depending on whether it's been supplied with a regs pointer or not. (*) Various IRQ handler function pointers have been moved to type irq_handler_t. Signed-Off-By: David Howells <dhowells@redhat.com> (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 21:55:46 +08:00
mv64xxx_i2c_intr(int irq, void *dev_id)
{
struct mv64xxx_i2c_data *drv_data = dev_id;
unsigned long flags;
u32 status;
irqreturn_t rc = IRQ_NONE;
spin_lock_irqsave(&drv_data->lock, flags);
i2c: mv64xxx: rework offload support to fix several problems 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 930ab3d403a ("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: 930ab3d403ae ("i2c: mv64xxx: Add I2C Transaction Generator support") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [wsa: fixed checkpatch warnings] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-12-12 00:33:46 +08:00
if (drv_data->offload_enabled)
rc = mv64xxx_i2c_intr_offload(drv_data);
while (readl(drv_data->reg_base + drv_data->reg_offsets.control) &
MV64XXX_I2C_REG_CONTROL_IFLG) {
status = readl(drv_data->reg_base + drv_data->reg_offsets.status);
mv64xxx_i2c_fsm(drv_data, status);
mv64xxx_i2c_do_action(drv_data);
if (drv_data->irq_clear_inverted)
writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_IFLG,
drv_data->reg_base + drv_data->reg_offsets.control);
rc = IRQ_HANDLED;
}
spin_unlock_irqrestore(&drv_data->lock, flags);
return rc;
}
/*
*****************************************************************************
*
* I2C Msg Execution Routines
*
*****************************************************************************
*/
static void
mv64xxx_i2c_wait_for_completion(struct mv64xxx_i2c_data *drv_data)
{
long time_left;
unsigned long flags;
char abort = 0;
time_left = wait_event_timeout(drv_data->waitq,
!drv_data->block, drv_data->adapter.timeout);
spin_lock_irqsave(&drv_data->lock, flags);
if (!time_left) { /* Timed out */
drv_data->rc = -ETIMEDOUT;
abort = 1;
} else if (time_left < 0) { /* Interrupted/Error */
drv_data->rc = time_left; /* errno value */
abort = 1;
}
if (abort && drv_data->block) {
drv_data->aborting = 1;
spin_unlock_irqrestore(&drv_data->lock, flags);
time_left = wait_event_timeout(drv_data->waitq,
!drv_data->block, drv_data->adapter.timeout);
if ((time_left <= 0) && drv_data->block) {
drv_data->state = MV64XXX_I2C_STATE_IDLE;
dev_err(&drv_data->adapter.dev,
"mv64xxx: I2C bus locked, block: %d, "
"time_left: %d\n", drv_data->block,
(int)time_left);
mv64xxx_i2c_hw_init(drv_data);
}
} else
spin_unlock_irqrestore(&drv_data->lock, flags);
}
static int
mv64xxx_i2c_execute_msg(struct mv64xxx_i2c_data *drv_data, struct i2c_msg *msg,
int is_last)
{
unsigned long flags;
spin_lock_irqsave(&drv_data->lock, flags);
drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
drv_data->send_stop = is_last;
drv_data->block = 1;
mv64xxx_i2c_send_start(drv_data);
spin_unlock_irqrestore(&drv_data->lock, flags);
mv64xxx_i2c_wait_for_completion(drv_data);
return drv_data->rc;
}
i2c: mv64xxx: rework offload support to fix several problems 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 930ab3d403a ("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: 930ab3d403ae ("i2c: mv64xxx: Add I2C Transaction Generator support") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [wsa: fixed checkpatch warnings] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-12-12 00:33:46 +08:00
static void
mv64xxx_i2c_prepare_tx(struct mv64xxx_i2c_data *drv_data)
{
struct i2c_msg *msg = drv_data->msgs;
u32 buf[2];
memcpy(buf, msg->buf, msg->len);
writel(buf[0], drv_data->reg_base + MV64XXX_I2C_REG_TX_DATA_LO);
writel(buf[1], drv_data->reg_base + MV64XXX_I2C_REG_TX_DATA_HI);
}
static int
mv64xxx_i2c_offload_xfer(struct mv64xxx_i2c_data *drv_data)
{
struct i2c_msg *msgs = drv_data->msgs;
int num = drv_data->num_msgs;
unsigned long ctrl_reg;
unsigned long flags;
spin_lock_irqsave(&drv_data->lock, flags);
/* Build transaction */
ctrl_reg = MV64XXX_I2C_BRIDGE_CONTROL_ENABLE |
(msgs[0].addr << MV64XXX_I2C_BRIDGE_CONTROL_ADDR_SHIFT);
if (msgs[0].flags & I2C_M_TEN)
ctrl_reg |= MV64XXX_I2C_BRIDGE_CONTROL_ADDR_EXT;
/* Single write message transaction */
if (num == 1 && !(msgs[0].flags & I2C_M_RD)) {
size_t len = msgs[0].len - 1;
ctrl_reg |= MV64XXX_I2C_BRIDGE_CONTROL_WR |
(len << MV64XXX_I2C_BRIDGE_CONTROL_TX_SIZE_SHIFT);
mv64xxx_i2c_prepare_tx(drv_data);
}
/* Single read message transaction */
else if (num == 1 && msgs[0].flags & I2C_M_RD) {
size_t len = msgs[0].len - 1;
ctrl_reg |= MV64XXX_I2C_BRIDGE_CONTROL_RD |
(len << MV64XXX_I2C_BRIDGE_CONTROL_RX_SIZE_SHIFT);
}
/*
* Transaction with one write and one read message. This is
* guaranteed by the mv64xx_i2c_can_offload() checks.
*/
else if (num == 2) {
size_t lentx = msgs[0].len - 1;
size_t lenrx = msgs[1].len - 1;
ctrl_reg |=
MV64XXX_I2C_BRIDGE_CONTROL_RD |
MV64XXX_I2C_BRIDGE_CONTROL_WR |
(lentx << MV64XXX_I2C_BRIDGE_CONTROL_TX_SIZE_SHIFT) |
(lenrx << MV64XXX_I2C_BRIDGE_CONTROL_RX_SIZE_SHIFT) |
MV64XXX_I2C_BRIDGE_CONTROL_REPEATED_START;
mv64xxx_i2c_prepare_tx(drv_data);
}
/* Execute transaction */
drv_data->block = 1;
writel(ctrl_reg, drv_data->reg_base + MV64XXX_I2C_REG_BRIDGE_CONTROL);
spin_unlock_irqrestore(&drv_data->lock, flags);
mv64xxx_i2c_wait_for_completion(drv_data);
return drv_data->rc;
}
static bool
mv64xxx_i2c_valid_offload_sz(struct i2c_msg *msg)
{
return msg->len <= 8 && msg->len >= 1;
}
static bool
mv64xxx_i2c_can_offload(struct mv64xxx_i2c_data *drv_data)
{
struct i2c_msg *msgs = drv_data->msgs;
int num = drv_data->num_msgs;
if (!drv_data->offload_enabled)
return false;
/*
* We can offload a transaction consisting of a single
* message, as long as the message has a length between 1 and
* 8 bytes.
*/
if (num == 1 && mv64xxx_i2c_valid_offload_sz(msgs))
return true;
/*
* We can offload a transaction consisting of two messages, if
* the first is a write and a second is a read, and both have
* a length between 1 and 8 bytes.
*/
if (num == 2 &&
mv64xxx_i2c_valid_offload_sz(msgs) &&
mv64xxx_i2c_valid_offload_sz(msgs + 1) &&
!(msgs[0].flags & I2C_M_RD) &&
msgs[1].flags & I2C_M_RD)
return true;
return false;
}
/*
*****************************************************************************
*
* I2C Core Support Routines (Interface to higher level I2C code)
*
*****************************************************************************
*/
static u32
mv64xxx_i2c_functionality(struct i2c_adapter *adap)
{
return I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR | I2C_FUNC_SMBUS_EMUL;
}
static int
mv64xxx_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
{
struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap);
int rc, ret = num;
BUG_ON(drv_data->msgs != NULL);
drv_data->msgs = msgs;
drv_data->num_msgs = num;
i2c: mv64xxx: rework offload support to fix several problems 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 930ab3d403a ("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: 930ab3d403ae ("i2c: mv64xxx: Add I2C Transaction Generator support") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [wsa: fixed checkpatch warnings] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-12-12 00:33:46 +08:00
if (mv64xxx_i2c_can_offload(drv_data))
rc = mv64xxx_i2c_offload_xfer(drv_data);
else
rc = mv64xxx_i2c_execute_msg(drv_data, &msgs[0], num == 1);
if (rc < 0)
ret = rc;
drv_data->num_msgs = 0;
drv_data->msgs = NULL;
return ret;
}
static const struct i2c_algorithm mv64xxx_i2c_algo = {
.master_xfer = mv64xxx_i2c_xfer,
.functionality = mv64xxx_i2c_functionality,
};
/*
*****************************************************************************
*
* Driver Interface & Early Init Routines
*
*****************************************************************************
*/
static const struct of_device_id mv64xxx_i2c_of_match_table[] = {
{ .compatible = "allwinner,sun4i-a10-i2c", .data = &mv64xxx_i2c_regs_sun4i},
{ .compatible = "allwinner,sun6i-a31-i2c", .data = &mv64xxx_i2c_regs_sun4i},
{ .compatible = "marvell,mv64xxx-i2c", .data = &mv64xxx_i2c_regs_mv64xxx},
{ .compatible = "marvell,mv78230-i2c", .data = &mv64xxx_i2c_regs_mv64xxx},
{ .compatible = "marvell,mv78230-a0-i2c", .data = &mv64xxx_i2c_regs_mv64xxx},
{}
};
MODULE_DEVICE_TABLE(of, mv64xxx_i2c_of_match_table);
#ifdef CONFIG_OF
static int
mv64xxx_calc_freq(struct mv64xxx_i2c_data *drv_data,
const int tclk, const int n, const int m)
{
if (drv_data->clk_n_base_0)
return tclk / (10 * (m + 1) * (1 << n));
else
return tclk / (10 * (m + 1) * (2 << n));
}
static bool
mv64xxx_find_baud_factors(struct mv64xxx_i2c_data *drv_data,
const u32 req_freq, const u32 tclk)
{
int freq, delta, best_delta = INT_MAX;
int m, n;
for (n = 0; n <= 7; n++)
for (m = 0; m <= 15; m++) {
freq = mv64xxx_calc_freq(drv_data, tclk, n, m);
delta = req_freq - freq;
if (delta >= 0 && delta < best_delta) {
drv_data->freq_m = m;
drv_data->freq_n = n;
best_delta = delta;
}
if (best_delta == 0)
return true;
}
if (best_delta == INT_MAX)
return false;
return true;
}
static int
mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
struct device *dev)
{
const struct of_device_id *device;
struct device_node *np = dev->of_node;
u32 bus_freq, tclk;
int rc = 0;
/* CLK is mandatory when using DT to describe the i2c bus. We
* need to know tclk in order to calculate bus clock
* factors.
*/
if (IS_ERR(drv_data->clk)) {
rc = -ENODEV;
goto out;
}
tclk = clk_get_rate(drv_data->clk);
if (of_property_read_u32(np, "clock-frequency", &bus_freq))
bus_freq = 100000; /* 100kHz by default */
if (of_device_is_compatible(np, "allwinner,sun4i-a10-i2c") ||
of_device_is_compatible(np, "allwinner,sun6i-a31-i2c"))
drv_data->clk_n_base_0 = true;
if (!mv64xxx_find_baud_factors(drv_data, bus_freq, tclk)) {
rc = -EINVAL;
goto out;
}
drv_data->rstc = devm_reset_control_get_optional(dev, NULL);
if (IS_ERR(drv_data->rstc)) {
rc = PTR_ERR(drv_data->rstc);
goto out;
}
reset_control_deassert(drv_data->rstc);
/* Its not yet defined how timeouts will be specified in device tree.
* So hard code the value to 1 second.
*/
drv_data->adapter.timeout = HZ;
device = of_match_device(mv64xxx_i2c_of_match_table, dev);
if (!device)
return -ENODEV;
memcpy(&drv_data->reg_offsets, device->data, sizeof(drv_data->reg_offsets));
/*
* For controllers embedded in new SoCs activate the
* Transaction Generator support and the errata fix.
*/
if (of_device_is_compatible(np, "marvell,mv78230-i2c")) {
drv_data->offload_enabled = true;
drv_data->errata_delay = true;
}
if (of_device_is_compatible(np, "marvell,mv78230-a0-i2c")) {
drv_data->offload_enabled = false;
drv_data->errata_delay = true;
}
if (of_device_is_compatible(np, "allwinner,sun6i-a31-i2c"))
drv_data->irq_clear_inverted = true;
out:
return rc;
}
#else /* CONFIG_OF */
static int
mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
struct device *dev)
{
return -ENODEV;
}
#endif /* CONFIG_OF */
static int
mv64xxx_i2c_probe(struct platform_device *pd)
{
struct mv64xxx_i2c_data *drv_data;
struct mv64xxx_i2c_pdata *pdata = dev_get_platdata(&pd->dev);
struct resource *r;
int rc;
if ((!pdata && !pd->dev.of_node))
return -ENODEV;
drv_data = devm_kzalloc(&pd->dev, sizeof(struct mv64xxx_i2c_data),
GFP_KERNEL);
if (!drv_data)
return -ENOMEM;
r = platform_get_resource(pd, IORESOURCE_MEM, 0);
drv_data->reg_base = devm_ioremap_resource(&pd->dev, r);
if (IS_ERR(drv_data->reg_base))
return PTR_ERR(drv_data->reg_base);
strlcpy(drv_data->adapter.name, MV64XXX_I2C_CTLR_NAME " adapter",
sizeof(drv_data->adapter.name));
init_waitqueue_head(&drv_data->waitq);
spin_lock_init(&drv_data->lock);
/* Not all platforms have a clk */
drv_data->clk = devm_clk_get(&pd->dev, NULL);
if (IS_ERR(drv_data->clk) && PTR_ERR(drv_data->clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (!IS_ERR(drv_data->clk))
clk_prepare_enable(drv_data->clk);
drv_data->irq = platform_get_irq(pd, 0);
if (pdata) {
drv_data->freq_m = pdata->freq_m;
drv_data->freq_n = pdata->freq_n;
drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
drv_data->offload_enabled = false;
memcpy(&drv_data->reg_offsets, &mv64xxx_i2c_regs_mv64xxx, sizeof(drv_data->reg_offsets));
} else if (pd->dev.of_node) {
rc = mv64xxx_of_config(drv_data, &pd->dev);
if (rc)
goto exit_clk;
}
if (drv_data->irq < 0) {
rc = drv_data->irq;
goto exit_reset;
}
drv_data->adapter.dev.parent = &pd->dev;
drv_data->adapter.algo = &mv64xxx_i2c_algo;
drv_data->adapter.owner = THIS_MODULE;
drv_data->adapter.class = I2C_CLASS_DEPRECATED;
drv_data->adapter.nr = pd->id;
drv_data->adapter.dev.of_node = pd->dev.of_node;
platform_set_drvdata(pd, drv_data);
i2c_set_adapdata(&drv_data->adapter, drv_data);
i2c-mv64xxx: Fix random oops at boot I have a Marvell board which has the same i2c hw block than mv64xxx, so I'm trying to use i2c-mv64xxx driver. But I get the following random oops at boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 Backtrace: [<c0397e4c>] (mv64xxx_i2c_intr+0x0/0x2b8) from [<c02879c4>] (__do_irq+0x4c/0x8c) [<c0287978>] (__do_irq+0x0/0x8c) from [<c0287c0c>] (do_level_IRQ+0x68/0xc0) r8 = C0501E08 r7 = 00000005 r6 = C0501E08 r5 = 00000005 r4 = C048BB78 [<c0287ba4>] (do_level_IRQ+0x0/0xc0) from [<c02885f8>] (asm_do_IRQ+0x50/0x134) r6 = C0449C78 r5 = F1020000 r4 = FFFFFFFF [<c02885a8>] (asm_do_IRQ+0x0/0x134) from [<c02869c4>] (__irq_svc+0x24/0x100) r8 = C1CAC400 r7 = 00000005 r6 = 00000002 r5 = F1020000 r4 = FFFFFFFF [<c0287efc>] (setup_irq+0x0/0x124) from [<c02880d0>] (request_irq+0xb0/0xd0) r7 = C041B2AC r6 = C0397E4C r5 = 00000000 r4 = 00000005 [<c0288020>] (request_irq+0x0/0xd0) from [<c03985f4>] (mv64xxx_i2c_probe+0x148/0x244) [<c03984ac>] (mv64xxx_i2c_probe+0x0/0x244) from [<c038bedc>] (platform_drv_probe+0x20/0x24) The oops is caused by a spurious interrupt that occurs when request_irq is called. mv64xxx_i2c_fsm() tries to read drv_data->msg, which is NULL. I noticed that hardware init is done after requesting irq. Thus any pending irq from previous hardware usage may cause this. The following patch fixes it: Signed-off-by: Maxime Bizon <mbizon@freebox.fr> Acked-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2007-01-06 00:54:05 +08:00
mv64xxx_i2c_hw_init(drv_data);
rc = request_irq(drv_data->irq, mv64xxx_i2c_intr, 0,
MV64XXX_I2C_CTLR_NAME, drv_data);
if (rc) {
dev_err(&drv_data->adapter.dev,
"mv64xxx: Can't register intr handler irq%d: %d\n",
drv_data->irq, rc);
goto exit_reset;
} else if ((rc = i2c_add_numbered_adapter(&drv_data->adapter)) != 0) {
dev_err(&drv_data->adapter.dev,
"mv64xxx: Can't add i2c adapter, rc: %d\n", -rc);
goto exit_free_irq;
}
return 0;
exit_free_irq:
free_irq(drv_data->irq, drv_data);
exit_reset:
reset_control_assert(drv_data->rstc);
exit_clk:
/* Not all platforms have a clk */
if (!IS_ERR(drv_data->clk))
clk_disable_unprepare(drv_data->clk);
return rc;
}
static int
mv64xxx_i2c_remove(struct platform_device *dev)
{
struct mv64xxx_i2c_data *drv_data = platform_get_drvdata(dev);
i2c_del_adapter(&drv_data->adapter);
free_irq(drv_data->irq, drv_data);
reset_control_assert(drv_data->rstc);
/* Not all platforms have a clk */
if (!IS_ERR(drv_data->clk))
clk_disable_unprepare(drv_data->clk);
return 0;
}
#ifdef CONFIG_PM
static int mv64xxx_i2c_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct mv64xxx_i2c_data *drv_data = platform_get_drvdata(pdev);
mv64xxx_i2c_hw_init(drv_data);
return 0;
}
static const struct dev_pm_ops mv64xxx_i2c_pm = {
.resume = mv64xxx_i2c_resume,
};
#define mv64xxx_i2c_pm_ops (&mv64xxx_i2c_pm)
#else
#define mv64xxx_i2c_pm_ops NULL
#endif
static struct platform_driver mv64xxx_i2c_driver = {
.probe = mv64xxx_i2c_probe,
.remove = mv64xxx_i2c_remove,
.driver = {
.name = MV64XXX_I2C_CTLR_NAME,
.pm = mv64xxx_i2c_pm_ops,
.of_match_table = mv64xxx_i2c_of_match_table,
},
};
module_platform_driver(mv64xxx_i2c_driver);
MODULE_AUTHOR("Mark A. Greer <mgreer@mvista.com>");
MODULE_DESCRIPTION("Marvell mv64xxx host bridge i2c ctlr driver");
MODULE_LICENSE("GPL");