Re: Migrate from soc_camera to v4l2
Hello Guennadi, Am Mittwoch, den 13.07.2011, 09:14 +0200 schrieb Guennadi Liakhovetski: On Wed, 13 Jul 2011, LBM wrote: my dear Guennadi I'm wrong about that v4l2-int-device,maybe it just V4L2. Now i have a board of OMAP3530 and a cmos camera MT9M111,so i want to get the image from the mt9m111. and ,I want to use the V4L2 API. But in the linux kernel 2.6.38,the driver of the mt9m111 is a soc_camera.I see some thing about how to convert the soc_camera to V4L2,like soc-camera: (partially) convert to v4l2-(sub)dev API. Can you tell me how to migrate from soc_camera to v4l2,and or do you tell me some experience about that? Currently there's no standard way to make a driver to work with both soc-camera and (pure) v4l2-subdev APIs. It is being worked on: http://www.spinics.net/lists/linux-media/msg34878.html and, hopefully, beginning with the next kernel version 3.1 it will become at least theoretically possible. For now you just have to hack the driver yourself for your local uses by removing all soc-camera specific code and replacing it with your own glue, something along these lines: We are also interested in the support of the MT9M111 and MT9V022 for OMAP-4460/OMAP-4430/OMAP-3525. I have not taken a deeper look at it yet. But what do you mean by theoretically possible? Could it work out of the box? Or is there more work to do? Regards, Teresa http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11486/focus=11691 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 -- 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: [PATCH] mt9v022: fix pixel clock
Hello Guennadi, Am Mittwoch, den 04.05.2011, 10:17 +0200 schrieb Guennadi Liakhovetski: Hi Teresa I'm adding Mauro to CC, because we were discussing adding these (this one and mt9m111) patches to .39. On Thu, 14 Apr 2011, Teresa Gámez wrote: The setup of the pixel clock is done wrong in the mt9v022 driver. The 'Invert Pixel Clock' bit has to be set to 1 for falling edge and not for rising. This is not clearly described in the data sheet. I finally got round to test your patch on pcm037. But sorry, I cannot reproduce your success. What's even worth, your patch, if applied to the stock kernel, really messes up Bayer colours for me. With your patch alone I cannot select the Bayer filter starting pixel parameter to produce correct colours. Without your patch colours do not look very clean, that's true, but I always attributed it to some sensor fine-tuning issues. But at least they are correct. Thank you for testing this. Of course the Bayer to RGB conversion can have a impact on the test result. To avoid this, it might be better to first try out the test pattern generated by the color or monochrom mtv9v022 sensor. With the test pattern no Bayer conversion should be made. Our setup in the i.MX31 controller: * Reg 0x53FC_0060 (CSI_SENS_CONF), Bit 3 (SENS_PIX_CLK_POL) = 0 quote pixel clock is directly applied to internal circuitry (rising edge). /quote Which means its using rising edge (See Datasheet mcimx31 Rev3.4 10/2007 i.MX31): quote The timing specifications are referenced to the rising edge of SENS_PIX_CLK when the SENS_PIX_CLK_POL bit in the CSI_SENS_CONF register is cleared. When the SENS_PIX_CLK_POL is set, the clock is inverted and all timing specifications will remain the same but are referenced to the falling edge of the clock./quote * The MCLOCK is setup with 20MHz Setup of the camera sensor mt9v022: * Reg 0x74 Bit 4 = 0# Pixelclock at rising edge * Reg 0x7F= 0x2800 # generates vertical shade * Reg 0x70 Bit 5 = 0# disable noise correction (is nessessary for correct testpattern) Our result: test pattern verical is ok Now changed setup to: * Reg 0x74 Bit 4 = 1# Pixelclock at falling edge Our result: test pattern has errors on a closer look. We have tested this with PCM037/PCM970 on a 2.6.39-rc6. Teresa An easy way to test colours is to point the camera at the LED pair on the board - blinking red and constant green next to the ethernet port. You once mentioned, that in your BSP you have the SOCAM_SENSOR_INVERT_PCLK flag set in your platform data. Maybe you were testing with that one? Then yes, of course, you'd have to compensate it by inverting the bit in the sensor. In any case, your patch if applied alone, seems to break camera on pcm037. Am I missing something? Thanks Guennadi Tested on pcm037 and pcm027/pcm990. Signed-off-by: Teresa Gámez t.ga...@phytec.de --- drivers/media/video/mt9v022.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 6a784c8..dec2a69 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -228,7 +228,7 @@ static int mt9v022_set_bus_param(struct soc_camera_device *icd, flags = soc_camera_apply_sensor_flags(icl, flags); - if (flags SOCAM_PCLK_SAMPLE_RISING) + if (flags SOCAM_PCLK_SAMPLE_FALLING) pixclk |= 0x10; if (!(flags SOCAM_HSYNC_ACTIVE_HIGH)) -- 1.7.0.4 --- 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: Antwort: Re: [PATCH 1/2] mt9v022: fix pixel clock
Am Mittwoch, den 13.04.2011, 08:31 +0200 schrieb Guennadi Liakhovetski: Hello Teresa Thanks very much for your extensive testing! I'm afraid, I don't have the time right now to go through all those register settings, so, can we, maybe, do the following: we currently have two platforms in the mainline, that use mt9v022. We believe, that the driver itself implements the pixel clock edge configuration wrongly. Could you please provide patches to 1. fix mt9v022 to match our new understanding 2. if needed - additionally fix pcm037 by setting the SOCAM_SENSOR_INVERT_PCLK flag 3. same for pcm990 / pcm027 As I can see only the driver code has to be changed. Platformcode for pcm037 and pcm990 is ok. I will resend the patch. I also noticed your wrong colours result - if colours are completely swapped, maybe you just have to adjust your Bayer decoder? They are not completely swapped. There some areas where it looks fine and others where the colors are wrong or the pixels are noisy. Once we get those patches, I'll try to test them, but I've a very tight schedule atm, so, maybe I'll just believe you to get them on time for 2.6.39. Thank you for testing this, too. Teresa Thanks Guennadi On Tue, 12 Apr 2011, Teresa Gamez wrote: Am Freitag, den 08.04.2011, 15:27 +0200 schrieb Teresa Gamez: Hello Guennadi, Am Donnerstag, den 07.04.2011, 14:41 +0200 schrieb Guennadi Liakhovetski: Hello Teresa On Thu, 7 Apr 2011, Teresa Gamez wrote: Hello Guennadi, the datasheet also says (see table 3): quote Pixel clock out. DOUT is valid on rising edge of this clock. /quote There is a difference between DOUT beeing vaild and DOUT beeing set up. So does SOCAM_PCLK_SAMPLE_RISING mean that the data is valid at rising edge or does it mean the data is set up at rising edge? Hm, yeah, looks like a typical example of a copy-paste datasheet to me:-( And now we don't know which of the two is actually supposed to be true. As for set up vs. valid - not sure, whether there is indeed a difference between them. To me set up _TO_ the rising edge is a short way to set set up to be valid at the rising edge, however, I might be wrong. Can you tell me in more detail what and where (at the sensor board or on the baseboard) you measured and what it looked like? I think, Figure 7 and the description below it are interesting. From that diagram I would indeed say indeed the DOUT pins are valid and should be sampled at the rising edge by default - when bit 4 in 0x74 is not set. SOCAM_PCLK_SAMPLE_RISING means, that the data should be sampled at the rising of pclkm, i.e., it is valid there. I meassured the outgoing pins from the baseboard to the camera board and checked the PCLK and D0 to see at which point the data is valid. I have also checked the quality of the image. All tests where made with sensor_type=color My results for pcm038 are with following register settings: mx2_camera 0x0 CSICR1: 0x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ugly image, wrong colors) Now I set the SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the mt9v022: mx2_camera 0x0 CSICR1 0x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: rising edge (image is OK) Now changed the PCLK of the mx2_camera: mx2_camera 0x0 CSICR1 0x10020b90 - falling edge mt9v022 0x74 PIXCLK_FV_LV0x0010 - rising edge (which I think is falling edge) meassured: falling edge (image is OK) So, yes, if your measurements agree with figure 7 from the datasheet, we shall assume, that the driver implements the pclk polarity wrongly. But the fix should be more extensive, than what you've submitted: if we invert driver's behaviour, we should also invert board configuration of all driver users: pcm990 and pcm037. Or we have to test them and verify, that the inverted pclk polarity doesn't megatively affect the image quality, or maybe even improves it. Thanks Guennadi I have tested this with a pcm038 but I will also make meassurements with the pcm037. Same results with the pcm037: mx3_camera 0x60 CSI_SENS_CONF: 0x0700 - rising edge mt9v022 0x74 PIXCLK_FV_LV:0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ulgy image, looks like b/w with pixel errors) Set SOCAM_SENSOR_INVERT_PCLK
Re: Antwort: Re: [PATCH 1/2] mt9v022: fix pixel clock
Am Freitag, den 08.04.2011, 15:27 +0200 schrieb Teresa Gamez: Hello Guennadi, Am Donnerstag, den 07.04.2011, 14:41 +0200 schrieb Guennadi Liakhovetski: Hello Teresa On Thu, 7 Apr 2011, Teresa Gamez wrote: Hello Guennadi, the datasheet also says (see table 3): quote Pixel clock out. DOUT is valid on rising edge of this clock. /quote There is a difference between DOUT beeing vaild and DOUT beeing set up. So does SOCAM_PCLK_SAMPLE_RISING mean that the data is valid at rising edge or does it mean the data is set up at rising edge? Hm, yeah, looks like a typical example of a copy-paste datasheet to me:-( And now we don't know which of the two is actually supposed to be true. As for set up vs. valid - not sure, whether there is indeed a difference between them. To me set up _TO_ the rising edge is a short way to set set up to be valid at the rising edge, however, I might be wrong. Can you tell me in more detail what and where (at the sensor board or on the baseboard) you measured and what it looked like? I think, Figure 7 and the description below it are interesting. From that diagram I would indeed say indeed the DOUT pins are valid and should be sampled at the rising edge by default - when bit 4 in 0x74 is not set. SOCAM_PCLK_SAMPLE_RISING means, that the data should be sampled at the rising of pclkm, i.e., it is valid there. I meassured the outgoing pins from the baseboard to the camera board and checked the PCLK and D0 to see at which point the data is valid. I have also checked the quality of the image. All tests where made with sensor_type=color My results for pcm038 are with following register settings: mx2_camera 0x0 CSICR1: 0x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ugly image, wrong colors) Now I set the SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the mt9v022: mx2_camera 0x0 CSICR1 0x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: rising edge (image is OK) Now changed the PCLK of the mx2_camera: mx2_camera 0x0 CSICR1 0x10020b90 - falling edge mt9v022 0x74 PIXCLK_FV_LV0x0010 - rising edge (which I think is falling edge) meassured: falling edge (image is OK) So, yes, if your measurements agree with figure 7 from the datasheet, we shall assume, that the driver implements the pclk polarity wrongly. But the fix should be more extensive, than what you've submitted: if we invert driver's behaviour, we should also invert board configuration of all driver users: pcm990 and pcm037. Or we have to test them and verify, that the inverted pclk polarity doesn't megatively affect the image quality, or maybe even improves it. Thanks Guennadi I have tested this with a pcm038 but I will also make meassurements with the pcm037. Same results with the pcm037: mx3_camera 0x60 CSI_SENS_CONF: 0x0700 - rising edge mt9v022 0x74 PIXCLK_FV_LV:0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ulgy image, looks like b/w with pixel errors) Set SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the mt9v022: mx3_camera 0x60 CSI_SENS_CONF: 0x0700 - rising edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: rising edge (image is OK) Additionally set MX3_CAMERA_PCP of the mx3_camera flags mx3_camera 0x60 CSI_SENS_CONF: 0x0708 - falling edge mt9v022 0x74 PIXCLK_FV_LV:0x0010 - rising edge (which I think is falling edge) meassured: falling edge (image is OK) Removed SOCAM_SENSOR_INVERT_PCLK flag for the mt9v022: mx3_camera 0x60 CSI_SENS_CONF: 0x0708 - falling edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: risging edge (ugly image, looks like the first one) I have noticed that on our pcm037 BSP the SOCAM_SENSOR_INVERT_PCLK flag for the camera was set to fix this issue. I will continue this test on the pcm990. Got the same result with the pcm990: pxa_camera 0x5010 CICR4: 0x00880001 - rising edge (0 22) mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (1 4) (which I think is falling edge) meassured: falling edge (some pixel have wrong colors) --- Now set the SOCAM_SENSOR_INVERT_PCLK for mt9v022: pxa_camera 0x5010 CICR4: 0x00880001 - rising edge (0 22) mt9v022 0x74 PIXCLK_FV_LV: 0x - falling edge (0 4) (which I think is rising edge) meassured: rising edge (image is OK
Re: Antwort: Re: [PATCH 1/2] mt9v022: fix pixel clock
Hello Guennadi, Am Donnerstag, den 07.04.2011, 14:41 +0200 schrieb Guennadi Liakhovetski: Hello Teresa On Thu, 7 Apr 2011, Teresa Gamez wrote: Hello Guennadi, the datasheet also says (see table 3): quote Pixel clock out. DOUT is valid on rising edge of this clock. /quote There is a difference between DOUT beeing vaild and DOUT beeing set up. So does SOCAM_PCLK_SAMPLE_RISING mean that the data is valid at rising edge or does it mean the data is set up at rising edge? Hm, yeah, looks like a typical example of a copy-paste datasheet to me:-( And now we don't know which of the two is actually supposed to be true. As for set up vs. valid - not sure, whether there is indeed a difference between them. To me set up _TO_ the rising edge is a short way to set set up to be valid at the rising edge, however, I might be wrong. Can you tell me in more detail what and where (at the sensor board or on the baseboard) you measured and what it looked like? I think, Figure 7 and the description below it are interesting. From that diagram I would indeed say indeed the DOUT pins are valid and should be sampled at the rising edge by default - when bit 4 in 0x74 is not set. SOCAM_PCLK_SAMPLE_RISING means, that the data should be sampled at the rising of pclkm, i.e., it is valid there. I meassured the outgoing pins from the baseboard to the camera board and checked the PCLK and D0 to see at which point the data is valid. I have also checked the quality of the image. All tests where made with sensor_type=color My results for pcm038 are with following register settings: mx2_camera 0x0 CSICR1: 0x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ugly image, wrong colors) Now I set the SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the mt9v022: mx2_camera 0x0 CSICR10x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: rising edge (image is OK) Now changed the PCLK of the mx2_camera: mx2_camera 0x0 CSICR1 0x10020b90 - falling edge mt9v022 0x74 PIXCLK_FV_LV0x0010 - rising edge (which I think is falling edge) meassured: falling edge (image is OK) So, yes, if your measurements agree with figure 7 from the datasheet, we shall assume, that the driver implements the pclk polarity wrongly. But the fix should be more extensive, than what you've submitted: if we invert driver's behaviour, we should also invert board configuration of all driver users: pcm990 and pcm037. Or we have to test them and verify, that the inverted pclk polarity doesn't megatively affect the image quality, or maybe even improves it. Thanks Guennadi I have tested this with a pcm038 but I will also make meassurements with the pcm037. Same results with the pcm037: mx3_camera 0x60 CSI_SENS_CONF: 0x0700 - rising edge mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ulgy image, looks like b/w with pixel errors) Set SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the mt9v022: mx3_camera 0x60 CSI_SENS_CONF: 0x0700 - rising edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: rising edge (image is OK) Additionally set MX3_CAMERA_PCP of the mx3_camera flags mx3_camera 0x60 CSI_SENS_CONF: 0x0708 - falling edge mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (which I think is falling edge) meassured: falling edge (image is OK) Removed SOCAM_SENSOR_INVERT_PCLK flag for the mt9v022: mx3_camera 0x60 CSI_SENS_CONF: 0x0708 - falling edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: risging edge (ugly image, looks like the first one) I have noticed that on our pcm037 BSP the SOCAM_SENSOR_INVERT_PCLK flag for the camera was set to fix this issue. I will continue this test on the pcm990. Teresa -- 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: [PATCH 1/2] mt9v022: fix pixel clock
Hello Guennadi, Sorry for the first mail... The datasheet also says (see table 3): quote Pixel clock out. DOUT is valid on rising edge of this clock. /quote There is a difference between DOUT beeing vaild and DOUT beeing set up. So does SOCAM_PCLK_SAMPLE_RISING mean that the data is valid at rising edge or does it mean the data is set up at rising edge? I have tested this with a pcm038 but I will also make meassurements with the pcm037. Teresa Am Donnerstag, den 07.04.2011, 13:08 +0200 schrieb Guennadi Liakhovetski: On Wed, 6 Apr 2011, Teresa Gámez wrote: Measurements show that the setup of the pixel clock is not correct. The 'Invert Pixel Clock' bit has to be set to 1 for falling edge and not for rising. Doesn't seem correct to me. The mt9v022 datasheet says: quote Invert pixel clock. When set, LINE_VALID, FRAME_VALID, and DOUT is set up to the rising edge of pixel clock, PIXCLK. When clear, they are set up to the falling edge of PIXCLK. /quote and this works for present mt9v022 configurations, which include at least two boards: PXA270-based arch/arm/mach-pxa/pcm990-baseboard.c and i.MX31 based arch/arm/mach-mx3/mach-pcm037.c. If this is different for your board, maybe you have to set the SOCAM_SENSOR_INVERT_PCLK flag in your struct soc_camera_link instance. Thanks Guennadi Signed-off-by: Teresa Gámez t.ga...@phytec.de --- drivers/media/video/mt9v022.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 6a784c8..dec2a69 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -228,7 +228,7 @@ static int mt9v022_set_bus_param(struct soc_camera_device *icd, flags = soc_camera_apply_sensor_flags(icl, flags); - if (flags SOCAM_PCLK_SAMPLE_RISING) + if (flags SOCAM_PCLK_SAMPLE_FALLING) pixclk |= 0x10; if (!(flags SOCAM_HSYNC_ACTIVE_HIGH)) -- 1.7.0.4 -- 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 --- 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 -- 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
