Hi Jean,
Please see my responses below (in bold).
Thanks,
On Fri, Oct 3, 2008 at 3:56 AM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> On Thu, 2 Oct 2008 18:03:35 -0400, naitik amin wrote:
> > I was trying to use the i2c-stub driver.
> >
> > What I did was I hardcoded the address to 0x23 and inserted the
> i2c-stub.ko
>
> Hard-coded? How, and why? The address is supposed to be passed as a
> module parameter:
>
> modprobe i2c-stub chip_addr=0x23
>
> *>>> I did it this way because doing insmod with argument gave me an
> error.*
>
*insmod i2c-stub.ko chip_addr=0x23
insmod: init_module 'i2c-stub.ko' failed (No such device)
This is may be because I am using Android Goldfish environment. So just to
go around I hardcoded it.
*
> I then inserted ds1682.ko also part of the 2.6 kernel.
Which kernel version exactly?
> *>>> 2.6.25*
>
>
> > I was hoping to see that the probe function for ds1682.ko to be called
> but
> > it didn't. Can someone comment on what I maybe missing.
>
> The ds1682 driver is a new-style driver, it doesn't scan the adapters
> for devices. Instead, kernel code must explicitly instantiate the
> devices. Alternatively, we could add a mechanism to instantiate devices
> from user-space, but it's not there yet.
>
> I don't think you will get it to work anyway, because the ds1682 driver
> makes use of I2C block transactions, which i2c-stub doesn't support
> yet. So you would have to add support for I2C block transactions first.
>
* >>> Please see the insert below*
>
> > Oh and BTW I did change the i2c_board_info by calling
> > i2c_register_board_info in machine level init. The parameters that I had
> > here were "ds1362" for driver name and 0x23 for address.
>
> "ds1362"? The only device supported by the ds1682 driver is "ds1682".
> But the way I2C devices are matched changed recently, so it really
> depends on what exact kernel version you are using.
>
> Anyway, what are you trying to achieve in the first place?
> *>>>* *What I am trying to achieve is to automatically instantiate a i2c
> device from the board level init (something that you mentioned is not there
> yet). So thats what I was trying to do, correct me if I am wrong here, I am
> new to this architecture, but what my understanding is, *
>
> - *under new style drivers, you have to populate i2c_board_info struct
> and when i2c_new_device gets called creates it the i2c_client stance.*
> - *so in order to add "ds1682" to i2c_board_info I did*
>
> struct i2c_board_info __initdata goldfish_i2c_devices[] =
{
{
I2C_BOARD_INFO("ds1682", 0x23),
}
};
static void __init goldfish_init(void)
{
platform_device_register(&goldfish_pdev_bus_device);
platform_device_register(&goldfish_vms_device);
/* I2C */
//goldfish_add_device_i2c(goldfish_i2c_devices,
ARRAY_SIZE(goldfish_i2c_devices));
*i2c_register_board_info(0, goldfish_i2c_devices,
ARRAY_SIZE(goldfish_i2c_devices));*
}
* goldfish_init is called as a part of the board level init
(init_machine)*
>
> - *So now with my i2c_board_info populated with ds1682, i modified
> i2c-stub.c to hardcode it to 0x23 and inserted i2c-stub.ko*
>
>
> - *looking at the code for i2c-stub.c, its init fn calls
> i2c_add_adapter, it goes then goes through the i2c_board_info list and
> should find "ds1682" and should go through source below
> *
>
>
> - *
>
> i2c_add_adapter-->i2c_register_adapter-->i2c_scan_static_board_info-->i2c_new_device-->
> i2c_attach_client*
>
>
> - *So it should create a new i2c_client and attach to it.*
>
>
Is is a right way to do things ? Please let me know.
--
Jean Delvare
On Fri, Oct 3, 2008 at 3:56 AM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> On Thu, 2 Oct 2008 18:03:35 -0400, naitik amin wrote:
> > I was trying to use the i2c-stub driver.
> >
> > What I did was I hardcoded the address to 0x23 and inserted the
> i2c-stub.ko
>
> Hard-coded? How, and why? The address is supposed to be passed as a
> module parameter:
>
> modprobe i2c-stub chip_addr=0x23
>
> > I then inserted ds1682.ko also part of the 2.6 kernel.
>
> Which kernel version exactly?
>
> > I was hoping to see that the probe function for ds1682.ko to be called
> but
> > it didn't. Can someone comment on what I maybe missing.
>
> The ds1682 driver is a new-style driver, it doesn't scan the adapters
> for devices. Instead, kernel code must explicitly instantiate the
> devices. Alternatively, we could add a mechanism to instantiate devices
> from user-space, but it's not there yet.
>
> I don't think you will get it to work anyway, because the ds1682 driver
> makes use of I2C block transactions, which i2c-stub doesn't support
> yet. So you would have to add support for I2C block transactions first.
>
> > Oh and BTW I did change the i2c_board_info by calling
> > i2c_register_board_info in machine level init. The parameters that I had
> > here were "ds1362" for driver name and 0x23 for address.
>
> "ds1362"? The only device supported by the ds1682 driver is "ds1682".
> But the way I2C devices are matched changed recently, so it really
> depends on what exact kernel version you are using.
>
> Anyway, what are you trying to achieve in the first place?
>
> --
> Jean Delvare
>
_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
