The Parallel to CSI-2 bridge TC358748 driver , I2C read 16bit reg issue

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi
I’m developing The Parallel to CSI-2 bridge TC358748 driver .
After writing the registers of configuration ,I want to verify the written value . The register’s address is 16 bit .The value of register is 16 bit or 32 bit.

When the register’s address is started at 0x00xx ,eg 0x0000, 0x0002, 0x0016 ,I get correct value .Like these

[  290.814525] tc358748 2-000e: tc358748_verify_reg()
[  290.819632] tc358748 2-000e: I2C read 0x0002 = 0x0001
[  290.825011] tc358748 2-000e: I2C read 0x0016 = 0x0013
[  290.830371] tc358748 2-000e: I2C read 0x0018 = 0x0603
[  290.835675] tc358748 2-000e: I2C read 0x0006 = 0x0032
[  290.840984] tc358748 2-000e: I2C read 0x0008 = 0x0060

When the register’s address is started NOT at 0x00xx, eg 0x0140, 0x214 , I get a wrong value .And the value is the last register of 0x00xx ,

[  290.814525] tc358748 2-000e: tc358748_verify_reg()
[  290.819632] tc358748 2-000e: I2C read 0x0002 = 0x0001
[  290.825011] tc358748 2-000e: I2C read 0x0016 = 0x0013
[  290.830371] tc358748 2-000e: I2C read 0x0018 = 0x0603
[  290.835675] tc358748 2-000e: I2C read 0x0006 = 0x0032
[  290.840984] tc358748 2-000e: I2C read 0x0008 = 0x0060
[  290.846290] tc358748 2-000e: I2C read 0x0022 = 0x0F00
[  290.851603] tc358748 2-000e: I2C read 0x0140 = 0x0F000F00
[  290.857293] tc358748 2-000e: I2C read 0x0144 = 0x0F000F00
[  290.862997] tc358748 2-000e: I2C read 0x0148 = 0x0F000F00
[  290.868660] tc358748 2-000e: I2C read 0x014C = 0x0F000F00
[  290.874327] tc358748 2-000e: I2C read 0x0150 = 0x0F000F00
[  290.879974] tc358748 2-000e: I2C read 0x0210 = 0x0F000F00
[  290.885602] tc358748 2-000e: I2C read 0x0214 = 0x0F00
[  290.890860] tc358748 2-000e: I2C read 0x0218 = 0x0F00
[  290.896114] tc358748 2-000e: I2C read 0x0220 = 0x0F00
[  290.901369] tc358748 2-000e: I2C read 0x0224 = 0x0F00
[  290.906620] tc358748 2-000e: I2C read 0x022C = 0x0F00
[  290.911870] tc358748 2-000e: I2C read 0x0230 = 0x0F00
[  290.917121] tc358748 2-000e: I2C read 0x0234 = 0x0F00
[  290.922373] tc358748 2-000e: I2C read 0x0238 = 0x0F00
[  290.927668] tc358748 2-000e: I2C read 0x0204 = 0x0F000F00
[  290.933323] tc358748 2-000e: I2C read 0x0518 = 0x0F000F00
[  290.938976] tc358748 2-000e: I2C read 0x0500 = 0x0F000F00
[  290.944574] tc358748 2-000e: I2C read 0x0004 = 0x1163

And as the last line in above massage , when changing read register of 0x0004 , we get the correct value again .

I write two style of I2C read function, one based on TC358743.C

static void i2c_rd(struct v4l2_subdev *sd, u16 reg, u8 *values, u32 n)
{
	struct i2c_client *client = v4l2_get_subdevdata(sd);
	int err;
//	*values = 0;
	u8 buf[2] = { reg >> 8, reg & 0xff };
	struct i2c_msg msgs[] = {
		{
			.addr = client->addr,
			.flags = 0,
			.len = 2,
			.buf = buf,
		},
		{
			.addr = client->addr,
			.flags = I2C_M_RD,
			.len = n,
			.buf = values,
		},
	};

	err = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
	if (err != ARRAY_SIZE(msgs)) {
		v4l2_err(sd, "%s: reading register 0x%x from 0x%x failed\n",
			__func__, reg, client->addr);
	}

	switch (n) {
	case 1:
		v4l2_info(sd, "I2C read 0x%04X = 0x%02X\n", reg, values[0]);
		break;
	case 2:
		v4l2_info(sd, "I2C read 0x%04X = 0x%02X%02X\n",
			reg, values[0], values[1]);
		break;
	case 4:
		v4l2_info(sd, "I2C read 0x%04X = 0x%02X%02X%02X%02X\n",
			reg, values[2], values[3], values[0], values[1]);
		break;
	default:
		v4l2_info(sd, "I2C read %d bytes from address 0x%04X\n",
			n, reg);
	}

}

one based on imx185.c

static inline int tc358748_read_reg(struct tc358748 *priv,
				u16 reg, u16 *val)
{
	int err = 0;
	u32 reg_val = 0;

	err = regmap_read(priv->regmap, reg, &reg_val);
	*val = reg_val & 0xFFFF;
	dev_dbg(priv->subdev->dev,"I2C read 0x%04X = 0x%04X\n",
			reg, *val);
	return err;
}

Neither got correct value.

Could anyone help.
Thanks.

2

The function almost the same with tc358840, however there’s no any problem for it.
A lot user bring up tc358748 you may search and check if any help.

3

Thanks for reply.

I have checked them ,but there seem be no issue like these.