RE: Camera Interface VS/HS Issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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?

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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux