Skip to contentSkip to conversation

omap3isp with DM3730 not working?!

DISCUSSION Michael Dietschi 4 participants 16 messages Jul 24, 2014 – Jul 31, 2014 Media (V4L/DVB)

lore
Share & tools
lore

Michael Dietschi

author
#0 lore raw

Hello,

I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253.
It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :(

I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ

Can someone please give me a hint?

Kind regards,
Michael

#1 lore raw
Quoted 8 lines · Michael Dietschi

Hello,

I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253.
It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :(

Quoted 4 lines

I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ

Can someone please give me a hint?

It's strange that you get the vd1_irq because it should not be set by the driver and never trigger...

Anyway maybe a different pinmux where the camera pins are not setup correctly?

Enrico

#2 lore raw

Hi Enrico and Michael,

Quoted 4 lines · Enrico
Quoted 2 lines · Michael Dietschi

Hello,

Quoted 8 lines
Quoted 8 lines

I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253.
It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :(

I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ

VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c).

I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this.

Quoted 4 lines
Quoted 1 line

Can someone please give me a hint?

It's strange that you get the vd1_irq because it should not be set by the driver and never trigger...

Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame.

Quoted 1 line

Anyway maybe a different pinmux where the camera pins are not setup correctly?

This is unlikely to be at least the source of all issues since VD1 is seen.

Cc Laurent.

Signature · 4 lines
Kind regards,

Sakari Ailus
e-mail: [email protected]	XMPP: [email protected]
author
#3 lore raw

Hi Sakari, Enrico and others,

first of all I want to thank you for your help but I have to admit that I made a stupid error while struggling with image capturing and the ISP which has led to some false information - I had misconfigured the video source :(

The corrected facts are:
* Capturing does work with Gumstix Overo with a DM3730 and a
TVP5151 chip
* It does not work with a LogicPD Torpedo DM3730 and a TVP5150AM1 chip
* I configured the Torpedo's pinmux exactly like on the Overo
* ...but the only interrupt I am getting is "HS_VS_IRQ"

Please apologize for the confusion and do not stop helping me...

Kind regards,
Michael

#4 lore raw
In reply to Sakari Ailus
Quoted 24 lines · Sakari Ailus

Hi Enrico and Michael,

Quoted 4 lines · Enrico
Quoted 2 lines · Michael Dietschi

Hello,

Quoted 8 lines
Quoted 8 lines

I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253.
It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :(

I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ

VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c).

I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Can someone please give me a hint?

It's strange that you get the vd1_irq because it should not be set by the driver and never trigger...

Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame.

Hi Sakari,

that's true in "normal" mode, but with bt656 patches VD1 is not used.

Enrico

#5 lore raw

Hi Enrico,

Quoted 27 lines · On Monday 28 July 2014 10:30:17 Enrico wrote:
Quoted 26 lines · Sakari Ailus
Quoted 11 lines · Enrico
Quoted 10 lines · Michael Dietschi

Hello,

I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253.
It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :(

I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ

VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c).

I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this.

Quoted 4 lines
Quoted 1 line

Can someone please give me a hint?

It's strange that you get the vd1_irq because it should not be set by the driver and never trigger...

Quoted 6 lines
Quoted 2 lines

Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame.

Hi Sakari,

that's true in "normal" mode, but with bt656 patches VD1 is not used.

That's not correct, VD1 is used in both modes. In BT.656 mode VD1 is even used to increment the frame counter in place of the HS_VS interrupt.

Signature · 3 lines
Regards,

Laurent Pinchart
#6 lore raw
Quoted 33 lines · Laurent Pinchart

Hi Enrico,

Quoted 30 lines · On Monday 28 July 2014 10:30:17 Enrico wrote:
Quoted 28 lines · Sakari Ailus
Quoted 11 lines · Enrico
Quoted 10 lines · Michael Dietschi

Hello,

I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253.
It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :(

I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ

VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c).

I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this.

Quoted 4 lines
Quoted 1 line

Can someone please give me a hint?

It's strange that you get the vd1_irq because it should not be set by the driver and never trigger...

Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame.

Quoted 6 lines
Quoted 3 lines

Hi Sakari,

that's true in "normal" mode, but with bt656 patches VD1 is not used.

That's not correct, VD1 is used in both modes. In BT.656 mode VD1 is even used to increment the frame counter in place of the HS_VS interrupt.

...in your new patches. But sleepyrobot's are the old ones and i bet Michael is using those patches.

Enrico

#7 lore raw

Hi Enrico,

Quoted 34 lines · On Monday 28 July 2014 15:18:04 Enrico wrote:
Quoted 33 lines · Laurent Pinchart
Quoted 32 lines · On Monday 28 July 2014 10:30:17 Enrico wrote:
Quoted 21 lines · Sakari Ailus
Quoted 11 lines · Enrico
Quoted 10 lines · Michael Dietschi

Hello,

I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253.
It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :(

I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ

VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c).

I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Can someone please give me a hint?

It's strange that you get the vd1_irq because it should not be set by the driver and never trigger...

Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame.

Hi Sakari,

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

that's true in "normal" mode, but with bt656 patches VD1 is not used.

That's not correct, VD1 is used in both modes. In BT.656 mode VD1 is even used to increment the frame counter in place of the HS_VS interrupt.

...in your new patches. But sleepyrobot's are the old ones and i bet Michael is using those patches.

You're right. Maybe that's the first problem to be fixed though ;-) Michael, could you try using the "official" (and under development) BT.656 support code for the OMAP3 ISP driver ? I've just pushed the branch to

git://linuxtv.org/pinchartl/media.git omap3isp/bt656

Signature · 3 lines
Regards,

Laurent Pinchart
author
#8 lore raw

Am 29.07.2014 02:53, schrieb Laurent Pinchart:

Quoted 1 line

You're right. Maybe that's the first problem to be fixed though ;-) Michael, could you try using the "official" (and under development) BT.656 support code for the OMAP3 ISP driver ? I've just pushed the branch to git://linuxtv.org/pinchartl/media.git omap3isp/bt656

I will try with your "official" kernel and report back.

Thanks,
Michael

author
#9 lore raw
In reply to Laurent Pinchart

Am 29.07.2014 02:53, schrieb Laurent Pinchart:

Quoted 1 line

You're right. Maybe that's the first problem to be fixed though ;-) Michael, could you try using the "official" (and under development) BT.656 support code for the OMAP3 ISP driver ? I've just pushed the branch to git://linuxtv.org/pinchartl/media.git omap3isp/bt656

Laurent,

I did try this kernel and it does not work either - but with a different error. Any Idea?

Michael

These are the commands and their output:

root@overo:~$  media-ctl -v -r -l '"tvp5150 3-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC

output":0[1]'
Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Resetting all links to inactive
Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]

root@overo:~$  media-ctl -v -V '"tvp5150 3-005c":0 [UYVY2X8 720x576], "OMAP3 ISP CCDC":1 [UYVY2X8 720x576]'Opening

media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Setting up format UYVY2X8 720x576 on pad tvp5150 3-005c/0 Format set: UYVY2X8 720x240
Setting up format UYVY2X8 720x240 on pad OMAP3 ISP CCDC/0 Format set: UYVY2X8 720x240
Setting up format UYVY2X8 720x576 on pad OMAP3 ISP CCDC/1 Format set: UYVY 720x240

root@overo:~$  yavta -f UYVY -s 720x576 --capture=1 --file=imagele /dev/video2

Device /dev/video2 opened.
Device OMAP3 ISP CCDC output' on media' is a video capture device. Video format set: UYVY (59565955) 720x576 (stride 1440) buffer size 829440 Video format: UYVY (59565955) 720x576 (stride 1440) buffer size 829440 8 buffers requested.
length: 829440 offset: 0
Buffer 0 mapped at address 0xb6e79000.
length: 829440 offset: 831488
Buffer 1 mapped at address 0xb6dae000.
length: 829440 offset: 1662976
Buffer 2 mapped at address 0xb6ce3000.
length: 829440 offset: 2494464
Buffer 3 mapped at address 0xb6c18000.
length: 829440 offset: 3325952
Buffer 4 mapped at address 0xb6b4d000.
length: 829440 offset: 4157440
Buffer 5 mapped at address 0xb6a82000.
length: 829440 offset: 4988928
Buffer 6 mapped at address 0xb69b7000.
length: 829440 offset: 5820416
Buffer 7 mapped at address 0xb68ec000.
Unable to start streaming: Invalid argument (22).
8 buffers released.

#10 lore raw
Quoted 10 lines · Michael Dietschi

Am 29.07.2014 02:53, schrieb Laurent Pinchart:

Quoted 5 lines

You're right. Maybe that's the first problem to be fixed though ;-) Michael, could you try using the "official" (and under development) BT.656 support code for the OMAP3 ISP driver ? I've just pushed the branch to
git://linuxtv.org/pinchartl/media.git omap3isp/bt656

Laurent,

Quoted 8 lines

I did try this kernel and it does not work either - but with a different error.
Any Idea?

Michael

These are the commands and their output:

Standard question: are you using media-ctl from
git://linuxtv.org/pinchartl/v4l-utils.git field branch and latest yavta from git://git.ideasonboard.org/yavta.git ?

Enrico

author
#11 lore raw

Am 30.07.2014 17:21, schrieb Enrico:

Quoted 5 lines

Standard question: are you using media-ctl from
git://linuxtv.org/pinchartl/v4l-utils.git field branch and latest yavta from git://git.ideasonboard.org/yavta.git ?

Enrico

No, not exactly. I used older versions which came with Yocto Poky Daisy. But I also tried with these newer ones and get the same:

root@overo:~$  ./media-ctl -v -r -l '"tvp5150 3-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'

Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Resetting all links to inactive
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Opening media device /dev/media0
Setting up link 16:0 -> 5:0 [1]
Opening media device /dev/media0
Setting up link 5:1 -> 6:0 [1]
Opening media device /dev/media0

root@overo:~$  ./media-ctl -v -f '"tvp5150 3-005c":0 [UYVY2X8 720x576], "OMAP3 ISP CCDC":1 [UYVY2X8 720x576]'

Warning: the -f option is deprecated and has been replaced by -V. Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Setting up format UYVY2X8 720x576 on pad tvp5150 3-005c/0 Format set: UYVY2X8 720x240
Setting up format UYVY2X8 720x240 on pad OMAP3 ISP CCDC/0 Format set: UYVY2X8 720x240
Setting up format UYVY2X8 720x576 on pad OMAP3 ISP CCDC/1 Format set: UYVY 720x240

root@overo:~$  ./yavta -f UYVY -s 720x576 --capture=1 --file=image.raw /dev/video2

Device /dev/video2 opened.
Device OMAP3 ISP CCDC output' on media' is a video output (without mplanes) device. Video format set: UYVY (59565955) 720x576 (stride 1440) field none buffer size 829440 Video format: UYVY (59565955) 720x576 (stride 1440) field none buffer size 829440 8 buffers requested.
length: 829440 offset: 0 timestamp type/source: mono/(null)
Buffer 0/0 mapped at address 0xb6e59000.
length: 829440 offset: 831488 timestamp type/source: mono/(null)
Buffer 1/0 mapped at address 0xb6d8e000.
length: 829440 offset: 1662976 timestamp type/source: mono/(null) Buffer 2/0 mapped at address 0xb6cc3000.
length: 829440 offset: 2494464 timestamp type/source: mono/(null) Buffer 3/0 mapped at address 0xb6bf8000.
length: 829440 offset: 3325952 timestamp type/source: mono/(null) Buffer 4/0 mapped at address 0xb6b2d000.
length: 829440 offset: 4157440 timestamp type/source: mono/(null) Buffer 5/0 mapped at address 0xb6a62000.
length: 829440 offset: 4988928 timestamp type/source: mono/(null) Buffer 6/0 mapped at address 0xb6997000.
length: 829440 offset: 5820416 timestamp type/source: mono/(null) Buffer 7/0 mapped at address 0xb68cc000.
Unable to start streaming: Invalid argument (22).
8 buffers released.

#12 lore raw
Quoted 15 lines · Michael Dietschi

Am 30.07.2014 17:21, schrieb Enrico:

Quoted 5 lines

Standard question: are you using media-ctl from
git://linuxtv.org/pinchartl/v4l-utils.git field branch and latest yavta from git://git.ideasonboard.org/yavta.git ?

Enrico

No, not exactly. I used older versions which came with Yocto Poky Daisy. But I also tried with these newer ones and get the same:

root@overo:~$  ./media-ctl -v -r -l '"tvp5150 3-005c":0->"OMAP3 ISP
CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
Quoted 6 lines
root@overo:~$  ./media-ctl -v -f '"tvp5150 3-005c":0 [UYVY2X8 720x576],
"OMAP3 ISP CCDC":1 [UYVY2X8 720x576]'
root@overo:~$  ./yavta -f UYVY -s 720x576 --capture=1 --file=image.raw
/dev/video2

I think you are missing the ccdc sink pad setup, basically you should have something like this:

....
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)

            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev2
        pad0: Sink
                [fmt:UYVY2X8/720x288 field:alternate]
                <- "OMAP3 ISP CCP2":1 []
                <- "OMAP3 ISP CSI2a":1 []
                <- "tvp5150 1-005c":0 [ENABLED]
        pad1: Source
                [fmt:UYVY/720x576 field:interlaced-tb
                 crop.bounds:(0,0)/720x288
                 crop:(0,0)/720x288]
                -> "OMAP3 ISP CCDC output":0 [ENABLED]
                -> "OMAP3 ISP resizer":0 []

with this setup i can correctly capture deinterlaced frames with yavta, but have a look at the "[PATCH 00/11] OMAP3 ISP BT.656 support" thread, i noticed some problems maybe it's the same for you.

Enrico

author
#13 lore raw

Am 31.07.2014 12:36, schrieb Enrico:

Quoted 20 lines

I think you are missing the ccdc sink pad setup, basically you should have something like this:

....
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)

             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev2
         pad0: Sink
                 [fmt:UYVY2X8/720x288 field:alternate]
                 <- "OMAP3 ISP CCP2":1 []
                 <- "OMAP3 ISP CSI2a":1 []
                 <- "tvp5150 1-005c":0 [ENABLED]
         pad1: Source
                 [fmt:UYVY/720x576 field:interlaced-tb
                  crop.bounds:(0,0)/720x288
                  crop:(0,0)/720x288]
                 -> "OMAP3 ISP CCDC output":0 [ENABLED]
                 -> "OMAP3 ISP resizer":0 []
Quoted 6 lines

with this setup i can correctly capture deinterlaced frames with yavta, but have a look at the "[PATCH 00/11] OMAP3 ISP BT.656 support" thread, i noticed some problems maybe it's the same for you.

Enrico

Hi Enrico,
the setup looks like:

...
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)

            type V4L2 subdev subtype Unknown flags 0

            device node name /dev/v4l-subdev2

    pad0: Sink

        [fmt:UYVY2X8/720x240 field:alternate]

        <- "OMAP3 ISP CCP2":1 []

        <- "OMAP3 ISP CSI2a":1 []

        <- "tvp5150 3-005c":0 [ENABLED]

    pad1: Source

        [fmt:UYVY/720x240 field:alternate

         crop.bounds:(0,0)/720x240

         crop:(0,0)/720x240]

        -> "OMAP3 ISP CCDC output":0 [ENABLED]

        -> "OMAP3 ISP resizer":0 []

    pad2: Source

        [fmt:unknown/720x239 field:alternate]

        -> "OMAP3 ISP preview":0 []

        -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE]

        -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE]

        -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE]

- entity 6: OMAP3 ISP CCDC output (1 pad, 1 link)

type Node subtype V4L flags 0

device node name /dev/video2

pad0: Sink

<- "OMAP3 ISP CCDC":1 [ENABLED]

...

- entity 16: tvp5150 3-005c (1 pad, 1 link)

type V4L2 subdev subtype Unknown flags 0

device node name /dev/v4l-subdev8

pad0: Source

[fmt:UYVY2X8/720x240 field:alternate]

-> "OMAP3 ISP CCDC":0 [ENABLED]

And I could not find any help in"[PATCH 00/11] OMAP3 ISP BT.656 support" because it seems that all the mentioned things are already done.

Michael

#14 lore raw
Quoted 18 lines · Michael Dietschi

Am 31.07.2014 12:36, schrieb Enrico:

Quoted 6 lines

I think you are missing the ccdc sink pad setup, basically you should have something like this:

....
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)

Quoted 9 lines
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev2
         pad1: Source
                 [fmt:UYVY/720x576 field:interlaced-tb
                  crop.bounds:(0,0)/720x288
                  crop:(0,0)/720x288]
                 -> "OMAP3 ISP CCDC output":0 [ENABLED]
                 -> "OMAP3 ISP resizer":0 []
Quoted 7 lines
    pad1: Source

        [fmt:UYVY/720x240 field:alternate

         crop.bounds:(0,0)/720x240

         crop:(0,0)/720x240]

It seems you are missing this:

media-ctl --set-format '"OMAP3 ISP CCDC":1 [UYVY 720x480 field:interlaced-tb]'

and add --field interlaced-tb to yavta.

Enrico

author
#15 lore raw

Am 31.07.2014 15:15, schrieb Enrico:

Quoted 1 line

It seems you are missing this: media-ctl --set-format '"OMAP3 ISP CCDC":1 [UYVY 720x480 field:interlaced-tb]' and add --field interlaced-tb to yavta. Enrico

Yippieh! It seems to work now - At least I am getting an file... If it is a "nice image" will be determined tomorrow!

Thank you for the help,
Michael