Skip to contentSkip to conversation

new style i2c client problem: probe () is not called

DISCUSSION Darius 4 participants 9 messages May 13, 2008 – May 15, 2008 4 messages not in the archive I2C subsystem host drivers

lore
Share & tools
lore

Darius

author
#0 lore raw

I'm writing i2c client driver. I have writen my own i2c adapter driver. For testing, I have one small LCD driver, that is writen in "legacy" driver model. It works ok - does attach client, dettach adapter, detects my LCD on i2c bus, transmits data...
But when I use the same adapter driver with new style i2c client, it only registers new client driver to i2c-core, but does not call probe() function.
What I'm doing wrong?
I set up i2c_board_info in board init function. Should I somewhere call i2c_new_device()?

Darius.

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

#1 lore raw
Quoted 2 lines · Darius

I set up i2c_board_info in board init function. Should I somewhere call i2c_new_device()?

Have you called i2c_register_board_info? (If not, check arch/arm/mach-iop32x/em7210.c for an example)

All the best,

Wolfram

Signature · 2 lines
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#3 lore raw
Quoted 9 lines · Wolfram Sang
Quoted 2 lines · Darius

I set up i2c_board_info in board init function. Should I somewhere call i2c_new_device()?

Have you called i2c_register_board_info? (If not, check arch/arm/mach-iop32x/em7210.c for an example)

All the best,

Wolfram

yes, I have.
I attach simplified i2c code part from my driver above:

---------------------------------------------------------------------------------------------------------

struct ov7670 {
	struct i2c_client *client;
};

static int ov7670_probe(struct i2c_client *client, const struct i2c_device_id *did)

{
	struct ov7670 *ov7670;
	struct i2c_adapter *adapter =to_i2c_adapter(client->dev.parent);
	int ret;

	printk ("OV7670: error1\n");

	if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA)){
		return -EIO;
	}
	
	ov7670 = kzalloc(sizeof(struct ov7670), GFP_KERNEL);
	if (!ov7670)
		return -ENOMEM;
	ov7670->client = client;
	i2c_set_clientdata(client, ov7670);
	return 0;
}

static int ov7670_remove(struct i2c_client *client)

{
	struct ov7670 *ov7670 = i2c_get_clientdata(client);
	struct i2c_adapter *adapter =to_i2c_adapter(client->dev.parent);
	kfree(ov7670);
	return 0;
}
static const struct i2c_device_id ov7670_id[] = {
	{ "ov7670", 0 },
	{ }
};

MODULE_DEVICE_TABLE(i2c, ov7670_id);

static struct i2c_driver ov7670_i2c_driver = {
	.driver = 	
			{
				.name = "ov7670",
			},
	.probe		= ov7670_probe,
	.remove		= ov7670_remove,
	.id_table	= ov7670_id,
};

static int __init ov7670_init(void)

{
	printk ("OV7670: driver init\n");
	return i2c_add_driver(&ov7670_i2c_driver);
}

static void __exit ov7670_exit(void)

{
	printk ("OV7670: driver exit\n");	
	i2c_del_driver(&ov7670_i2c_driver);
}

module_init(ov7670_init);
module_exit(ov7670_exit);

-------------------------------------------------------------------------------------------

And piece from board init:

------------------------------------------------------------------------------------------

static struct i2c_board_info __initdata mx1ads_i2c_devices[] = {
	{
		I2C_BOARD_INFO("ov7670", 0x42),
	}
};

<...> i2c_register_board_info(0,mx1ads_i2c_devices,ARRAY_SIZE(mx1ads_i2c_devices)); <...>

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

#4 lore raw

Hi Darius,

Quoted 81 lines · Darius

I attach simplified i2c code part from my driver above:

---------------------------------------------------------------------------------------------------------

struct ov7670 {
	struct i2c_client *client;
};

static int ov7670_probe(struct i2c_client *client, const struct i2c_device_id *did)

{
	struct ov7670 *ov7670;
	struct i2c_adapter *adapter =to_i2c_adapter(client->dev.parent);
	int ret;

	printk ("OV7670: error1\n");

	if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA)){
		return -EIO;
	}
	
	ov7670 = kzalloc(sizeof(struct ov7670), GFP_KERNEL);
	if (!ov7670)
		return -ENOMEM;
	ov7670->client = client;
	i2c_set_clientdata(client, ov7670);
	return 0;
}

static int ov7670_remove(struct i2c_client *client)

{
	struct ov7670 *ov7670 = i2c_get_clientdata(client);
	struct i2c_adapter *adapter =to_i2c_adapter(client->dev.parent);
	kfree(ov7670);
	return 0;
}
static const struct i2c_device_id ov7670_id[] = {
	{ "ov7670", 0 },
	{ }
};

MODULE_DEVICE_TABLE(i2c, ov7670_id);

static struct i2c_driver ov7670_i2c_driver = {
	.driver = 	
			{
				.name = "ov7670",
			},
	.probe		= ov7670_probe,
	.remove		= ov7670_remove,
	.id_table	= ov7670_id,
};

static int __init ov7670_init(void)

{
	printk ("OV7670: driver init\n");
	return i2c_add_driver(&ov7670_i2c_driver);
}

static void __exit ov7670_exit(void)

{
	printk ("OV7670: driver exit\n");	
	i2c_del_driver(&ov7670_i2c_driver);
}

module_init(ov7670_init);
module_exit(ov7670_exit);

-------------------------------------------------------------------------------------------

And piece from board init:

------------------------------------------------------------------------------------------

static struct i2c_board_info __initdata mx1ads_i2c_devices[] = {
	{
		I2C_BOARD_INFO("ov7670", 0x42),
	}
};
Quoted 3 lines

<...> i2c_register_board_info(0,mx1ads_i2c_devices,ARRAY_SIZE(mx1ads_i2c_devices)); <...>

This code looks OK to me. But which driver handles i2c bus 0? Does your platform code create i2c bus 0? i2c-code will instantiate the ov7670 i2c device when i2c bus 0 is created by i2c_add_numbered_adapter(). So if you don't see it created, I suspect that i2c bus 0 itself is never registered.

Signature · 6 lines
Jean Delvare

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#6 lore raw
Quoted 6 lines

This code looks OK to me. But which driver handles i2c bus 0? Does your platform code create i2c bus 0? i2c-code will instantiate the ov7670 i2c device when i2c bus 0 is created by i2c_add_numbered_adapter(). So if you don't see it created, I suspect that i2c bus 0 itself is never registered.

Thanks, there was the problem. I have modified i2c adapter driver to use
i2c_add_numbered_adapter() instead i2c_add_adapter() and pass to the
adapter->nr = pdev->id. now probe is called.

Jean, what do you think about adding my i2c driver to mainline kernel? I've added this to Russel patch tracking system. Now it is a bit ugraded. Should I make new patch and send it here?

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

#7 lore raw
Quoted 7 lines · Darius
Quoted 6 lines

This code looks OK to me. But which driver handles i2c bus 0? Does your platform code create i2c bus 0? i2c-code will instantiate the ov7670 i2c device when i2c bus 0 is created by i2c_add_numbered_adapter(). So if you don't see it created, I suspect that i2c bus 0 itself is never registered.

Quoted 5 lines

Thanks, there was the problem. I have modified i2c adapter driver to use
i2c_add_numbered_adapter() instead i2c_add_adapter() and pass to the
adapter->nr = pdev->id. now probe is called.

Jean, what do you think about adding my i2c driver to mainline kernel?

Sorry, which driver?

Quoted 2 lines

I've added this to Russel patch tracking system. Now it is a bit ugraded. Should I make new patch and send it here?

Sure, sending an updated patch can't hurt.

Signature · 6 lines
Jean Delvare

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#9 lore raw
Quoted 7 lines · Jean Delvare
Quoted 6 lines · Darius
Quoted 6 lines

This code looks OK to me. But which driver handles i2c bus 0? Does your platform code create i2c bus 0? i2c-code will instantiate the ov7670 i2c device when i2c bus 0 is created by i2c_add_numbered_adapter(). So if you don't see it created, I suspect that i2c bus 0 itself is never registered.

Quoted 7 lines
Quoted 5 lines

Thanks, there was the problem. I have modified i2c adapter driver to use
i2c_add_numbered_adapter() instead i2c_add_adapter() and pass to the
adapter->nr = pdev->id. now probe is called.

Jean, what do you think about adding my i2c driver to mainline kernel?

Sorry, which driver?

I2C driver for IMX

Quoted 6 lines
Quoted 3 lines

I've added this to Russel patch tracking system. Now it is a bit ugraded. Should I make new patch and send it here?

Sure, sending an updated patch can't hurt.

ok, i'll prepare it.

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

#10 lore raw
In reply to Darius
Quoted 10 lines · Darius
Quoted 6 lines

This code looks OK to me. But which driver handles i2c bus 0? Does your platform code create i2c bus 0? i2c-code will instantiate the ov7670 i2c device when i2c bus 0 is created by i2c_add_numbered_adapter(). So if you don't see it created, I suspect that i2c bus 0 itself is never registered.

Thanks, there was the problem. I have modified i2c adapter driver to use
i2c_add_numbered_adapter() instead i2c_add_adapter() and pass to the
adapter->nr = pdev->id. now probe is called.

I'm not so sure this 1:1 mapping of platform to i2c bus ID is such a good idea, what if you have two i2c controllers and want to swap the two of them around?

Quoted 3 lines

Jean, what do you think about adding my i2c driver to mainline kernel? I've added this to Russel patch tracking system. Now it is a bit ugraded. Should I make new patch and send it here?

As a rule, stuff that touches drivers/i2c should be submitted via the i2c list with a cc: to the architecture specific list as a courtesy to the maintainer of that arch. It is not really within Russell (or any other arch maintainer) remit to be actually submitting upstream for drivers/i2c.

If a patch really has to touch both drivers/i2c and some other part of the kernel, then it either is up to the architecture maintainer(s) to ack the package for inclusion via the i2c tree, or up to both the i2c and architecture maintainers to get someone like akpm to merge.

Signature · 8 lines
Ben ([email protected], http://www.fluff.org/)

  'a smiley only costs 4 bytes'

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

A message that is not in the archive (sent off-list or not yet received): [email protected]

#12 lore raw

Hi Ben,

Quoted 8 lines · Ben Dooks
Quoted 3 lines · Darius

Thanks, there was the problem. I have modified i2c adapter driver to use
i2c_add_numbered_adapter() instead i2c_add_adapter() and pass to the
adapter->nr = pdev->id. now probe is called.

I'm not so sure this 1:1 mapping of platform to i2c bus ID is such a good idea, what if you have two i2c controllers and want to swap the two of them around?

You are right that using the platform device ID as the bus number has limitations. It seems that it has worked fine for everyone so far though. I guess that most embedded platforms have only one type of I2C controllers so there are no collisions. If a platform was to use several types of I2C controllers, presumably requiring different drivers, then the current strategy may lead to collisions. But then it shouldn't be too difficult to work around it, by passing the correct I2C bus number as platform data. I guess developers have been using the platform device ID merely as a shortcut.

I'm not too sure what you mean with "swapping the i2c controllers" though. Why would you want to do that? Maybe a concrete example would help.

Signature · 6 lines
Jean Delvare

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c