Re: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
Hi Javier, On Friday 27 May 2011 17:36:24 javier Martin wrote: > On 27 May 2011 16:31, Laurent Pinchart wrote: > > On Thursday 26 May 2011 13:31:37 javier Martin wrote: > >> OK, I think I've found the problem with the power management. > >> > >> As it is stated in mt9p031 datasheet [3] p 59, a sequence involving > >> [VAA,VAA_PIX,VDD_PLL], [VDD,VDD_IO], [Reset] and [Ext Clk] must be > >> followed in order to properly power up or down the sensor. > >> > >> If we take a look to the LI-5M031 schematic[1] and Beagleboard xM > >> schematic [2] we'll notice that voltages are connected as follows: > >> > >> [VDD] (1,8V) <--- V2.8 <--- CAM_CORE <--- VAUX3 TPS65950 > >> [VDD_IO (VDDQ)] (1,8V) <--- V1.8 <--- CAM_IO <--- VAUX4 TPS65950 > >> [VAA, VAA_PIX, VDD_PLL] (2,8V) <---| U6 |<-- V3.3VD <-- HUB_3V3 <--| > >> U16 | enabled by USBHOST_PWR_EN <-- LEDA TPS65950 > >> > >> VAUX3 (VDD) and VAUX4 (VDD_IO) are fine, they are only used for > >> powering our camera sensor. However, when it comes to the analog part > >> (VAA, VAA_PIX...), it is got from HUB_3V3 which is also used for > >> powering USB and ethernet. > > > > *sigh* Why do hardware designers do things like that, really ? > > > >> If we really want to activate/deactivate regulators that power mt9p031 > >> we need to follow [3] p59. However, for that purpose we need to ensure > >> that a call to regulator_enable() or regulator_disable() will really > >> power on/off that supply, otherwise the sequence won't be matched and > >> the chip will have problems. > >> > >> Beagleboard xM is a good example of platform where this happens since > >> HUB_3V3 and thus (VAA, VAA_PIX, etc...) cannot be deactivated since it > >> is being used by other devices. But there could be others. > >> > >> So, as a conclusion, and in order to unblock my work, my purpose for > >> power management in mt9p031 would be the following: > >> - Drop regulator handling as we cannot guarantee that power on > >> sequence will be accomplished. > >> - Keep on asserting/de-asserting reset which saves a lot of power. > >> - Also activate/deactivate clock when necessary to save some power. > >> > >> I'm looking forward to read your comments on this. > > > > Even if you keep the sensor powered all the time, how do you ensure that > > VAUX3 is available before HUB_3V3 when the system is powered up ? > > You can't. And in fact what happens its the opposite. But it works. I wonder why, as the power supplies are sequenced the wrong way. It seems like the hardware has been designed not to work. Sometimes I wish hardware designers would read the chip specs before shipping boards in the wild and relying on us to fix their mistakes. > On the other hand, not being able to disable/enable HUB_3V3 can make, > as a hardware guy has told me, power on reset internal circuit not to > work [1] and thus the power down / power up fails. > > [1] http://en.wikipedia.org/wiki/Power-on_reset -- Regards, Laurent Pinchart -- 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On 30 May 2011 08:48, Koen Kooi wrote: > > Op 30 mei 2011, om 04:13 heeft Chris Rodley het volgende geschreven: > >> On 29/05/11 03:04, Guennadi Liakhovetski wrote: >>> On Sat, 28 May 2011, Guennadi Liakhovetski wrote: >>> Hi Javier On Thu, 26 May 2011, javier Martin wrote: > I use a patched version of yavta and Mplayer to see video > (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) Are you really using those versions and patches, as described in BBxM-MT9P031.txt? I don't think those versions still work with 2.6.39, they don't even compile for me. Whereas if I take current HEAD, it builds and media-ctl seems to run error-free, but yavta produces no output. >>> >>> Ok, sorry for the noise. It works with current media-ctl with no patches, >>> so, we better don't try to confuse our users / testers:) >>> >>> Thanks >>> Guennadi >> >> Hi, >> >> Still no luck getting the v3 patch working. >> I did go back and re-test the first v1 patch that Javier released. >> This works fine with the same version of media-ctl and yavta. >> So it isn't either of those programs that is causing the problem. >> >> Must be something else. >> >> Will wait and see how Koen goes. > > I'm still stuck in "isp did no go idle" land, so even if yavta works, I can't > get any output. It did output 3 frames to disk a few days ago, but that got > deleted on reboot :( I don't know guys what to tell you. I use kernel 2.6.39 + last version of my patches + old patched yavta version (http://download.open-technology.de/BeagleBoard_xM-MT9P031/). Guennadi, did you manage to get it working? I'm preparing new patches for kernel 2.6.39 which I think should be ready for submission. I'll send them during the morning. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
Op 30 mei 2011, om 04:13 heeft Chris Rodley het volgende geschreven: > On 29/05/11 03:04, Guennadi Liakhovetski wrote: >> On Sat, 28 May 2011, Guennadi Liakhovetski wrote: >> >>> Hi Javier >>> >>> On Thu, 26 May 2011, javier Martin wrote: >>> I use a patched version of yavta and Mplayer to see video (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) >>> >>> Are you really using those versions and patches, as described in >>> BBxM-MT9P031.txt? I don't think those versions still work with 2.6.39, >>> they don't even compile for me. Whereas if I take current HEAD, it builds >>> and media-ctl seems to run error-free, but yavta produces no output. >> >> Ok, sorry for the noise. It works with current media-ctl with no patches, >> so, we better don't try to confuse our users / testers:) >> >> Thanks >> Guennadi > > Hi, > > Still no luck getting the v3 patch working. > I did go back and re-test the first v1 patch that Javier released. > This works fine with the same version of media-ctl and yavta. > So it isn't either of those programs that is causing the problem. > > Must be something else. > > Will wait and see how Koen goes. I'm still stuck in "isp did no go idle" land, so even if yavta works, I can't get any output. It did output 3 frames to disk a few days ago, but that got deleted on reboot :(-- 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On Sun, 29 May 2011, Chris Rodley wrote: > On 29/05/11 03:04, Guennadi Liakhovetski wrote: > > On Sat, 28 May 2011, Guennadi Liakhovetski wrote: > > > >> Hi Javier > >> > >> On Thu, 26 May 2011, javier Martin wrote: > >> > >>> I use a patched version of yavta and Mplayer to see video > >>> (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) > >> > >> Are you really using those versions and patches, as described in > >> BBxM-MT9P031.txt? I don't think those versions still work with 2.6.39, > >> they don't even compile for me. Whereas if I take current HEAD, it builds > >> and media-ctl seems to run error-free, but yavta produces no output. > > > > Ok, sorry for the noise. It works with current media-ctl with no patches, > > so, we better don't try to confuse our users / testers:) > > > > Thanks > > Guennadi > > Hi, > > Still no luck getting the v3 patch working. > I did go back and re-test the first v1 patch that Javier released. > This works fine with the same version of media-ctl and yavta. > So it isn't either of those programs that is causing the problem. It is. For 2.6.39 + v3 of Javier's patches you need a current media-ctl version unpatched. Interestingly, the new yavta version didn't work for me, but maybe I've done something wrong. The old (patched) version did work though. > Must be something else. > > Will wait and see how Koen goes. 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On 29/05/11 03:04, Guennadi Liakhovetski wrote: > On Sat, 28 May 2011, Guennadi Liakhovetski wrote: > >> Hi Javier >> >> On Thu, 26 May 2011, javier Martin wrote: >> >>> I use a patched version of yavta and Mplayer to see video >>> (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) >> >> Are you really using those versions and patches, as described in >> BBxM-MT9P031.txt? I don't think those versions still work with 2.6.39, >> they don't even compile for me. Whereas if I take current HEAD, it builds >> and media-ctl seems to run error-free, but yavta produces no output. > > Ok, sorry for the noise. It works with current media-ctl with no patches, > so, we better don't try to confuse our users / testers:) > > Thanks > Guennadi Hi, Still no luck getting the v3 patch working. I did go back and re-test the first v1 patch that Javier released. This works fine with the same version of media-ctl and yavta. So it isn't either of those programs that is causing the problem. Must be something else. Will wait and see how Koen goes. Cheers, Chris -- 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On Sat, 28 May 2011, Guennadi Liakhovetski wrote: > Hi Javier > > On Thu, 26 May 2011, javier Martin wrote: > > > I use a patched version of yavta and Mplayer to see video > > (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) > > Are you really using those versions and patches, as described in > BBxM-MT9P031.txt? I don't think those versions still work with 2.6.39, > they don't even compile for me. Whereas if I take current HEAD, it builds > and media-ctl seems to run error-free, but yavta produces no output. Ok, sorry for the noise. It works with current media-ctl with no patches, so, we better don't try to confuse our users / testers:) 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
Hi Javier On Thu, 26 May 2011, javier Martin wrote: > I use a patched version of yavta and Mplayer to see video > (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) Are you really using those versions and patches, as described in BBxM-MT9P031.txt? I don't think those versions still work with 2.6.39, they don't even compile for me. Whereas if I take current HEAD, it builds and media-ctl seems to run error-free, but yavta produces no output. 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On 27 May 2011 16:31, Laurent Pinchart wrote: > Hi Javier, > > On Thursday 26 May 2011 13:31:37 javier Martin wrote: >> OK, I think I've found the problem with the power management. >> >> As it is stated in mt9p031 datasheet [3] p 59, a sequence involving >> [VAA,VAA_PIX,VDD_PLL], [VDD,VDD_IO], [Reset] and [Ext Clk] must be >> followed in order to properly power up or down the sensor. >> >> If we take a look to the LI-5M031 schematic[1] and Beagleboard xM >> schematic [2] we'll notice that voltages are connected as follows: >> >> [VDD] (1,8V) <--- V2.8 <--- CAM_CORE <--- VAUX3 TPS65950 >> [VDD_IO (VDDQ)] (1,8V) <--- V1.8 <--- CAM_IO <--- VAUX4 TPS65950 >> [VAA, VAA_PIX, VDD_PLL] (2,8V) <---| U6 |<-- V3.3VD <-- HUB_3V3 <--| >> U16 | enabled by USBHOST_PWR_EN <-- LEDA TPS65950 >> >> VAUX3 (VDD) and VAUX4 (VDD_IO) are fine, they are only used for >> powering our camera sensor. However, when it comes to the analog part >> (VAA, VAA_PIX...), it is got from HUB_3V3 which is also used for >> powering USB and ethernet. > > *sigh* Why do hardware designers do things like that, really ? > >> If we really want to activate/deactivate regulators that power mt9p031 >> we need to follow [3] p59. However, for that purpose we need to ensure >> that a call to regulator_enable() or regulator_disable() will really >> power on/off that supply, otherwise the sequence won't be matched and >> the chip will have problems. >> >> Beagleboard xM is a good example of platform where this happens since >> HUB_3V3 and thus (VAA, VAA_PIX, etc...) cannot be deactivated since it >> is being used by other devices. But there could be others. >> >> So, as a conclusion, and in order to unblock my work, my purpose for >> power management in mt9p031 would be the following: >> - Drop regulator handling as we cannot guarantee that power on >> sequence will be accomplished. >> - Keep on asserting/de-asserting reset which saves a lot of power. >> - Also activate/deactivate clock when necessary to save some power. >> >> I'm looking forward to read your comments on this. > > Even if you keep the sensor powered all the time, how do you ensure that VAUX3 > is available before HUB_3V3 when the system is powered up ? You can't. And in fact what happens its the opposite. But it works. On the other hand, not being able to disable/enable HUB_3V3 can make, as a hardware guy has told me, power on reset internal circuit not to work [1] and thus the power down / power up fails. [1] http://en.wikipedia.org/wiki/Power-on_reset -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
Hi Javier, On Thursday 26 May 2011 13:31:37 javier Martin wrote: > OK, I think I've found the problem with the power management. > > As it is stated in mt9p031 datasheet [3] p 59, a sequence involving > [VAA,VAA_PIX,VDD_PLL], [VDD,VDD_IO], [Reset] and [Ext Clk] must be > followed in order to properly power up or down the sensor. > > If we take a look to the LI-5M031 schematic[1] and Beagleboard xM > schematic [2] we'll notice that voltages are connected as follows: > > [VDD] (1,8V) <--- V2.8 <--- CAM_CORE <--- VAUX3 TPS65950 > [VDD_IO (VDDQ)] (1,8V) <--- V1.8 <--- CAM_IO <--- VAUX4 TPS65950 > [VAA, VAA_PIX, VDD_PLL] (2,8V) <---| U6 |<-- V3.3VD <-- HUB_3V3 <--| > U16 | enabled by USBHOST_PWR_EN <-- LEDA TPS65950 > > VAUX3 (VDD) and VAUX4 (VDD_IO) are fine, they are only used for > powering our camera sensor. However, when it comes to the analog part > (VAA, VAA_PIX...), it is got from HUB_3V3 which is also used for > powering USB and ethernet. *sigh* Why do hardware designers do things like that, really ? > If we really want to activate/deactivate regulators that power mt9p031 > we need to follow [3] p59. However, for that purpose we need to ensure > that a call to regulator_enable() or regulator_disable() will really > power on/off that supply, otherwise the sequence won't be matched and > the chip will have problems. > > Beagleboard xM is a good example of platform where this happens since > HUB_3V3 and thus (VAA, VAA_PIX, etc...) cannot be deactivated since it > is being used by other devices. But there could be others. > > So, as a conclusion, and in order to unblock my work, my purpose for > power management in mt9p031 would be the following: > - Drop regulator handling as we cannot guarantee that power on > sequence will be accomplished. > - Keep on asserting/de-asserting reset which saves a lot of power. > - Also activate/deactivate clock when necessary to save some power. > > I'm looking forward to read your comments on this. Even if you keep the sensor powered all the time, how do you ensure that VAUX3 is available before HUB_3V3 when the system is powered up ? > [1] https://www.leopardimaging.com/uploads/li-5m03_camera_board_v2.pdf > [2] http://beagle.s3.amazonaws.com/design/xM-A3/BB-xM_Schematic_REVA3.pdf > [3] http://www.aptina.com/products/image_sensors/mt9p031i12stc/ -- Regards, Laurent Pinchart -- 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On 26/05/11 19:24, javier Martin wrote: > On 25 May 2011 15:38, Koen Kooi wrote: >> > >> > Op 25 mei 2011, om 13:16 heeft Javier Martin het volgende geschreven: >> > >>> >> It includes several fixes pointed out by Laurent Pinchart. However, >>> >> the BUG which shows artifacts in the image (horizontal lines) still >>> >> persists. It won't happen if 1v8 regulator is not disabled (i.e. >>> >> comment line where it is disabled in function "mt9p031_power_off"). >>> >> I know there can be some other details to fix but I would like someone >>> >> could help in the power management issue. >> > >> > I tried this + your beagle patch on 2.6.39 and both ISP and sensor being >> > builtin to the kernel, I get the following: >> > >> > root@beagleboardxMC:~# media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP >> > CCDC":0[1 ], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' >> > Resetting all links to inactive >> > Setting up link 16:0 -> 5:0 [1] >> > Setting up link 5:1 -> 6:0 [1] >> > >> > root@beagleboardxMC:~# media-ctl -f '"mt9p031 2-0048":0[SGRBG12 320x240], >> > "OMAP3 ISP CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' >> > Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0 >> > Format set: SGRBG12 320x240 >> > Setting up format SGRBG12 320x240 on pad OMAP3 ISP CCDC/0 >> > Format set: SGRBG12 320x240 >> > Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0 >> > Format set: SGRBG8 320x240 >> > Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1 >> > Format set: SGRBG8 320x240 >> > >> > oot@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip >> > 3 -F `media-ctl -e "OMAP3 ISP CCDC output"` >> > Device /dev/video2 opened. >> > Device `OMAP3 ISP CCDC output' on `media' is a video capture device. >> > Video format set: SGRBG8 (47425247) 320x240 buffer size 76800 >> > Video format: SGRBG8 (47425247) 320x240 buffer size 76800 >> > 4 buffers requested. >> > length: 76800 offset: 0 >> > Buffer 0 mapped at address 0x4030d000. >> > length: 76800 offset: 77824 >> > Buffer 1 mapped at address 0x4033. >> > length: 76800 offset: 155648 >> > Buffer 2 mapped at address 0x4042d000. >> > length: 76800 offset: 233472 >> > Buffer 3 mapped at address 0x40502000. >> > [ 4131.459930] omap3isp omap3isp: CCDC won't become idle! > Please, test it again using new RFC v3 I've just submitted. > I have personally tested it against kernel 2.6.39 with the following > .config file: Hi, No improvements here for me with v3. Still: # yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F `media-ctl -e "OMAP3 ISP CCDC output"` | nc 10.1.1.16 3000 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: width: 320 height: 240 buffer size: 76800 Video format: GRBG (47425247) 320x240 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x400d8000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x40292000. length: 76800 offset: 155648 Buffer 2 mapped at address 0x40345000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x40377000. Will wait and see if Koen finds anything. Cheers, Chris -- 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
OK, I think I've found the problem with the power management. As it is stated in mt9p031 datasheet [3] p 59, a sequence involving [VAA,VAA_PIX,VDD_PLL], [VDD,VDD_IO], [Reset] and [Ext Clk] must be followed in order to properly power up or down the sensor. If we take a look to the LI-5M031 schematic[1] and Beagleboard xM schematic [2] we'll notice that voltages are connected as follows: [VDD] (1,8V) <--- V2.8 <--- CAM_CORE <--- VAUX3 TPS65950 [VDD_IO (VDDQ)] (1,8V) <--- V1.8 <--- CAM_IO <--- VAUX4 TPS65950 [VAA, VAA_PIX, VDD_PLL] (2,8V) <---| U6 |<-- V3.3VD <-- HUB_3V3 <--| U16 | enabled by USBHOST_PWR_EN <-- LEDA TPS65950 VAUX3 (VDD) and VAUX4 (VDD_IO) are fine, they are only used for powering our camera sensor. However, when it comes to the analog part (VAA, VAA_PIX...), it is got from HUB_3V3 which is also used for powering USB and ethernet. If we really want to activate/deactivate regulators that power mt9p031 we need to follow [3] p59. However, for that purpose we need to ensure that a call to regulator_enable() or regulator_disable() will really power on/off that supply, otherwise the sequence won't be matched and the chip will have problems. Beagleboard xM is a good example of platform where this happens since HUB_3V3 and thus (VAA, VAA_PIX, etc...) cannot be deactivated since it is being used by other devices. But there could be others. So, as a conclusion, and in order to unblock my work, my purpose for power management in mt9p031 would be the following: - Drop regulator handling as we cannot guarantee that power on sequence will be accomplished. - Keep on asserting/de-asserting reset which saves a lot of power. - Also activate/deactivate clock when necessary to save some power. I'm looking forward to read your comments on this. [1] https://www.leopardimaging.com/uploads/li-5m03_camera_board_v2.pdf [2] http://beagle.s3.amazonaws.com/design/xM-A3/BB-xM_Schematic_REVA3.pdf [3] http://www.aptina.com/products/image_sensors/mt9p031i12stc/ -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
Op 26 mei 2011, om 11:27 heeft javier Martin het volgende geschreven: > On 26 May 2011 10:51, Koen Kooi wrote: >> >> Op 26 mei 2011, om 09:24 heeft Javier Martin het volgende geschreven: >> >>> Hi Koen, >>> >>> On 25 May 2011 15:38, Koen Kooi wrote: Op 25 mei 2011, om 13:16 heeft Javier Martin het volgende geschreven: > It includes several fixes pointed out by Laurent Pinchart. However, > the BUG which shows artifacts in the image (horizontal lines) still > persists. It won't happen if 1v8 regulator is not disabled (i.e. > comment line where it is disabled in function "mt9p031_power_off"). > I know there can be some other details to fix but I would like someone > could help in the power management issue. I tried this + your beagle patch on 2.6.39 and both ISP and sensor being builtin to the kernel, I get the following: root@beagleboardxMC:~# media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1 ], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to inactive Setting up link 16:0 -> 5:0 [1] Setting up link 5:1 -> 6:0 [1] root@beagleboardxMC:~# media-ctl -f '"mt9p031 2-0048":0[SGRBG12 320x240], "OMAP3 ISP CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0 Format set: SGRBG12 320x240 Setting up format SGRBG12 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG12 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG8 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1 Format set: SGRBG8 320x240 oot@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 -F `media-ctl -e "OMAP3 ISP CCDC output"` Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 320x240 buffer size 76800 Video format: SGRBG8 (47425247) 320x240 buffer size 76800 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x4030d000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x4033. length: 76800 offset: 155648 Buffer 2 mapped at address 0x4042d000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x40502000. [ 4131.459930] omap3isp omap3isp: CCDC won't become idle! >>> >>> Please, test it again using new RFC v3 I've just submitted. >> >> Slightly better: >> >> Video format: SGRBG8 (47425247) 320x240 buffer size 76800 >> 4 buffers requested. >> length: 76800 offset: 0 >> Buffer 0 mapped at address 0x401d1000. >> length: 76800 offset: 77824 >> Buffer 1 mapped at address 0x40266000. >> length: 76800 offset: 155648 >> Buffer 2 mapped at address 0x402c6000. >> length: 76800 offset: 233472 >> Buffer 3 mapped at address 0x4036e000. >> 0 (0) [-] 4294967295 76800 bytes 110.899139 1306398890.364593 0.001 fps >> 1 (1) [-] 4294967295 76800 bytes 111.128997 1306398890.594421 4.351 fps >> [ 111.214019] omap3isp omap3isp: CCDC won't become idle! >> >> >>> I have personally tested it against kernel 2.6.39 with the following >>> .config file: >> >> And with that config: >> >> [4.250244] VFS: Cannot open root device "mmcblk0p2" or >> unknown-block(179,2) >> [4.257720] Please append a correct "root=" boot option; here are the >> available partitions: >> [4.266540] b300 7977472 mmcblk0 driver: mmcblk >> [4.272125] b301 72261 mmcblk0p1 >> ----0mmcblk0p1 >> [4.280578] b302 7903980 mmcblk0p2 >> ----0mmcblk0p2 >> [4.289031] Kernel panic - not syncing: VFS: Unable to mount root fs on >> unknown-block(179,2) >> >> Which is the good old kernel-mux-is-broken problem again, after turning off >> kernel-mux: >> >> 0 (0) [-] 4294967295 76800 bytes 29.186920 1306399517.283752 0.001 fps >> 1 (1) [-] 4294967295 76800 bytes 29.416778 1306399517.513580 4.351 fps >> 2 (2) [-] 4294967295 76800 bytes 29.528137 1306399517.624938 8.980 fps >> [ 29.616943] omap3isp omap3isp: CCDC won't become idle! >> > > Are you using a LI-5M03 module? > (https://www.leopardimaging.com/Beagle_Board_xM_Camera.html) Yes, I also have the vga and 3M module to test with. > I also added pull ups to the I2C2 line so that I could communicate with > mt9p031. Uboot enables the on-chip pullups, which worked for me when using the 2.6.32 kernel. >> So that seems to be the same as with my config. How do I view the files >> yavta dumps? > > I use a patched version of yavta and Mplayer to see video > (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) > > Then in my PC: > nc -l 3000 | ./mplayer - -demuxer rawvideo -rawvideo > w=320:h=240:format=ba81:size=76800 -vf ba81 -vo x11 > > In the Beagleboard: > > ./media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3
Re: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On Thursday 26 May 2011 11:35:59 Guennadi Liakhovetski wrote: > On Thu, 26 May 2011, javier Martin wrote: > > Are you using a LI-5M03 module? > > (https://www.leopardimaging.com/Beagle_Board_xM_Camera.html) > > I also added pull ups to the I2C2 line so that I could communicate with > > mt9p031. > > Hm, strange, I didn't have to solder anything. You can also turn the OMAP3 internal pull-ups. Depending on who you ask, that's usually way simpler than soldering resistors :-) -- Regards, Laurent Pinchart -- 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On Thu, 26 May 2011, javier Martin wrote: > Are you using a LI-5M03 module? > (https://www.leopardimaging.com/Beagle_Board_xM_Camera.html) > I also added pull ups to the I2C2 line so that I could communicate with > mt9p031. Hm, strange, I didn't have to solder anything. 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On 26 May 2011 10:51, Koen Kooi wrote: > > Op 26 mei 2011, om 09:24 heeft Javier Martin het volgende geschreven: > >> Hi Koen, >> >> On 25 May 2011 15:38, Koen Kooi wrote: >>> >>> Op 25 mei 2011, om 13:16 heeft Javier Martin het volgende geschreven: >>> It includes several fixes pointed out by Laurent Pinchart. However, the BUG which shows artifacts in the image (horizontal lines) still persists. It won't happen if 1v8 regulator is not disabled (i.e. comment line where it is disabled in function "mt9p031_power_off"). I know there can be some other details to fix but I would like someone could help in the power management issue. >>> >>> I tried this + your beagle patch on 2.6.39 and both ISP and sensor being >>> builtin to the kernel, I get the following: >>> >>> root@beagleboardxMC:~# media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP >>> CCDC":0[1 ], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' >>> Resetting all links to inactive >>> Setting up link 16:0 -> 5:0 [1] >>> Setting up link 5:1 -> 6:0 [1] >>> >>> root@beagleboardxMC:~# media-ctl -f '"mt9p031 2-0048":0[SGRBG12 320x240], >>> "OMAP3 ISP CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' >>> Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0 >>> Format set: SGRBG12 320x240 >>> Setting up format SGRBG12 320x240 on pad OMAP3 ISP CCDC/0 >>> Format set: SGRBG12 320x240 >>> Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0 >>> Format set: SGRBG8 320x240 >>> Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1 >>> Format set: SGRBG8 320x240 >>> >>> oot@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 >>> -F `media-ctl -e "OMAP3 ISP CCDC output"` >>> Device /dev/video2 opened. >>> Device `OMAP3 ISP CCDC output' on `media' is a video capture device. >>> Video format set: SGRBG8 (47425247) 320x240 buffer size 76800 >>> Video format: SGRBG8 (47425247) 320x240 buffer size 76800 >>> 4 buffers requested. >>> length: 76800 offset: 0 >>> Buffer 0 mapped at address 0x4030d000. >>> length: 76800 offset: 77824 >>> Buffer 1 mapped at address 0x4033. >>> length: 76800 offset: 155648 >>> Buffer 2 mapped at address 0x4042d000. >>> length: 76800 offset: 233472 >>> Buffer 3 mapped at address 0x40502000. >>> [ 4131.459930] omap3isp omap3isp: CCDC won't become idle! >> >> Please, test it again using new RFC v3 I've just submitted. > > Slightly better: > > Video format: SGRBG8 (47425247) 320x240 buffer size 76800 > 4 buffers requested. > length: 76800 offset: 0 > Buffer 0 mapped at address 0x401d1000. > length: 76800 offset: 77824 > Buffer 1 mapped at address 0x40266000. > length: 76800 offset: 155648 > Buffer 2 mapped at address 0x402c6000. > length: 76800 offset: 233472 > Buffer 3 mapped at address 0x4036e000. > 0 (0) [-] 4294967295 76800 bytes 110.899139 1306398890.364593 0.001 fps > 1 (1) [-] 4294967295 76800 bytes 111.128997 1306398890.594421 4.351 fps > [ 111.214019] omap3isp omap3isp: CCDC won't become idle! > > >> I have personally tested it against kernel 2.6.39 with the following >> .config file: > > And with that config: > > [ 4.250244] VFS: Cannot open root device "mmcblk0p2" or > unknown-block(179,2) > [ 4.257720] Please append a correct "root=" boot option; here are the > available partitions: > [ 4.266540] b300 7977472 mmcblk0 driver: mmcblk > [ 4.272125] b301 72261 mmcblk0p1 > ----0mmcblk0p1 > [ 4.280578] b302 7903980 mmcblk0p2 > ----0mmcblk0p2 > [ 4.289031] Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(179,2) > > Which is the good old kernel-mux-is-broken problem again, after turning off > kernel-mux: > > 0 (0) [-] 4294967295 76800 bytes 29.186920 1306399517.283752 0.001 fps > 1 (1) [-] 4294967295 76800 bytes 29.416778 1306399517.513580 4.351 fps > 2 (2) [-] 4294967295 76800 bytes 29.528137 1306399517.624938 8.980 fps > [ 29.616943] omap3isp omap3isp: CCDC won't become idle! > Are you using a LI-5M03 module? (https://www.leopardimaging.com/Beagle_Board_xM_Camera.html) I also added pull ups to the I2C2 line so that I could communicate with mt9p031. > So that seems to be the same as with my config. How do I view the files yavta > dumps? I use a patched version of yavta and Mplayer to see video (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) Then in my PC: nc -l 3000 | ./mplayer - -demuxer rawvideo -rawvideo w=320:h=240:format=ba81:size=76800 -vf ba81 -vo x11 In the Beagleboard: ./media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' ./media-ctl -f '"mt9p031 2-0048":0[SGRBG12 320x240], "OMAP3 ISP CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' ./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F `./media-ctl -e "OMAP3 ISP CCDC output"` | nc 192.168.0.42 3000 -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-
Re: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
Op 25 mei 2011, om 13:16 heeft Javier Martin het volgende geschreven: > It includes several fixes pointed out by Laurent Pinchart. However, > the BUG which shows artifacts in the image (horizontal lines) still > persists. It won't happen if 1v8 regulator is not disabled (i.e. > comment line where it is disabled in function "mt9p031_power_off"). > I know there can be some other details to fix but I would like someone > could help in the power management issue. I tried this + your beagle patch on 2.6.39 and both ISP and sensor being builtin to the kernel, I get the following: root@beagleboardxMC:~# media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1 ], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to inactive Setting up link 16:0 -> 5:0 [1] Setting up link 5:1 -> 6:0 [1] root@beagleboardxMC:~# media-ctl -f '"mt9p031 2-0048":0[SGRBG12 320x240], "OMAP3 ISP CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0 Format set: SGRBG12 320x240 Setting up format SGRBG12 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG12 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG8 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1 Format set: SGRBG8 320x240 oot@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 -F `media-ctl -e "OMAP3 ISP CCDC output"` Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 320x240 buffer size 76800 Video format: SGRBG8 (47425247) 320x240 buffer size 76800 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x4030d000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x4033. length: 76800 offset: 155648 Buffer 2 mapped at address 0x4042d000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x40502000. [ 4131.459930] omap3isp omap3isp: CCDC won't become idle! [..] ^C[ 4134.919464] omap3isp omap3isp: CCDC won't become idle! [ 4135.926116] omap3isp omap3isp: Unable to stop OMAP3 ISP CCDC Do I need some extra ISP patches? Media-ctl -p output is listed below. regards, Koen root@beagleboardxMC:~# media-ctl -p Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Input [SGRBG10 4096x4096] <- 'OMAP3 ISP CCP2 input':pad0 [] pad1: Output [SGRBG10 4096x4096] -> 'OMAP3 ISP CCDC':pad0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Output -> 'OMAP3 ISP CCP2':pad0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Input [SGRBG10 4096x4096] pad1: Output [SGRBG10 4096x4096] -> 'OMAP3 ISP CSI2a output':pad0 [] -> 'OMAP3 ISP CCDC':pad0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Input <- 'OMAP3 ISP CSI2a':pad1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG8 320x240] <- 'OMAP3 ISP CCP2':pad1 [] <- 'OMAP3 ISP CSI2a':pad1 [] <- 'mt9p031 2-0048':pad0 [ACTIVE] pad1: Output [SGRBG8 320x240] -> 'OMAP3 ISP CCDC output':pad0 [ACTIVE] -> 'OMAP3 ISP resizer':pad0 [] pad2: Output [SGRBG8 320x239] -> 'OMAP3 ISP preview':pad0 [] -> 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] -> 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] -> 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Input <- 'OMAP3 ISP CCDC':pad1 [ACTIVE] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Input [SGRBG10 4096x4096] <- 'OMAP3 ISP CCDC':pad2 [] <- 'OMAP3 ISP preview input':pad0 [] pad1: Output [YUYV 4082x4088] -> 'OMAP3 ISP preview output':pad0 [] -> 'OMAP3 ISP resizer':pad0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Output -> 'OMAP3 ISP preview':pad0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L
[PATCH] Second RFC version of mt9p031 sensor with power managament.
It includes several fixes pointed out by Laurent Pinchart. However,
the BUG which shows artifacts in the image (horizontal lines) still
persists. It won't happen if 1v8 regulator is not disabled (i.e.
comment line where it is disabled in function "mt9p031_power_off").
I know there can be some other details to fix but I would like someone
could help in the power management issue.
Signed-off-by: Javier Martin
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 752 +
include/media/mt9p031.h | 11 +
4 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..8a596cc 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,13 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate "Aptina MT9P031 support"
+ depends on I2C && VIDEO_V4L2
+ ---help---
+This is a Video4Linux2 sensor-level driver for the Aptina
+(Micron) mt9p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate "Micron mt9v011 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..39579de
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,752 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define MT9P031_PIXCLK_FREQ5400
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_DEF 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_DEF16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#defineMT9P031_WINDOW_HEIGHT_MAX 1944
+#defineMT9P031_WINDOW_HEIGHT_MIN 2
+#define MT9P031_WINDOW_WIDTH 0x04
+#defineMT9P031_WINDOW_WIDTH_MAX2592
+#defineMT9P031_WINDOW_WIDTH_MIN18
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RST0x0d
+#defineMT9P031_RST_ENABLE 1
+#defineMT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct mt9p031_platform_data *pdata;
+ struct mutex power_lock; /* lock to protect power_count */
+ int power_count;
+ u16
