From mboxrd@z Thu Jan 1 00:00:00 1970 From: "naitik amin" Subject: Re: i2c-stub Date: Fri, 3 Oct 2008 13:07:00 -0400 Message-ID: References: <20081003095647.5fb7f0de@hyperion.delvare> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0377727273067599202==" Return-path: In-Reply-To: <20081003095647.5fb7f0de-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i2c-bounces-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Errors-To: i2c-bounces-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org To: Jean Delvare Cc: i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org List-Id: linux-i2c@vger.kernel.org --===============0377727273067599202== Content-Type: multipart/alternative; boundary="----=_Part_10842_10381419.1223053620776" ------=_Part_10842_10381419.1223053620776 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jean, Please see my responses below (in bold). Thanks, On Fri, Oct 3, 2008 at 3:56 AM, Jean Delvare 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 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 > ------=_Part_10842_10381419.1223053620776 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Jean,

Please see my responses below (in bold).

Thanks,

On Fri, Oct 3, 2008 at 3:56 AM, Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> 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 <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> 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

------=_Part_10842_10381419.1223053620776-- --===============0377727273067599202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ i2c mailing list i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org http://lists.lm-sensors.org/mailman/listinfo/i2c --===============0377727273067599202==--