Latest stack that can be merged on top of linux-next tree

Latest stack that can be merged on top of linux-next tree

[Karicheri, Muralidharan]

Guennadi,

I am not sure if your MT9T031 changes are part of linux-next tree at v4l-dvb. If not, can you point me to the latest stack that I can apply on top of linux-next tree to get your latest changes for MT9T031 sensor driver?

I plan to do integrate sensor driver with vpfe capture driver this week.

BTW, Is there a driver for the PCA9543 i2c switch that is part of MT9T031 headboard? 

Thanks.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2@ti.com

Re: Latest stack that can be merged on top of linux-next tree

[HoP]

Hi,

2009/12/10 Karicheri, Muralidharan <m-karicheri2@ti.com>:
> Guennadi,
>
> I am not sure if your MT9T031 changes are part of linux-next tree at v4l-dvb. If not, can you point me to the latest stack that I can apply on top of linux-next tree to get your latest changes for MT9T031 sensor driver?
>
> I plan to do integrate sensor driver with vpfe capture driver this week.
>
> BTW, Is there a driver for the PCA9543 i2c switch that is part of MT9T031 headboard?
>

I would like to know answer also :)

I had to add support for pca9542 (what is 2 port switch) for our project.
After some googling I found some patches for similar kernel I was
working on (2.6.22). You can find original patches for example there:
http://www.mail-archive.com/i2c@lm-sensors.org/msg00315.html

FYI, the driver pca954x.c seems to be driver for full family of i2c
muxes/switches. Such code works fine for me.

The only thing I didn't find was why the code was never merged.

I hope it can helps you.

/Honza

Re: Latest stack that can be merged on top of linux-next tree

[Daniel Glöckner]

Hi,

On 12/10/2009 08:39 PM, HoP wrote:
> 2009/12/10 Karicheri, Muralidharan <m-karicheri2@ti.com>:
>> BTW, Is there a driver for the PCA9543 i2c switch that is part of MT9T031
>> headboard?
>>
> 
> I would like to know answer also :)
> 
> I had to add support for pca9542 (what is 2 port switch) for our project.
> After some googling I found some patches for similar kernel I was
> working on (2.6.22). You can find original patches for example there:
> http://www.mail-archive.com/i2c@lm-sensors.org/msg00315.html
> 
> FYI, the driver pca954x.c seems to be driver for full family of i2c
> muxes/switches. Such code works fine for me.
> 
> The only thing I didn't find was why the code was never merged.

the driver that has the greatest chance of being accepted has been discussed
on the linux-i2c list a few days ago:

http://thread.gmane.org/gmane.linux.drivers.i2c/4856

The patchset they are talking about is this one:

http://thread.gmane.org/gmane.linux.drivers.i2c/2998

With these patches the bus segments beyond the i2c multiplexer will be
registered as separate i2c busses. Access to a device on those busses
will then automatically reconfigure the multiplexer.


Last time we tried to enable only one channel of the pca9543 on the mt9d131
board it had an effect on the brightness. Unfortunately we don't have the
schematics of the head board. Can anyone explain what was going on there?

  Daniel

-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner

RE: Latest stack that can be merged on top of linux-next tree

[Karicheri, Muralidharan]

Hi,

Thanks for the email.

Any idea how i2c drivers can work with this?

Currently in my board, I have adapter id = 1 for main i2c bus. So when this mux driver is built into the kernel, I guess I can access it using a different adapter id, right? If so, what is the adapter id?

How do I use this with MT9T031 driver? Any idea to share?

Thanks

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2@ti.com

>-----Original Message-----
>From: Daniel Glöckner [mailto:dg@emlix.com]
>Sent: Thursday, December 10, 2009 3:15 PM
>To: HoP
>Cc: Karicheri, Muralidharan; linux-media@vger.kernel.org
>Subject: Re: Latest stack that can be merged on top of linux-next tree
>
>Hi,
>
>On 12/10/2009 08:39 PM, HoP wrote:
>> 2009/12/10 Karicheri, Muralidharan <m-karicheri2@ti.com>:
>>> BTW, Is there a driver for the PCA9543 i2c switch that is part of
>MT9T031
>>> headboard?
>>>
>>
>> I would like to know answer also :)
>>
>> I had to add support for pca9542 (what is 2 port switch) for our project.
>> After some googling I found some patches for similar kernel I was
>> working on (2.6.22). You can find original patches for example there:
>> http://www.mail-archive.com/i2c@lm-sensors.org/msg00315.html
>>
>> FYI, the driver pca954x.c seems to be driver for full family of i2c
>> muxes/switches. Such code works fine for me.
>>
>> The only thing I didn't find was why the code was never merged.
>
>the driver that has the greatest chance of being accepted has been
>discussed
>on the linux-i2c list a few days ago:
>
>http://thread.gmane.org/gmane.linux.drivers.i2c/4856
>
>The patchset they are talking about is this one:
>
>http://thread.gmane.org/gmane.linux.drivers.i2c/2998
>
>With these patches the bus segments beyond the i2c multiplexer will be
>registered as separate i2c busses. Access to a device on those busses
>will then automatically reconfigure the multiplexer.
>
>
>Last time we tried to enable only one channel of the pca9543 on the mt9d131
>board it had an effect on the brightness. Unfortunately we don't have the
>schematics of the head board. Can anyone explain what was going on there?
>
>  Daniel
>
>--
>Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
>Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany
>Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
>Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055
>
>emlix - your embedded linux partner

Re: Latest stack that can be merged on top of linux-next tree

[HoP]

Hi,

2009/12/10 Karicheri, Muralidharan <m-karicheri2@ti.com>:
> Hi,
>
> Thanks for the email.
>
> Any idea how i2c drivers can work with this?
>
> Currently in my board, I have adapter id = 1 for main i2c bus. So when this mux driver is built into the kernel, I guess I can access it using a different adapter id, right? If so, what is the adapter id?

Yes, exactly that is way of using - additional i2c buses were born when pca954x
started.

Daniel already described this in his mail:

"With these patches the bus segments beyond the i2c multiplexer will be
registered as separate i2c busses. Access to a device on those busses
will then automatically reconfigure the multiplexer."

Additional i2c buses (adapters) were counted from number +1 higher
then highest i2c bus number. If you main i2c bus is i2c-1, then you
you should find i2c-2,i2c-3,i2c-4,i2c-5 new buses after pca954x loading.

You can check that with i2cdetect tools.

>
> How do I use this with MT9T031 driver? Any idea to share?
>

I never had a look inside mt9t031 driver, but in general - you simply
point to some of that additional adaper by i2c_get_adapter(x)

Idea is very smart. You don't need to manage pca954x on your own.
Driver do it itself :)

/Honza

RE: Latest stack that can be merged on top of linux-next tree

[Karicheri, Muralidharan]

Hi,

Thanks for the response. One more question that I have is if
the devices on the two buses can use the same i2c address.
That is the case for my board. So wondering if this works as
well.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2@ti.com

>-----Original Message-----
>From: HoP [mailto:jpetrous@gmail.com]
>Sent: Thursday, December 10, 2009 4:16 PM
>To: Karicheri, Muralidharan
>Cc: Daniel Glöckner; linux-media@vger.kernel.org
>Subject: Re: Latest stack that can be merged on top of linux-next tree
>
>Hi,
>
>2009/12/10 Karicheri, Muralidharan <m-karicheri2@ti.com>:
>> Hi,
>>
>> Thanks for the email.
>>
>> Any idea how i2c drivers can work with this?
>>
>> Currently in my board, I have adapter id = 1 for main i2c bus. So when
>this mux driver is built into the kernel, I guess I can access it using a
>different adapter id, right? If so, what is the adapter id?
>
>Yes, exactly that is way of using - additional i2c buses were born when
>pca954x
>started.
>
>Daniel already described this in his mail:
>
>"With these patches the bus segments beyond the i2c multiplexer will be
>registered as separate i2c busses. Access to a device on those busses
>will then automatically reconfigure the multiplexer."
>
>Additional i2c buses (adapters) were counted from number +1 higher
>then highest i2c bus number. If you main i2c bus is i2c-1, then you
>you should find i2c-2,i2c-3,i2c-4,i2c-5 new buses after pca954x loading.
>
>You can check that with i2cdetect tools.
>
>>
>> How do I use this with MT9T031 driver? Any idea to share?
>>
>
>I never had a look inside mt9t031 driver, but in general - you simply
>point to some of that additional adaper by i2c_get_adapter(x)
>
>Idea is very smart. You don't need to manage pca954x on your own.
>Driver do it itself :)
>
>/Honza

Re: Latest stack that can be merged on top of linux-next tree

[HoP]

Hi

2009/12/11 Karicheri, Muralidharan <m-karicheri2@ti.com>:
> Hi,
>
> Thanks for the response. One more question that I have is if
> the devices on the two buses can use the same i2c address.
> That is the case for my board. So wondering if this works as
> well.
>

That is IMHO exactly reason of existence such "expanders".
We, for example have two DVB-S2 tuners, using totally
same i2c addresses (for demod & pll).

If you are carefull and access such devices only using
those virtual i2c buses, then you not need to manage
switching between them at all. It is job for pca954x
driver. Simple and easy :)

/Honza

Re: Latest stack that can be merged on top of linux-next tree

[Guennadi Liakhovetski]

Hi Muralidharan

On Thu, 10 Dec 2009, Karicheri, Muralidharan wrote:

> Guennadi,
> 
> I am not sure if your MT9T031 changes are part of linux-next tree at 
> v4l-dvb. If not, can you point me to the latest stack that I can apply 
> on top of linux-next tree to get your latest changes for MT9T031 sensor 
> driver?

As you probably have seen, I posted a pull request a couple of hours ago, 
which also contains the change to mt9t031, that you're asking about.

> I plan to do integrate sensor driver with vpfe capture driver this week.
> 
> BTW, Is there a driver for the PCA9543 i2c switch that is part of 
> MT9T031 headboard?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

RE: Latest stack that can be merged on top of linux-next tree

[Karicheri, Muralidharan]

Guennadi,

I marged relevant files from the latest of your v4l tree after seeing your pull request. I worked fine for VGA capture. But I need to enable SOC_CAMERA to get the MT9T031 enabled which looks improper to me. Can we remove this restriction from KConfig? I plan to send a vpfe capture patch to support capture using this driver this week.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2@ti.com

>-----Original Message-----
>From: Guennadi Liakhovetski [mailto:g.liakhovetski@gmx.de]
>Sent: Friday, December 11, 2009 7:47 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org
>Subject: Re: Latest stack that can be merged on top of linux-next tree
>
>Hi Muralidharan
>
>On Thu, 10 Dec 2009, Karicheri, Muralidharan wrote:
>
>> Guennadi,
>>
>> I am not sure if your MT9T031 changes are part of linux-next tree at
>> v4l-dvb. If not, can you point me to the latest stack that I can apply
>> on top of linux-next tree to get your latest changes for MT9T031 sensor
>> driver?
>
>As you probably have seen, I posted a pull request a couple of hours ago,
>which also contains the change to mt9t031, that you're asking about.
>
>> I plan to do integrate sensor driver with vpfe capture driver this week.
>>
>> BTW, Is there a driver for the PCA9543 i2c switch that is part of
>> MT9T031 headboard?
>
>Thanks
>Guennadi
>---
>Guennadi Liakhovetski, Ph.D.
>Freelance Open-Source Software Developer
>http://www.open-technology.de/

RE: Latest stack that can be merged on top of linux-next tree

[Guennadi Liakhovetski]

On Mon, 14 Dec 2009, Karicheri, Muralidharan wrote:

> Guennadi,
> 
> I marged relevant files from the latest of your v4l tree after seeing 
> your pull request. I worked fine for VGA capture.

Good.

> But I need to enable 
> SOC_CAMERA to get the MT9T031 enabled which looks improper to me. Can we 
> remove this restriction from KConfig?

Sure, as long as we have a valid case where the driver can and does work 
without soc-camera, which we now do, we shall remove this dependency.

> I plan to send a vpfe capture 
> patch to support capture using this driver this week.

Good, looking forward to it.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

RE: Latest stack that can be merged on top of linux-next tree

[Karicheri, Muralidharan]

Guennadi,

>> I plan to send a vpfe capture
>> patch to support capture using this driver this week.
>
>Good, looking forward to it.

I will copy you on the request for reviewing the patch.
It will be great if you can review the same. 
-Murali
>
>Thanks
>Guennadi
>---
>Guennadi Liakhovetski, Ph.D.
>Freelance Open-Source Software Developer
>http://www.open-technology.de/