Camera Interface VS/HS Issue

Camera Interface VS/HS Issue

[matthias schwarz]

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?

Thank you very much,
Matthias

RE: Camera Interface VS/HS Issue

[Aguirre Rodriguez, Sergio Alberto]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of matthias schwarz
> Sent: Monday, July 27, 2009 7:47 AM
> To: linux-omap@vger.kernel.org
> 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.

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

Re: Camera Interface VS/HS Issue

[matthias schwarz]

Sure i can,
register values are the following:

ccdc_pix_lines: 0x050005a0

ccdc_hd_vd_wid: 0x00320064

ccdc_syn_mode: 0x00050c0c

ccdc_cfg: 0x00008000

tctrl_ctrl_cfg: 0x80000463

ccdc_pcr: 0x00000001

Thank you,
Matthias



2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>
>
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of matthias schwarz
>> Sent: Monday, July 27, 2009 7:47 AM
>> To: linux-omap@vger.kernel.org
>> 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.
>
> 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@vger.kernel.org
>> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Camera Interface VS/HS Issue

[Aguirre Rodriguez, Sergio Alberto]

(rearranging mail to avoid top posting..)

From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >
> >
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
> >> Sent: Monday, July 27, 2009 7:47 AM
> >> To: linux-omap@vger.kernel.org
> >> 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.

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

Re: Camera Interface VS/HS Issue

[matthias schwarz]

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?

Thank you,
Matthias

2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> (rearranging mail to avoid top posting..)
>
> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >
>> >
>> >> -----Original Message-----
>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
>> >> Sent: Monday, July 27, 2009 7:47 AM
>> >> To: linux-omap@vger.kernel.org
>> >> 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.
>
> 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@vger.kernel.org
>> >> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Camera Interface VS/HS Issue

[matthias schwarz]

I also set,

ISPCTRL_CCDC_CLK_EN
ISPCTRL_CCDC_RAM_EN

but those also won't change the always low voltage pins.

2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
> 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?
>
> Thank you,
> Matthias
>
> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> (rearranging mail to avoid top posting..)
>>
>> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
>>> >> Sent: Monday, July 27, 2009 7:47 AM
>>> >> To: linux-omap@vger.kernel.org
>>> >> 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.
>>
>> 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@vger.kernel.org
>>> >> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Camera Interface VS/HS Issue

[Aguirre Rodriguez, Sergio Alberto]

Matthias,

Please avoid top-posting, because its prohibited by the mailing list rules. I'm readjusting it for you below:

From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> 2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >> (rearranging mail to avoid top posting..)
> >>
> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >>> >
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
> >>> >> Sent: Monday, July 27, 2009 7:47 AM
> >>> >> To: linux-omap@vger.kernel.org
> >>> >> 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? 

I just confirmed with our internal TI HW support, and you need a valid pixel input clock to assert/deassert the signals.

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

Re: Camera Interface VS/HS Issue

[matthias schwarz]

2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> 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@googlemail.com]
>> 2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
>> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >> (rearranging mail to avoid top posting..)
>> >>
>> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >>> >
>> >>> >
>> >>> >> -----Original Message-----
>> >>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> >>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
>> >>> >> Sent: Monday, July 27, 2009 7:47 AM
>> >>> >> To: linux-omap@vger.kernel.org
>> >>> >> 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@vger.kernel.org
>> >>> >> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Camera Interface VS/HS Issue

[Aguirre Rodriguez, Sergio Alberto]

> -----Original Message-----
> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> Sent: Monday, July 27, 2009 10:59 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-omap@vger.kernel.org
> Subject: Re: Camera Interface VS/HS Issue
> 
> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> > 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@googlemail.com]
> >> 2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
> >> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >> >> (rearranging mail to avoid top posting..)
> >> >>
> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> >> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >> >>> >
> >> >>> >
> >> >>> >> -----Original Message-----
> >> >>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> >>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
> >> >>> >> Sent: Monday, July 27, 2009 7:47 AM
> >> >>> >> To: linux-omap@vger.kernel.org
> >> >>> >> 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 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@vger.kernel.org
> >> >>> >> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Camera Interface VS/HS Issue

[matthias schwarz]

2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>
>
>> -----Original Message-----
>> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> Sent: Monday, July 27, 2009 10:59 AM
>> To: Aguirre Rodriguez, Sergio Alberto
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: Camera Interface VS/HS Issue
>>
>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> > 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@googlemail.com]
>> >> 2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
>> >> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >> >> (rearranging mail to avoid top posting..)
>> >> >>
>> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> >> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >> >>> >
>> >> >>> >
>> >> >>> >> -----Original Message-----
>> >> >>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> >> >>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
>> >> >>> >> Sent: Monday, July 27, 2009 7:47 AM
>> >> >>> >> To: linux-omap@vger.kernel.org
>> >> >>> >> 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...

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

RE: Camera Interface VS/HS Issue

[Aguirre Rodriguez, Sergio Alberto]

> -----Original Message-----
> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> Sent: Monday, July 27, 2009 11:12 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-omap@vger.kernel.org
> Subject: Re: Camera Interface VS/HS Issue
> 
> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >
> >
> >> -----Original Message-----
> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> >> Sent: Monday, July 27, 2009 10:59 AM
> >> To: Aguirre Rodriguez, Sergio Alberto
> >> Cc: linux-omap@vger.kernel.org
> >> Subject: Re: Camera Interface VS/HS Issue
> >>
> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >> > 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@googlemail.com]
> >> >> 2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
> >> >> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >> >> >> (rearranging mail to avoid top posting..)
> >> >> >>
> >> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> >> >> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >> -----Original Message-----
> >> >> >>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> >> >>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
> >> >> >>> >> Sent: Monday, July 27, 2009 7:47 AM
> >> >> >>> >> To: linux-omap@vger.kernel.org
> >> >> >>> >> 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@vger.kernel.org
> >> >> >>> >> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Camera Interface VS/HS Issue

[matthias schwarz]

2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>
>
>> -----Original Message-----
>> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> Sent: Monday, July 27, 2009 11:12 AM
>> To: Aguirre Rodriguez, Sergio Alberto
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: Camera Interface VS/HS Issue
>>
>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >
>> >
>> >> -----Original Message-----
>> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> >> Sent: Monday, July 27, 2009 10:59 AM
>> >> To: Aguirre Rodriguez, Sergio Alberto
>> >> Cc: linux-omap@vger.kernel.org
>> >> Subject: Re: Camera Interface VS/HS Issue
>> >>
>> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >> > 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@googlemail.com]
>> >> >> 2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
>> >> >> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >> >> >> (rearranging mail to avoid top posting..)
>> >> >> >>
>> >> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> >> >> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >> -----Original Message-----
>> >> >> >>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> >> >> >>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
>> >> >> >>> >> Sent: Monday, July 27, 2009 7:47 AM
>> >> >> >>> >> To: linux-omap@vger.kernel.org
>> >> >> >>> >> 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@vger.kernel.org
>> >> >> >>> >> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Camera Interface VS/HS Issue

[Aguirre Rodriguez, Sergio Alberto]

> -----Original Message-----
> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> Sent: Monday, July 27, 2009 12:37 PM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-omap@vger.kernel.org
> Subject: Re: Camera Interface VS/HS Issue
> 
> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >
> >
> >> -----Original Message-----
> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> >> Sent: Monday, July 27, 2009 11:12 AM
> >> To: Aguirre Rodriguez, Sergio Alberto
> >> Cc: linux-omap@vger.kernel.org
> >> Subject: Re: Camera Interface VS/HS Issue
> >>
> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> >> >> Sent: Monday, July 27, 2009 10:59 AM
> >> >> To: Aguirre Rodriguez, Sergio Alberto
> >> >> Cc: linux-omap@vger.kernel.org
> >> >> Subject: Re: Camera Interface VS/HS Issue
> >> >>
> >> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >> >> > 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@googlemail.com]
> >> >> >> 2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
> >> >> >> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> >> >> >> >> (rearranging mail to avoid top posting..)
> >> >> >> >>
> >> >> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
> >> >> >> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto
> <saaguirre@ti.com>:
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> >> -----Original Message-----
> >> >> >> >>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> >> >> >>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
> >> >> >> >>> >> Sent: Monday, July 27, 2009 7:47 AM
> >> >> >> >>> >> To: linux-omap@vger.kernel.org
> >> >> >> >>> >> 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?

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?

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?

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

Re: Camera Interface VS/HS Issue

[matthias schwarz]

---------- Forwarded message ----------
From: matthias schwarz <matthias.schw@googlemail.com>
Date: 2009/7/27
Subject: Re: Camera Interface VS/HS Issue
To: "Aguirre Rodriguez, Sergio Alberto" <saaguirre@ti.com>


2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>
>
>> -----Original Message-----
>> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> Sent: Monday, July 27, 2009 12:37 PM
>> To: Aguirre Rodriguez, Sergio Alberto
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: Camera Interface VS/HS Issue
>>
>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >
>> >
>> >> -----Original Message-----
>> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> >> Sent: Monday, July 27, 2009 11:12 AM
>> >> To: Aguirre Rodriguez, Sergio Alberto
>> >> Cc: linux-omap@vger.kernel.org
>> >> Subject: Re: Camera Interface VS/HS Issue
>> >>
>> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> >> >> Sent: Monday, July 27, 2009 10:59 AM
>> >> >> To: Aguirre Rodriguez, Sergio Alberto
>> >> >> Cc: linux-omap@vger.kernel.org
>> >> >> Subject: Re: Camera Interface VS/HS Issue
>> >> >>
>> >> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >> >> > 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@googlemail.com]
>> >> >> >> 2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
>> >> >> >> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>> >> >> >> >> (rearranging mail to avoid top posting..)
>> >> >> >> >>
>> >> >> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>> >> >> >> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto
>> <saaguirre@ti.com>:
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> >> -----Original Message-----
>> >> >> >> >>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> >> >> >> >>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
>> >> >> >> >>> >> Sent: Monday, July 27, 2009 7:47 AM
>> >> >> >> >>> >> To: linux-omap@vger.kernel.org
>> >> >> >> >>> >> 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

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

OMAP camera with BT-656 sensor

[Gary Thomas]

Sergio,

I'm trying to use your tree with a BT-656 style sensor(*).  I've
managed to get this [more or less] working when I use the official
TI PSP tree + OMAP3 patches, but I'm not getting very far with
your code.  I just updated my copy from your tree, but I don't
see any real changes since June 18 when I first started looking
at this.

I've made a number of changes, inspired by the PSP code to get
the BT-656 handling enabled in the CCDC.  I do see that the PSP
codebase seems older than yours? but is more complete in other
respects.  Can you enlighten me as to the heritage of these
different trees?

The problem I have at the moment is that sensor data is getting
into the CCDC module, but since the previewer/resizer modules
are not used, nothing is ever delivered to my user code.

Bottom line, I'm confused as to how I should go about getting
my driver/system working.  Do I use your work, or just stick
with the PSP base (why?)??

Thanks

(*) I cloned: git://dev.omapzoom.org/pub/scm/saaguirre/linux-omap-camera.git

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

RE: OMAP camera with BT-656 sensor

[Aguirre Rodriguez, Sergio Alberto]

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Monday, July 27, 2009 2:11 PM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-omap@vger.kernel.org
> Subject: OMAP camera with BT-656 sensor
> 
> Sergio,
> 
> I'm trying to use your tree with a BT-656 style sensor(*).  I've
> managed to get this [more or less] working when I use the official
> TI PSP tree + OMAP3 patches, but I'm not getting very far with
> your code.  I just updated my copy from your tree, but I don't
> see any real changes since June 18 when I first started looking
> at this.

Yeah, I know, and I'm sorry for that :(

Lately, I have been busy with some high priority customer specific tasks, and haven't had time to work on the public tree at all...

The good thing is that I'll be now dedicating on this full time, as This will eventually become my only task in the future (interact with the community for enahncemets/fixes in the driver).

One bad thing is that as I don't have a BT656 sensor with me, its near to impossible for me to develop on that area, so Vaibhav Hiremath in their PSP releases, is doing that instead. Anyways, I'll be looking forward to make those changes part of my tree aswell, if Vaibhav is ok with it (as I'm almost completely sure he is)
> 
> I've made a number of changes, inspired by the PSP code to get
> the BT-656 handling enabled in the CCDC.  I do see that the PSP
> codebase seems older than yours? but is more complete in other
> respects.  Can you enlighten me as to the heritage of these
> different trees?

Ok, let me explain the currently existing trees, and their connection:

Linux-omap is the "baseline" in which all this code is based, because you couldn't find everything yet on kernel.org.

Sakari Ailus (from Nokia) and Myself (from TI) we're trying to get the code accepted on the linux-omap and linux-media lists, so Sakari created a tree which contains the latest developed driver in Nokia, which is based on an older internal TI code, and in which I have been helping to fix for acceptance aswell. You can find that tree here:

	http://gitorious.org/omap3camera

But that tree only contains the core OMAP3 Camera-ISP driver, without any sensor or board specific code, and also it is based on an older kernel (because is the one in which Sakari tests). So there's when my tree comes to overcome this things. So I created a tree in gitorious right away:

	http://gitorious.org/omap3-linux-camera-driver

And Vaibhav, who was interested in bringing up this code on 3530EVM with an onboard TV tuner interfaced with BT656 to the camera driver (like it was a sensor), started his development on top of my gitorious tree.

Later on, Sakari updated his tree with some more code changes, but this time I could get a more formal tree under the omapzoom server, in which TI has full control. So instead of updating my gitorious, I decided to better create a new tree, and pull there the new code coming from Sakari's tree instead. So I created the tree you're currently looking at:

	http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=shortlog;h=refs/heads/devel

In which I'm trying to make work my 3430SDP with some camera sensors I have handy (MT9P012 and OV3640), an OMAP Zoom1 (a.k.a. LDP), and an OMAP Zoom2 (under works still).

So, I hope looks clear for you on how all these trees are related...

> 
> The problem I have at the moment is that sensor data is getting
> into the CCDC module, but since the previewer/resizer modules
> are not used, nothing is ever delivered to my user code.

The CCDC is capable of saving to memory directly, so you don't specifically need Preview and resizer all the time.
> 
> Bottom line, I'm confused as to how I should go about getting
> my driver/system working.  Do I use your work, or just stick
> with the PSP base (why?)??

What I do feel is that the PSP base will fulfill better your immediate needs, but in the future, as I'm getting aware of Vaibhav changes, I'll be interested in making them part of my tree aswell, so Vaibhav could avoid rebasing the BT646 support internally everytime...

> 
> Thanks

Thanks for your interest!

Regards,
Sergio
> 
> (*) I cloned: git://dev.omapzoom.org/pub/scm/saaguirre/linux-omap-
> camera.git
> 
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------

Re: OMAP camera with BT-656 sensor

[Gary Thomas]

Aguirre Rodriguez, Sergio Alberto wrote:
> 
>> -----Original Message-----
>> From: Gary Thomas [mailto:gary@mlbassoc.com]
>> Sent: Monday, July 27, 2009 2:11 PM
>> To: Aguirre Rodriguez, Sergio Alberto
>> Cc: linux-omap@vger.kernel.org
>> Subject: OMAP camera with BT-656 sensor
   ... snip

>> Bottom line, I'm confused as to how I should go about getting
>> my driver/system working.  Do I use your work, or just stick
>> with the PSP base (why?)??
> 
> What I do feel is that the PSP base will fulfill better your immediate needs, but in the future, as I'm getting aware of Vaibhav changes, I'll be interested in making them part of my tree aswell, so Vaibhav could avoid rebasing the BT646 support internally everytime...

Is there a GIT tree for this?

A [hopefully] minor complication is that I'm using Tomi's DSS2
tree for the base of my port.  How can I move/merge the PSP
based support into it?  Can I just pick up the whole drivers/media
subtree and put in in place of what I have?

Thanks for your help - this myriad of trees and very disparate
support levels is really confusing to those of us on the outside...

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

RE: OMAP camera with BT-656 sensor

[Aguirre Rodriguez, Sergio Alberto]

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Monday, July 27, 2009 2:59 PM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-omap@vger.kernel.org
> Subject: Re: OMAP camera with BT-656 sensor
> 
> Aguirre Rodriguez, Sergio Alberto wrote:
> >
> >> -----Original Message-----
> >> From: Gary Thomas [mailto:gary@mlbassoc.com]
> >> Sent: Monday, July 27, 2009 2:11 PM
> >> To: Aguirre Rodriguez, Sergio Alberto
> >> Cc: linux-omap@vger.kernel.org
> >> Subject: OMAP camera with BT-656 sensor
>    ... snip
> 
> >> Bottom line, I'm confused as to how I should go about getting
> >> my driver/system working.  Do I use your work, or just stick
> >> with the PSP base (why?)??
> >
> > What I do feel is that the PSP base will fulfill better your immediate
> needs, but in the future, as I'm getting aware of Vaibhav changes, I'll be
> interested in making them part of my tree aswell, so Vaibhav could avoid
> rebasing the BT646 support internally everytime...
> 
> Is there a GIT tree for this?

AFAIK, this is the latest tree Vaibhav is exposing:

http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git

He maintains a camera and a DSS2 branch exactly to make both work on his 3530EVM.

> 
> A [hopefully] minor complication is that I'm using Tomi's DSS2
> tree for the base of my port.  How can I move/merge the PSP
> based support into it?  Can I just pick up the whole drivers/media
> subtree and put in in place of what I have?

I recommend looking at the git tree above... I think that job is already done...

> 
> Thanks for your help - this myriad of trees and very disparate
> support levels is really confusing to those of us on the outside...

I know, and the lack of proper documentation is one of the first issues for me to look at...

You're welcome.
> 
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------

RE: OMAP camera with BT-656 sensor

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio
> Alberto
> Sent: Tuesday, July 28, 2009 1:45 AM
> To: Gary Thomas
> Cc: linux-omap@vger.kernel.org
> Subject: RE: OMAP camera with BT-656 sensor
> 
> 
> 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@mlbassoc.com]
> > Sent: Monday, July 27, 2009 2:59 PM
> > To: Aguirre Rodriguez, Sergio Alberto
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: OMAP camera with BT-656 sensor
> >
> > Aguirre Rodriguez, Sergio Alberto wrote:
> > >
> > >> -----Original Message-----
> > >> From: Gary Thomas [mailto:gary@mlbassoc.com]
> > >> Sent: Monday, July 27, 2009 2:11 PM
> > >> To: Aguirre Rodriguez, Sergio Alberto
> > >> Cc: linux-omap@vger.kernel.org
> > >> Subject: OMAP camera with BT-656 sensor
> >    ... snip
> >
> > >> Bottom line, I'm confused as to how I should go about getting
> > >> my driver/system working.  Do I use your work, or just stick
> > >> with the PSP base (why?)??
> > >
> > > What I do feel is that the PSP base will fulfill better your
> immediate
> > needs, but in the future, as I'm getting aware of Vaibhav changes,
> I'll be
> > interested in making them part of my tree aswell, so Vaibhav could
> avoid
> > rebasing the BT646 support internally everytime...
> >
> > Is there a GIT tree for this?
> 
> AFAIK, this is the latest tree Vaibhav is exposing:
> 
> http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git
> 
> He maintains a camera and a DSS2 branch exactly to make both work on
> his 3530EVM.
> 
[Hiremath, Vaibhav] Thanks Sergio for taking this up. Just to add on top of Sergio's comments, the current status of above tree is, DSS2 is already merged to latest kernel (Even on PM branch) baseline.

http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/ti_display

http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/pm


The next PSP release will contain 2.6.31(PM) + DSS2 + Camera + Resizer modules together in one release. I have started with Camera modules merging on top of 2.6.31 + DSS2; hopefully I should be able to complete this by next week (provided that I don't get any interrupts)

You should be looking to Arago tree for all the developments which I do under Arago.

Please let me know if you have any issues/doubts OR if you are looking for some quick solutions.

Thanks,
Vaibhav

> >
> > A [hopefully] minor complication is that I'm using Tomi's DSS2
> > tree for the base of my port.  How can I move/merge the PSP
> > based support into it?  Can I just pick up the whole drivers/media
> > subtree and put in in place of what I have?
> 
> I recommend looking at the git tree above... I think that job is
> already done...
> 
> >
> > Thanks for your help - this myriad of trees and very disparate
> > support levels is really confusing to those of us on the
> outside...
> 
> I know, and the lack of proper documentation is one of the first
> issues for me to look at...
> 
> You're welcome.
> >
> > --
> > ------------------------------------------------------------
> > Gary Thomas                 |  Consulting for the
> > MLB Associates              |    Embedded world
> > ------------------------------------------------------------
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Camera Interface VS/HS Issue

[matthias schwarz]

2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
> ---------- Forwarded message ----------
> From: matthias schwarz <matthias.schw@googlemail.com>
> Date: 2009/7/27
> Subject: Re: Camera Interface VS/HS Issue
> To: "Aguirre Rodriguez, Sergio Alberto" <saaguirre@ti.com>
>
>
> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>>
>>
>>> -----Original Message-----
>>> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>>> Sent: Monday, July 27, 2009 12:37 PM
>>> To: Aguirre Rodriguez, Sergio Alberto
>>> Cc: linux-omap@vger.kernel.org
>>> Subject: Re: Camera Interface VS/HS Issue
>>>
>>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>>> >> Sent: Monday, July 27, 2009 11:12 AM
>>> >> To: Aguirre Rodriguez, Sergio Alberto
>>> >> Cc: linux-omap@vger.kernel.org
>>> >> Subject: Re: Camera Interface VS/HS Issue
>>> >>
>>> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>>> >> >
>>> >> >
>>> >> >> -----Original Message-----
>>> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>>> >> >> Sent: Monday, July 27, 2009 10:59 AM
>>> >> >> To: Aguirre Rodriguez, Sergio Alberto
>>> >> >> Cc: linux-omap@vger.kernel.org
>>> >> >> Subject: Re: Camera Interface VS/HS Issue
>>> >> >>
>>> >> >> 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>>> >> >> > 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@googlemail.com]
>>> >> >> >> 2009/7/27 matthias schwarz <matthias.schw@googlemail.com>:
>>> >> >> >> > 2009/7/27 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
>>> >> >> >> >> (rearranging mail to avoid top posting..)
>>> >> >> >> >>
>>> >> >> >> >> From: matthias schwarz [mailto:matthias.schw@googlemail.com]
>>> >> >> >> >>> 2009/7/27 Aguirre Rodriguez, Sergio Alberto
>>> <saaguirre@ti.com>:
>>> >> >> >> >>> >
>>> >> >> >> >>> >
>>> >> >> >> >>> >> -----Original Message-----
>>> >> >> >> >>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>>> >> >> >> >>> >> owner@vger.kernel.org] On Behalf Of matthias schwarz
>>> >> >> >> >>> >> Sent: Monday, July 27, 2009 7:47 AM
>>> >> >> >> >>> >> To: linux-omap@vger.kernel.org
>>> >> >> >> >>> >> 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@vger.kernel.org
>>> >> >> >> >>> >> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP camera with BT-656 sensor

[Gary Thomas]

Hiremath, Vaibhav wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio
>> Alberto
>> Sent: Tuesday, July 28, 2009 1:45 AM
>> To: Gary Thomas
>> Cc: linux-omap@vger.kernel.org
>> Subject: RE: OMAP camera with BT-656 sensor
>>
>>
>>
>>> -----Original Message-----
>>> From: Gary Thomas [mailto:gary@mlbassoc.com]
>>> Sent: Monday, July 27, 2009 2:59 PM
>>> To: Aguirre Rodriguez, Sergio Alberto
>>> Cc: linux-omap@vger.kernel.org
>>> Subject: Re: OMAP camera with BT-656 sensor
>>>
>>> Aguirre Rodriguez, Sergio Alberto wrote:
>>>>> -----Original Message-----
>>>>> From: Gary Thomas [mailto:gary@mlbassoc.com]
>>>>> Sent: Monday, July 27, 2009 2:11 PM
>>>>> To: Aguirre Rodriguez, Sergio Alberto
>>>>> Cc: linux-omap@vger.kernel.org
>>>>> Subject: OMAP camera with BT-656 sensor
>>>    ... snip
>>>
>>>>> Bottom line, I'm confused as to how I should go about getting
>>>>> my driver/system working.  Do I use your work, or just stick
>>>>> with the PSP base (why?)??
>>>> What I do feel is that the PSP base will fulfill better your
>> immediate
>>> needs, but in the future, as I'm getting aware of Vaibhav changes,
>> I'll be
>>> interested in making them part of my tree aswell, so Vaibhav could
>> avoid
>>> rebasing the BT646 support internally everytime...
>>>
>>> Is there a GIT tree for this?
>> AFAIK, this is the latest tree Vaibhav is exposing:
>>
>> http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git
>>
>> He maintains a camera and a DSS2 branch exactly to make both work on
>> his 3530EVM.
>>
> [Hiremath, Vaibhav] Thanks Sergio for taking this up. Just to add on top of Sergio's comments, the current status of above tree is, DSS2 is already merged to latest kernel (Even on PM branch) baseline.
> 
> http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/ti_display
> 
> http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/pm
> 
> 
> The next PSP release will contain 2.6.31(PM) + DSS2 + Camera + Resizer modules together in one release. I have started with Camera modules merging on top of 2.6.31 + DSS2; hopefully I should be able to complete this by next week (provided that I don't get any interrupts)
> 
> You should be looking to Arago tree for all the developments which I do under Arago.
> 
> Please let me know if you have any issues/doubts OR if you are looking for some quick solutions.

I'd like to use the latest tree with DSS2 (ti_display seems to be it), but
the OMAP3 camera support is not present.
  * How hard would it be to merge the ti_omap3camera and ti_display branches?
  * Would this be a reasonable way forward?

It would be nice if I could wait for your next release, but alas, my
project is already weeks late and every hour counts...

>>> A [hopefully] minor complication is that I'm using Tomi's DSS2
>>> tree for the base of my port.  How can I move/merge the PSP
>>> based support into it?  Can I just pick up the whole drivers/media
>>> subtree and put in in place of what I have?
>> I recommend looking at the git tree above... I think that job is
>> already done...
>>
>>> Thanks for your help - this myriad of trees and very disparate
>>> support levels is really confusing to those of us on the
>> outside...
>>
>> I know, and the lack of proper documentation is one of the first
>> issues for me to look at...
>>
>> You're welcome.


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

RE: OMAP camera with BT-656 sensor

[Hiremath, Vaibhav]

Hi Thomas,

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Tuesday, July 28, 2009 6:15 PM
> To: Hiremath, Vaibhav
> Cc: Aguirre Rodriguez, Sergio Alberto; linux-omap@vger.kernel.org
> Subject: Re: OMAP camera with BT-656 sensor
> 
> Hiremath, Vaibhav wrote:
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> owner@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio
> >> Alberto
> >> Sent: Tuesday, July 28, 2009 1:45 AM
> >> To: Gary Thomas
> >> Cc: linux-omap@vger.kernel.org
> >> Subject: RE: OMAP camera with BT-656 sensor
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Gary Thomas [mailto:gary@mlbassoc.com]
> >>> Sent: Monday, July 27, 2009 2:59 PM
> >>> To: Aguirre Rodriguez, Sergio Alberto
> >>> Cc: linux-omap@vger.kernel.org
> >>> Subject: Re: OMAP camera with BT-656 sensor
> >>>
> >>> Aguirre Rodriguez, Sergio Alberto wrote:
> >>>>> -----Original Message-----
> >>>>> From: Gary Thomas [mailto:gary@mlbassoc.com]
> >>>>> Sent: Monday, July 27, 2009 2:11 PM
> >>>>> To: Aguirre Rodriguez, Sergio Alberto
> >>>>> Cc: linux-omap@vger.kernel.org
> >>>>> Subject: OMAP camera with BT-656 sensor
> >>>    ... snip
> >>>
> >>>>> Bottom line, I'm confused as to how I should go about getting
> >>>>> my driver/system working.  Do I use your work, or just stick
> >>>>> with the PSP base (why?)??
> >>>> What I do feel is that the PSP base will fulfill better your
> >> immediate
> >>> needs, but in the future, as I'm getting aware of Vaibhav
> changes,
> >> I'll be
> >>> interested in making them part of my tree aswell, so Vaibhav
> could
> >> avoid
> >>> rebasing the BT646 support internally everytime...
> >>>
> >>> Is there a GIT tree for this?
> >> AFAIK, this is the latest tree Vaibhav is exposing:
> >>
> >> http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git
> >>
> >> He maintains a camera and a DSS2 branch exactly to make both work
> on
> >> his 3530EVM.
> >>
> > [Hiremath, Vaibhav] Thanks Sergio for taking this up. Just to add
> on top of Sergio's comments, the current status of above tree is,
> DSS2 is already merged to latest kernel (Even on PM branch)
> baseline.
> >
> > http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-
> video.git;a=shortlog;h=refs/heads/ti_display
> >
> > http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-
> video.git;a=shortlog;h=refs/heads/pm
> >
> >
> > The next PSP release will contain 2.6.31(PM) + DSS2 + Camera +
> Resizer modules together in one release. I have started with Camera
> modules merging on top of 2.6.31 + DSS2; hopefully I should be able
> to complete this by next week (provided that I don't get any
> interrupts)
> >
> > You should be looking to Arago tree for all the developments which
> I do under Arago.
> >
> > Please let me know if you have any issues/doubts OR if you are
> looking for some quick solutions.
> 
> I'd like to use the latest tree with DSS2 (ti_display seems to be
> it), but
> the OMAP3 camera support is not present.
[Hiremath, Vaibhav] Yes you are correct.
>   * How hard would it be to merge the ti_omap3camera and ti_display
> branches?

[Hiremath, Vaibhav] Should not be that hard but I would suggest to go with latest Camera changes.

>   * Would this be a reasonable way forward?

 [Hiremath, Vaibhav] It would be really difficult to maintain the old code base, which in my opinion waste of efforts.

> 
> It would be nice if I could wait for your next release, but alas, my
> project is already weeks late and every hour counts...
> 
> >>> A [hopefully] minor complication is that I'm using Tomi's DSS2
> >>> tree for the base of my port.  How can I move/merge the PSP
> >>> based support into it?  Can I just pick up the whole
> drivers/media
> >>> subtree and put in in place of what I have?
> >> I recommend looking at the git tree above... I think that job is
> >> already done...
> >>
> >>> Thanks for your help - this myriad of trees and very disparate
> >>> support levels is really confusing to those of us on the
> >> outside...
> >>
> >> I know, and the lack of proper documentation is one of the first
> >> issues for me to look at...
> >>
> >> You're welcome.
> 
> 
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------