RE: Latest stack that can be merged on top of linux-next tree
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-kariche...@ti.com -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Latest stack that can be merged on top of linux-next tree
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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Latest stack that can be merged on top of linux-next tree
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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest stack that can be merged on top of linux-next tree
Hi 2009/12/11 Karicheri, Muralidharan m-kariche...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Latest stack that can be merged on top of linux-next tree
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-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest stack that can be merged on top of linux-next tree
Hi, 2009/12/10 Karicheri, Muralidharan m-kariche...@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/i...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-kariche...@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/i...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Latest stack that can be merged on top of linux-next tree
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-kariche...@ti.com -Original Message- From: Daniel Glöckner [mailto:d...@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-kariche...@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/i...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest stack that can be merged on top of linux-next tree
Hi, 2009/12/10 Karicheri, Muralidharan m-kariche...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
