2018-05-07 05:58:06 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2008-03-27 03:40:49 +08:00
|
|
|
/*
|
2011-09-22 17:22:12 +08:00
|
|
|
* i2c driver for Freescale i.MX series
|
2008-03-27 03:40:49 +08:00
|
|
|
*
|
|
|
|
* (c) 2007 Pengutronix, Sascha Hauer <s.hauer@pengutronix.de>
|
2011-09-22 17:22:12 +08:00
|
|
|
* (c) 2011 Marek Vasut <marek.vasut@gmail.com>
|
2020-07-02 11:13:00 +08:00
|
|
|
* Copyright 2020 NXP
|
2011-09-22 17:22:12 +08:00
|
|
|
*
|
|
|
|
* Based on i2c-imx.c from linux kernel:
|
|
|
|
* Copyright (C) 2005 Torsten Koschorrek <koschorrek at synertronixx.de>
|
|
|
|
* Copyright (C) 2005 Matthias Blaschke <blaschke at synertronixx.de>
|
|
|
|
* Copyright (C) 2007 RightHand Technologies, Inc.
|
|
|
|
* Copyright (C) 2008 Darius Augulis <darius.augulis at teltonika.lt>
|
|
|
|
*
|
2008-03-27 03:40:49 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <common.h>
|
2020-05-11 01:40:05 +08:00
|
|
|
#include <log.h>
|
2011-01-04 06:27:39 +08:00
|
|
|
#include <asm/arch/clock.h>
|
2011-03-14 22:43:56 +08:00
|
|
|
#include <asm/arch/imx-regs.h>
|
2020-10-31 11:38:53 +08:00
|
|
|
#include <asm/global_data.h>
|
2020-02-03 22:36:16 +08:00
|
|
|
#include <dm/device_compat.h>
|
2020-05-11 01:40:11 +08:00
|
|
|
#include <linux/delay.h>
|
2016-09-21 10:28:55 +08:00
|
|
|
#include <linux/errno.h>
|
2017-06-29 16:16:06 +08:00
|
|
|
#include <asm/mach-imx/mxc_i2c.h>
|
2020-05-01 22:08:35 +08:00
|
|
|
#include <asm/mach-imx/sys_proto.h>
|
2012-07-19 16:18:03 +08:00
|
|
|
#include <asm/io.h>
|
2011-10-26 08:05:44 +08:00
|
|
|
#include <i2c.h>
|
2012-07-19 16:18:09 +08:00
|
|
|
#include <watchdog.h>
|
2015-05-15 07:29:12 +08:00
|
|
|
#include <dm.h>
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
#include <dm/pinctrl.h>
|
2015-05-15 07:29:12 +08:00
|
|
|
#include <fdtdec.h>
|
2008-03-27 03:40:49 +08:00
|
|
|
|
2014-02-11 06:02:52 +08:00
|
|
|
DECLARE_GLOBAL_DATA_PTR;
|
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
#define I2C_QUIRK_FLAG (1 << 0)
|
|
|
|
|
|
|
|
#define IMX_I2C_REGSHIFT 2
|
|
|
|
#define VF610_I2C_REGSHIFT 0
|
2016-06-08 18:24:51 +08:00
|
|
|
|
|
|
|
#define I2C_EARLY_INIT_INDEX 0
|
|
|
|
#ifdef CONFIG_SYS_I2C_IFDR_DIV
|
|
|
|
#define I2C_IFDR_DIV_CONSERVATIVE CONFIG_SYS_I2C_IFDR_DIV
|
|
|
|
#else
|
|
|
|
#define I2C_IFDR_DIV_CONSERVATIVE 0x7e
|
|
|
|
#endif
|
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
/* Register index */
|
|
|
|
#define IADR 0
|
|
|
|
#define IFDR 1
|
|
|
|
#define I2CR 2
|
|
|
|
#define I2SR 3
|
|
|
|
#define I2DR 4
|
2008-03-27 03:40:49 +08:00
|
|
|
|
|
|
|
#define I2CR_IIEN (1 << 6)
|
|
|
|
#define I2CR_MSTA (1 << 5)
|
|
|
|
#define I2CR_MTX (1 << 4)
|
|
|
|
#define I2CR_TX_NO_AK (1 << 3)
|
|
|
|
#define I2CR_RSTA (1 << 2)
|
|
|
|
|
|
|
|
#define I2SR_ICF (1 << 7)
|
|
|
|
#define I2SR_IBB (1 << 5)
|
2012-07-19 16:18:15 +08:00
|
|
|
#define I2SR_IAL (1 << 4)
|
2008-03-27 03:40:49 +08:00
|
|
|
#define I2SR_IIF (1 << 1)
|
|
|
|
#define I2SR_RX_NO_AK (1 << 0)
|
|
|
|
|
2013-06-17 15:30:39 +08:00
|
|
|
#ifdef I2C_QUIRK_REG
|
|
|
|
#define I2CR_IEN (0 << 7)
|
|
|
|
#define I2CR_IDIS (1 << 7)
|
|
|
|
#define I2SR_IIF_CLEAR (1 << 1)
|
|
|
|
#else
|
|
|
|
#define I2CR_IEN (1 << 7)
|
|
|
|
#define I2CR_IDIS (0 << 7)
|
|
|
|
#define I2SR_IIF_CLEAR (0 << 1)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef I2C_QUIRK_REG
|
|
|
|
static u16 i2c_clk_div[60][2] = {
|
|
|
|
{ 20, 0x00 }, { 22, 0x01 }, { 24, 0x02 }, { 26, 0x03 },
|
|
|
|
{ 28, 0x04 }, { 30, 0x05 }, { 32, 0x09 }, { 34, 0x06 },
|
|
|
|
{ 36, 0x0A }, { 40, 0x07 }, { 44, 0x0C }, { 48, 0x0D },
|
|
|
|
{ 52, 0x43 }, { 56, 0x0E }, { 60, 0x45 }, { 64, 0x12 },
|
|
|
|
{ 68, 0x0F }, { 72, 0x13 }, { 80, 0x14 }, { 88, 0x15 },
|
|
|
|
{ 96, 0x19 }, { 104, 0x16 }, { 112, 0x1A }, { 128, 0x17 },
|
|
|
|
{ 136, 0x4F }, { 144, 0x1C }, { 160, 0x1D }, { 176, 0x55 },
|
|
|
|
{ 192, 0x1E }, { 208, 0x56 }, { 224, 0x22 }, { 228, 0x24 },
|
|
|
|
{ 240, 0x1F }, { 256, 0x23 }, { 288, 0x5C }, { 320, 0x25 },
|
|
|
|
{ 384, 0x26 }, { 448, 0x2A }, { 480, 0x27 }, { 512, 0x2B },
|
|
|
|
{ 576, 0x2C }, { 640, 0x2D }, { 768, 0x31 }, { 896, 0x32 },
|
|
|
|
{ 960, 0x2F }, { 1024, 0x33 }, { 1152, 0x34 }, { 1280, 0x35 },
|
|
|
|
{ 1536, 0x36 }, { 1792, 0x3A }, { 1920, 0x37 }, { 2048, 0x3B },
|
|
|
|
{ 2304, 0x3C }, { 2560, 0x3D }, { 3072, 0x3E }, { 3584, 0x7A },
|
|
|
|
{ 3840, 0x3F }, { 4096, 0x7B }, { 5120, 0x7D }, { 6144, 0x7E },
|
|
|
|
};
|
|
|
|
#else
|
2011-09-22 17:22:12 +08:00
|
|
|
static u16 i2c_clk_div[50][2] = {
|
|
|
|
{ 22, 0x20 }, { 24, 0x21 }, { 26, 0x22 }, { 28, 0x23 },
|
|
|
|
{ 30, 0x00 }, { 32, 0x24 }, { 36, 0x25 }, { 40, 0x26 },
|
|
|
|
{ 42, 0x03 }, { 44, 0x27 }, { 48, 0x28 }, { 52, 0x05 },
|
|
|
|
{ 56, 0x29 }, { 60, 0x06 }, { 64, 0x2A }, { 72, 0x2B },
|
|
|
|
{ 80, 0x2C }, { 88, 0x09 }, { 96, 0x2D }, { 104, 0x0A },
|
|
|
|
{ 112, 0x2E }, { 128, 0x2F }, { 144, 0x0C }, { 160, 0x30 },
|
|
|
|
{ 192, 0x31 }, { 224, 0x32 }, { 240, 0x0F }, { 256, 0x33 },
|
|
|
|
{ 288, 0x10 }, { 320, 0x34 }, { 384, 0x35 }, { 448, 0x36 },
|
|
|
|
{ 480, 0x13 }, { 512, 0x37 }, { 576, 0x14 }, { 640, 0x38 },
|
|
|
|
{ 768, 0x39 }, { 896, 0x3A }, { 960, 0x17 }, { 1024, 0x3B },
|
|
|
|
{ 1152, 0x18 }, { 1280, 0x3C }, { 1536, 0x3D }, { 1792, 0x3E },
|
|
|
|
{ 1920, 0x1B }, { 2048, 0x3F }, { 2304, 0x1C }, { 2560, 0x1D },
|
|
|
|
{ 3072, 0x1E }, { 3840, 0x1F }
|
|
|
|
};
|
2013-06-17 15:30:39 +08:00
|
|
|
#endif
|
2011-09-22 17:22:12 +08:00
|
|
|
|
2013-09-22 00:13:35 +08:00
|
|
|
#ifndef CONFIG_SYS_MXC_I2C1_SPEED
|
|
|
|
#define CONFIG_SYS_MXC_I2C1_SPEED 100000
|
|
|
|
#endif
|
|
|
|
#ifndef CONFIG_SYS_MXC_I2C2_SPEED
|
|
|
|
#define CONFIG_SYS_MXC_I2C2_SPEED 100000
|
|
|
|
#endif
|
|
|
|
#ifndef CONFIG_SYS_MXC_I2C3_SPEED
|
|
|
|
#define CONFIG_SYS_MXC_I2C3_SPEED 100000
|
|
|
|
#endif
|
2015-03-21 01:20:40 +08:00
|
|
|
#ifndef CONFIG_SYS_MXC_I2C4_SPEED
|
|
|
|
#define CONFIG_SYS_MXC_I2C4_SPEED 100000
|
|
|
|
#endif
|
2013-09-22 00:13:35 +08:00
|
|
|
|
|
|
|
#ifndef CONFIG_SYS_MXC_I2C1_SLAVE
|
|
|
|
#define CONFIG_SYS_MXC_I2C1_SLAVE 0
|
|
|
|
#endif
|
|
|
|
#ifndef CONFIG_SYS_MXC_I2C2_SLAVE
|
|
|
|
#define CONFIG_SYS_MXC_I2C2_SLAVE 0
|
|
|
|
#endif
|
|
|
|
#ifndef CONFIG_SYS_MXC_I2C3_SLAVE
|
|
|
|
#define CONFIG_SYS_MXC_I2C3_SLAVE 0
|
|
|
|
#endif
|
2015-03-21 01:20:40 +08:00
|
|
|
#ifndef CONFIG_SYS_MXC_I2C4_SLAVE
|
|
|
|
#define CONFIG_SYS_MXC_I2C4_SLAVE 0
|
|
|
|
#endif
|
2013-09-22 00:13:35 +08:00
|
|
|
|
2011-09-22 17:22:12 +08:00
|
|
|
/*
|
|
|
|
* Calculate and set proper clock divider
|
|
|
|
*/
|
2015-05-15 07:29:12 +08:00
|
|
|
static uint8_t i2c_imx_get_clk(struct mxc_i2c_bus *i2c_bus, unsigned int rate)
|
2008-03-27 03:40:49 +08:00
|
|
|
{
|
2011-09-22 17:22:12 +08:00
|
|
|
unsigned int i2c_clk_rate;
|
|
|
|
unsigned int div;
|
2011-10-26 08:05:44 +08:00
|
|
|
u8 clk_div;
|
2008-03-27 03:40:49 +08:00
|
|
|
|
2011-01-04 06:27:39 +08:00
|
|
|
#if defined(CONFIG_MX31)
|
2011-01-20 15:50:44 +08:00
|
|
|
struct clock_control_regs *sc_regs =
|
|
|
|
(struct clock_control_regs *)CCM_BASE;
|
2011-09-22 17:22:12 +08:00
|
|
|
|
2009-02-13 16:23:36 +08:00
|
|
|
/* start the required I2C clock */
|
2012-04-25 01:33:25 +08:00
|
|
|
writel(readl(&sc_regs->cgr0) | (3 << CONFIG_SYS_I2C_CLK_OFFSET),
|
2011-01-20 15:50:44 +08:00
|
|
|
&sc_regs->cgr0);
|
2011-01-04 06:27:39 +08:00
|
|
|
#endif
|
2009-02-13 16:23:36 +08:00
|
|
|
|
2011-09-22 17:22:12 +08:00
|
|
|
/* Divider value calculation */
|
2019-08-08 09:43:30 +08:00
|
|
|
#if CONFIG_IS_ENABLED(CLK)
|
|
|
|
i2c_clk_rate = clk_get_rate(&i2c_bus->per_clk);
|
|
|
|
#else
|
2012-09-24 10:46:53 +08:00
|
|
|
i2c_clk_rate = mxc_get_clock(MXC_I2C_CLK);
|
2019-08-08 09:43:30 +08:00
|
|
|
#endif
|
|
|
|
|
2011-09-22 17:22:12 +08:00
|
|
|
div = (i2c_clk_rate + rate - 1) / rate;
|
|
|
|
if (div < i2c_clk_div[0][0])
|
2011-09-27 14:34:11 +08:00
|
|
|
clk_div = 0;
|
2011-09-22 17:22:12 +08:00
|
|
|
else if (div > i2c_clk_div[ARRAY_SIZE(i2c_clk_div) - 1][0])
|
2011-09-27 14:34:11 +08:00
|
|
|
clk_div = ARRAY_SIZE(i2c_clk_div) - 1;
|
2011-09-22 17:22:12 +08:00
|
|
|
else
|
2011-09-27 14:34:11 +08:00
|
|
|
for (clk_div = 0; i2c_clk_div[clk_div][0] < div; clk_div++)
|
2011-09-22 17:22:12 +08:00
|
|
|
;
|
|
|
|
|
|
|
|
/* Store divider value */
|
2011-10-26 08:05:44 +08:00
|
|
|
return clk_div;
|
2011-09-22 17:22:12 +08:00
|
|
|
}
|
2008-03-27 03:40:49 +08:00
|
|
|
|
2011-09-22 17:22:12 +08:00
|
|
|
/*
|
2012-07-19 16:18:18 +08:00
|
|
|
* Set I2C Bus speed
|
2011-09-22 17:22:12 +08:00
|
|
|
*/
|
2015-05-15 07:29:12 +08:00
|
|
|
static int bus_i2c_set_bus_speed(struct mxc_i2c_bus *i2c_bus, int speed)
|
2011-09-22 17:22:12 +08:00
|
|
|
{
|
2015-05-15 07:29:12 +08:00
|
|
|
ulong base = i2c_bus->base;
|
|
|
|
bool quirk = i2c_bus->driver_data & I2C_QUIRK_FLAG ? true : false;
|
|
|
|
u8 clk_idx = i2c_imx_get_clk(i2c_bus, speed);
|
2011-10-26 08:05:44 +08:00
|
|
|
u8 idx = i2c_clk_div[clk_idx][1];
|
2015-05-15 07:29:12 +08:00
|
|
|
int reg_shift = quirk ? VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
2011-10-26 08:05:44 +08:00
|
|
|
|
2015-05-18 16:58:12 +08:00
|
|
|
if (!base)
|
2017-09-18 06:54:53 +08:00
|
|
|
return -EINVAL;
|
2015-05-18 16:58:12 +08:00
|
|
|
|
2011-10-26 08:05:44 +08:00
|
|
|
/* Store divider value */
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(idx, base + (IFDR << reg_shift));
|
2011-10-26 08:05:44 +08:00
|
|
|
|
2012-07-19 16:18:12 +08:00
|
|
|
/* Reset module */
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(I2CR_IDIS, base + (I2CR << reg_shift));
|
|
|
|
writeb(0, base + (I2SR << reg_shift));
|
2011-09-27 14:34:11 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-07-19 16:18:09 +08:00
|
|
|
#define ST_BUS_IDLE (0 | (I2SR_IBB << 8))
|
|
|
|
#define ST_BUS_BUSY (I2SR_IBB | (I2SR_IBB << 8))
|
|
|
|
#define ST_IIF (I2SR_IIF | (I2SR_IIF << 8))
|
2011-01-20 15:51:31 +08:00
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
static int wait_for_sr_state(struct mxc_i2c_bus *i2c_bus, unsigned state)
|
2008-03-27 03:40:49 +08:00
|
|
|
{
|
2012-07-19 16:18:09 +08:00
|
|
|
unsigned sr;
|
|
|
|
ulong elapsed;
|
2015-05-15 07:29:12 +08:00
|
|
|
bool quirk = i2c_bus->driver_data & I2C_QUIRK_FLAG ? true : false;
|
|
|
|
int reg_shift = quirk ? VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
|
|
|
ulong base = i2c_bus->base;
|
2012-07-19 16:18:09 +08:00
|
|
|
ulong start_time = get_timer(0);
|
|
|
|
for (;;) {
|
2015-05-15 07:29:12 +08:00
|
|
|
sr = readb(base + (I2SR << reg_shift));
|
2012-07-19 16:18:15 +08:00
|
|
|
if (sr & I2SR_IAL) {
|
2015-05-15 07:29:12 +08:00
|
|
|
if (quirk)
|
|
|
|
writeb(sr | I2SR_IAL, base +
|
|
|
|
(I2SR << reg_shift));
|
|
|
|
else
|
|
|
|
writeb(sr & ~I2SR_IAL, base +
|
|
|
|
(I2SR << reg_shift));
|
2012-07-19 16:18:15 +08:00
|
|
|
printf("%s: Arbitration lost sr=%x cr=%x state=%x\n",
|
2015-05-15 07:29:12 +08:00
|
|
|
__func__, sr, readb(base + (I2CR << reg_shift)),
|
|
|
|
state);
|
2012-07-19 16:18:15 +08:00
|
|
|
return -ERESTART;
|
|
|
|
}
|
2012-07-19 16:18:09 +08:00
|
|
|
if ((sr & (state >> 8)) == (unsigned char)state)
|
|
|
|
return sr;
|
|
|
|
WATCHDOG_RESET();
|
|
|
|
elapsed = get_timer(start_time);
|
|
|
|
if (elapsed > (CONFIG_SYS_HZ / 10)) /* .1 seconds */
|
|
|
|
break;
|
2011-09-22 17:22:12 +08:00
|
|
|
}
|
2012-07-19 16:18:09 +08:00
|
|
|
printf("%s: failed sr=%x cr=%x state=%x\n", __func__,
|
2015-05-15 07:29:12 +08:00
|
|
|
sr, readb(base + (I2CR << reg_shift)), state);
|
2012-07-19 16:18:04 +08:00
|
|
|
return -ETIMEDOUT;
|
2008-03-27 03:40:49 +08:00
|
|
|
}
|
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
static int tx_byte(struct mxc_i2c_bus *i2c_bus, u8 byte)
|
2011-01-20 15:51:31 +08:00
|
|
|
{
|
2012-07-19 16:18:04 +08:00
|
|
|
int ret;
|
2015-05-15 07:29:12 +08:00
|
|
|
int reg_shift = i2c_bus->driver_data & I2C_QUIRK_FLAG ?
|
|
|
|
VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
|
|
|
ulong base = i2c_bus->base;
|
2011-01-20 15:51:31 +08:00
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(I2SR_IIF_CLEAR, base + (I2SR << reg_shift));
|
|
|
|
writeb(byte, base + (I2DR << reg_shift));
|
|
|
|
|
|
|
|
ret = wait_for_sr_state(i2c_bus, ST_IIF);
|
2012-07-19 16:18:04 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
if (ret & I2SR_RX_NO_AK)
|
2017-09-18 06:54:53 +08:00
|
|
|
return -EREMOTEIO;
|
2012-07-19 16:18:04 +08:00
|
|
|
return 0;
|
2011-09-22 17:22:12 +08:00
|
|
|
}
|
2011-01-20 15:51:31 +08:00
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
/*
|
|
|
|
* Stub implementations for outer i2c slave operations.
|
|
|
|
*/
|
|
|
|
void __i2c_force_reset_slave(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
void i2c_force_reset_slave(void)
|
|
|
|
__attribute__((weak, alias("__i2c_force_reset_slave")));
|
|
|
|
|
2011-09-22 17:22:12 +08:00
|
|
|
/*
|
2012-07-19 16:18:13 +08:00
|
|
|
* Stop I2C transaction
|
2011-09-22 17:22:12 +08:00
|
|
|
*/
|
2015-05-15 07:29:12 +08:00
|
|
|
static void i2c_imx_stop(struct mxc_i2c_bus *i2c_bus)
|
2008-03-27 03:40:49 +08:00
|
|
|
{
|
2012-07-19 16:18:09 +08:00
|
|
|
int ret;
|
2015-05-15 07:29:12 +08:00
|
|
|
int reg_shift = i2c_bus->driver_data & I2C_QUIRK_FLAG ?
|
|
|
|
VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
|
|
|
ulong base = i2c_bus->base;
|
|
|
|
unsigned int temp = readb(base + (I2CR << reg_shift));
|
2011-09-22 17:22:12 +08:00
|
|
|
|
2012-07-19 16:18:02 +08:00
|
|
|
temp &= ~(I2CR_MSTA | I2CR_MTX);
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(temp, base + (I2CR << reg_shift));
|
|
|
|
ret = wait_for_sr_state(i2c_bus, ST_BUS_IDLE);
|
2012-07-19 16:18:09 +08:00
|
|
|
if (ret < 0)
|
|
|
|
printf("%s:trigger stop failed\n", __func__);
|
2008-03-27 03:40:49 +08:00
|
|
|
}
|
|
|
|
|
2011-09-22 17:22:12 +08:00
|
|
|
/*
|
2012-07-19 16:18:06 +08:00
|
|
|
* Send start signal, chip address and
|
|
|
|
* write register address
|
2011-09-22 17:22:12 +08:00
|
|
|
*/
|
2015-05-15 07:29:12 +08:00
|
|
|
static int i2c_init_transfer_(struct mxc_i2c_bus *i2c_bus, u8 chip,
|
|
|
|
u32 addr, int alen)
|
2008-03-27 03:40:49 +08:00
|
|
|
{
|
2012-07-19 16:18:11 +08:00
|
|
|
unsigned int temp;
|
|
|
|
int ret;
|
2015-05-15 07:29:12 +08:00
|
|
|
bool quirk = i2c_bus->driver_data & I2C_QUIRK_FLAG ? true : false;
|
|
|
|
ulong base = i2c_bus->base;
|
|
|
|
int reg_shift = quirk ? VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
|
|
|
|
|
|
|
/* Reset i2c slave */
|
|
|
|
i2c_force_reset_slave();
|
2012-07-19 16:18:11 +08:00
|
|
|
|
|
|
|
/* Enable I2C controller */
|
2015-05-15 07:29:12 +08:00
|
|
|
if (quirk)
|
|
|
|
ret = readb(base + (I2CR << reg_shift)) & I2CR_IDIS;
|
|
|
|
else
|
|
|
|
ret = !(readb(base + (I2CR << reg_shift)) & I2CR_IEN);
|
|
|
|
|
|
|
|
if (ret) {
|
|
|
|
writeb(I2CR_IEN, base + (I2CR << reg_shift));
|
2012-07-19 16:18:13 +08:00
|
|
|
/* Wait for controller to be stable */
|
|
|
|
udelay(50);
|
|
|
|
}
|
2015-05-15 07:29:12 +08:00
|
|
|
|
|
|
|
if (readb(base + (IADR << reg_shift)) == (chip << 1))
|
|
|
|
writeb((chip << 1) ^ 2, base + (IADR << reg_shift));
|
|
|
|
writeb(I2SR_IIF_CLEAR, base + (I2SR << reg_shift));
|
|
|
|
ret = wait_for_sr_state(i2c_bus, ST_BUS_IDLE);
|
2012-07-19 16:18:13 +08:00
|
|
|
if (ret < 0)
|
2012-07-19 16:18:16 +08:00
|
|
|
return ret;
|
2012-07-19 16:18:11 +08:00
|
|
|
|
|
|
|
/* Start I2C transaction */
|
2015-05-15 07:29:12 +08:00
|
|
|
temp = readb(base + (I2CR << reg_shift));
|
2012-07-19 16:18:11 +08:00
|
|
|
temp |= I2CR_MSTA;
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(temp, base + (I2CR << reg_shift));
|
2012-07-19 16:18:11 +08:00
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
ret = wait_for_sr_state(i2c_bus, ST_BUS_BUSY);
|
2012-07-19 16:18:11 +08:00
|
|
|
if (ret < 0)
|
2012-07-19 16:18:16 +08:00
|
|
|
return ret;
|
2012-07-19 16:18:06 +08:00
|
|
|
|
2012-07-19 16:18:11 +08:00
|
|
|
temp |= I2CR_MTX | I2CR_TX_NO_AK;
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(temp, base + (I2CR << reg_shift));
|
2012-07-19 16:18:11 +08:00
|
|
|
|
2017-11-08 23:35:09 +08:00
|
|
|
if (alen >= 0) {
|
|
|
|
/* write slave address */
|
|
|
|
ret = tx_byte(i2c_bus, chip << 1);
|
2012-07-19 16:18:04 +08:00
|
|
|
if (ret < 0)
|
2012-07-19 16:18:16 +08:00
|
|
|
return ret;
|
2017-11-08 23:35:09 +08:00
|
|
|
|
|
|
|
while (alen--) {
|
|
|
|
ret = tx_byte(i2c_bus, (addr >> (alen * 8)) & 0xff);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
2011-01-20 15:51:31 +08:00
|
|
|
}
|
2017-11-08 23:35:09 +08:00
|
|
|
|
2012-07-19 16:18:06 +08:00
|
|
|
return 0;
|
2012-07-19 16:18:16 +08:00
|
|
|
}
|
|
|
|
|
2020-07-02 11:13:00 +08:00
|
|
|
#if !defined(I2C2_BASE_ADDR)
|
|
|
|
#define I2C2_BASE_ADDR 0
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if !defined(I2C3_BASE_ADDR)
|
|
|
|
#define I2C3_BASE_ADDR 0
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if !defined(I2C4_BASE_ADDR)
|
|
|
|
#define I2C4_BASE_ADDR 0
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if !defined(I2C5_BASE_ADDR)
|
|
|
|
#define I2C5_BASE_ADDR 0
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if !defined(I2C6_BASE_ADDR)
|
|
|
|
#define I2C6_BASE_ADDR 0
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if !defined(I2C7_BASE_ADDR)
|
|
|
|
#define I2C7_BASE_ADDR 0
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if !defined(I2C8_BASE_ADDR)
|
|
|
|
#define I2C8_BASE_ADDR 0
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static struct mxc_i2c_bus mxc_i2c_buses[] = {
|
|
|
|
#if defined(CONFIG_ARCH_LS1021A) || defined(CONFIG_VF610) || \
|
|
|
|
defined(CONFIG_FSL_LAYERSCAPE)
|
|
|
|
{ 0, I2C1_BASE_ADDR, I2C_QUIRK_FLAG },
|
|
|
|
{ 1, I2C2_BASE_ADDR, I2C_QUIRK_FLAG },
|
|
|
|
{ 2, I2C3_BASE_ADDR, I2C_QUIRK_FLAG },
|
|
|
|
{ 3, I2C4_BASE_ADDR, I2C_QUIRK_FLAG },
|
|
|
|
{ 4, I2C5_BASE_ADDR, I2C_QUIRK_FLAG },
|
|
|
|
{ 5, I2C6_BASE_ADDR, I2C_QUIRK_FLAG },
|
|
|
|
{ 6, I2C7_BASE_ADDR, I2C_QUIRK_FLAG },
|
|
|
|
{ 7, I2C8_BASE_ADDR, I2C_QUIRK_FLAG },
|
|
|
|
#else
|
|
|
|
{ 0, I2C1_BASE_ADDR, 0 },
|
|
|
|
{ 1, I2C2_BASE_ADDR, 0 },
|
|
|
|
{ 2, I2C3_BASE_ADDR, 0 },
|
|
|
|
{ 3, I2C4_BASE_ADDR, 0 },
|
|
|
|
{ 4, I2C5_BASE_ADDR, 0 },
|
|
|
|
{ 5, I2C6_BASE_ADDR, 0 },
|
|
|
|
{ 6, I2C7_BASE_ADDR, 0 },
|
|
|
|
{ 7, I2C8_BASE_ADDR, 0 },
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
2021-02-09 19:52:45 +08:00
|
|
|
#if !CONFIG_IS_ENABLED(DM_I2C)
|
2015-05-15 07:29:12 +08:00
|
|
|
int i2c_idle_bus(struct mxc_i2c_bus *i2c_bus)
|
|
|
|
{
|
|
|
|
if (i2c_bus && i2c_bus->idle_bus_fn)
|
|
|
|
return i2c_bus->idle_bus_fn(i2c_bus->idle_bus_data);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
/*
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
* See Linux Documentation/devicetree/bindings/i2c/i2c-imx.txt
|
|
|
|
* "
|
|
|
|
* scl-gpios: specify the gpio related to SCL pin
|
|
|
|
* sda-gpios: specify the gpio related to SDA pin
|
|
|
|
* add pinctrl to configure i2c pins to gpio function for i2c
|
|
|
|
* bus recovery, call it "gpio" state
|
|
|
|
* "
|
|
|
|
*
|
|
|
|
* The i2c_idle_bus is an implementation following Linux Kernel.
|
2015-05-15 07:29:12 +08:00
|
|
|
*/
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
int i2c_idle_bus(struct mxc_i2c_bus *i2c_bus)
|
2015-05-15 07:29:12 +08:00
|
|
|
{
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
struct udevice *bus = i2c_bus->bus;
|
2019-04-04 18:35:34 +08:00
|
|
|
struct dm_i2c_bus *i2c = dev_get_uclass_priv(bus);
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
struct gpio_desc *scl_gpio = &i2c_bus->scl_gpio;
|
|
|
|
struct gpio_desc *sda_gpio = &i2c_bus->sda_gpio;
|
2019-04-04 18:35:34 +08:00
|
|
|
int sda, scl, idle_sclks;
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
int i, ret = 0;
|
|
|
|
ulong elapsed, start_time;
|
2012-07-19 16:18:19 +08:00
|
|
|
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
if (pinctrl_select_state(bus, "gpio")) {
|
|
|
|
dev_dbg(bus, "Can not to switch to use gpio pinmux\n");
|
|
|
|
/*
|
|
|
|
* GPIO pinctrl for i2c force idle is not a must,
|
|
|
|
* but it is strongly recommended to be used.
|
|
|
|
* Because it can help you to recover from bad
|
|
|
|
* i2c bus state. Do not return failure, because
|
|
|
|
* it is not a must.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
dm_gpio_set_dir_flags(scl_gpio, GPIOD_IS_IN);
|
|
|
|
dm_gpio_set_dir_flags(sda_gpio, GPIOD_IS_IN);
|
|
|
|
scl = dm_gpio_get_value(scl_gpio);
|
|
|
|
sda = dm_gpio_get_value(sda_gpio);
|
|
|
|
|
|
|
|
if ((sda & scl) == 1)
|
|
|
|
goto exit; /* Bus is idle already */
|
|
|
|
|
2019-04-04 18:35:34 +08:00
|
|
|
/*
|
|
|
|
* In most cases it is just enough to generate 8 + 1 SCLK
|
|
|
|
* clocks to recover I2C slave device from 'stuck' state
|
|
|
|
* (when for example SW reset was performed, in the middle of
|
|
|
|
* I2C transmission).
|
|
|
|
*
|
|
|
|
* However, there are devices which send data in packets of
|
|
|
|
* N bytes (N > 1). In such case we do need N * 8 + 1 SCLK
|
|
|
|
* clocks.
|
|
|
|
*/
|
|
|
|
idle_sclks = 8 + 1;
|
|
|
|
|
|
|
|
if (i2c->max_transaction_bytes > 0)
|
|
|
|
idle_sclks = i2c->max_transaction_bytes * 8 + 1;
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
/* Send high and low on the SCL line */
|
2019-04-04 18:35:34 +08:00
|
|
|
for (i = 0; i < idle_sclks; i++) {
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
dm_gpio_set_dir_flags(scl_gpio, GPIOD_IS_OUT);
|
|
|
|
dm_gpio_set_value(scl_gpio, 0);
|
|
|
|
udelay(50);
|
|
|
|
dm_gpio_set_dir_flags(scl_gpio, GPIOD_IS_IN);
|
|
|
|
udelay(50);
|
|
|
|
}
|
|
|
|
start_time = get_timer(0);
|
|
|
|
for (;;) {
|
|
|
|
dm_gpio_set_dir_flags(scl_gpio, GPIOD_IS_IN);
|
|
|
|
dm_gpio_set_dir_flags(sda_gpio, GPIOD_IS_IN);
|
|
|
|
scl = dm_gpio_get_value(scl_gpio);
|
|
|
|
sda = dm_gpio_get_value(sda_gpio);
|
|
|
|
if ((sda & scl) == 1)
|
|
|
|
break;
|
|
|
|
WATCHDOG_RESET();
|
|
|
|
elapsed = get_timer(start_time);
|
|
|
|
if (elapsed > (CONFIG_SYS_HZ / 5)) { /* .2 seconds */
|
|
|
|
ret = -EBUSY;
|
|
|
|
printf("%s: failed to clear bus, sda=%d scl=%d\n", __func__, sda, scl);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
exit:
|
|
|
|
pinctrl_select_state(bus, "default");
|
|
|
|
return ret;
|
|
|
|
}
|
2015-05-15 07:29:12 +08:00
|
|
|
#endif
|
2020-07-02 11:13:00 +08:00
|
|
|
/*
|
|
|
|
* Early init I2C for prepare read the clk through I2C.
|
|
|
|
*/
|
|
|
|
void i2c_early_init_f(void)
|
|
|
|
{
|
|
|
|
ulong base = mxc_i2c_buses[I2C_EARLY_INIT_INDEX].base;
|
|
|
|
bool quirk = mxc_i2c_buses[I2C_EARLY_INIT_INDEX].driver_data
|
|
|
|
& I2C_QUIRK_FLAG ? true : false;
|
|
|
|
int reg_shift = quirk ? VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
|
|
|
|
|
|
|
/* Set I2C divider value */
|
|
|
|
writeb(I2C_IFDR_DIV_CONSERVATIVE, base + (IFDR << reg_shift));
|
|
|
|
/* Reset module */
|
|
|
|
writeb(I2CR_IDIS, base + (I2CR << reg_shift));
|
|
|
|
writeb(0, base + (I2SR << reg_shift));
|
|
|
|
/* Enable I2C */
|
|
|
|
writeb(I2CR_IEN, base + (I2CR << reg_shift));
|
|
|
|
}
|
2015-05-15 07:29:12 +08:00
|
|
|
|
|
|
|
static int i2c_init_transfer(struct mxc_i2c_bus *i2c_bus, u8 chip,
|
|
|
|
u32 addr, int alen)
|
2012-07-19 16:18:16 +08:00
|
|
|
{
|
|
|
|
int retry;
|
|
|
|
int ret;
|
2015-05-15 07:29:12 +08:00
|
|
|
int reg_shift = i2c_bus->driver_data & I2C_QUIRK_FLAG ?
|
|
|
|
VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
2015-05-18 16:58:12 +08:00
|
|
|
|
|
|
|
if (!i2c_bus->base)
|
2017-09-18 06:54:53 +08:00
|
|
|
return -EINVAL;
|
2015-05-18 16:58:12 +08:00
|
|
|
|
2012-07-19 16:18:16 +08:00
|
|
|
for (retry = 0; retry < 3; retry++) {
|
2015-05-15 07:29:12 +08:00
|
|
|
ret = i2c_init_transfer_(i2c_bus, chip, addr, alen);
|
2012-07-19 16:18:16 +08:00
|
|
|
if (ret >= 0)
|
|
|
|
return 0;
|
2015-05-15 07:29:12 +08:00
|
|
|
i2c_imx_stop(i2c_bus);
|
2017-09-18 06:54:53 +08:00
|
|
|
if (ret == -EREMOTEIO)
|
2012-07-19 16:18:16 +08:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
printf("%s: failed for chip 0x%x retry=%d\n", __func__, chip,
|
|
|
|
retry);
|
|
|
|
if (ret != -ERESTART)
|
2013-06-17 15:30:39 +08:00
|
|
|
/* Disable controller */
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(I2CR_IDIS, i2c_bus->base + (I2CR << reg_shift));
|
2012-07-19 16:18:16 +08:00
|
|
|
udelay(100);
|
2015-05-15 07:29:12 +08:00
|
|
|
if (i2c_idle_bus(i2c_bus) < 0)
|
2012-07-19 16:18:19 +08:00
|
|
|
break;
|
2012-07-19 16:18:16 +08:00
|
|
|
}
|
2015-05-15 07:29:12 +08:00
|
|
|
printf("%s: give up i2c_regs=0x%lx\n", __func__, i2c_bus->base);
|
2011-09-22 17:22:12 +08:00
|
|
|
return ret;
|
2008-03-27 03:40:49 +08:00
|
|
|
}
|
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
|
|
|
|
static int i2c_write_data(struct mxc_i2c_bus *i2c_bus, u8 chip, const u8 *buf,
|
|
|
|
int len)
|
|
|
|
{
|
|
|
|
int i, ret = 0;
|
|
|
|
|
|
|
|
debug("i2c_write_data: chip=0x%x, len=0x%x\n", chip, len);
|
|
|
|
debug("write_data: ");
|
|
|
|
/* use rc for counter */
|
|
|
|
for (i = 0; i < len; ++i)
|
|
|
|
debug(" 0x%02x", buf[i]);
|
|
|
|
debug("\n");
|
|
|
|
|
|
|
|
for (i = 0; i < len; i++) {
|
|
|
|
ret = tx_byte(i2c_bus, buf[i]);
|
|
|
|
if (ret < 0) {
|
|
|
|
debug("i2c_write_data(): rc=%d\n", ret);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
/* Will generate a STOP after the last byte if "last" is true, i.e. this is the
|
|
|
|
* final message of a transaction. If not, it switches the bus back to TX mode
|
|
|
|
* and does not send a STOP, leaving the bus in a state where a repeated start
|
|
|
|
* and address can be sent for another message.
|
|
|
|
*/
|
2015-05-15 07:29:12 +08:00
|
|
|
static int i2c_read_data(struct mxc_i2c_bus *i2c_bus, uchar chip, uchar *buf,
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
int len, bool last)
|
2011-09-22 17:22:12 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
unsigned int temp;
|
|
|
|
int i;
|
2015-05-15 07:29:12 +08:00
|
|
|
int reg_shift = i2c_bus->driver_data & I2C_QUIRK_FLAG ?
|
|
|
|
VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
|
|
|
ulong base = i2c_bus->base;
|
2011-09-22 17:22:12 +08:00
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
debug("i2c_read_data: chip=0x%x, len=0x%x\n", chip, len);
|
2011-09-22 17:22:12 +08:00
|
|
|
|
|
|
|
/* setup bus to read data */
|
2015-05-15 07:29:12 +08:00
|
|
|
temp = readb(base + (I2CR << reg_shift));
|
2011-09-22 17:22:12 +08:00
|
|
|
temp &= ~(I2CR_MTX | I2CR_TX_NO_AK);
|
|
|
|
if (len == 1)
|
|
|
|
temp |= I2CR_TX_NO_AK;
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(temp, base + (I2CR << reg_shift));
|
|
|
|
writeb(I2SR_IIF_CLEAR, base + (I2SR << reg_shift));
|
|
|
|
/* dummy read to clear ICF */
|
|
|
|
readb(base + (I2DR << reg_shift));
|
2011-09-22 17:22:12 +08:00
|
|
|
|
|
|
|
/* read data */
|
|
|
|
for (i = 0; i < len; i++) {
|
2015-05-15 07:29:12 +08:00
|
|
|
ret = wait_for_sr_state(i2c_bus, ST_IIF);
|
2012-07-19 16:18:09 +08:00
|
|
|
if (ret < 0) {
|
2015-05-15 07:29:12 +08:00
|
|
|
debug("i2c_read_data(): ret=%d\n", ret);
|
|
|
|
i2c_imx_stop(i2c_bus);
|
2011-09-22 17:22:12 +08:00
|
|
|
return ret;
|
2012-07-19 16:18:07 +08:00
|
|
|
}
|
2011-09-22 17:22:12 +08:00
|
|
|
|
|
|
|
if (i == (len - 1)) {
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
/* Final byte has already been received by master! When
|
|
|
|
* we read it from I2DR, the master will start another
|
|
|
|
* cycle. We must program it first to send a STOP or
|
|
|
|
* switch to TX to avoid this.
|
|
|
|
*/
|
|
|
|
if (last) {
|
|
|
|
i2c_imx_stop(i2c_bus);
|
|
|
|
} else {
|
|
|
|
/* Final read, no stop, switch back to tx */
|
|
|
|
temp = readb(base + (I2CR << reg_shift));
|
|
|
|
temp |= I2CR_MTX | I2CR_TX_NO_AK;
|
|
|
|
writeb(temp, base + (I2CR << reg_shift));
|
|
|
|
}
|
2011-09-22 17:22:12 +08:00
|
|
|
} else if (i == (len - 2)) {
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
/* Master has already recevied penultimate byte. When
|
|
|
|
* we read it from I2DR, master will start RX of final
|
|
|
|
* byte. We must set TX_NO_AK now so it does not ACK
|
|
|
|
* that final byte.
|
|
|
|
*/
|
2015-05-15 07:29:12 +08:00
|
|
|
temp = readb(base + (I2CR << reg_shift));
|
2011-09-22 17:22:12 +08:00
|
|
|
temp |= I2CR_TX_NO_AK;
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(temp, base + (I2CR << reg_shift));
|
2011-09-22 17:22:12 +08:00
|
|
|
}
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
writeb(I2SR_IIF_CLEAR, base + (I2SR << reg_shift));
|
|
|
|
buf[i] = readb(base + (I2DR << reg_shift));
|
2008-03-27 03:40:49 +08:00
|
|
|
}
|
2015-05-15 07:29:12 +08:00
|
|
|
|
|
|
|
/* reuse ret for counter*/
|
|
|
|
for (ret = 0; ret < len; ++ret)
|
|
|
|
debug(" 0x%02x", buf[ret]);
|
|
|
|
debug("\n");
|
|
|
|
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
/* It is not clear to me that this is necessary */
|
|
|
|
if (last)
|
|
|
|
i2c_imx_stop(i2c_bus);
|
2012-07-19 16:18:09 +08:00
|
|
|
return 0;
|
2008-03-27 03:40:49 +08:00
|
|
|
}
|
|
|
|
|
2019-07-10 21:00:22 +08:00
|
|
|
int __enable_i2c_clk(unsigned char enable, unsigned int i2c_num)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int enable_i2c_clk(unsigned char enable, unsigned int i2c_num)
|
|
|
|
__attribute__((weak, alias("__enable_i2c_clk")));
|
|
|
|
|
2021-02-09 19:52:45 +08:00
|
|
|
#if !CONFIG_IS_ENABLED(DM_I2C)
|
2011-09-22 17:22:12 +08:00
|
|
|
/*
|
2015-05-15 07:29:12 +08:00
|
|
|
* Read data from I2C device
|
2019-05-01 00:08:18 +08:00
|
|
|
*
|
|
|
|
* The transactions use the syntax defined in the Linux kernel I2C docs.
|
|
|
|
*
|
|
|
|
* If alen is > 0, then this function will send a transaction of the form:
|
|
|
|
* S Chip Wr [A] Addr [A] S Chip Rd [A] [data] A ... NA P
|
|
|
|
* This is a normal I2C register read: writing the register address, then doing
|
|
|
|
* a repeated start and reading the data.
|
|
|
|
*
|
|
|
|
* If alen == 0, then we get this transaction:
|
|
|
|
* S Chip Wr [A] S Chip Rd [A] [data] A ... NA P
|
|
|
|
* This is somewhat unusual, though valid, transaction. It addresses the chip
|
|
|
|
* in write mode, but doesn't actually write any register address or data, then
|
|
|
|
* does a repeated start and reads data.
|
|
|
|
*
|
|
|
|
* If alen < 0, then we get this transaction:
|
|
|
|
* S Chip Rd [A] [data] A ... NA P
|
|
|
|
* The chip is addressed in read mode and then data is read. No register
|
|
|
|
* address is written first. This is perfectly valid on most devices and
|
|
|
|
* required on some (usually those that don't act like an array of registers).
|
2011-09-22 17:22:12 +08:00
|
|
|
*/
|
2015-05-15 07:29:12 +08:00
|
|
|
static int bus_i2c_read(struct mxc_i2c_bus *i2c_bus, u8 chip, u32 addr,
|
|
|
|
int alen, u8 *buf, int len)
|
2008-03-27 03:40:49 +08:00
|
|
|
{
|
2015-05-15 07:29:12 +08:00
|
|
|
int ret = 0;
|
|
|
|
u32 temp;
|
|
|
|
int reg_shift = i2c_bus->driver_data & I2C_QUIRK_FLAG ?
|
|
|
|
VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
|
|
|
ulong base = i2c_bus->base;
|
2008-03-27 03:40:49 +08:00
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
ret = i2c_init_transfer(i2c_bus, chip, addr, alen);
|
2012-07-19 16:18:04 +08:00
|
|
|
if (ret < 0)
|
2011-09-22 17:22:12 +08:00
|
|
|
return ret;
|
2008-03-27 03:40:49 +08:00
|
|
|
|
2017-11-08 23:35:09 +08:00
|
|
|
if (alen >= 0) {
|
|
|
|
temp = readb(base + (I2CR << reg_shift));
|
|
|
|
temp |= I2CR_RSTA;
|
|
|
|
writeb(temp, base + (I2CR << reg_shift));
|
|
|
|
}
|
2015-05-15 07:29:12 +08:00
|
|
|
|
|
|
|
ret = tx_byte(i2c_bus, (chip << 1) | 1);
|
|
|
|
if (ret < 0) {
|
|
|
|
i2c_imx_stop(i2c_bus);
|
|
|
|
return ret;
|
2011-09-22 17:22:12 +08:00
|
|
|
}
|
2015-05-15 07:29:12 +08:00
|
|
|
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
ret = i2c_read_data(i2c_bus, chip, buf, len, true);
|
2015-05-15 07:29:12 +08:00
|
|
|
|
|
|
|
i2c_imx_stop(i2c_bus);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write data to I2C device
|
2019-05-01 00:08:18 +08:00
|
|
|
*
|
|
|
|
* If alen > 0, we get this transaction:
|
|
|
|
* S Chip Wr [A] addr [A] data [A] ... [A] P
|
|
|
|
* An ordinary write register command.
|
|
|
|
*
|
|
|
|
* If alen == 0, then we get this:
|
|
|
|
* S Chip Wr [A] data [A] ... [A] P
|
|
|
|
* This is a simple I2C write.
|
|
|
|
*
|
|
|
|
* If alen < 0, then we get this:
|
|
|
|
* S data [A] ... [A] P
|
|
|
|
* This is most likely NOT something that should be used. It doesn't send the
|
|
|
|
* chip address first, so in effect, the first byte of data will be used as the
|
|
|
|
* address.
|
2015-05-15 07:29:12 +08:00
|
|
|
*/
|
|
|
|
static int bus_i2c_write(struct mxc_i2c_bus *i2c_bus, u8 chip, u32 addr,
|
|
|
|
int alen, const u8 *buf, int len)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
ret = i2c_init_transfer(i2c_bus, chip, addr, alen);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = i2c_write_data(i2c_bus, chip, buf, len);
|
|
|
|
|
|
|
|
i2c_imx_stop(i2c_bus);
|
|
|
|
|
2011-09-22 17:22:12 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2012-07-19 16:18:08 +08:00
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
struct mxc_i2c_bus *i2c_get_base(struct i2c_adapter *adap)
|
2012-07-19 16:18:19 +08:00
|
|
|
{
|
2015-05-15 07:29:12 +08:00
|
|
|
return &mxc_i2c_buses[adap->hwadapnr];
|
2012-07-19 16:18:19 +08:00
|
|
|
}
|
|
|
|
|
2013-09-22 00:13:35 +08:00
|
|
|
static int mxc_i2c_read(struct i2c_adapter *adap, uint8_t chip,
|
|
|
|
uint addr, int alen, uint8_t *buffer,
|
|
|
|
int len)
|
2012-07-19 16:18:18 +08:00
|
|
|
{
|
2013-09-22 00:13:35 +08:00
|
|
|
return bus_i2c_read(i2c_get_base(adap), chip, addr, alen, buffer, len);
|
2012-07-19 16:18:18 +08:00
|
|
|
}
|
|
|
|
|
2013-09-22 00:13:35 +08:00
|
|
|
static int mxc_i2c_write(struct i2c_adapter *adap, uint8_t chip,
|
|
|
|
uint addr, int alen, uint8_t *buffer,
|
|
|
|
int len)
|
2012-07-19 16:18:18 +08:00
|
|
|
{
|
2013-09-22 00:13:35 +08:00
|
|
|
return bus_i2c_write(i2c_get_base(adap), chip, addr, alen, buffer, len);
|
2012-07-19 16:18:18 +08:00
|
|
|
}
|
|
|
|
|
2012-07-19 16:18:08 +08:00
|
|
|
/*
|
|
|
|
* Test if a chip at a given address responds (probe the chip)
|
|
|
|
*/
|
2013-09-22 00:13:35 +08:00
|
|
|
static int mxc_i2c_probe(struct i2c_adapter *adap, uint8_t chip)
|
2012-07-19 16:18:08 +08:00
|
|
|
{
|
2013-09-22 00:13:35 +08:00
|
|
|
return bus_i2c_write(i2c_get_base(adap), chip, 0, 0, NULL, 0);
|
2012-07-19 16:18:18 +08:00
|
|
|
}
|
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
void bus_i2c_init(int index, int speed, int unused,
|
|
|
|
int (*idle_bus_fn)(void *p), void *idle_bus_data)
|
2012-07-19 16:18:18 +08:00
|
|
|
{
|
2015-05-15 07:29:12 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (index >= ARRAY_SIZE(mxc_i2c_buses)) {
|
|
|
|
debug("Error i2c index\n");
|
2012-07-19 16:18:18 +08:00
|
|
|
return;
|
|
|
|
}
|
2015-05-15 07:29:12 +08:00
|
|
|
|
2020-05-01 22:08:35 +08:00
|
|
|
if (CONFIG_IS_ENABLED(IMX_MODULE_FUSE)) {
|
|
|
|
if (i2c_fused((ulong)mxc_i2c_buses[index].base)) {
|
|
|
|
printf("SoC fuse indicates I2C@0x%lx is unavailable.\n",
|
|
|
|
(ulong)mxc_i2c_buses[index].base);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-18 17:38:01 +08:00
|
|
|
/*
|
|
|
|
* Warning: Be careful to allow the assignment to a static
|
|
|
|
* variable here. This function could be called while U-Boot is
|
|
|
|
* still running in flash memory. So such assignment is equal
|
|
|
|
* to write data to flash without erasing.
|
|
|
|
*/
|
|
|
|
if (idle_bus_fn)
|
|
|
|
mxc_i2c_buses[index].idle_bus_fn = idle_bus_fn;
|
|
|
|
if (idle_bus_data)
|
|
|
|
mxc_i2c_buses[index].idle_bus_data = idle_bus_data;
|
2015-05-15 07:29:12 +08:00
|
|
|
|
|
|
|
ret = enable_i2c_clk(1, index);
|
|
|
|
if (ret < 0) {
|
|
|
|
debug("I2C-%d clk fail to enable.\n", index);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
bus_i2c_set_bus_speed(&mxc_i2c_buses[index], speed);
|
2012-07-19 16:18:18 +08:00
|
|
|
}
|
|
|
|
|
2016-06-08 18:24:51 +08:00
|
|
|
|
|
|
|
|
2012-07-19 16:18:18 +08:00
|
|
|
/*
|
|
|
|
* Init I2C Bus
|
|
|
|
*/
|
2013-09-22 00:13:35 +08:00
|
|
|
static void mxc_i2c_init(struct i2c_adapter *adap, int speed, int slaveaddr)
|
2012-07-19 16:18:18 +08:00
|
|
|
{
|
2015-05-15 07:29:12 +08:00
|
|
|
bus_i2c_init(adap->hwadapnr, speed, slaveaddr, NULL, NULL);
|
2012-07-19 16:18:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set I2C Speed
|
|
|
|
*/
|
2015-05-15 07:29:12 +08:00
|
|
|
static u32 mxc_i2c_set_bus_speed(struct i2c_adapter *adap, uint speed)
|
2012-07-19 16:18:18 +08:00
|
|
|
{
|
2013-09-22 00:13:35 +08:00
|
|
|
return bus_i2c_set_bus_speed(i2c_get_base(adap), speed);
|
2012-07-19 16:18:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-09-22 00:13:35 +08:00
|
|
|
* Register mxc i2c adapters
|
2012-07-19 16:18:18 +08:00
|
|
|
*/
|
2015-09-22 04:43:38 +08:00
|
|
|
#ifdef CONFIG_SYS_I2C_MXC_I2C1
|
2013-09-22 00:13:35 +08:00
|
|
|
U_BOOT_I2C_ADAP_COMPLETE(mxc0, mxc_i2c_init, mxc_i2c_probe,
|
|
|
|
mxc_i2c_read, mxc_i2c_write,
|
|
|
|
mxc_i2c_set_bus_speed,
|
|
|
|
CONFIG_SYS_MXC_I2C1_SPEED,
|
|
|
|
CONFIG_SYS_MXC_I2C1_SLAVE, 0)
|
2015-09-22 04:43:38 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_SYS_I2C_MXC_I2C2
|
2013-09-22 00:13:35 +08:00
|
|
|
U_BOOT_I2C_ADAP_COMPLETE(mxc1, mxc_i2c_init, mxc_i2c_probe,
|
|
|
|
mxc_i2c_read, mxc_i2c_write,
|
|
|
|
mxc_i2c_set_bus_speed,
|
|
|
|
CONFIG_SYS_MXC_I2C2_SPEED,
|
|
|
|
CONFIG_SYS_MXC_I2C2_SLAVE, 1)
|
2015-09-22 04:43:38 +08:00
|
|
|
#endif
|
|
|
|
|
2015-03-21 01:20:40 +08:00
|
|
|
#ifdef CONFIG_SYS_I2C_MXC_I2C3
|
2013-09-22 00:13:35 +08:00
|
|
|
U_BOOT_I2C_ADAP_COMPLETE(mxc2, mxc_i2c_init, mxc_i2c_probe,
|
|
|
|
mxc_i2c_read, mxc_i2c_write,
|
|
|
|
mxc_i2c_set_bus_speed,
|
|
|
|
CONFIG_SYS_MXC_I2C3_SPEED,
|
|
|
|
CONFIG_SYS_MXC_I2C3_SLAVE, 2)
|
|
|
|
#endif
|
2015-05-15 07:29:12 +08:00
|
|
|
|
2015-03-21 01:20:40 +08:00
|
|
|
#ifdef CONFIG_SYS_I2C_MXC_I2C4
|
|
|
|
U_BOOT_I2C_ADAP_COMPLETE(mxc3, mxc_i2c_init, mxc_i2c_probe,
|
|
|
|
mxc_i2c_read, mxc_i2c_write,
|
|
|
|
mxc_i2c_set_bus_speed,
|
|
|
|
CONFIG_SYS_MXC_I2C4_SPEED,
|
|
|
|
CONFIG_SYS_MXC_I2C4_SLAVE, 3)
|
|
|
|
#endif
|
2015-05-15 07:29:12 +08:00
|
|
|
|
2018-02-06 13:56:31 +08:00
|
|
|
#ifdef CONFIG_SYS_I2C_MXC_I2C5
|
|
|
|
U_BOOT_I2C_ADAP_COMPLETE(mxc4, mxc_i2c_init, mxc_i2c_probe,
|
|
|
|
mxc_i2c_read, mxc_i2c_write,
|
|
|
|
mxc_i2c_set_bus_speed,
|
|
|
|
CONFIG_SYS_MXC_I2C5_SPEED,
|
|
|
|
CONFIG_SYS_MXC_I2C5_SLAVE, 4)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_SYS_I2C_MXC_I2C6
|
|
|
|
U_BOOT_I2C_ADAP_COMPLETE(mxc5, mxc_i2c_init, mxc_i2c_probe,
|
|
|
|
mxc_i2c_read, mxc_i2c_write,
|
|
|
|
mxc_i2c_set_bus_speed,
|
|
|
|
CONFIG_SYS_MXC_I2C6_SPEED,
|
|
|
|
CONFIG_SYS_MXC_I2C6_SLAVE, 5)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_SYS_I2C_MXC_I2C7
|
|
|
|
U_BOOT_I2C_ADAP_COMPLETE(mxc6, mxc_i2c_init, mxc_i2c_probe,
|
|
|
|
mxc_i2c_read, mxc_i2c_write,
|
|
|
|
mxc_i2c_set_bus_speed,
|
|
|
|
CONFIG_SYS_MXC_I2C7_SPEED,
|
|
|
|
CONFIG_SYS_MXC_I2C7_SLAVE, 6)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_SYS_I2C_MXC_I2C8
|
|
|
|
U_BOOT_I2C_ADAP_COMPLETE(mxc7, mxc_i2c_init, mxc_i2c_probe,
|
|
|
|
mxc_i2c_read, mxc_i2c_write,
|
|
|
|
mxc_i2c_set_bus_speed,
|
|
|
|
CONFIG_SYS_MXC_I2C8_SPEED,
|
|
|
|
CONFIG_SYS_MXC_I2C8_SLAVE, 7)
|
|
|
|
#endif
|
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
#else
|
|
|
|
|
|
|
|
static int mxc_i2c_set_bus_speed(struct udevice *bus, unsigned int speed)
|
|
|
|
{
|
|
|
|
struct mxc_i2c_bus *i2c_bus = dev_get_priv(bus);
|
|
|
|
|
|
|
|
return bus_i2c_set_bus_speed(i2c_bus, speed);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mxc_i2c_probe(struct udevice *bus)
|
|
|
|
{
|
|
|
|
struct mxc_i2c_bus *i2c_bus = dev_get_priv(bus);
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
const void *fdt = gd->fdt_blob;
|
2017-01-18 07:52:55 +08:00
|
|
|
int node = dev_of_offset(bus);
|
2015-05-15 07:29:12 +08:00
|
|
|
fdt_addr_t addr;
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
int ret, ret2;
|
2015-05-15 07:29:12 +08:00
|
|
|
|
|
|
|
i2c_bus->driver_data = dev_get_driver_data(bus);
|
|
|
|
|
2020-07-17 13:36:48 +08:00
|
|
|
addr = dev_read_addr(bus);
|
2015-05-15 07:29:12 +08:00
|
|
|
if (addr == FDT_ADDR_T_NONE)
|
2017-09-18 06:54:53 +08:00
|
|
|
return -EINVAL;
|
2015-05-15 07:29:12 +08:00
|
|
|
|
2020-05-01 22:08:35 +08:00
|
|
|
if (CONFIG_IS_ENABLED(IMX_MODULE_FUSE)) {
|
|
|
|
if (i2c_fused((ulong)addr)) {
|
|
|
|
printf("SoC fuse indicates I2C@0x%lx is unavailable.\n",
|
|
|
|
(ulong)addr);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
i2c_bus->base = addr;
|
2020-12-17 12:20:07 +08:00
|
|
|
i2c_bus->index = dev_seq(bus);
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
i2c_bus->bus = bus;
|
2015-05-15 07:29:12 +08:00
|
|
|
|
|
|
|
/* Enable clk */
|
2019-08-08 09:43:30 +08:00
|
|
|
#if CONFIG_IS_ENABLED(CLK)
|
|
|
|
ret = clk_get_by_index(bus, 0, &i2c_bus->per_clk);
|
|
|
|
if (ret) {
|
|
|
|
printf("Failed to get i2c clk\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
ret = clk_enable(&i2c_bus->per_clk);
|
|
|
|
if (ret) {
|
|
|
|
printf("Failed to enable i2c clk\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
#else
|
2020-12-17 12:20:07 +08:00
|
|
|
ret = enable_i2c_clk(1, dev_seq(bus));
|
2015-05-15 07:29:12 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
2019-08-08 09:43:30 +08:00
|
|
|
#endif
|
2015-05-15 07:29:12 +08:00
|
|
|
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
/*
|
|
|
|
* See Documentation/devicetree/bindings/i2c/i2c-imx.txt
|
|
|
|
* Use gpio to force bus idle when necessary.
|
|
|
|
*/
|
2016-10-03 07:59:28 +08:00
|
|
|
ret = fdt_stringlist_search(fdt, node, "pinctrl-names", "gpio");
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
if (ret < 0) {
|
2020-09-15 22:44:39 +08:00
|
|
|
debug("i2c bus %d at 0x%2lx, no gpio pinctrl state.\n",
|
2020-12-17 12:20:07 +08:00
|
|
|
dev_seq(bus), i2c_bus->base);
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
} else {
|
2017-05-31 11:47:09 +08:00
|
|
|
ret = gpio_request_by_name_nodev(offset_to_ofnode(node),
|
|
|
|
"scl-gpios", 0, &i2c_bus->scl_gpio,
|
|
|
|
GPIOD_IS_OUT);
|
|
|
|
ret2 = gpio_request_by_name_nodev(offset_to_ofnode(node),
|
|
|
|
"sda-gpios", 0, &i2c_bus->sda_gpio,
|
|
|
|
GPIOD_IS_OUT);
|
2017-12-29 15:06:08 +08:00
|
|
|
if (!dm_gpio_is_valid(&i2c_bus->sda_gpio) ||
|
|
|
|
!dm_gpio_is_valid(&i2c_bus->scl_gpio) ||
|
|
|
|
ret || ret2) {
|
2020-09-15 22:44:39 +08:00
|
|
|
dev_err(bus,
|
2020-12-21 22:50:16 +08:00
|
|
|
"i2c bus %d at 0x%2lx, fail to request scl/sda gpio\n",
|
2020-12-17 12:20:07 +08:00
|
|
|
dev_seq(bus), i2c_bus->base);
|
2017-09-18 06:54:53 +08:00
|
|
|
return -EINVAL;
|
dm: i2c: mxc_i2c: implement i2c_idle_bus
Implement i2c_idle_bus in driver, then setup_i2c can
be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
The i2c_idle_bus force bus idle flow follows setup_i2c in
arch/arm/imx-common/i2c-mxv7.c
This patch is an implementation following linux kernel patch:
"
commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
Author: Gao Pan <b54642@freescale.com>
Date: Fri Oct 23 20:28:54 2015 +0800
i2c: imx: implement bus recovery
Implement bus recovery methods for i2c-imx so we can recover from
situations where SCL/SDA are stuck low.
Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
pinctrl to gpio mode by calling pinctrl sleep set function, and then
use GPIO to emulate the i2c protocol to send nine dummy clock to recover
i2c device. After recovery, set i2c pinctrl to default group setting.
"
See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
description.
1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
2. Discard the __weak attribute for i2c_idle_bus and implement it,
since we have pinctrl driver/driver model gpio driver. We can
use device tree, but not let board code to do this.
3. gpio state for mxc_i2c is not a must, but it is recommended. If
there is no gpio state, driver will give tips, but not fail.
4. The i2c controller was first probed, default pinctrl state will
be used, so when need to use gpio function, need to do
"pinctrl_select_state(dev, "gpio")" and after force bus idle,
need to switch back "pinctrl_select_state(dev, "default")".
This is example about how to use the gpio force bus
idle function:
"
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
status = "okay";
[....]
};
[.....]
pinctrl_i2c1_gpio: i2c1grp_gpio {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>;
};
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
2016-03-11 16:47:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-15 07:29:12 +08:00
|
|
|
/*
|
|
|
|
* Pinmux settings are in board file now, until pinmux is supported,
|
|
|
|
* we can set pinmux here in probe function.
|
|
|
|
*/
|
|
|
|
|
|
|
|
debug("i2c : controller bus %d at %lu , speed %d: ",
|
2020-12-17 12:20:07 +08:00
|
|
|
dev_seq(bus), i2c_bus->base,
|
2015-05-15 07:29:12 +08:00
|
|
|
i2c_bus->speed);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-05-01 00:08:18 +08:00
|
|
|
/* Sends: S Addr Wr [A|NA] P */
|
2015-05-15 07:29:12 +08:00
|
|
|
static int mxc_i2c_probe_chip(struct udevice *bus, u32 chip_addr,
|
|
|
|
u32 chip_flags)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct mxc_i2c_bus *i2c_bus = dev_get_priv(bus);
|
|
|
|
|
|
|
|
ret = i2c_init_transfer(i2c_bus, chip_addr, 0, 0);
|
|
|
|
if (ret < 0) {
|
|
|
|
debug("%s failed, ret = %d\n", __func__, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
i2c_imx_stop(i2c_bus);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mxc_i2c_xfer(struct udevice *bus, struct i2c_msg *msg, int nmsgs)
|
|
|
|
{
|
|
|
|
struct mxc_i2c_bus *i2c_bus = dev_get_priv(bus);
|
|
|
|
int ret = 0;
|
|
|
|
ulong base = i2c_bus->base;
|
|
|
|
int reg_shift = i2c_bus->driver_data & I2C_QUIRK_FLAG ?
|
|
|
|
VF610_I2C_REGSHIFT : IMX_I2C_REGSHIFT;
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
int read_mode;
|
2015-05-15 07:29:12 +08:00
|
|
|
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
/* Here address len is set to -1 to not send any address at first.
|
|
|
|
* Otherwise i2c_init_transfer will send the chip address with write
|
|
|
|
* mode set. This is wrong if the 1st message is read.
|
2015-05-15 07:29:12 +08:00
|
|
|
*/
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
ret = i2c_init_transfer(i2c_bus, msg->addr, 0, -1);
|
2015-05-15 07:29:12 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
debug("i2c_init_transfer error: %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
read_mode = -1; /* So it's always different on the first message */
|
2015-05-15 07:29:12 +08:00
|
|
|
for (; nmsgs > 0; nmsgs--, msg++) {
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
const int msg_is_read = !!(msg->flags & I2C_M_RD);
|
|
|
|
|
|
|
|
debug("i2c_xfer: chip=0x%x, len=0x%x, dir=%c\n", msg->addr,
|
|
|
|
msg->len, msg_is_read ? 'R' : 'W');
|
|
|
|
|
|
|
|
if (msg_is_read != read_mode) {
|
|
|
|
/* Send repeated start if not 1st message */
|
|
|
|
if (read_mode != -1) {
|
|
|
|
debug("i2c_xfer: [RSTART]\n");
|
2015-05-15 07:29:12 +08:00
|
|
|
ret = readb(base + (I2CR << reg_shift));
|
|
|
|
ret |= I2CR_RSTA;
|
|
|
|
writeb(ret, base + (I2CR << reg_shift));
|
|
|
|
}
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
debug("i2c_xfer: [ADDR %02x | %c]\n", msg->addr,
|
|
|
|
msg_is_read ? 'R' : 'W');
|
|
|
|
ret = tx_byte(i2c_bus, (msg->addr << 1) | msg_is_read);
|
|
|
|
if (ret < 0) {
|
|
|
|
debug("i2c_xfer: [STOP]\n");
|
|
|
|
i2c_imx_stop(i2c_bus);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
read_mode = msg_is_read;
|
2015-05-15 07:29:12 +08:00
|
|
|
}
|
i2c: mxc_i2c: Fix read and read->write xfers in DM mode
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han <nandor.han@ge.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Breno Matheus Lima <brenomatheus@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-01 00:08:19 +08:00
|
|
|
|
|
|
|
if (msg->flags & I2C_M_RD)
|
|
|
|
ret = i2c_read_data(i2c_bus, msg->addr, msg->buf,
|
|
|
|
msg->len, nmsgs == 1 ||
|
|
|
|
(msg->flags & I2C_M_STOP));
|
|
|
|
else
|
|
|
|
ret = i2c_write_data(i2c_bus, msg->addr, msg->buf,
|
|
|
|
msg->len);
|
|
|
|
|
|
|
|
if (ret < 0)
|
|
|
|
break;
|
2015-05-15 07:29:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
debug("i2c_write: error sending\n");
|
|
|
|
|
|
|
|
i2c_imx_stop(i2c_bus);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct dm_i2c_ops mxc_i2c_ops = {
|
|
|
|
.xfer = mxc_i2c_xfer,
|
|
|
|
.probe_chip = mxc_i2c_probe_chip,
|
|
|
|
.set_bus_speed = mxc_i2c_set_bus_speed,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct udevice_id mxc_i2c_ids[] = {
|
|
|
|
{ .compatible = "fsl,imx21-i2c", },
|
|
|
|
{ .compatible = "fsl,vf610-i2c", .data = I2C_QUIRK_FLAG, },
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
|
|
|
U_BOOT_DRIVER(i2c_mxc) = {
|
|
|
|
.name = "i2c_mxc",
|
|
|
|
.id = UCLASS_I2C,
|
|
|
|
.of_match = mxc_i2c_ids,
|
|
|
|
.probe = mxc_i2c_probe,
|
2020-12-04 07:55:17 +08:00
|
|
|
.priv_auto = sizeof(struct mxc_i2c_bus),
|
2015-05-15 07:29:12 +08:00
|
|
|
.ops = &mxc_i2c_ops,
|
2019-12-31 15:33:39 +08:00
|
|
|
.flags = DM_FLAG_PRE_RELOC,
|
2015-05-15 07:29:12 +08:00
|
|
|
};
|
|
|
|
#endif
|