2009/7/27 matthias schwarz <matthias.schw@xxxxxxxxxxxxxx>: > ---------- Forwarded message ---------- > From: matthias schwarz <matthias.schw@xxxxxxxxxxxxxx> > Date: 2009/7/27 > Subject: Re: Camera Interface VS/HS Issue > To: "Aguirre Rodriguez, Sergio Alberto" <saaguirre@xxxxxx> > > > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@xxxxxx>: >> >> >>> -----Original Message----- >>> From: matthias schwarz [mailto:matthias.schw@xxxxxxxxxxxxxx] >>> Sent: Monday, July 27, 2009 12:37 PM >>> 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 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? >> >> Well, yeah... >> >> But one thing I'm still confused about is why you need sync signals without a valid sensor config? > > Was just to try out if pixelclock was the only thing going wrong. > Anything else would have taken more time, will look into the config > tomorrow though. > >> >> Normally it is just a matter of providing a valid XCLK to the sensor for it to start working, so the sensor can be configured through I2C without problem, and then at the last, turn on CCDC->PREV->RSZ just after the sensor is properly configured. >> >> Are you using Omap3 camera driver posted by both Sakari Ailus and myself? > > I just wrote that module together myself, but will look into your code > of course. > >> >> Sakari's tree is located on: >> >> http://www.gitorious.org/projects/omap3camera >> >> And mine is located on: >> >> http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=shortlog;h=refs/heads/devel >> >> Mine is based on Sakari's, but rebased with a newer kernel and with some sensors interfaced with the 3430SDP, MT9P012 (5MP Parallel interface) and OV3640 (3MP CSI2 Interface). >> >> Are you doing this from scratch? > > Like i said before, yes i am currently doing this from scratch, but > will look into that. > Thank you, > Matthias > Since i looked into these repositories, i would want to ask if there are also some userspace code examples to control these devices? Things would be much easier for me then. Thank you, Matthias >> >> Regards, >> Sergio >>> >>> 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
