2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@xxxxxx>: > > >> -----Original Message----- >> From: matthias schwarz [mailto:matthias.schw@xxxxxxxxxxxxxx] >> Sent: Monday, July 27, 2009 11:12 AM >> To: Aguirre Rodriguez, Sergio Alberto >> Cc: linux-omap@xxxxxxxxxxxxxxx >> Subject: Re: Camera Interface VS/HS Issue >> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@xxxxxx>: >> > >> > >> >> -----Original Message----- >> >> From: matthias schwarz [mailto:matthias.schw@xxxxxxxxxxxxxx] >> >> Sent: Monday, July 27, 2009 10:59 AM >> >> To: Aguirre Rodriguez, Sergio Alberto >> >> Cc: linux-omap@xxxxxxxxxxxxxxx >> >> Subject: Re: Camera Interface VS/HS Issue >> >> >> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@xxxxxx>: >> >> > Matthias, >> >> > >> >> > Please avoid top-posting, because its prohibited by the mailing list >> >> rules. I'm readjusting it for you below >> >> >> >> Oh, i am sorry about that, it is not going to happen again, promise. >> >> And thank you for readjusting. >> > >> > Anytime :) >> >> >> >> > >> >> > From: matthias schwarz [mailto:matthias.schw@xxxxxxxxxxxxxx] >> >> >> 2009/7/27 matthias schwarz <matthias.schw@xxxxxxxxxxxxxx>: >> >> >> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@xxxxxx>: >> >> >> >> (rearranging mail to avoid top posting..) >> >> >> >> >> >> >> >> From: matthias schwarz [mailto:matthias.schw@xxxxxxxxxxxxxx] >> >> >> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@xxxxxx>: >> >> >> >>> > >> >> >> >>> > >> >> >> >>> >> -----Original Message----- >> >> >> >>> >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- >> >> >> >>> >> owner@xxxxxxxxxxxxxxx] On Behalf Of matthias schwarz >> >> >> >>> >> Sent: Monday, July 27, 2009 7:47 AM >> >> >> >>> >> To: linux-omap@xxxxxxxxxxxxxxx >> >> >> >>> >> Subject: Camera Interface VS/HS Issue >> >> >> >>> >> >> >> >> >>> >> Hi there, >> >> >> >>> >> >> >> >> >>> >> i just recently ran into a problem when trying to let the ISP >> >> >> >>> >> (OMAP3530) generate HS/VS signals in SYNC mode. >> >> >> >>> >> I am building a module to do so. >> >> >> >>> >> >> >> >> >>> >> It basically enables the three clocks (cam_ick, cam_mclk and >> >> >> >>> >> csi2_96m_fck), >> >> >> >>> >> then sets >> >> >> >>> >> >> >> >> >>> >> ISPCCDC_PIX_LINES_PPLN >> >> >> >>> >> ISPCCDC_PIX_LINES_HLPRF >> >> >> >>> >> ISPCCDC_HD_VD_WID_VDW >> >> >> >>> >> ISPCCDC_HD_VD_WID_HDW >> >> >> >>> >> ISPCCDC_SYN_MODE_VDHDEN >> >> >> >>> >> ISPCCDC_SYN_MODE_VDHDOUT >> >> >> >>> >> ISPCCDC_CFG_VDLC >> >> >> >>> >> ISPTCTRL_CTRL_DIVA >> >> >> >>> >> ISPTCTRL_CTRL_DIVB >> >> >> >>> >> ISPCCDC_PCR >> >> >> >>> >> >> >> >> >>> >> via some calls to ioremap and ioread32/iowrite32. >> >> >> >>> >> My question now is the following: >> >> >> >>> >> when i hook an oscilloscope to the corresponding pins >> (CAM_VS, >> >> >> CAM_HS, >> >> >> >>> >> CAM_XCLKA) i can see that only the CAM_XCLKA is working >> >> correctly, >> >> >> >>> >> also at the configured frequency. >> >> >> >>> >> Both, CAM_VS and CAM_HS remain at low voltage all the time, >> even >> >> >> when >> >> >> >>> >> i switch their polarities (ISPCCDC_SYN_MODE_VDPOL, >> >> >> >>> >> ISPCCDC_SYN_MODE_HDPOL) that behavior does not change and >> >> signals >> >> >> >>> >> always remain at low voltage. >> >> >> >>> >> >> >> >> >>> >> Could someone help me out, or give me a hint what i might be >> >> >> missing >> >> >> >>> >> to generate those output signals correctly? >> >> >> >>> > >> >> >> >>> > Matthias, >> >> >> >>> > >> >> >> >>> > Can you please provide a register dump of the above values? >> >> >> >>> > >> >> >> >>> > Looks like you're touching the adequate registers though... >> But I >> >> >> can >> >> >> >>> help you more looking at the values. >> >> >> >>> > >> >> >> >>> Sure i can, >> >> >> >>> register values are the following: >> >> >> >>> >> >> >> >>> ccdc_pix_lines: 0x050005a0 >> >> >> >>> >> >> >> >>> ccdc_hd_vd_wid: 0x00320064 >> >> >> >>> >> >> >> >>> ccdc_syn_mode: 0x00050c0c >> >> >> >> >> >> >> >> This is wrong, because: >> >> >> >> >> >> >> >> Bit0 sets directions of cam_hs and cam_vs signals with this >> values: >> >> >> >> - 0: Input (what you're setting with that values) >> >> >> >> - 1: Output (Is this what you want?) >> >> >> >> >> >> >> >> Bit1 Sets direction of cam_fld pin, which follows the same logic >> as >> >> the >> >> >> Bit0. >> >> >> >> >> >> >> >> Others could be wrong or bad, depending on your exact usecase and >> >> >> config intention. >> >> >> >> >> >> >> >> Hope this helps. >> >> >> >> >> >> >> > Hmm, >> >> >> > so now i have: >> >> >> > >> >> >> > ccdc_syn_mode: 0x00050c0f >> >> >> > >> >> >> > but that does not change the behavior i am experiencing, both pins >> >> >> > (CAM_VS, CAM_HS) remain at low voltage at all times. >> >> >> > >> >> >> > I don't have to do anything but enabling the corresponding clocks >> to >> >> >> > make sure the CCDC is working? >> >> >> I also set, >> >> >> >> >> >> ISPCTRL_CCDC_CLK_EN >> >> >> ISPCTRL_CCDC_RAM_EN >> >> >> >> >> >> but those also won't change the always low voltage pins. >> >> > >> >> > Are you having a valid Pixel clock input to the CCDC? >> >> >> >> Actually, i did not check that. And that signal also is not provided. >> >> Just to confirm: pixelclock refers to the clocking signal coming back >> >> from the sensor? >> > >> > Yeah, you normally provide the XCLK to the sensor, and the sensor >> responds with a PCLK (Pixelclock) to make the ISP aware on when to latch >> the values coming from the port, and increase the counters for the timing >> generator to generate HS/VS in your case. >> >> I know its dirty, but since the sensor won't give me a pixelclock >> without fiddling with its config, i just connected XCLK to PCLK (which >> should provide a PCLK to CCDC then). >> What i experience now is still the same issue, meaning low voltage on >> both CAM_VS and CAM_HS... > > Hmm, > > I'm sorry, but I'm a bit confused on what are you trying to do exactly... > > Is it possible to elaborate on your usecase publicly? I am trying to attach an image-sensor which won't generate a pixelclock without further configuration. And since i need a valid PCLK to generate H- and V-Sync signals correctly i am just trying to connect the correspondig pins (so XCLK is looped back to PCLK) to see if the CCDC will generate those signals. Later on i will surely configure the sensor correctly to generate its own PCLK signal. But apparently it does not work, which should mean that there is still some other issue, doesn't it? Thank you, Matthias > > Regards, > Sergio >> >> >> >> >> > >> >> > I just confirmed with our internal TI HW support, and you need a >> valid >> >> pixel input clock to assert/deassert the signals. >> >> >> >> So it is an issue with the sensor itself, >> > >> > Looks like... >> > >> >> Thank you very much, >> >> Matthias >> >> >> >> > >> >> > Regards, >> >> > Sergio >> >> >> > >> >> >> > Thank you, >> >> >> > Matthias >> >> >> >> Regards, >> >> >> >> Sergio >> >> >> >>> >> >> >> >>> ccdc_cfg: 0x00008000 >> >> >> >>> >> >> >> >>> tctrl_ctrl_cfg: 0x80000463 >> >> >> >>> >> >> >> >>> ccdc_pcr: 0x00000001 >> >> >> >>> >> >> >> >>> Thank you, >> >> >> >>> Matthias >> >> >> >>> > Regards, >> >> >> >>> > Sergio >> >> >> >>> >> >> >> >> >>> >> Thank you very much, >> >> >> >>> >> Matthias >> >> >> >>> >> -- >> >> >> >>> >> To unsubscribe from this list: send the line "unsubscribe >> linux- >> >> >> omap" >> >> >> >>> in >> >> >> >>> >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >> >> >>> >> More majordomo info at http://vger.kernel.org/majordomo- >> >> info.html >> >> >> >>> > >> >> >> >>> > >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> > >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
