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.gamez@xxxxxxxxx> > > --- > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
