2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2007-11-13 01:38:51 +08:00
|
|
|
* 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).
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* 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>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/i2c.h>
|
|
|
|
#include <linux/interrupt.h>
|
2007-11-13 01:38:51 +08:00
|
|
|
#include <linux/mv643xx_i2c.h>
|
2005-10-30 02:07:23 +08:00
|
|
|
#include <linux/platform_device.h>
|
2014-03-05 00:28:37 +08:00
|
|
|
#include <linux/reset.h>
|
2010-05-22 00:41:01 +08:00
|
|
|
#include <linux/io.h>
|
2012-07-22 18:51:35 +08:00
|
|
|
#include <linux/of.h>
|
2013-06-13 00:53:31 +08:00
|
|
|
#include <linux/of_device.h>
|
2012-07-22 18:51:35 +08:00
|
|
|
#include <linux/of_irq.h>
|
|
|
|
#include <linux/clk.h>
|
|
|
|
#include <linux/err.h>
|
2013-08-22 22:19:06 +08:00
|
|
|
#include <linux/delay.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-06-13 00:53:30 +08:00
|
|
|
#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)
|
|
|
|
|
2014-12-12 00:33:45 +08:00
|
|
|
#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)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* 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
|
|
|
|
|
2013-08-22 22:19:05 +08:00
|
|
|
/* 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 */
|
2014-12-12 00:33:45 +08:00
|
|
|
#define MV64XXX_I2C_BRIDGE_CONTROL_WR BIT(0)
|
|
|
|
#define MV64XXX_I2C_BRIDGE_CONTROL_RD BIT(1)
|
2013-08-22 22:19:05 +08:00
|
|
|
#define MV64XXX_I2C_BRIDGE_CONTROL_ADDR_SHIFT 2
|
2014-12-12 00:33:45 +08:00
|
|
|
#define MV64XXX_I2C_BRIDGE_CONTROL_ADDR_EXT BIT(12)
|
2013-08-22 22:19:05 +08:00
|
|
|
#define MV64XXX_I2C_BRIDGE_CONTROL_TX_SIZE_SHIFT 13
|
|
|
|
#define MV64XXX_I2C_BRIDGE_CONTROL_RX_SIZE_SHIFT 16
|
2014-12-12 00:33:45 +08:00
|
|
|
#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)
|
2013-08-22 22:19:05 +08:00
|
|
|
|
|
|
|
/* Bridge Status values */
|
2014-12-12 00:33:45 +08:00
|
|
|
#define MV64XXX_I2C_BRIDGE_STATUS_ERROR BIT(0)
|
2013-08-22 22:19:05 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* Driver states */
|
|
|
|
enum {
|
|
|
|
MV64XXX_I2C_STATE_INVALID,
|
|
|
|
MV64XXX_I2C_STATE_IDLE,
|
|
|
|
MV64XXX_I2C_STATE_WAITING_FOR_START_COND,
|
2010-11-27 00:06:56 +08:00
|
|
|
MV64XXX_I2C_STATE_WAITING_FOR_RESTART,
|
2005-04-17 06:20:36 +08:00
|
|
|
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,
|
2010-11-27 00:06:56 +08:00
|
|
|
MV64XXX_I2C_ACTION_SEND_RESTART,
|
2005-04-17 06:20:36 +08:00
|
|
|
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,
|
|
|
|
};
|
|
|
|
|
2013-06-13 00:53:31 +08:00
|
|
|
struct mv64xxx_i2c_regs {
|
|
|
|
u8 addr;
|
|
|
|
u8 ext_addr;
|
|
|
|
u8 data;
|
|
|
|
u8 control;
|
|
|
|
u8 status;
|
|
|
|
u8 clock;
|
|
|
|
u8 soft_reset;
|
|
|
|
};
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
struct mv64xxx_i2c_data {
|
2013-05-17 04:39:12 +08:00
|
|
|
struct i2c_msg *msgs;
|
|
|
|
int num_msgs;
|
2005-04-17 06:20:36 +08:00
|
|
|
int irq;
|
|
|
|
u32 state;
|
|
|
|
u32 action;
|
2005-12-19 00:22:01 +08:00
|
|
|
u32 aborting;
|
2005-04-17 06:20:36 +08:00
|
|
|
u32 cntl_bits;
|
|
|
|
void __iomem *reg_base;
|
2013-06-13 00:53:31 +08:00
|
|
|
struct mv64xxx_i2c_regs reg_offsets;
|
2005-04-17 06:20:36 +08:00
|
|
|
u32 addr1;
|
|
|
|
u32 addr2;
|
|
|
|
u32 bytes_left;
|
|
|
|
u32 byte_posn;
|
2010-11-27 00:06:56 +08:00
|
|
|
u32 send_stop;
|
2005-04-17 06:20:36 +08:00
|
|
|
u32 block;
|
|
|
|
int rc;
|
|
|
|
u32 freq_m;
|
|
|
|
u32 freq_n;
|
2012-07-22 18:51:35 +08:00
|
|
|
struct clk *clk;
|
2005-04-17 06:20:36 +08:00
|
|
|
wait_queue_head_t waitq;
|
|
|
|
spinlock_t lock;
|
|
|
|
struct i2c_msg *msg;
|
|
|
|
struct i2c_adapter adapter;
|
2013-08-22 22:19:05 +08:00
|
|
|
bool offload_enabled;
|
2013-08-22 22:19:06 +08:00
|
|
|
/* 5us delay in order to avoid repeated start timing violation */
|
|
|
|
bool errata_delay;
|
2014-03-05 00:28:37 +08:00
|
|
|
struct reset_control *rstc;
|
2014-03-05 00:28:38 +08:00
|
|
|
bool irq_clear_inverted;
|
2015-09-27 22:57:08 +08:00
|
|
|
/* Clk div is 2 to the power n, not 2 to the power n + 1 */
|
|
|
|
bool clk_n_base_0;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2013-06-13 00:53:31 +08:00
|
|
|
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,
|
|
|
|
};
|
|
|
|
|
2013-06-13 00:53:32 +08:00
|
|
|
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,
|
|
|
|
};
|
|
|
|
|
2013-05-17 04:38:11 +08:00
|
|
|
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 {
|
2013-06-13 00:53:30 +08:00
|
|
|
drv_data->addr1 = MV64XXX_I2C_ADDR_ADDR((u32)msg->addr) | dir;
|
2013-05-17 04:38:11 +08:00
|
|
|
drv_data->addr2 = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
*****************************************************************************
|
|
|
|
*
|
|
|
|
* Finite State Machine & Interrupt Routines
|
|
|
|
*
|
|
|
|
*****************************************************************************
|
|
|
|
*/
|
2007-08-15 00:37:14 +08:00
|
|
|
|
|
|
|
/* Reset hardware and initialize FSM */
|
|
|
|
static void
|
|
|
|
mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
|
|
|
|
{
|
2013-08-22 22:19:05 +08:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2013-06-13 00:53:31 +08:00
|
|
|
writel(0, drv_data->reg_base + drv_data->reg_offsets.soft_reset);
|
2013-06-13 00:53:30 +08:00
|
|
|
writel(MV64XXX_I2C_BAUD_DIV_M(drv_data->freq_m) | MV64XXX_I2C_BAUD_DIV_N(drv_data->freq_n),
|
2013-06-13 00:53:31 +08:00
|
|
|
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);
|
2007-08-15 00:37:14 +08:00
|
|
|
writel(MV64XXX_I2C_REG_CONTROL_TWSIEN | MV64XXX_I2C_REG_CONTROL_STOP,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.control);
|
2007-08-15 00:37:14 +08:00
|
|
|
drv_data->state = MV64XXX_I2C_STATE_IDLE;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
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 */
|
2005-12-19 00:22:01 +08:00
|
|
|
if ((drv_data->bytes_left == 0)
|
|
|
|
|| (drv_data->aborting
|
|
|
|
&& (drv_data->byte_posn != 0))) {
|
2013-05-17 04:39:12 +08:00
|
|
|
if (drv_data->send_stop || drv_data->aborting) {
|
2010-11-27 00:06:56 +08:00
|
|
|
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;
|
|
|
|
}
|
2005-12-19 00:22:01 +08:00
|
|
|
} else {
|
2005-04-17 06:20:36 +08:00
|
|
|
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;
|
|
|
|
|
2005-12-19 00:22:01 +08:00
|
|
|
if ((drv_data->bytes_left == 1) || drv_data->aborting)
|
2005-04-17 06:20:36 +08:00
|
|
|
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;
|
2013-06-20 05:53:52 +08:00
|
|
|
drv_data->rc = -ENXIO;
|
2005-04-17 06:20:36 +08:00
|
|
|
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;
|
2007-08-15 00:37:14 +08:00
|
|
|
mv64xxx_i2c_hw_init(drv_data);
|
2005-04-17 06:20:36 +08:00
|
|
|
drv_data->rc = -EIO;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-14 04:36:31 +08:00
|
|
|
static void mv64xxx_i2c_send_start(struct mv64xxx_i2c_data *drv_data)
|
|
|
|
{
|
2014-02-14 04:36:33 +08:00
|
|
|
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);
|
2014-02-14 04:36:31 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static void
|
|
|
|
mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
|
|
|
|
{
|
|
|
|
switch(drv_data->action) {
|
2010-11-27 00:06:56 +08:00
|
|
|
case MV64XXX_I2C_ACTION_SEND_RESTART:
|
2013-05-17 04:39:12 +08:00
|
|
|
/* We should only get here if we have further messages */
|
|
|
|
BUG_ON(drv_data->num_msgs == 0);
|
|
|
|
|
|
|
|
drv_data->msgs++;
|
|
|
|
drv_data->num_msgs--;
|
2014-02-14 04:36:31 +08:00
|
|
|
mv64xxx_i2c_send_start(drv_data);
|
2013-05-17 04:39:12 +08:00
|
|
|
|
2013-08-22 22:19:06 +08:00
|
|
|
if (drv_data->errata_delay)
|
|
|
|
udelay(5);
|
|
|
|
|
2013-05-17 04:39:12 +08:00
|
|
|
/*
|
|
|
|
* 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;
|
2010-11-27 00:06:56 +08:00
|
|
|
break;
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
case MV64XXX_I2C_ACTION_CONTINUE:
|
|
|
|
writel(drv_data->cntl_bits,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.control);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case MV64XXX_I2C_ACTION_SEND_ADDR_1:
|
|
|
|
writel(drv_data->addr1,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.data);
|
2005-04-17 06:20:36 +08:00
|
|
|
writel(drv_data->cntl_bits,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.control);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case MV64XXX_I2C_ACTION_SEND_ADDR_2:
|
|
|
|
writel(drv_data->addr2,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.data);
|
2005-04-17 06:20:36 +08:00
|
|
|
writel(drv_data->cntl_bits,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.control);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case MV64XXX_I2C_ACTION_SEND_DATA:
|
|
|
|
writel(drv_data->msg->buf[drv_data->byte_posn++],
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.data);
|
2005-04-17 06:20:36 +08:00
|
|
|
writel(drv_data->cntl_bits,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.control);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case MV64XXX_I2C_ACTION_RCV_DATA:
|
|
|
|
drv_data->msg->buf[drv_data->byte_posn++] =
|
2013-06-13 00:53:31 +08:00
|
|
|
readl(drv_data->reg_base + drv_data->reg_offsets.data);
|
2005-04-17 06:20:36 +08:00
|
|
|
writel(drv_data->cntl_bits,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.control);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case MV64XXX_I2C_ACTION_RCV_DATA_STOP:
|
|
|
|
drv_data->msg->buf[drv_data->byte_posn++] =
|
2013-06-13 00:53:31 +08:00
|
|
|
readl(drv_data->reg_base + drv_data->reg_offsets.data);
|
2005-04-17 06:20:36 +08:00
|
|
|
drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN;
|
|
|
|
writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_STOP,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.control);
|
2005-04-17 06:20:36 +08:00
|
|
|
drv_data->block = 0;
|
2013-08-22 22:19:06 +08:00
|
|
|
if (drv_data->errata_delay)
|
|
|
|
udelay(5);
|
|
|
|
|
2013-05-16 18:30:59 +08:00
|
|
|
wake_up(&drv_data->waitq);
|
2005-04-17 06:20:36 +08:00
|
|
|
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;
|
2013-08-22 22:19:05 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* 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,
|
2013-06-13 00:53:31 +08:00
|
|
|
drv_data->reg_base + drv_data->reg_offsets.control);
|
2005-04-17 06:20:36 +08:00
|
|
|
drv_data->block = 0;
|
2013-05-16 18:30:59 +08:00
|
|
|
wake_up(&drv_data->waitq);
|
2005-04-17 06:20:36 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
}
|
2013-08-22 22:19:05 +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--;
|
2005-04-17 06:20:36 +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
|
|
|
/*
|
|
|
|
* 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;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2009-09-07 18:00:13 +08:00
|
|
|
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)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct mv64xxx_i2c_data *drv_data = dev_id;
|
|
|
|
unsigned long flags;
|
|
|
|
u32 status;
|
2009-09-07 18:00:13 +08:00
|
|
|
irqreturn_t rc = IRQ_NONE;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
spin_lock_irqsave(&drv_data->lock, flags);
|
2013-08-22 22:19:05 +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
|
|
|
if (drv_data->offload_enabled)
|
|
|
|
rc = mv64xxx_i2c_intr_offload(drv_data);
|
|
|
|
|
2013-06-13 00:53:31 +08:00
|
|
|
while (readl(drv_data->reg_base + drv_data->reg_offsets.control) &
|
2005-04-17 06:20:36 +08:00
|
|
|
MV64XXX_I2C_REG_CONTROL_IFLG) {
|
2013-06-13 00:53:31 +08:00
|
|
|
status = readl(drv_data->reg_base + drv_data->reg_offsets.status);
|
2005-04-17 06:20:36 +08:00
|
|
|
mv64xxx_i2c_fsm(drv_data, status);
|
|
|
|
mv64xxx_i2c_do_action(drv_data);
|
2014-03-05 00:28:38 +08:00
|
|
|
|
|
|
|
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);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
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;
|
|
|
|
|
2013-05-16 18:30:59 +08:00
|
|
|
time_left = wait_event_timeout(drv_data->waitq,
|
2009-03-29 04:34:43 +08:00
|
|
|
!drv_data->block, drv_data->adapter.timeout);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
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) {
|
2005-12-19 00:22:01 +08:00
|
|
|
drv_data->aborting = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
spin_unlock_irqrestore(&drv_data->lock, flags);
|
|
|
|
|
|
|
|
time_left = wait_event_timeout(drv_data->waitq,
|
2009-03-29 04:34:43 +08:00
|
|
|
!drv_data->block, drv_data->adapter.timeout);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-12-19 00:22:01 +08:00
|
|
|
if ((time_left <= 0) && drv_data->block) {
|
2005-04-17 06:20:36 +08:00
|
|
|
drv_data->state = MV64XXX_I2C_STATE_IDLE;
|
|
|
|
dev_err(&drv_data->adapter.dev,
|
2005-12-19 00:22:01 +08:00
|
|
|
"mv64xxx: I2C bus locked, block: %d, "
|
|
|
|
"time_left: %d\n", drv_data->block,
|
|
|
|
(int)time_left);
|
2007-08-15 00:37:14 +08:00
|
|
|
mv64xxx_i2c_hw_init(drv_data);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
} else
|
|
|
|
spin_unlock_irqrestore(&drv_data->lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2010-11-27 00:06:56 +08:00
|
|
|
mv64xxx_i2c_execute_msg(struct mv64xxx_i2c_data *drv_data, struct i2c_msg *msg,
|
2013-05-17 04:39:12 +08:00
|
|
|
int is_last)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&drv_data->lock, flags);
|
|
|
|
|
2014-02-14 04:36:29 +08:00
|
|
|
drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
|
|
|
|
|
2010-11-27 00:06:56 +08:00
|
|
|
drv_data->send_stop = is_last;
|
2005-04-17 06:20:36 +08:00
|
|
|
drv_data->block = 1;
|
2014-02-14 04:36:32 +08:00
|
|
|
mv64xxx_i2c_send_start(drv_data);
|
2005-04-17 06:20:36 +08:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
*****************************************************************************
|
|
|
|
*
|
|
|
|
* 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);
|
2013-05-17 04:39:12 +08:00
|
|
|
int rc, ret = num;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-05-17 04:39:12 +08:00
|
|
|
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);
|
|
|
|
|
2013-05-17 04:39:12 +08:00
|
|
|
if (rc < 0)
|
|
|
|
ret = rc;
|
|
|
|
|
|
|
|
drv_data->num_msgs = 0;
|
|
|
|
drv_data->msgs = NULL;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-05-17 04:39:12 +08:00
|
|
|
return ret;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2006-09-04 04:39:46 +08:00
|
|
|
static const struct i2c_algorithm mv64xxx_i2c_algo = {
|
2005-04-17 06:20:36 +08:00
|
|
|
.master_xfer = mv64xxx_i2c_xfer,
|
|
|
|
.functionality = mv64xxx_i2c_functionality,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
*****************************************************************************
|
|
|
|
*
|
|
|
|
* Driver Interface & Early Init Routines
|
|
|
|
*
|
|
|
|
*****************************************************************************
|
|
|
|
*/
|
2013-06-13 00:53:31 +08:00
|
|
|
static const struct of_device_id mv64xxx_i2c_of_match_table[] = {
|
2014-03-31 20:54:57 +08:00
|
|
|
{ .compatible = "allwinner,sun4i-a10-i2c", .data = &mv64xxx_i2c_regs_sun4i},
|
2014-03-05 00:28:38 +08:00
|
|
|
{ .compatible = "allwinner,sun6i-a31-i2c", .data = &mv64xxx_i2c_regs_sun4i},
|
2013-06-13 00:53:31 +08:00
|
|
|
{ .compatible = "marvell,mv64xxx-i2c", .data = &mv64xxx_i2c_regs_mv64xxx},
|
2013-08-22 22:19:05 +08:00
|
|
|
{ .compatible = "marvell,mv78230-i2c", .data = &mv64xxx_i2c_regs_mv64xxx},
|
2013-12-31 23:59:33 +08:00
|
|
|
{ .compatible = "marvell,mv78230-a0-i2c", .data = &mv64xxx_i2c_regs_mv64xxx},
|
2013-06-13 00:53:31 +08:00
|
|
|
{}
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, mv64xxx_i2c_of_match_table);
|
|
|
|
|
2012-07-22 18:51:35 +08:00
|
|
|
#ifdef CONFIG_OF
|
2012-11-28 04:59:38 +08:00
|
|
|
static int
|
2015-09-27 22:57:08 +08:00
|
|
|
mv64xxx_calc_freq(struct mv64xxx_i2c_data *drv_data,
|
|
|
|
const int tclk, const int n, const int m)
|
2012-07-22 18:51:35 +08:00
|
|
|
{
|
2015-09-27 22:57:08 +08:00
|
|
|
if (drv_data->clk_n_base_0)
|
|
|
|
return tclk / (10 * (m + 1) * (1 << n));
|
|
|
|
else
|
|
|
|
return tclk / (10 * (m + 1) * (2 << n));
|
2012-07-22 18:51:35 +08:00
|
|
|
}
|
|
|
|
|
2012-11-28 04:59:38 +08:00
|
|
|
static bool
|
2015-09-27 22:57:08 +08:00
|
|
|
mv64xxx_find_baud_factors(struct mv64xxx_i2c_data *drv_data,
|
|
|
|
const u32 req_freq, const u32 tclk)
|
2012-07-22 18:51:35 +08:00
|
|
|
{
|
|
|
|
int freq, delta, best_delta = INT_MAX;
|
|
|
|
int m, n;
|
|
|
|
|
|
|
|
for (n = 0; n <= 7; n++)
|
|
|
|
for (m = 0; m <= 15; m++) {
|
2015-09-27 22:57:08 +08:00
|
|
|
freq = mv64xxx_calc_freq(drv_data, tclk, n, m);
|
2012-07-22 18:51:35 +08:00
|
|
|
delta = req_freq - freq;
|
|
|
|
if (delta >= 0 && delta < best_delta) {
|
2015-09-27 22:57:08 +08:00
|
|
|
drv_data->freq_m = m;
|
|
|
|
drv_data->freq_n = n;
|
2012-07-22 18:51:35 +08:00
|
|
|
best_delta = delta;
|
|
|
|
}
|
|
|
|
if (best_delta == 0)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (best_delta == INT_MAX)
|
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-11-28 04:59:38 +08:00
|
|
|
static int
|
2012-07-22 18:51:35 +08:00
|
|
|
mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
|
2013-06-13 00:53:31 +08:00
|
|
|
struct device *dev)
|
2012-07-22 18:51:35 +08:00
|
|
|
{
|
2013-09-18 20:50:52 +08:00
|
|
|
const struct of_device_id *device;
|
|
|
|
struct device_node *np = dev->of_node;
|
|
|
|
u32 bus_freq, tclk;
|
|
|
|
int rc = 0;
|
|
|
|
|
i2c: mv64xxx: remove CONFIG_HAVE_CLK conditionals
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: Wolfram Sang <wsa@the-dreams.de>
2016-04-22 21:19:54 +08:00
|
|
|
/* CLK is mandatory when using DT to describe the i2c bus. We
|
|
|
|
* need to know tclk in order to calculate bus clock
|
|
|
|
* factors.
|
|
|
|
*/
|
2012-07-22 18:51:35 +08:00
|
|
|
if (IS_ERR(drv_data->clk)) {
|
|
|
|
rc = -ENODEV;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
tclk = clk_get_rate(drv_data->clk);
|
2013-06-21 21:32:06 +08:00
|
|
|
|
2014-09-01 22:28:13 +08:00
|
|
|
if (of_property_read_u32(np, "clock-frequency", &bus_freq))
|
2013-06-21 21:32:06 +08:00
|
|
|
bus_freq = 100000; /* 100kHz by default */
|
|
|
|
|
2015-09-27 22:57:08 +08:00
|
|
|
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)) {
|
2012-07-22 18:51:35 +08:00
|
|
|
rc = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2014-03-10 19:12:10 +08:00
|
|
|
drv_data->rstc = devm_reset_control_get_optional(dev, NULL);
|
2014-03-05 00:28:37 +08:00
|
|
|
if (IS_ERR(drv_data->rstc)) {
|
2017-03-15 19:31:34 +08:00
|
|
|
rc = PTR_ERR(drv_data->rstc);
|
|
|
|
goto out;
|
2014-03-05 00:28:37 +08:00
|
|
|
}
|
2017-03-15 19:31:34 +08:00
|
|
|
reset_control_deassert(drv_data->rstc);
|
2014-03-05 00:28:37 +08:00
|
|
|
|
2012-07-22 18:51:35 +08:00
|
|
|
/* 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;
|
2013-06-13 00:53:31 +08:00
|
|
|
|
|
|
|
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));
|
|
|
|
|
2013-08-22 22:19:05 +08:00
|
|
|
/*
|
|
|
|
* For controllers embedded in new SoCs activate the
|
2013-08-22 22:19:06 +08:00
|
|
|
* Transaction Generator support and the errata fix.
|
2013-08-22 22:19:05 +08:00
|
|
|
*/
|
2013-08-22 22:19:06 +08:00
|
|
|
if (of_device_is_compatible(np, "marvell,mv78230-i2c")) {
|
2013-08-22 22:19:05 +08:00
|
|
|
drv_data->offload_enabled = true;
|
2013-08-22 22:19:06 +08:00
|
|
|
drv_data->errata_delay = true;
|
|
|
|
}
|
2013-08-22 22:19:05 +08:00
|
|
|
|
2013-12-31 23:59:33 +08:00
|
|
|
if (of_device_is_compatible(np, "marvell,mv78230-a0-i2c")) {
|
|
|
|
drv_data->offload_enabled = false;
|
|
|
|
drv_data->errata_delay = true;
|
|
|
|
}
|
2014-03-05 00:28:38 +08:00
|
|
|
|
|
|
|
if (of_device_is_compatible(np, "allwinner,sun6i-a31-i2c"))
|
|
|
|
drv_data->irq_clear_inverted = true;
|
|
|
|
|
2012-07-22 18:51:35 +08:00
|
|
|
out:
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
#else /* CONFIG_OF */
|
2012-11-28 04:59:38 +08:00
|
|
|
static int
|
2012-07-22 18:51:35 +08:00
|
|
|
mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
|
2013-06-13 00:53:31 +08:00
|
|
|
struct device *dev)
|
2012-07-22 18:51:35 +08:00
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_OF */
|
|
|
|
|
2012-11-28 04:59:38 +08:00
|
|
|
static int
|
2005-11-10 06:32:44 +08:00
|
|
|
mv64xxx_i2c_probe(struct platform_device *pd)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct mv64xxx_i2c_data *drv_data;
|
2013-07-30 15:59:33 +08:00
|
|
|
struct mv64xxx_i2c_pdata *pdata = dev_get_platdata(&pd->dev);
|
2013-05-17 04:33:09 +08:00
|
|
|
struct resource *r;
|
2005-04-17 06:20:36 +08:00
|
|
|
int rc;
|
|
|
|
|
2012-07-22 18:51:35 +08:00
|
|
|
if ((!pdata && !pd->dev.of_node))
|
2005-04-17 06:20:36 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
2013-05-17 04:35:10 +08:00
|
|
|
drv_data = devm_kzalloc(&pd->dev, sizeof(struct mv64xxx_i2c_data),
|
|
|
|
GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!drv_data)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2013-05-17 04:33:09 +08:00
|
|
|
r = platform_get_resource(pd, IORESOURCE_MEM, 0);
|
|
|
|
drv_data->reg_base = devm_ioremap_resource(&pd->dev, r);
|
2013-05-17 04:35:10 +08:00
|
|
|
if (IS_ERR(drv_data->reg_base))
|
|
|
|
return PTR_ERR(drv_data->reg_base);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-12-19 00:22:01 +08:00
|
|
|
strlcpy(drv_data->adapter.name, MV64XXX_I2C_CTLR_NAME " adapter",
|
2007-05-02 05:26:28 +08:00
|
|
|
sizeof(drv_data->adapter.name));
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
init_waitqueue_head(&drv_data->waitq);
|
|
|
|
spin_lock_init(&drv_data->lock);
|
|
|
|
|
2012-07-22 18:51:35 +08:00
|
|
|
/* Not all platforms have a clk */
|
2013-05-17 04:34:10 +08:00
|
|
|
drv_data->clk = devm_clk_get(&pd->dev, NULL);
|
i2c: mv64xxx: handle probe deferral for the clock
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-04-22 21:19:52 +08:00
|
|
|
if (IS_ERR(drv_data->clk) && PTR_ERR(drv_data->clk) == -EPROBE_DEFER)
|
|
|
|
return -EPROBE_DEFER;
|
2016-04-22 21:19:53 +08:00
|
|
|
if (!IS_ERR(drv_data->clk))
|
|
|
|
clk_prepare_enable(drv_data->clk);
|
i2c: mv64xxx: remove CONFIG_HAVE_CLK conditionals
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: Wolfram Sang <wsa@the-dreams.de>
2016-04-22 21:19:54 +08:00
|
|
|
|
2017-05-16 20:07:24 +08:00
|
|
|
drv_data->irq = platform_get_irq(pd, 0);
|
|
|
|
|
2012-07-22 18:51:35 +08:00
|
|
|
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);
|
2013-08-22 22:19:05 +08:00
|
|
|
drv_data->offload_enabled = false;
|
2013-06-13 00:53:31 +08:00
|
|
|
memcpy(&drv_data->reg_offsets, &mv64xxx_i2c_regs_mv64xxx, sizeof(drv_data->reg_offsets));
|
2012-07-22 18:51:35 +08:00
|
|
|
} else if (pd->dev.of_node) {
|
2013-06-13 00:53:31 +08:00
|
|
|
rc = mv64xxx_of_config(drv_data, &pd->dev);
|
2012-07-22 18:51:35 +08:00
|
|
|
if (rc)
|
2013-05-17 04:35:10 +08:00
|
|
|
goto exit_clk;
|
2012-07-22 18:51:35 +08:00
|
|
|
}
|
2006-01-20 01:56:29 +08:00
|
|
|
if (drv_data->irq < 0) {
|
2017-05-16 20:07:24 +08:00
|
|
|
rc = drv_data->irq;
|
2014-03-05 00:28:37 +08:00
|
|
|
goto exit_reset;
|
2006-01-20 01:56:29 +08:00
|
|
|
}
|
2012-07-22 18:51:35 +08:00
|
|
|
|
2007-02-14 05:09:03 +08:00
|
|
|
drv_data->adapter.dev.parent = &pd->dev;
|
2005-04-17 06:20:36 +08:00
|
|
|
drv_data->adapter.algo = &mv64xxx_i2c_algo;
|
|
|
|
drv_data->adapter.owner = THIS_MODULE;
|
2014-07-10 19:46:27 +08:00
|
|
|
drv_data->adapter.class = I2C_CLASS_DEPRECATED;
|
2007-07-12 20:12:29 +08:00
|
|
|
drv_data->adapter.nr = pd->id;
|
2012-07-22 18:51:35 +08:00
|
|
|
drv_data->adapter.dev.of_node = pd->dev.of_node;
|
2005-11-10 06:32:44 +08:00
|
|
|
platform_set_drvdata(pd, drv_data);
|
2005-04-17 06:20:36 +08:00
|
|
|
i2c_set_adapdata(&drv_data->adapter, drv_data);
|
|
|
|
|
2007-01-06 00:54:05 +08:00
|
|
|
mv64xxx_i2c_hw_init(drv_data);
|
|
|
|
|
2013-05-17 04:36:11 +08:00
|
|
|
rc = request_irq(drv_data->irq, mv64xxx_i2c_intr, 0,
|
|
|
|
MV64XXX_I2C_CTLR_NAME, drv_data);
|
|
|
|
if (rc) {
|
2005-12-17 03:08:43 +08:00
|
|
|
dev_err(&drv_data->adapter.dev,
|
2013-05-17 04:36:11 +08:00
|
|
|
"mv64xxx: Can't register intr handler irq%d: %d\n",
|
|
|
|
drv_data->irq, rc);
|
2014-03-05 00:28:37 +08:00
|
|
|
goto exit_reset;
|
2007-07-12 20:12:29 +08:00
|
|
|
} else if ((rc = i2c_add_numbered_adapter(&drv_data->adapter)) != 0) {
|
2005-12-17 03:08:43 +08:00
|
|
|
dev_err(&drv_data->adapter.dev,
|
|
|
|
"mv64xxx: Can't add i2c adapter, rc: %d\n", -rc);
|
2005-04-17 06:20:36 +08:00
|
|
|
goto exit_free_irq;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2013-05-17 04:35:10 +08:00
|
|
|
exit_free_irq:
|
|
|
|
free_irq(drv_data->irq, drv_data);
|
2014-03-05 00:28:37 +08:00
|
|
|
exit_reset:
|
2017-03-15 19:31:34 +08:00
|
|
|
reset_control_assert(drv_data->rstc);
|
2013-05-17 04:35:10 +08:00
|
|
|
exit_clk:
|
2012-07-22 18:51:35 +08:00
|
|
|
/* Not all platforms have a clk */
|
2016-04-22 21:19:53 +08:00
|
|
|
if (!IS_ERR(drv_data->clk))
|
|
|
|
clk_disable_unprepare(drv_data->clk);
|
i2c: mv64xxx: remove CONFIG_HAVE_CLK conditionals
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: Wolfram Sang <wsa@the-dreams.de>
2016-04-22 21:19:54 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2012-11-28 04:59:38 +08:00
|
|
|
static int
|
2005-11-10 06:32:44 +08:00
|
|
|
mv64xxx_i2c_remove(struct platform_device *dev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2005-11-10 06:32:44 +08:00
|
|
|
struct mv64xxx_i2c_data *drv_data = platform_get_drvdata(dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-03-09 16:16:46 +08:00
|
|
|
i2c_del_adapter(&drv_data->adapter);
|
2005-04-17 06:20:36 +08:00
|
|
|
free_irq(drv_data->irq, drv_data);
|
2017-03-15 19:31:34 +08:00
|
|
|
reset_control_assert(drv_data->rstc);
|
2012-07-22 18:51:35 +08:00
|
|
|
/* Not all platforms have a clk */
|
2016-04-22 21:19:53 +08:00
|
|
|
if (!IS_ERR(drv_data->clk))
|
|
|
|
clk_disable_unprepare(drv_data->clk);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-03-09 16:16:46 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2016-12-22 23:54:02 +08:00
|
|
|
#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
|
|
|
|
|
2005-11-10 06:32:44 +08:00
|
|
|
static struct platform_driver mv64xxx_i2c_driver = {
|
2005-04-17 06:20:36 +08:00
|
|
|
.probe = mv64xxx_i2c_probe,
|
2012-11-28 04:59:38 +08:00
|
|
|
.remove = mv64xxx_i2c_remove,
|
2005-11-10 06:32:44 +08:00
|
|
|
.driver = {
|
|
|
|
.name = MV64XXX_I2C_CTLR_NAME,
|
2016-12-22 23:54:02 +08:00
|
|
|
.pm = mv64xxx_i2c_pm_ops,
|
2013-09-30 11:34:25 +08:00
|
|
|
.of_match_table = mv64xxx_i2c_of_match_table,
|
2005-11-10 06:32:44 +08:00
|
|
|
},
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2012-01-13 03:32:04 +08:00
|
|
|
module_platform_driver(mv64xxx_i2c_driver);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
MODULE_AUTHOR("Mark A. Greer <mgreer@mvista.com>");
|
|
|
|
MODULE_DESCRIPTION("Marvell mv64xxx host bridge i2c ctlr driver");
|
|
|
|
MODULE_LICENSE("GPL");
|