Re: Camera Interface VS/HS Issue

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

 



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.

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

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