Calling an I2C camera sensor with SMBUS API?

Calling an I2C camera sensor with SMBUS API?

[Aguirre Rodriguez, Sergio Alberto]

Hi,

Some days back, Vaibhav Hiremat submitted patches for an I2C chip, and somebody (I think David Brownell) suggested to use SMBUS API instead of manually constructing i2c messages and sending using i2c_transfer API.

So I attempted to do the same for a camera sensor I've been working on.

But one thing I noticed is that my sensor needs to access 16-bit register addresses in the device, and I saw in SMBUS spec 2.0 that the equivalent thing (SMBUS commands) are only 8-bit length.

So, should this automatically discard using SMBUS api for my case, or am I missing something else? (like a SMBUS 16-bit expansion or so)

Regards,
Sergio

Re: Calling an I2C camera sensor with SMBUS API?

[David Brownell]

On Thursday 11 December 2008, Aguirre Rodriguez, Sergio Alberto wrote:
> But one thing I noticed is that my sensor needs to access 16-bit
> register addresses in the device, and I saw in SMBUS spec 2.0 that
> the equivalent thing (SMBUS commands) are only 8-bit length.  
> 
> So, should this automatically discard using SMBUS api for my case,
> or am I missing something else? (like a SMBUS 16-bit expansion or so) 

There's the "proc call" which gives 16 bits in each direction;
I think the Linux call for that got removed because it had no
users, but could be restored if needed.

Probably best to take this question up on the I2C list.

- Dave

RE: Calling an I2C camera sensor with SMBUS API?

[Aguirre Rodriguez, Sergio Alberto]

> From: David Brownell [mailto:david-b@pacbell.net]
> On Thursday 11 December 2008, Aguirre Rodriguez, Sergio Alberto wrote:
> > But one thing I noticed is that my sensor needs to access 16-bit
> > register addresses in the device, and I saw in SMBUS spec 2.0 that
> > the equivalent thing (SMBUS commands) are only 8-bit length.
> >
> > So, should this automatically discard using SMBUS api for my case,
> > or am I missing something else? (like a SMBUS 16-bit expansion or so)
> 
> There's the "proc call" which gives 16 bits in each direction;
> I think the Linux call for that got removed because it had no
> users, but could be restored if needed.
> 
> Probably best to take this question up on the I2C list.

Ok, thanks. Just did that. (with both of you guys on CC)

Regards,
Sergio

Issue: TWL4030-USB

[Pandita, Vikram]

I have not been following much of the TWL4030 USB development.
I came across this code:

<snip-start>
static int twl4030_set_peripheral(struct otg_transceiver *x,
                struct usb_gadget *gadget)
{
...
if (!gadget) {
>>>>>       omap_writew(0, OTG_IRQ_EN);
...
<snip-end>

This code will not work for OMAP3. There is no OHCI OTG block on OMAP3.


Regards,
Vikram 

Re: Issue: TWL4030-USB

[David Brownell]

On Tuesday 16 December 2008, Pandita, Vikram wrote:
> 
> I have not been following much of the TWL4030 USB development.
> I came across this code:
> 
> <snip-start>
> static int twl4030_set_peripheral(struct otg_transceiver *x,
>                 struct usb_gadget *gadget)
> {
> ...
> if (!gadget) {
> >>>>>       omap_writew(0, OTG_IRQ_EN);
> ...
> <snip-end>
> 
> This code will not work for OMAP3. There is no OHCI OTG block on OMAP3.

Exactly why that code is removed in the latest code ... I don't
see it in drivers/usb/otg/twl4030-usb.c do you?

- Dave



> 
> 
> Regards,
> Vikram 
> 
> 

RE: Issue: TWL4030-USB

[Pandita, Vikram]

>-----Original Message-----
>From: David Brownell [mailto:david-b@pacbell.net]
>Sent: Tuesday, December 16, 2008 2:36 PM
>To: Pandita, Vikram
>Cc: linux-omap@vger.kernel.org
>Subject: Re: Issue: TWL4030-USB
>
>On Tuesday 16 December 2008, Pandita, Vikram wrote:
>>
>> I have not been following much of the TWL4030 USB development.
>> I came across this code:
>>
>> <snip-start>
>> static int twl4030_set_peripheral(struct otg_transceiver *x,
>>                 struct usb_gadget *gadget)
>> {
>> ...
>> if (!gadget) {
>> >>>>>       omap_writew(0, OTG_IRQ_EN);
>> ...
>> <snip-end>
>>
>> This code will not work for OMAP3. There is no OHCI OTG block on OMAP3.
>
>Exactly why that code is removed in the latest code ... I don't
>see it in drivers/usb/otg/twl4030-usb.c do you?

I looked into: drivers/i2c/chips/twl4030-usb.c
Is this supposed to be removed then? 

>
>- Dave
>
>
>
>>
>>
>> Regards,
>> Vikram
>>
>>
>
>

Re: Issue: TWL4030-USB

[Felipe Balbi]

On Wed, Dec 17, 2008 at 02:25:29AM +0530, Pandita, Vikram wrote:
> I looked into: drivers/i2c/chips/twl4030-usb.c
> Is this supposed to be removed then? 

you should probably git pull :-)

This code doesn't exist in current linux-omap.

-- 
balbi

Re: Issue: TWL4030-USB

[David Brownell]

On Tuesday 16 December 2008, Pandita, Vikram wrote:
> >Exactly why that code is removed in the latest code ... I
> >don't see it in drivers/usb/otg/twl4030-usb.c do you?
> 
> I looked into: drivers/i2c/chips/twl4030-usb.c
> Is this supposed to be removed then? 

It's been moved, since new i2c/chips code can't be
merged to mainline.

- dave

RE: Issue: TWL4030-USB

[Pandita, Vikram]

>-----Original Message-----
>From: Felipe Balbi [mailto:me@felipebalbi.com]
>Sent: Tuesday, December 16, 2008 3:10 PM
>To: Pandita, Vikram
>Cc: David Brownell; linux-omap@vger.kernel.org
>Subject: Re: Issue: TWL4030-USB
>
>On Wed, Dec 17, 2008 at 02:25:29AM +0530, Pandita, Vikram wrote:
>> I looked into: drivers/i2c/chips/twl4030-usb.c
>> Is this supposed to be removed then?
>
>you should probably git pull :-)
>
>This code doesn't exist in current linux-omap.

Yes the git pull solved the issue. 

>
>--
>balbi