All of lore.kernel.org
 help / color / mirror / Atom feed
* Getting started with OMAP3 ISP
@ 2011-08-25 16:07 Gary Thomas
  2011-08-29 10:49 ` Laurent Pinchart
  0 siblings, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-08-25 16:07 UTC (permalink / raw)
  To: linux-media

Background:  I have working video capture drivers based on the
TI PSP codebase from 2.6.32.  In particular, I managed to get
a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver
working with the rewritten ISP code.  Sadly, I'm having a hard
time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works
with the OMAP3 ISP code.  I've updated it to use my decoder device,
but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
   * udev doesn't create any video devices although they have been
     registered.  I see a full set in /sys/class/video4linux
        # ls /sys/class/video4linux/
        v4l-subdev0  v4l-subdev3  v4l-subdev6  video1       video4
        v4l-subdev1  v4l-subdev4  v4l-subdev7  video2       video5
        v4l-subdev2  v4l-subdev5  video0       video3       video6

     Indeed, if I create /dev/videoX by hand, I can get somewhere, but
     I don't really understand how this is supposed to work.  e.g.
       # v4l2-dbg --info /dev/video3
       Driver info:
           Driver name   : ispvideo
           Card type     : OMAP3 ISP CCP2 input
           Bus info      : media
           Driver version: 1
           Capabilities  : 0x04000002
                   Video Output
                   Streaming

   * If I try to grab video, the ISP layer gets a ton of warnings, but
     I never see it call down into my driver, e.g. to check the current
     format, etc.  I have some of my own code from before which fails
     miserably (not a big surprise given the hack level of those programs).
     I tried something off-the-shelf which also fails pretty bad:
       # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2 junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning
much about what might be wrong.

Can someone give me some ideas/guidance, please?

Thanks

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-25 16:07 Getting started with OMAP3 ISP Gary Thomas
@ 2011-08-29 10:49 ` Laurent Pinchart
  2011-08-30 14:08   ` Gary Thomas
  2011-08-30 22:45   ` Gary Thomas
  0 siblings, 2 replies; 45+ messages in thread
From: Laurent Pinchart @ 2011-08-29 10:49 UTC (permalink / raw)
  To: Gary Thomas; +Cc: linux-media

Hi Gary,

On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
> Background:  I have working video capture drivers based on the
> TI PSP codebase from 2.6.32.  In particular, I managed to get
> a driver for the TVP5150 (analogue BT656) working with that kernel.
> 
> Now I need to update to Linux 3.0, so I'm trying to get a driver
> working with the rewritten ISP code.  Sadly, I'm having a hard
> time with this - probably just missing something basic.
> 
> I've tried to clone the TVP514x driver which says that it works
> with the OMAP3 ISP code.  I've updated it to use my decoder device,
> but I can't even seem to get into that code from user land.
> 
> Here are the problems I've had so far:
>    * udev doesn't create any video devices although they have been
>      registered.  I see a full set in /sys/class/video4linux
>         # ls /sys/class/video4linux/
>         v4l-subdev0  v4l-subdev3  v4l-subdev6  video1       video4
>         v4l-subdev1  v4l-subdev4  v4l-subdev7  video2       video5
>         v4l-subdev2  v4l-subdev5  video0       video3       video6

It looks like a udev issue. I don't think that's related to the kernel 
drivers.

>      Indeed, if I create /dev/videoX by hand, I can get somewhere, but
>      I don't really understand how this is supposed to work.  e.g.
>        # v4l2-dbg --info /dev/video3
>        Driver info:
>            Driver name   : ispvideo
>            Card type     : OMAP3 ISP CCP2 input
>            Bus info      : media
>            Driver version: 1
>            Capabilities  : 0x04000002
>                    Video Output
>                    Streaming
> 
>    * If I try to grab video, the ISP layer gets a ton of warnings, but
>      I never see it call down into my driver, e.g. to check the current
>      format, etc.  I have some of my own code from before which fails
>      miserably (not a big surprise given the hack level of those programs).
>      I tried something off-the-shelf which also fails pretty bad:
>        # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
> junk.mp4
> 
> I've read through Documentation/video4linux/omap3isp.txt without learning
> much about what might be wrong.
> 
> Can someone give me some ideas/guidance, please?

In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and 
then capture video.

Configuring the pipeline is done through the media controller API and the V4L2 
subdev pad-level API. To experiment with those you can use the media-ctl 
command line application available at http://git.ideasonboard.org/?p=media-
ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot 
-Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a 
sensor:

./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP 
CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP 
resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP 
CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP 
resizer":1[YUYV 800x600]'

After configuring your pipeline you will be able to capture video using the 
V4L2 API on the device node at the output of the pipeline.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-29 10:49 ` Laurent Pinchart
@ 2011-08-30 14:08   ` Gary Thomas
  2011-08-30 14:18     ` Gary Thomas
  2011-08-30 22:45   ` Gary Thomas
  1 sibling, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-08-30 14:08 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On 2011-08-29 04:49, Laurent Pinchart wrote:
> Hi Gary,
>
> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
>> Background:  I have working video capture drivers based on the
>> TI PSP codebase from 2.6.32.  In particular, I managed to get
>> a driver for the TVP5150 (analogue BT656) working with that kernel.
>>
>> Now I need to update to Linux 3.0, so I'm trying to get a driver
>> working with the rewritten ISP code.  Sadly, I'm having a hard
>> time with this - probably just missing something basic.
>>
>> I've tried to clone the TVP514x driver which says that it works
>> with the OMAP3 ISP code.  I've updated it to use my decoder device,
>> but I can't even seem to get into that code from user land.
>>
>> Here are the problems I've had so far:
>>     * udev doesn't create any video devices although they have been
>>       registered.  I see a full set in /sys/class/video4linux
>>          # ls /sys/class/video4linux/
>>          v4l-subdev0  v4l-subdev3  v4l-subdev6  video1       video4
>>          v4l-subdev1  v4l-subdev4  v4l-subdev7  video2       video5
>>          v4l-subdev2  v4l-subdev5  video0       video3       video6
>
> It looks like a udev issue. I don't think that's related to the kernel
> drivers.
>
>>       Indeed, if I create /dev/videoX by hand, I can get somewhere, but
>>       I don't really understand how this is supposed to work.  e.g.
>>         # v4l2-dbg --info /dev/video3
>>         Driver info:
>>             Driver name   : ispvideo
>>             Card type     : OMAP3 ISP CCP2 input
>>             Bus info      : media
>>             Driver version: 1
>>             Capabilities  : 0x04000002
>>                     Video Output
>>                     Streaming
>>
>>     * If I try to grab video, the ISP layer gets a ton of warnings, but
>>       I never see it call down into my driver, e.g. to check the current
>>       format, etc.  I have some of my own code from before which fails
>>       miserably (not a big surprise given the hack level of those programs).
>>       I tried something off-the-shelf which also fails pretty bad:
>>         # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
>> junk.mp4
>>
>> I've read through Documentation/video4linux/omap3isp.txt without learning
>> much about what might be wrong.
>>
>> Can someone give me some ideas/guidance, please?
>
> In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and
> then capture video.
>
> Configuring the pipeline is done through the media controller API and the V4L2
> subdev pad-level API. To experiment with those you can use the media-ctl
> command line application available at http://git.ideasonboard.org/?p=media-
> ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot
> -Tps to get a postscript graphical view of your device.
>
> Here's a sample pipeline configuration to capture scaled-down YUV data from a
> sensor:
>
> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
> ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP
> CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP
> resizer":1[YUYV 800x600]'
>
> After configuring your pipeline you will be able to capture video using the
> V4L2 API on the device node at the output of the pipeline.

Thanks for the info.

When I run 'media-ctl -p', I see the various nodes, etc, and they all look
good except that I get lots of messages like this:
   - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
             type V4L2 subdev subtype Unknown
         pad0: Input v4l2_subdev_open: Failed to open subdev device node

When I try to setup my pipeline using something similar to what you provided, the
first step runs and I can see that it does something (some lines on the graph went
from dotted to solid), but I still get errors:
   # media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
   Resetting all links to inactive
   Setting up link 16:0 -> 5:0 [1]
   Setting up link 5:1 -> 6:0 [1]
   # media-ctl -f '"tvp5150m1 2-005c":0[SGRBG12 320x240], "OMAP3 ISP CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]'
   Setting up format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
   v4l2_subdev_open: Failed to open subdev device node
   Unable to set format: No such file or directory (-2)

As far as I can tell, none if this is making any callbacks into my driver.

Any ideas what I might be missing?

Thanks

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 14:08   ` Gary Thomas
@ 2011-08-30 14:18     ` Gary Thomas
  2011-08-30 14:20       ` Laurent Pinchart
  0 siblings, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-08-30 14:18 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On 2011-08-30 08:08, Gary Thomas wrote:
> On 2011-08-29 04:49, Laurent Pinchart wrote:
>> Hi Gary,
>>
>> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
>>> Background: I have working video capture drivers based on the
>>> TI PSP codebase from 2.6.32. In particular, I managed to get
>>> a driver for the TVP5150 (analogue BT656) working with that kernel.
>>>
>>> Now I need to update to Linux 3.0, so I'm trying to get a driver
>>> working with the rewritten ISP code. Sadly, I'm having a hard
>>> time with this - probably just missing something basic.
>>>
>>> I've tried to clone the TVP514x driver which says that it works
>>> with the OMAP3 ISP code. I've updated it to use my decoder device,
>>> but I can't even seem to get into that code from user land.
>>>
>>> Here are the problems I've had so far:
>>> * udev doesn't create any video devices although they have been
>>> registered. I see a full set in /sys/class/video4linux
>>> # ls /sys/class/video4linux/
>>> v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
>>> v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
>>> v4l-subdev2 v4l-subdev5 video0 video3 video6
>>
>> It looks like a udev issue. I don't think that's related to the kernel
>> drivers.
>>
>>> Indeed, if I create /dev/videoX by hand, I can get somewhere, but
>>> I don't really understand how this is supposed to work. e.g.
>>> # v4l2-dbg --info /dev/video3
>>> Driver info:
>>> Driver name : ispvideo
>>> Card type : OMAP3 ISP CCP2 input
>>> Bus info : media
>>> Driver version: 1
>>> Capabilities : 0x04000002
>>> Video Output
>>> Streaming
>>>
>>> * If I try to grab video, the ISP layer gets a ton of warnings, but
>>> I never see it call down into my driver, e.g. to check the current
>>> format, etc. I have some of my own code from before which fails
>>> miserably (not a big surprise given the hack level of those programs).
>>> I tried something off-the-shelf which also fails pretty bad:
>>> # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
>>> junk.mp4
>>>
>>> I've read through Documentation/video4linux/omap3isp.txt without learning
>>> much about what might be wrong.
>>>
>>> Can someone give me some ideas/guidance, please?
>>
>> In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and
>> then capture video.
>>
>> Configuring the pipeline is done through the media controller API and the V4L2
>> subdev pad-level API. To experiment with those you can use the media-ctl
>> command line application available at http://git.ideasonboard.org/?p=media-
>> ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot
>> -Tps to get a postscript graphical view of your device.
>>
>> Here's a sample pipeline configuration to capture scaled-down YUV data from a
>> sensor:
>>
>> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
>> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
>> ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP
>> CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP
>> resizer":1[YUYV 800x600]'
>>
>> After configuring your pipeline you will be able to capture video using the
>> V4L2 API on the device node at the output of the pipeline.
>
> Thanks for the info.
>
> When I run 'media-ctl -p', I see the various nodes, etc, and they all look
> good except that I get lots of messages like this:
> - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
> type V4L2 subdev subtype Unknown
> pad0: Input v4l2_subdev_open: Failed to open subdev device node

Could this be related to my missing [udev] device nodes?

I can see media-ctl get confused and try to open a nonsense device name.  Here's
what I see when I run
   # strace media-ctl -p | grep open
   open("/dev/media0", O_RDWR)             = 3
   open("", O_RDWR)                        = -1 ENOENT (No such file or directory)
   write(1, "\tpad0: Input v4l2_subdev_open: F"..., 66) = 66

>
> When I try to setup my pipeline using something similar to what you provided, the
> first step runs and I can see that it does something (some lines on the graph went
> from dotted to solid), but I still get errors:
> # media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> Resetting all links to inactive
> Setting up link 16:0 -> 5:0 [1]
> Setting up link 5:1 -> 6:0 [1]
> # media-ctl -f '"tvp5150m1 2-005c":0[SGRBG12 320x240], "OMAP3 ISP CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]'
> Setting up format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
> v4l2_subdev_open: Failed to open subdev device node
> Unable to set format: No such file or directory (-2)
>
> As far as I can tell, none if this is making any callbacks into my driver.
>
> Any ideas what I might be missing?
>
> Thanks
>

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 14:18     ` Gary Thomas
@ 2011-08-30 14:20       ` Laurent Pinchart
  2011-08-30 14:56         ` Gary Thomas
  0 siblings, 1 reply; 45+ messages in thread
From: Laurent Pinchart @ 2011-08-30 14:20 UTC (permalink / raw)
  To: Gary Thomas; +Cc: linux-media

Hi Gary,

On Tuesday 30 August 2011 16:18:00 Gary Thomas wrote:
> On 2011-08-30 08:08, Gary Thomas wrote:
> > On 2011-08-29 04:49, Laurent Pinchart wrote:
> >> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
> >>> Background: I have working video capture drivers based on the
> >>> TI PSP codebase from 2.6.32. In particular, I managed to get
> >>> a driver for the TVP5150 (analogue BT656) working with that kernel.
> >>> 
> >>> Now I need to update to Linux 3.0, so I'm trying to get a driver
> >>> working with the rewritten ISP code. Sadly, I'm having a hard
> >>> time with this - probably just missing something basic.
> >>> 
> >>> I've tried to clone the TVP514x driver which says that it works
> >>> with the OMAP3 ISP code. I've updated it to use my decoder device,
> >>> but I can't even seem to get into that code from user land.
> >>> 
> >>> Here are the problems I've had so far:
> >>> * udev doesn't create any video devices although they have been
> >>> registered. I see a full set in /sys/class/video4linux
> >>> # ls /sys/class/video4linux/
> >>> v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
> >>> v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
> >>> v4l-subdev2 v4l-subdev5 video0 video3 video6
> >> 
> >> It looks like a udev issue. I don't think that's related to the kernel
> >> drivers.
> >> 
> >>> Indeed, if I create /dev/videoX by hand, I can get somewhere, but
> >>> I don't really understand how this is supposed to work. e.g.
> >>> # v4l2-dbg --info /dev/video3
> >>> Driver info:
> >>> Driver name : ispvideo
> >>> Card type : OMAP3 ISP CCP2 input
> >>> Bus info : media
> >>> Driver version: 1
> >>> Capabilities : 0x04000002
> >>> Video Output
> >>> Streaming
> >>> 
> >>> * If I try to grab video, the ISP layer gets a ton of warnings, but
> >>> I never see it call down into my driver, e.g. to check the current
> >>> format, etc. I have some of my own code from before which fails
> >>> miserably (not a big surprise given the hack level of those programs).
> >>> I tried something off-the-shelf which also fails pretty bad:
> >>> # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
> >>> junk.mp4
> >>> 
> >>> I've read through Documentation/video4linux/omap3isp.txt without
> >>> learning much about what might be wrong.
> >>> 
> >>> Can someone give me some ideas/guidance, please?
> >> 
> >> In a nutshell, you will first have to configure the OMAP3 ISP pipeline,
> >> and then capture video.
> >> 
> >> Configuring the pipeline is done through the media controller API and
> >> the V4L2 subdev pad-level API. To experiment with those you can use the
> >> media-ctl command line application available at
> >> http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it
> >> with --print-dot and pipe the result to dot -Tps to get a postscript
> >> graphical view of your device.
> >> 
> >> Here's a sample pipeline configuration to capture scaled-down YUV data
> >> from a sensor:
> >> 
> >> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> >> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
> >> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
> >> ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP
> >> CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3
> >> ISP resizer":1[YUYV 800x600]'
> >> 
> >> After configuring your pipeline you will be able to capture video using
> >> the V4L2 API on the device node at the output of the pipeline.
> > 
> > Thanks for the info.
> > 
> > When I run 'media-ctl -p', I see the various nodes, etc, and they all
> > look good except that I get lots of messages like this:
> > - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
> > type V4L2 subdev subtype Unknown
> > pad0: Input v4l2_subdev_open: Failed to open subdev device node
> 
> Could this be related to my missing [udev] device nodes?

It could be. You need the /dev/video* and /dev/v4l-subdev* device nodes.

> I can see media-ctl get confused and try to open a nonsense device name. 
> Here's what I see when I run
>    # strace media-ctl -p | grep open
>    open("/dev/media0", O_RDWR)             = 3
>    open("", O_RDWR)                        = -1 ENOENT (No such file or
> directory) write(1, "\tpad0: Input v4l2_subdev_open: F"..., 66) = 66
> 
> > When I try to setup my pipeline using something similar to what you
> > provided, the first step runs and I can see that it does something (some
> > lines on the graph went from dotted to solid), but I still get errors:
> > # media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3
> > ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to
> > inactive
> > Setting up link 16:0 -> 5:0 [1]
> > Setting up link 5:1 -> 6:0 [1]
> > # media-ctl -f '"tvp5150m1 2-005c":0[SGRBG12 320x240], "OMAP3 ISP
> > CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' Setting up
> > format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
> > v4l2_subdev_open: Failed to open subdev device node
> > Unable to set format: No such file or directory (-2)
> > 
> > As far as I can tell, none if this is making any callbacks into my
> > driver.
> > 
> > Any ideas what I might be missing?
> > 
> > Thanks

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 14:20       ` Laurent Pinchart
@ 2011-08-30 14:56         ` Gary Thomas
  2011-08-30 15:48           ` Laurent Pinchart
  2011-08-30 16:07           ` Enrico
  0 siblings, 2 replies; 45+ messages in thread
From: Gary Thomas @ 2011-08-30 14:56 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On 2011-08-30 08:20, Laurent Pinchart wrote:
> Hi Gary,
>
> On Tuesday 30 August 2011 16:18:00 Gary Thomas wrote:
>> On 2011-08-30 08:08, Gary Thomas wrote:
>>> On 2011-08-29 04:49, Laurent Pinchart wrote:
>>>> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
>>>>> Background: I have working video capture drivers based on the
>>>>> TI PSP codebase from 2.6.32. In particular, I managed to get
>>>>> a driver for the TVP5150 (analogue BT656) working with that kernel.
>>>>>
>>>>> Now I need to update to Linux 3.0, so I'm trying to get a driver
>>>>> working with the rewritten ISP code. Sadly, I'm having a hard
>>>>> time with this - probably just missing something basic.
>>>>>
>>>>> I've tried to clone the TVP514x driver which says that it works
>>>>> with the OMAP3 ISP code. I've updated it to use my decoder device,
>>>>> but I can't even seem to get into that code from user land.
>>>>>
>>>>> Here are the problems I've had so far:
>>>>> * udev doesn't create any video devices although they have been
>>>>> registered. I see a full set in /sys/class/video4linux
>>>>> # ls /sys/class/video4linux/
>>>>> v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
>>>>> v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
>>>>> v4l-subdev2 v4l-subdev5 video0 video3 video6
>>>>
>>>> It looks like a udev issue. I don't think that's related to the kernel
>>>> drivers.
>>>>
>>>>> Indeed, if I create /dev/videoX by hand, I can get somewhere, but
>>>>> I don't really understand how this is supposed to work. e.g.
>>>>> # v4l2-dbg --info /dev/video3
>>>>> Driver info:
>>>>> Driver name : ispvideo
>>>>> Card type : OMAP3 ISP CCP2 input
>>>>> Bus info : media
>>>>> Driver version: 1
>>>>> Capabilities : 0x04000002
>>>>> Video Output
>>>>> Streaming
>>>>>
>>>>> * If I try to grab video, the ISP layer gets a ton of warnings, but
>>>>> I never see it call down into my driver, e.g. to check the current
>>>>> format, etc. I have some of my own code from before which fails
>>>>> miserably (not a big surprise given the hack level of those programs).
>>>>> I tried something off-the-shelf which also fails pretty bad:
>>>>> # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
>>>>> junk.mp4
>>>>>
>>>>> I've read through Documentation/video4linux/omap3isp.txt without
>>>>> learning much about what might be wrong.
>>>>>
>>>>> Can someone give me some ideas/guidance, please?
>>>>
>>>> In a nutshell, you will first have to configure the OMAP3 ISP pipeline,
>>>> and then capture video.
>>>>
>>>> Configuring the pipeline is done through the media controller API and
>>>> the V4L2 subdev pad-level API. To experiment with those you can use the
>>>> media-ctl command line application available at
>>>> http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it
>>>> with --print-dot and pipe the result to dot -Tps to get a postscript
>>>> graphical view of your device.
>>>>
>>>> Here's a sample pipeline configuration to capture scaled-down YUV data
>>>> from a sensor:
>>>>
>>>> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>>>> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
>>>> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
>>>> ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP
>>>> CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3
>>>> ISP resizer":1[YUYV 800x600]'
>>>>
>>>> After configuring your pipeline you will be able to capture video using
>>>> the V4L2 API on the device node at the output of the pipeline.
>>>
>>> Thanks for the info.
>>>
>>> When I run 'media-ctl -p', I see the various nodes, etc, and they all
>>> look good except that I get lots of messages like this:
>>> - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
>>> type V4L2 subdev subtype Unknown
>>> pad0: Input v4l2_subdev_open: Failed to open subdev device node
>>
>> Could this be related to my missing [udev] device nodes?
>
> It could be. You need the /dev/video* and /dev/v4l-subdev* device nodes.

Yes, that helped a lot.  When I create the devices by hand, I can now see
my driver starting to be accessed (right now it's very much an empty stub)

Any ideas why udev (version 164) is not making these nodes automatically?

>
>> I can see media-ctl get confused and try to open a nonsense device name.
>> Here's what I see when I run
>>     # strace media-ctl -p | grep open
>>     open("/dev/media0", O_RDWR)             = 3
>>     open("", O_RDWR)                        = -1 ENOENT (No such file or
>> directory) write(1, "\tpad0: Input v4l2_subdev_open: F"..., 66) = 66
>>
>>> When I try to setup my pipeline using something similar to what you
>>> provided, the first step runs and I can see that it does something (some
>>> lines on the graph went from dotted to solid), but I still get errors:
>>> # media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to
>>> inactive
>>> Setting up link 16:0 ->  5:0 [1]
>>> Setting up link 5:1 ->  6:0 [1]
>>> # media-ctl -f '"tvp5150m1 2-005c":0[SGRBG12 320x240], "OMAP3 ISP
>>> CCDC":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' Setting up
>>> format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
>>> v4l2_subdev_open: Failed to open subdev device node
>>> Unable to set format: No such file or directory (-2)
>>>
>>> As far as I can tell, none if this is making any callbacks into my
>>> driver.
>>>
>>> Any ideas what I might be missing?
>>>
>>> Thanks
>

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 14:56         ` Gary Thomas
@ 2011-08-30 15:48           ` Laurent Pinchart
  2011-08-30 16:07           ` Enrico
  1 sibling, 0 replies; 45+ messages in thread
From: Laurent Pinchart @ 2011-08-30 15:48 UTC (permalink / raw)
  To: Gary Thomas; +Cc: linux-media

Hi Gary,

On Tuesday 30 August 2011 16:56:11 Gary Thomas wrote:
> On 2011-08-30 08:20, Laurent Pinchart wrote:
> > On Tuesday 30 August 2011 16:18:00 Gary Thomas wrote:
> >> On 2011-08-30 08:08, Gary Thomas wrote:

[snip]

> >>> When I run 'media-ctl -p', I see the various nodes, etc, and they all
> >>> look good except that I get lots of messages like this:
> >>> - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
> >>> type V4L2 subdev subtype Unknown
> >>> pad0: Input v4l2_subdev_open: Failed to open subdev device node
> >> 
> >> Could this be related to my missing [udev] device nodes?
> > 
> > It could be. You need the /dev/video* and /dev/v4l-subdev* device nodes.
> 
> Yes, that helped a lot.  When I create the devices by hand, I can now see
> my driver starting to be accessed (right now it's very much an empty stub)
> 
> Any ideas why udev (version 164) is not making these nodes automatically?

I'm sorry, I don't. You're not the first person to report this though. It 
would be nice if you could explain how you solved the issue when you'll find 
the solution.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 14:56         ` Gary Thomas
  2011-08-30 15:48           ` Laurent Pinchart
@ 2011-08-30 16:07           ` Enrico
  2011-08-30 16:23             ` Gary Thomas
  1 sibling, 1 reply; 45+ messages in thread
From: Enrico @ 2011-08-30 16:07 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Laurent Pinchart, linux-media

On Tue, Aug 30, 2011 at 4:56 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> Yes, that helped a lot.  When I create the devices by hand, I can now see
> my driver starting to be accessed (right now it's very much an empty stub)

>From your logs it seems you are using a tvp5150, i've posted a patch
[1] for tvp5150 that makes it very close to work, it could be faster
to debug it instead of starting from scratch.

Enrico

[1] http://www.spinics.net/lists/linux-media/msg37116.html

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 16:07           ` Enrico
@ 2011-08-30 16:23             ` Gary Thomas
  2011-08-30 16:36               ` Enrico
  2011-08-30 21:19               ` Sakari Ailus
  0 siblings, 2 replies; 45+ messages in thread
From: Gary Thomas @ 2011-08-30 16:23 UTC (permalink / raw)
  To: Enrico; +Cc: Laurent Pinchart, linux-media

On 2011-08-30 10:07, Enrico wrote:
> On Tue, Aug 30, 2011 at 4:56 PM, Gary Thomas<gary@mlbassoc.com>  wrote:
>> Yes, that helped a lot.  When I create the devices by hand, I can now see
>> my driver starting to be accessed (right now it's very much an empty stub)
>
>> From your logs it seems you are using a tvp5150, i've posted a patch
> [1] for tvp5150 that makes it very close to work, it could be faster
> to debug it instead of starting from scratch.
>
> Enrico
>
> [1] http://www.spinics.net/lists/linux-media/msg37116.html

Thanks, I'll give it a look.

Your note says that /dev/video* is properly registered.  Does this
mean that udev created them for you on boot as well?  If so, what
version of udev are you using?  What's your root file system setup?
n.b. I'm using an OpenEmbedded variant, Poky

Thanks

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 16:23             ` Gary Thomas
@ 2011-08-30 16:36               ` Enrico
  2011-08-30 16:48                 ` Gary Thomas
  2011-08-30 21:19               ` Sakari Ailus
  1 sibling, 1 reply; 45+ messages in thread
From: Enrico @ 2011-08-30 16:36 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Laurent Pinchart, linux-media

On Tue, Aug 30, 2011 at 6:23 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> Thanks, I'll give it a look.
>
> Your note says that /dev/video* is properly registered.  Does this
> mean that udev created them for you on boot as well?  If so, what
> version of udev are you using?  What's your root file system setup?
> n.b. I'm using an OpenEmbedded variant, Poky

They are not created on boot but when i modprobe omap3-isp (and
tvp5150 gets automatically loaded).

Udev is version 173 and i'm using Angstrom, an OpenEmbedded (core) variant too.

Anyway when developing the patch it happened to me too that i had
those subdev open errors, but if i remember correctly only for tvp5150
so it was something wrong in my code.

And if i continue to remember correctly it was because you had to set
the V4L2_SUBDEV_FL_HAS_DEVNODE after calling v4l2_i2c_subdev_init.
Seems nonsense but this is what i remember, actually this is what the
mt9v032 driver does.

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 16:36               ` Enrico
@ 2011-08-30 16:48                 ` Gary Thomas
  0 siblings, 0 replies; 45+ messages in thread
From: Gary Thomas @ 2011-08-30 16:48 UTC (permalink / raw)
  To: Enrico; +Cc: Laurent Pinchart, linux-media

On 2011-08-30 10:36, Enrico wrote:
> On Tue, Aug 30, 2011 at 6:23 PM, Gary Thomas<gary@mlbassoc.com>  wrote:
>> Thanks, I'll give it a look.
>>
>> Your note says that /dev/video* is properly registered.  Does this
>> mean that udev created them for you on boot as well?  If so, what
>> version of udev are you using?  What's your root file system setup?
>> n.b. I'm using an OpenEmbedded variant, Poky
>
> They are not created on boot but when i modprobe omap3-isp (and
> tvp5150 gets automatically loaded).
>
> Udev is version 173 and i'm using Angstrom, an OpenEmbedded (core) variant too.
>
> Anyway when developing the patch it happened to me too that i had
> those subdev open errors, but if i remember correctly only for tvp5150
> so it was something wrong in my code.
>
> And if i continue to remember correctly it was because you had to set
> the V4L2_SUBDEV_FL_HAS_DEVNODE after calling v4l2_i2c_subdev_init.
> Seems nonsense but this is what i remember, actually this is what the
> mt9v032 driver does.

Yes, without that setting, the tvp device doesn't register a proper v4l_subdev node.

I'm getting the devices created, i.e. they exist in /sys, but just
not in /dev.  I'll see if I can run a new udev - maybe that will fix it.

Thanks

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 16:23             ` Gary Thomas
  2011-08-30 16:36               ` Enrico
@ 2011-08-30 21:19               ` Sakari Ailus
  1 sibling, 0 replies; 45+ messages in thread
From: Sakari Ailus @ 2011-08-30 21:19 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Enrico, Laurent Pinchart, linux-media

On Tue, Aug 30, 2011 at 10:23:05AM -0600, Gary Thomas wrote:
> On 2011-08-30 10:07, Enrico wrote:
> >On Tue, Aug 30, 2011 at 4:56 PM, Gary Thomas<gary@mlbassoc.com>  wrote:
> >>Yes, that helped a lot.  When I create the devices by hand, I can now see
> >>my driver starting to be accessed (right now it's very much an empty stub)
> >
> >>From your logs it seems you are using a tvp5150, i've posted a patch
> >[1] for tvp5150 that makes it very close to work, it could be faster
> >to debug it instead of starting from scratch.
> >
> >Enrico
> >
> >[1] http://www.spinics.net/lists/linux-media/msg37116.html
> 
> Thanks, I'll give it a look.
> 
> Your note says that /dev/video* is properly registered.  Does this
> mean that udev created them for you on boot as well?  If so, what

No. This message means that the device has been registered to the kernel (
it is accessbile through a major/minor number pair). Device node referring
to the major/minor pair is separately created by udev.

-- 
Sakari Ailus
sakari.ailus@iki.fi

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-29 10:49 ` Laurent Pinchart
  2011-08-30 14:08   ` Gary Thomas
@ 2011-08-30 22:45   ` Gary Thomas
  2011-08-30 22:50     ` Laurent Pinchart
  1 sibling, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-08-30 22:45 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On 2011-08-29 04:49, Laurent Pinchart wrote:
> Hi Gary,
>
> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
>> Background:  I have working video capture drivers based on the
>> TI PSP codebase from 2.6.32.  In particular, I managed to get
>> a driver for the TVP5150 (analogue BT656) working with that kernel.
>>
>> Now I need to update to Linux 3.0, so I'm trying to get a driver
>> working with the rewritten ISP code.  Sadly, I'm having a hard
>> time with this - probably just missing something basic.
>>
>> I've tried to clone the TVP514x driver which says that it works
>> with the OMAP3 ISP code.  I've updated it to use my decoder device,
>> but I can't even seem to get into that code from user land.
>>
>> Here are the problems I've had so far:
>>     * udev doesn't create any video devices although they have been
>>       registered.  I see a full set in /sys/class/video4linux
>>          # ls /sys/class/video4linux/
>>          v4l-subdev0  v4l-subdev3  v4l-subdev6  video1       video4
>>          v4l-subdev1  v4l-subdev4  v4l-subdev7  video2       video5
>>          v4l-subdev2  v4l-subdev5  video0       video3       video6
>
> It looks like a udev issue. I don't think that's related to the kernel
> drivers.
>
>>       Indeed, if I create /dev/videoX by hand, I can get somewhere, but
>>       I don't really understand how this is supposed to work.  e.g.
>>         # v4l2-dbg --info /dev/video3
>>         Driver info:
>>             Driver name   : ispvideo
>>             Card type     : OMAP3 ISP CCP2 input
>>             Bus info      : media
>>             Driver version: 1
>>             Capabilities  : 0x04000002
>>                     Video Output
>>                     Streaming
>>
>>     * If I try to grab video, the ISP layer gets a ton of warnings, but
>>       I never see it call down into my driver, e.g. to check the current
>>       format, etc.  I have some of my own code from before which fails
>>       miserably (not a big surprise given the hack level of those programs).
>>       I tried something off-the-shelf which also fails pretty bad:
>>         # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
>> junk.mp4
>>
>> I've read through Documentation/video4linux/omap3isp.txt without learning
>> much about what might be wrong.
>>
>> Can someone give me some ideas/guidance, please?
>
> In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and
> then capture video.
>
> Configuring the pipeline is done through the media controller API and the V4L2
> subdev pad-level API. To experiment with those you can use the media-ctl
> command line application available at http://git.ideasonboard.org/?p=media-
> ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot
> -Tps to get a postscript graphical view of your device.
>
> Here's a sample pipeline configuration to capture scaled-down YUV data from a
> sensor:
>
> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
> ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP
> CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP
> resizer":1[YUYV 800x600]'
>
> After configuring your pipeline you will be able to capture video using the
> V4L2 API on the device node at the output of the pipeline.

Getting somewhere now, thanks.  When I use this full pipeline, I can get all
the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline?  For example, I'd normally be
happy with just the CCDC output.  How would I do that?  What pixel format
would I use with ffmpeg?

n.b. I know most of these are pretty n00b questions - I'd look up the
answers for myself, but I've had precious little success finding any
documentation, especially on media-ctl and/or the OMAP3 ISP setups.

Thanks again

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 22:45   ` Gary Thomas
@ 2011-08-30 22:50     ` Laurent Pinchart
  2011-08-31  0:07       ` Gary Thomas
  0 siblings, 1 reply; 45+ messages in thread
From: Laurent Pinchart @ 2011-08-30 22:50 UTC (permalink / raw)
  To: Gary Thomas; +Cc: linux-media

Hi Gary,

On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:
> On 2011-08-29 04:49, Laurent Pinchart wrote:
> > On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
> >> Background:  I have working video capture drivers based on the
> >> TI PSP codebase from 2.6.32.  In particular, I managed to get
> >> a driver for the TVP5150 (analogue BT656) working with that kernel.
> >> 
> >> Now I need to update to Linux 3.0, so I'm trying to get a driver
> >> working with the rewritten ISP code.  Sadly, I'm having a hard
> >> time with this - probably just missing something basic.
> >> 
> >> I've tried to clone the TVP514x driver which says that it works
> >> with the OMAP3 ISP code.  I've updated it to use my decoder device,
> >> but I can't even seem to get into that code from user land.
> >> 
> >> Here are the problems I've had so far:
> >>     * udev doesn't create any video devices although they have been
> >>     
> >>       registered.  I see a full set in /sys/class/video4linux
> >>       
> >>          # ls /sys/class/video4linux/
> >>          v4l-subdev0  v4l-subdev3  v4l-subdev6  video1       video4
> >>          v4l-subdev1  v4l-subdev4  v4l-subdev7  video2       video5
> >>          v4l-subdev2  v4l-subdev5  video0       video3       video6
> > 
> > It looks like a udev issue. I don't think that's related to the kernel
> > drivers.
> > 
> >>       Indeed, if I create /dev/videoX by hand, I can get somewhere, but
> >>       I don't really understand how this is supposed to work.  e.g.
> >>       
> >>         # v4l2-dbg --info /dev/video3
> >>         
> >>         Driver info:
> >>             Driver name   : ispvideo
> >>             Card type     : OMAP3 ISP CCP2 input
> >>             Bus info      : media
> >>             Driver version: 1
> >>             Capabilities  : 0x04000002
> >>             
> >>                     Video Output
> >>                     Streaming
> >>     
> >>     * If I try to grab video, the ISP layer gets a ton of warnings, but
> >>     
> >>       I never see it call down into my driver, e.g. to check the current
> >>       format, etc.  I have some of my own code from before which fails
> >>       miserably (not a big surprise given the hack level of those
> >>       programs).
> >>       
> >>       I tried something off-the-shelf which also fails pretty bad:
> >>         # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
> >> 
> >> junk.mp4
> >> 
> >> I've read through Documentation/video4linux/omap3isp.txt without
> >> learning much about what might be wrong.
> >> 
> >> Can someone give me some ideas/guidance, please?
> > 
> > In a nutshell, you will first have to configure the OMAP3 ISP pipeline,
> > and then capture video.
> > 
> > Configuring the pipeline is done through the media controller API and the
> > V4L2 subdev pad-level API. To experiment with those you can use the
> > media-ctl command line application available at
> > http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it
> > with --print-dot and pipe the result to dot -Tps to get a postscript
> > graphical view of your device.
> > 
> > Here's a sample pipeline configuration to capture scaled-down YUV data
> > from a sensor:
> > 
> > ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> > CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
> > resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
> > ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP
> > CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3
> > ISP resizer":1[YUYV 800x600]'
> > 
> > After configuring your pipeline you will be able to capture video using
> > the V4L2 API on the device node at the output of the pipeline.
> 
> Getting somewhere now, thanks.  When I use this full pipeline, I can get
> all the way into my driver where it's trying to start the data.
> 
> What if I want to use less of the pipeline?  For example, I'd normally be
> happy with just the CCDC output.  How would I do that?

Then connect CCDC's pad 1 to the CCDC output video node and capture on that 
video node.

> What pixel format would I use with ffmpeg?

What does your subdev deliver ?

> n.b. I know most of these are pretty n00b questions - I'd look up the
> answers for myself, but I've had precious little success finding any
> documentation, especially on media-ctl and/or the OMAP3 ISP setups.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-30 22:50     ` Laurent Pinchart
@ 2011-08-31  0:07       ` Gary Thomas
  2011-08-31  8:13         ` Laurent Pinchart
  0 siblings, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-08-31  0:07 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On 2011-08-30 16:50, Laurent Pinchart wrote:
> Hi Gary,
>
> On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:
>> On 2011-08-29 04:49, Laurent Pinchart wrote:
>>> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
>>>> Background:  I have working video capture drivers based on the
>>>> TI PSP codebase from 2.6.32.  In particular, I managed to get
>>>> a driver for the TVP5150 (analogue BT656) working with that kernel.
>>>>
>>>> Now I need to update to Linux 3.0, so I'm trying to get a driver
>>>> working with the rewritten ISP code.  Sadly, I'm having a hard
>>>> time with this - probably just missing something basic.
>>>>
>>>> I've tried to clone the TVP514x driver which says that it works
>>>> with the OMAP3 ISP code.  I've updated it to use my decoder device,
>>>> but I can't even seem to get into that code from user land.
>>>>
>>>> Here are the problems I've had so far:
>>>>      * udev doesn't create any video devices although they have been
>>>>
>>>>        registered.  I see a full set in /sys/class/video4linux
>>>>
>>>>           # ls /sys/class/video4linux/
>>>>           v4l-subdev0  v4l-subdev3  v4l-subdev6  video1       video4
>>>>           v4l-subdev1  v4l-subdev4  v4l-subdev7  video2       video5
>>>>           v4l-subdev2  v4l-subdev5  video0       video3       video6
>>>
>>> It looks like a udev issue. I don't think that's related to the kernel
>>> drivers.
>>>
>>>>        Indeed, if I create /dev/videoX by hand, I can get somewhere, but
>>>>        I don't really understand how this is supposed to work.  e.g.
>>>>
>>>>          # v4l2-dbg --info /dev/video3
>>>>
>>>>          Driver info:
>>>>              Driver name   : ispvideo
>>>>              Card type     : OMAP3 ISP CCP2 input
>>>>              Bus info      : media
>>>>              Driver version: 1
>>>>              Capabilities  : 0x04000002
>>>>
>>>>                      Video Output
>>>>                      Streaming
>>>>
>>>>      * If I try to grab video, the ISP layer gets a ton of warnings, but
>>>>
>>>>        I never see it call down into my driver, e.g. to check the current
>>>>        format, etc.  I have some of my own code from before which fails
>>>>        miserably (not a big surprise given the hack level of those
>>>>        programs).
>>>>
>>>>        I tried something off-the-shelf which also fails pretty bad:
>>>>          # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
>>>>
>>>> junk.mp4
>>>>
>>>> I've read through Documentation/video4linux/omap3isp.txt without
>>>> learning much about what might be wrong.
>>>>
>>>> Can someone give me some ideas/guidance, please?
>>>
>>> In a nutshell, you will first have to configure the OMAP3 ISP pipeline,
>>> and then capture video.
>>>
>>> Configuring the pipeline is done through the media controller API and the
>>> V4L2 subdev pad-level API. To experiment with those you can use the
>>> media-ctl command line application available at
>>> http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it
>>> with --print-dot and pipe the result to dot -Tps to get a postscript
>>> graphical view of your device.
>>>
>>> Here's a sample pipeline configuration to capture scaled-down YUV data
>>> from a sensor:
>>>
>>> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>>> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
>>> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
>>> ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP
>>> CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3
>>> ISP resizer":1[YUYV 800x600]'
>>>
>>> After configuring your pipeline you will be able to capture video using
>>> the V4L2 API on the device node at the output of the pipeline.
>>
>> Getting somewhere now, thanks.  When I use this full pipeline, I can get
>> all the way into my driver where it's trying to start the data.
>>
>> What if I want to use less of the pipeline?  For example, I'd normally be
>> happy with just the CCDC output.  How would I do that?
>
> Then connect CCDC's pad 1 to the CCDC output video node and capture on that
> video node.
>
>> What pixel format would I use with ffmpeg?
>
> What does your subdev deliver ?

It's a BT656 encoder - 8-bit UYVY 4:2:2

>
>> n.b. I know most of these are pretty n00b questions - I'd look up the
>> answers for myself, but I've had precious little success finding any
>> documentation, especially on media-ctl and/or the OMAP3 ISP setups.
>

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31  0:07       ` Gary Thomas
@ 2011-08-31  8:13         ` Laurent Pinchart
  2011-08-31 10:56           ` Gary Thomas
  0 siblings, 1 reply; 45+ messages in thread
From: Laurent Pinchart @ 2011-08-31  8:13 UTC (permalink / raw)
  To: Gary Thomas; +Cc: linux-media

Hi Gary,

On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:
> On 2011-08-30 16:50, Laurent Pinchart wrote:
> > On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:
> >> On 2011-08-29 04:49, Laurent Pinchart wrote:
> >>> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
> >>>> Background:  I have working video capture drivers based on the
> >>>> TI PSP codebase from 2.6.32.  In particular, I managed to get
> >>>> a driver for the TVP5150 (analogue BT656) working with that kernel.
> >>>> 
> >>>> Now I need to update to Linux 3.0, so I'm trying to get a driver
> >>>> working with the rewritten ISP code.  Sadly, I'm having a hard
> >>>> time with this - probably just missing something basic.
> >>>> 
> >>>> I've tried to clone the TVP514x driver which says that it works
> >>>> with the OMAP3 ISP code.  I've updated it to use my decoder device,
> >>>> but I can't even seem to get into that code from user land.
> >>>> 
> >>>> Here are the problems I've had so far:
> >>>>      * udev doesn't create any video devices although they have been
> >>>>      
> >>>>        registered.  I see a full set in /sys/class/video4linux
> >>>>        
> >>>>           # ls /sys/class/video4linux/
> >>>>           v4l-subdev0  v4l-subdev3  v4l-subdev6  video1       video4
> >>>>           v4l-subdev1  v4l-subdev4  v4l-subdev7  video2       video5
> >>>>           v4l-subdev2  v4l-subdev5  video0       video3       video6
> >>> 
> >>> It looks like a udev issue. I don't think that's related to the kernel
> >>> drivers.
> >>> 
> >>>>        Indeed, if I create /dev/videoX by hand, I can get somewhere,
> >>>>        but I don't really understand how this is supposed to work. 
> >>>>        e.g.
> >>>>        
> >>>>          # v4l2-dbg --info /dev/video3
> >>>>          
> >>>>          Driver info:
> >>>>              Driver name   : ispvideo
> >>>>              Card type     : OMAP3 ISP CCP2 input
> >>>>              Bus info      : media
> >>>>              Driver version: 1
> >>>>              Capabilities  : 0x04000002
> >>>>              
> >>>>                      Video Output
> >>>>                      Streaming
> >>>>      
> >>>>      * If I try to grab video, the ISP layer gets a ton of warnings,
> >>>>      but
> >>>>      
> >>>>        I never see it call down into my driver, e.g. to check the
> >>>>        current format, etc.  I have some of my own code from before
> >>>>        which fails miserably (not a big surprise given the hack level
> >>>>        of those programs).
> >>>>        
> >>>>        I tried something off-the-shelf which also fails pretty bad:
> >>>>          # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i
> >>>>          /dev/video2
> >>>> 
> >>>> junk.mp4
> >>>> 
> >>>> I've read through Documentation/video4linux/omap3isp.txt without
> >>>> learning much about what might be wrong.
> >>>> 
> >>>> Can someone give me some ideas/guidance, please?
> >>> 
> >>> In a nutshell, you will first have to configure the OMAP3 ISP pipeline,
> >>> and then capture video.
> >>> 
> >>> Configuring the pipeline is done through the media controller API and
> >>> the V4L2 subdev pad-level API. To experiment with those you can use
> >>> the media-ctl command line application available at
> >>> http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it
> >>> with --print-dot and pipe the result to dot -Tps to get a postscript
> >>> graphical view of your device.
> >>> 
> >>> Here's a sample pipeline configuration to capture scaled-down YUV data
> >>> from a sensor:
> >>> 
> >>> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
> >>> ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3
> >>> ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer
> >>> output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768],
> >>> "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV
> >>> 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'
> >>> 
> >>> After configuring your pipeline you will be able to capture video using
> >>> the V4L2 API on the device node at the output of the pipeline.
> >> 
> >> Getting somewhere now, thanks.  When I use this full pipeline, I can get
> >> all the way into my driver where it's trying to start the data.
> >> 
> >> What if I want to use less of the pipeline?  For example, I'd normally
> >> be happy with just the CCDC output.  How would I do that?
> > 
> > Then connect CCDC's pad 1 to the CCDC output video node and capture on
> > that video node.
> > 
> >> What pixel format would I use with ffmpeg?
> > 
> > What does your subdev deliver ?
> 
> It's a BT656 encoder - 8-bit UYVY 4:2:2

Then you will first have to add YUV support to the CCDC. It wouldn't be fun if 
it worked out of the box, would it ? :-)

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31  8:13         ` Laurent Pinchart
@ 2011-08-31 10:56           ` Gary Thomas
  2011-08-31 11:00             ` Laurent Pinchart
  0 siblings, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-08-31 10:56 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On 2011-08-31 02:13, Laurent Pinchart wrote:
> Hi Gary,
>
> On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:
>> On 2011-08-30 16:50, Laurent Pinchart wrote:
>>> On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:
>>>> On 2011-08-29 04:49, Laurent Pinchart wrote:
>>>>> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
>>>>>> Background:  I have working video capture drivers based on the
>>>>>> TI PSP codebase from 2.6.32.  In particular, I managed to get
>>>>>> a driver for the TVP5150 (analogue BT656) working with that kernel.
>>>>>>
>>>>>> Now I need to update to Linux 3.0, so I'm trying to get a driver
>>>>>> working with the rewritten ISP code.  Sadly, I'm having a hard
>>>>>> time with this - probably just missing something basic.
>>>>>>
>>>>>> I've tried to clone the TVP514x driver which says that it works
>>>>>> with the OMAP3 ISP code.  I've updated it to use my decoder device,
>>>>>> but I can't even seem to get into that code from user land.
>>>>>>
>>>>>> Here are the problems I've had so far:
>>>>>>       * udev doesn't create any video devices although they have been
>>>>>>
>>>>>>         registered.  I see a full set in /sys/class/video4linux
>>>>>>
>>>>>>            # ls /sys/class/video4linux/
>>>>>>            v4l-subdev0  v4l-subdev3  v4l-subdev6  video1       video4
>>>>>>            v4l-subdev1  v4l-subdev4  v4l-subdev7  video2       video5
>>>>>>            v4l-subdev2  v4l-subdev5  video0       video3       video6
>>>>>
>>>>> It looks like a udev issue. I don't think that's related to the kernel
>>>>> drivers.
>>>>>
>>>>>>         Indeed, if I create /dev/videoX by hand, I can get somewhere,
>>>>>>         but I don't really understand how this is supposed to work.
>>>>>>         e.g.
>>>>>>
>>>>>>           # v4l2-dbg --info /dev/video3
>>>>>>
>>>>>>           Driver info:
>>>>>>               Driver name   : ispvideo
>>>>>>               Card type     : OMAP3 ISP CCP2 input
>>>>>>               Bus info      : media
>>>>>>               Driver version: 1
>>>>>>               Capabilities  : 0x04000002
>>>>>>
>>>>>>                       Video Output
>>>>>>                       Streaming
>>>>>>
>>>>>>       * If I try to grab video, the ISP layer gets a ton of warnings,
>>>>>>       but
>>>>>>
>>>>>>         I never see it call down into my driver, e.g. to check the
>>>>>>         current format, etc.  I have some of my own code from before
>>>>>>         which fails miserably (not a big surprise given the hack level
>>>>>>         of those programs).
>>>>>>
>>>>>>         I tried something off-the-shelf which also fails pretty bad:
>>>>>>           # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i
>>>>>>           /dev/video2
>>>>>>
>>>>>> junk.mp4
>>>>>>
>>>>>> I've read through Documentation/video4linux/omap3isp.txt without
>>>>>> learning much about what might be wrong.
>>>>>>
>>>>>> Can someone give me some ideas/guidance, please?
>>>>>
>>>>> In a nutshell, you will first have to configure the OMAP3 ISP pipeline,
>>>>> and then capture video.
>>>>>
>>>>> Configuring the pipeline is done through the media controller API and
>>>>> the V4L2 subdev pad-level API. To experiment with those you can use
>>>>> the media-ctl command line application available at
>>>>> http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it
>>>>> with --print-dot and pipe the result to dot -Tps to get a postscript
>>>>> graphical view of your device.
>>>>>
>>>>> Here's a sample pipeline configuration to capture scaled-down YUV data
>>>>> from a sensor:
>>>>>
>>>>> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>>>>> ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3
>>>>> ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer
>>>>> output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768],
>>>>> "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV
>>>>> 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'
>>>>>
>>>>> After configuring your pipeline you will be able to capture video using
>>>>> the V4L2 API on the device node at the output of the pipeline.
>>>>
>>>> Getting somewhere now, thanks.  When I use this full pipeline, I can get
>>>> all the way into my driver where it's trying to start the data.
>>>>
>>>> What if I want to use less of the pipeline?  For example, I'd normally
>>>> be happy with just the CCDC output.  How would I do that?
>>>
>>> Then connect CCDC's pad 1 to the CCDC output video node and capture on
>>> that video node.
>>>
>>>> What pixel format would I use with ffmpeg?
>>>
>>> What does your subdev deliver ?
>>
>> It's a BT656 encoder - 8-bit UYVY 4:2:2
>
> Then you will first have to add YUV support to the CCDC. It wouldn't be fun if
> it worked out of the box, would it ? :-)

So, functionality that was present in 2.6.32 (TI PSP version at least)
is not currently available?

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31 10:56           ` Gary Thomas
@ 2011-08-31 11:00             ` Laurent Pinchart
  2011-08-31 12:01               ` Gary Thomas
  0 siblings, 1 reply; 45+ messages in thread
From: Laurent Pinchart @ 2011-08-31 11:00 UTC (permalink / raw)
  To: Gary Thomas; +Cc: linux-media

Hi Gary,

On Wednesday 31 August 2011 12:56:29 Gary Thomas wrote:
> On 2011-08-31 02:13, Laurent Pinchart wrote:
> > On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:
> >> On 2011-08-30 16:50, Laurent Pinchart wrote:
> >>> On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:
> >>>> On 2011-08-29 04:49, Laurent Pinchart wrote:
> >>>>> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
> >>>>>> Background:  I have working video capture drivers based on the
> >>>>>> TI PSP codebase from 2.6.32.  In particular, I managed to get
> >>>>>> a driver for the TVP5150 (analogue BT656) working with that kernel.
> >>>>>> 
> >>>>>> Now I need to update to Linux 3.0, so I'm trying to get a driver
> >>>>>> working with the rewritten ISP code.  Sadly, I'm having a hard
> >>>>>> time with this - probably just missing something basic.
> >>>>>> 
> >>>>>> I've tried to clone the TVP514x driver which says that it works
> >>>>>> with the OMAP3 ISP code.  I've updated it to use my decoder device,
> >>>>>> but I can't even seem to get into that code from user land.
> >>>>>> 
> >>>>>> Here are the problems I've had so far:
> >>>>>>       * udev doesn't create any video devices although they have
> >>>>>>       been
> >>>>>>       
> >>>>>>         registered.  I see a full set in /sys/class/video4linux
> >>>>>>         
> >>>>>>            # ls /sys/class/video4linux/
> >>>>>>            v4l-subdev0  v4l-subdev3  v4l-subdev6  video1      
> >>>>>>            video4 v4l-subdev1  v4l-subdev4  v4l-subdev7  video2    
> >>>>>>              video5 v4l-subdev2  v4l-subdev5  video0       video3  
> >>>>>>                video6
> >>>>> 
> >>>>> It looks like a udev issue. I don't think that's related to the
> >>>>> kernel drivers.
> >>>>> 
> >>>>>>         Indeed, if I create /dev/videoX by hand, I can get
> >>>>>>         somewhere, but I don't really understand how this is
> >>>>>>         supposed to work. e.g.
> >>>>>>         
> >>>>>>           # v4l2-dbg --info /dev/video3
> >>>>>>           
> >>>>>>           Driver info:
> >>>>>>               Driver name   : ispvideo
> >>>>>>               Card type     : OMAP3 ISP CCP2 input
> >>>>>>               Bus info      : media
> >>>>>>               Driver version: 1
> >>>>>>               Capabilities  : 0x04000002
> >>>>>>               
> >>>>>>                       Video Output
> >>>>>>                       Streaming
> >>>>>>       
> >>>>>>       * If I try to grab video, the ISP layer gets a ton of
> >>>>>>       warnings, but
> >>>>>>       
> >>>>>>         I never see it call down into my driver, e.g. to check the
> >>>>>>         current format, etc.  I have some of my own code from before
> >>>>>>         which fails miserably (not a big surprise given the hack
> >>>>>>         level of those programs).
> >>>>>>         
> >>>>>>         I tried something off-the-shelf which also fails pretty bad:
> >>>>>>           # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i
> >>>>>>           /dev/video2
> >>>>>> 
> >>>>>> junk.mp4
> >>>>>> 
> >>>>>> I've read through Documentation/video4linux/omap3isp.txt without
> >>>>>> learning much about what might be wrong.
> >>>>>> 
> >>>>>> Can someone give me some ideas/guidance, please?
> >>>>> 
> >>>>> In a nutshell, you will first have to configure the OMAP3 ISP
> >>>>> pipeline, and then capture video.
> >>>>> 
> >>>>> Configuring the pipeline is done through the media controller API and
> >>>>> the V4L2 subdev pad-level API. To experiment with those you can use
> >>>>> the media-ctl command line application available at
> >>>>> http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run
> >>>>> it with --print-dot and pipe the result to dot -Tps to get a
> >>>>> postscript graphical view of your device.
> >>>>> 
> >>>>> Here's a sample pipeline configuration to capture scaled-down YUV
> >>>>> data from a sensor:
> >>>>> 
> >>>>> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
> >>>>> ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3
> >>>>> ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer
> >>>>> output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768],
> >>>>> "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV
> >>>>> 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'
> >>>>> 
> >>>>> After configuring your pipeline you will be able to capture video
> >>>>> using the V4L2 API on the device node at the output of the pipeline.
> >>>> 
> >>>> Getting somewhere now, thanks.  When I use this full pipeline, I can
> >>>> get all the way into my driver where it's trying to start the data.
> >>>> 
> >>>> What if I want to use less of the pipeline?  For example, I'd normally
> >>>> be happy with just the CCDC output.  How would I do that?
> >>> 
> >>> Then connect CCDC's pad 1 to the CCDC output video node and capture on
> >>> that video node.
> >>> 
> >>>> What pixel format would I use with ffmpeg?
> >>> 
> >>> What does your subdev deliver ?
> >> 
> >> It's a BT656 encoder - 8-bit UYVY 4:2:2
> > 
> > Then you will first have to add YUV support to the CCDC. It wouldn't be
> > fun if it worked out of the box, would it ? :-)
> 
> So, functionality that was present in 2.6.32 (TI PSP version at least)
> is not currently available?

That's right. You can blame TI for not pushing it to mainline :-)

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31 11:00             ` Laurent Pinchart
@ 2011-08-31 12:01               ` Gary Thomas
  2011-08-31 15:15                 ` Laurent Pinchart
  0 siblings, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-08-31 12:01 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On 2011-08-31 05:00, Laurent Pinchart wrote:
> Hi Gary,
>
> On Wednesday 31 August 2011 12:56:29 Gary Thomas wrote:
>> On 2011-08-31 02:13, Laurent Pinchart wrote:
>>> On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:
>>>> On 2011-08-30 16:50, Laurent Pinchart wrote:
>>>>> On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:
>>>>>> On 2011-08-29 04:49, Laurent Pinchart wrote:
>>>>>>> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
>>>>>>>> Background:  I have working video capture drivers based on the
>>>>>>>> TI PSP codebase from 2.6.32.  In particular, I managed to get
>>>>>>>> a driver for the TVP5150 (analogue BT656) working with that kernel.
>>>>>>>>
>>>>>>>> Now I need to update to Linux 3.0, so I'm trying to get a driver
>>>>>>>> working with the rewritten ISP code.  Sadly, I'm having a hard
>>>>>>>> time with this - probably just missing something basic.
>>>>>>>>
>>>>>>>> I've tried to clone the TVP514x driver which says that it works
>>>>>>>> with the OMAP3 ISP code.  I've updated it to use my decoder device,
>>>>>>>> but I can't even seem to get into that code from user land.
>>>>>>>>
>>>>>>>> Here are the problems I've had so far:
>>>>>>>>        * udev doesn't create any video devices although they have
>>>>>>>>        been
>>>>>>>>
>>>>>>>>          registered.  I see a full set in /sys/class/video4linux
>>>>>>>>
>>>>>>>>             # ls /sys/class/video4linux/
>>>>>>>>             v4l-subdev0  v4l-subdev3  v4l-subdev6  video1
>>>>>>>>             video4 v4l-subdev1  v4l-subdev4  v4l-subdev7  video2
>>>>>>>>               video5 v4l-subdev2  v4l-subdev5  video0       video3
>>>>>>>>                 video6
>>>>>>>
>>>>>>> It looks like a udev issue. I don't think that's related to the
>>>>>>> kernel drivers.
>>>>>>>
>>>>>>>>          Indeed, if I create /dev/videoX by hand, I can get
>>>>>>>>          somewhere, but I don't really understand how this is
>>>>>>>>          supposed to work. e.g.
>>>>>>>>
>>>>>>>>            # v4l2-dbg --info /dev/video3
>>>>>>>>
>>>>>>>>            Driver info:
>>>>>>>>                Driver name   : ispvideo
>>>>>>>>                Card type     : OMAP3 ISP CCP2 input
>>>>>>>>                Bus info      : media
>>>>>>>>                Driver version: 1
>>>>>>>>                Capabilities  : 0x04000002
>>>>>>>>
>>>>>>>>                        Video Output
>>>>>>>>                        Streaming
>>>>>>>>
>>>>>>>>        * If I try to grab video, the ISP layer gets a ton of
>>>>>>>>        warnings, but
>>>>>>>>
>>>>>>>>          I never see it call down into my driver, e.g. to check the
>>>>>>>>          current format, etc.  I have some of my own code from before
>>>>>>>>          which fails miserably (not a big surprise given the hack
>>>>>>>>          level of those programs).
>>>>>>>>
>>>>>>>>          I tried something off-the-shelf which also fails pretty bad:
>>>>>>>>            # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i
>>>>>>>>            /dev/video2
>>>>>>>>
>>>>>>>> junk.mp4
>>>>>>>>
>>>>>>>> I've read through Documentation/video4linux/omap3isp.txt without
>>>>>>>> learning much about what might be wrong.
>>>>>>>>
>>>>>>>> Can someone give me some ideas/guidance, please?
>>>>>>>
>>>>>>> In a nutshell, you will first have to configure the OMAP3 ISP
>>>>>>> pipeline, and then capture video.
>>>>>>>
>>>>>>> Configuring the pipeline is done through the media controller API and
>>>>>>> the V4L2 subdev pad-level API. To experiment with those you can use
>>>>>>> the media-ctl command line application available at
>>>>>>> http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run
>>>>>>> it with --print-dot and pipe the result to dot -Tps to get a
>>>>>>> postscript graphical view of your device.
>>>>>>>
>>>>>>> Here's a sample pipeline configuration to capture scaled-down YUV
>>>>>>> data from a sensor:
>>>>>>>
>>>>>>> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>>>>>>> ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3
>>>>>>> ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer
>>>>>>> output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768],
>>>>>>> "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV
>>>>>>> 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]'
>>>>>>>
>>>>>>> After configuring your pipeline you will be able to capture video
>>>>>>> using the V4L2 API on the device node at the output of the pipeline.
>>>>>>
>>>>>> Getting somewhere now, thanks.  When I use this full pipeline, I can
>>>>>> get all the way into my driver where it's trying to start the data.
>>>>>>
>>>>>> What if I want to use less of the pipeline?  For example, I'd normally
>>>>>> be happy with just the CCDC output.  How would I do that?
>>>>>
>>>>> Then connect CCDC's pad 1 to the CCDC output video node and capture on
>>>>> that video node.
>>>>>
>>>>>> What pixel format would I use with ffmpeg?
>>>>>
>>>>> What does your subdev deliver ?
>>>>
>>>> It's a BT656 encoder - 8-bit UYVY 4:2:2
>>>
>>> Then you will first have to add YUV support to the CCDC. It wouldn't be
>>> fun if it worked out of the box, would it ? :-)
>>
>> So, functionality that was present in 2.6.32 (TI PSP version at least)
>> is not currently available?
>
> That's right. You can blame TI for not pushing it to mainline :-)
>

Is this only important if I want to push data past the CCDC?  In the past, we were
happy with just using the CCDC like a frame grabber which delivered YUV data to memory
[raw data from /dev/videoN]  Is this possible with the CCDC support as is?  The only
discussion I could find about this on this list was in early March 2011 and I think
you implied that it should work. I'm a bit concerned that it won't as the BT656 data
has embedded syncs that the CCDC needs to be set up for.

I saw a reference to 'Add YUV support to CCDC' on 2010-11-15, but no followup.
That work seemed to be for a much older driver and not applicable to the current
work, or am I missing something?

Has there been other discussion on this topic (I didn't see it in onthis list which
I've been quietly monitoring for two years)?  Is the lack of YUV support in CCDC
for this current driver (drivers/media/video/omap3isp) a concious decision, or just
a lack of movement?  Is there someone at TI that I should contact?

I'm just trying to understand what I have to do to move forward on this.  I really
hadn't planned/scheduled a large effort to recreate functionality that we've already
been using for years when we moved to a newer kernel.

That said though I can see that this new driver structure (with the flexible elements
and connections, etc) is a vast improvement on the old, hard-wired stuff.  I only hope
I can figure out how to make it work with my sensor.

Thanks

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31 12:01               ` Gary Thomas
@ 2011-08-31 15:15                 ` Laurent Pinchart
  2011-08-31 15:19                   ` Gary Thomas
  2011-08-31 16:25                   ` Enrico
  0 siblings, 2 replies; 45+ messages in thread
From: Laurent Pinchart @ 2011-08-31 15:15 UTC (permalink / raw)
  To: Gary Thomas; +Cc: linux-media

Hi Gary,

On Wednesday 31 August 2011 14:01:07 Gary Thomas wrote:
> On 2011-08-31 05:00, Laurent Pinchart wrote:
> > On Wednesday 31 August 2011 12:56:29 Gary Thomas wrote:
> >> On 2011-08-31 02:13, Laurent Pinchart wrote:
> >>> On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:
> >>>> On 2011-08-30 16:50, Laurent Pinchart wrote:
> >>>>> On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:
> >>>>>> On 2011-08-29 04:49, Laurent Pinchart wrote:
> >>>>>>> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
> >>>>>>>> Background:  I have working video capture drivers based on the
> >>>>>>>> TI PSP codebase from 2.6.32.  In particular, I managed to get
> >>>>>>>> a driver for the TVP5150 (analogue BT656) working with that
> >>>>>>>> kernel.
> >>>>>>>> 
> >>>>>>>> Now I need to update to Linux 3.0, so I'm trying to get a driver
> >>>>>>>> working with the rewritten ISP code.  Sadly, I'm having a hard
> >>>>>>>> time with this - probably just missing something basic.
> >>>>>>>> 
> >>>>>>>> I've tried to clone the TVP514x driver which says that it works
> >>>>>>>> with the OMAP3 ISP code.  I've updated it to use my decoder
> >>>>>>>> device, but I can't even seem to get into that code from user
> >>>>>>>> land.
> >>>>>>>> 
> >>>>>>>> Here are the problems I've had so far:
> >>>>>>>>        * udev doesn't create any video devices although they have
> >>>>>>>>        been
> >>>>>>>>        
> >>>>>>>>          registered.  I see a full set in /sys/class/video4linux
> >>>>>>>>          
> >>>>>>>>             # ls /sys/class/video4linux/
> >>>>>>>>             v4l-subdev0  v4l-subdev3  v4l-subdev6  video1
> >>>>>>>>             video4 v4l-subdev1  v4l-subdev4  v4l-subdev7  video2
> >>>>>>>>             
> >>>>>>>>               video5 v4l-subdev2  v4l-subdev5  video0       video3
> >>>>>>>>               
> >>>>>>>>                 video6
> >>>>>>> 
> >>>>>>> It looks like a udev issue. I don't think that's related to the
> >>>>>>> kernel drivers.
> >>>>>>> 
> >>>>>>>>          Indeed, if I create /dev/videoX by hand, I can get
> >>>>>>>>          somewhere, but I don't really understand how this is
> >>>>>>>>          supposed to work. e.g.
> >>>>>>>>          
> >>>>>>>>            # v4l2-dbg --info /dev/video3
> >>>>>>>>            
> >>>>>>>>            Driver info:
> >>>>>>>>                Driver name   : ispvideo
> >>>>>>>>                Card type     : OMAP3 ISP CCP2 input
> >>>>>>>>                Bus info      : media
> >>>>>>>>                Driver version: 1
> >>>>>>>>                Capabilities  : 0x04000002
> >>>>>>>>                
> >>>>>>>>                        Video Output
> >>>>>>>>                        Streaming
> >>>>>>>>        
> >>>>>>>>        * If I try to grab video, the ISP layer gets a ton of
> >>>>>>>>        warnings, but
> >>>>>>>>        
> >>>>>>>>          I never see it call down into my driver, e.g. to check
> >>>>>>>>          the current format, etc.  I have some of my own code
> >>>>>>>>          from before which fails miserably (not a big surprise
> >>>>>>>>          given the hack level of those programs).
> >>>>>>>>          
> >>>>>>>>          I tried something off-the-shelf which also fails pretty 
bad:
> >>>>>>>>            # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i
> >>>>>>>>            /dev/video2
> >>>>>>>> 
> >>>>>>>> junk.mp4
> >>>>>>>> 
> >>>>>>>> I've read through Documentation/video4linux/omap3isp.txt without
> >>>>>>>> learning much about what might be wrong.
> >>>>>>>> 
> >>>>>>>> Can someone give me some ideas/guidance, please?
> >>>>>>> 
> >>>>>>> In a nutshell, you will first have to configure the OMAP3 ISP
> >>>>>>> pipeline, and then capture video.
> >>>>>>> 
> >>>>>>> Configuring the pipeline is done through the media controller API
> >>>>>>> and the V4L2 subdev pad-level API. To experiment with those you
> >>>>>>> can use the media-ctl command line application available at
> >>>>>>> http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can
> >>>>>>> run it with --print-dot and pipe the result to dot -Tps to get a
> >>>>>>> postscript graphical view of your device.
> >>>>>>> 
> >>>>>>> Here's a sample pipeline configuration to capture scaled-down YUV
> >>>>>>> data from a sensor:
> >>>>>>> 
> >>>>>>> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1],
> >>>>>>> "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP
> >>>>>>> preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP
> >>>>>>> resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f
> >>>>>>> '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10
> >>>>>>> 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP
> >>>>>>> resizer":1[YUYV 800x600]'
> >>>>>>> 
> >>>>>>> After configuring your pipeline you will be able to capture video
> >>>>>>> using the V4L2 API on the device node at the output of the
> >>>>>>> pipeline.
> >>>>>> 
> >>>>>> Getting somewhere now, thanks.  When I use this full pipeline, I can
> >>>>>> get all the way into my driver where it's trying to start the data.
> >>>>>> 
> >>>>>> What if I want to use less of the pipeline?  For example, I'd
> >>>>>> normally be happy with just the CCDC output.  How would I do that?
> >>>>> 
> >>>>> Then connect CCDC's pad 1 to the CCDC output video node and capture
> >>>>> on that video node.
> >>>>> 
> >>>>>> What pixel format would I use with ffmpeg?
> >>>>> 
> >>>>> What does your subdev deliver ?
> >>>> 
> >>>> It's a BT656 encoder - 8-bit UYVY 4:2:2
> >>> 
> >>> Then you will first have to add YUV support to the CCDC. It wouldn't be
> >>> fun if it worked out of the box, would it ? :-)
> >> 
> >> So, functionality that was present in 2.6.32 (TI PSP version at least)
> >> is not currently available?
> > 
> > That's right. You can blame TI for not pushing it to mainline :-)
> 
> Is this only important if I want to push data past the CCDC?  In the past,
> we were happy with just using the CCDC like a frame grabber which
> delivered YUV data to memory [raw data from /dev/videoN]  Is this possible
> with the CCDC support as is?  The only discussion I could find about this
> on this list was in early March 2011 and I think you implied that it
> should work. I'm a bit concerned that it won't as the BT656 data has
> embedded syncs that the CCDC needs to be set up for.

The CCDC needs to be setup for BT.656 synchronization. That shouldn't be 
difficult.

> I saw a reference to 'Add YUV support to CCDC' on 2010-11-15, but no
> followup. That work seemed to be for a much older driver and not
> applicable to the current work, or am I missing something?

Sergio Aguirre worked on YUV support in the CCDC some time ago. The patch 
didn't make it as-is as some changes were needed, and it hasn't been reworked 
since.

> Has there been other discussion on this topic (I didn't see it in onthis
> list which I've been quietly monitoring for two years)?  Is the lack of
> YUV support in CCDC for this current driver (drivers/media/video/omap3isp)
> a concious decision, or just a lack of movement?

Just a lack of movement. It should not be difficult to implement.

> Is there someone at TI that I should contact?

TI moved to the OMAP4, I'm not sure if there's anyone still working on the 
OMAP3 ISP there.

> I'm just trying to understand what I have to do to move forward on this. I
> really hadn't planned/scheduled a large effort to recreate functionality
> that we've already been using for years when we moved to a newer kernel.

I've just sent three preliminary patches to the list to add YUYV support in 
the OMAP3 ISP CCDC.

> That said though I can see that this new driver structure (with the
> flexible elements and connections, etc) is a vast improvement on the old,
> hard-wired stuff.  I only hope I can figure out how to make it work with
> my sensor.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31 15:15                 ` Laurent Pinchart
@ 2011-08-31 15:19                   ` Gary Thomas
  2011-08-31 16:25                   ` Enrico
  1 sibling, 0 replies; 45+ messages in thread
From: Gary Thomas @ 2011-08-31 15:19 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On 2011-08-31 09:15, Laurent Pinchart wrote:
> Hi Gary,
>
> On Wednesday 31 August 2011 14:01:07 Gary Thomas wrote:
>> On 2011-08-31 05:00, Laurent Pinchart wrote:
>>> On Wednesday 31 August 2011 12:56:29 Gary Thomas wrote:
>>>> On 2011-08-31 02:13, Laurent Pinchart wrote:
>>>>> On Wednesday 31 August 2011 02:07:36 Gary Thomas wrote:
>>>>>> On 2011-08-30 16:50, Laurent Pinchart wrote:
>>>>>>> On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:
>>>>>>>> On 2011-08-29 04:49, Laurent Pinchart wrote:
>>>>>>>>> On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
>>>>>>>>>> Background:  I have working video capture drivers based on the
>>>>>>>>>> TI PSP codebase from 2.6.32.  In particular, I managed to get
>>>>>>>>>> a driver for the TVP5150 (analogue BT656) working with that
>>>>>>>>>> kernel.
>>>>>>>>>>
>>>>>>>>>> Now I need to update to Linux 3.0, so I'm trying to get a driver
>>>>>>>>>> working with the rewritten ISP code.  Sadly, I'm having a hard
>>>>>>>>>> time with this - probably just missing something basic.
>>>>>>>>>>
>>>>>>>>>> I've tried to clone the TVP514x driver which says that it works
>>>>>>>>>> with the OMAP3 ISP code.  I've updated it to use my decoder
>>>>>>>>>> device, but I can't even seem to get into that code from user
>>>>>>>>>> land.
>>>>>>>>>>
>>>>>>>>>> Here are the problems I've had so far:
>>>>>>>>>>         * udev doesn't create any video devices although they have
>>>>>>>>>>         been
>>>>>>>>>>
>>>>>>>>>>           registered.  I see a full set in /sys/class/video4linux
>>>>>>>>>>
>>>>>>>>>>              # ls /sys/class/video4linux/
>>>>>>>>>>              v4l-subdev0  v4l-subdev3  v4l-subdev6  video1
>>>>>>>>>>              video4 v4l-subdev1  v4l-subdev4  v4l-subdev7  video2
>>>>>>>>>>
>>>>>>>>>>                video5 v4l-subdev2  v4l-subdev5  video0       video3
>>>>>>>>>>
>>>>>>>>>>                  video6
>>>>>>>>>
>>>>>>>>> It looks like a udev issue. I don't think that's related to the
>>>>>>>>> kernel drivers.
>>>>>>>>>
>>>>>>>>>>           Indeed, if I create /dev/videoX by hand, I can get
>>>>>>>>>>           somewhere, but I don't really understand how this is
>>>>>>>>>>           supposed to work. e.g.
>>>>>>>>>>
>>>>>>>>>>             # v4l2-dbg --info /dev/video3
>>>>>>>>>>
>>>>>>>>>>             Driver info:
>>>>>>>>>>                 Driver name   : ispvideo
>>>>>>>>>>                 Card type     : OMAP3 ISP CCP2 input
>>>>>>>>>>                 Bus info      : media
>>>>>>>>>>                 Driver version: 1
>>>>>>>>>>                 Capabilities  : 0x04000002
>>>>>>>>>>
>>>>>>>>>>                         Video Output
>>>>>>>>>>                         Streaming
>>>>>>>>>>
>>>>>>>>>>         * If I try to grab video, the ISP layer gets a ton of
>>>>>>>>>>         warnings, but
>>>>>>>>>>
>>>>>>>>>>           I never see it call down into my driver, e.g. to check
>>>>>>>>>>           the current format, etc.  I have some of my own code
>>>>>>>>>>           from before which fails miserably (not a big surprise
>>>>>>>>>>           given the hack level of those programs).
>>>>>>>>>>
>>>>>>>>>>           I tried something off-the-shelf which also fails pretty
> bad:
>>>>>>>>>>             # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i
>>>>>>>>>>             /dev/video2
>>>>>>>>>>
>>>>>>>>>> junk.mp4
>>>>>>>>>>
>>>>>>>>>> I've read through Documentation/video4linux/omap3isp.txt without
>>>>>>>>>> learning much about what might be wrong.
>>>>>>>>>>
>>>>>>>>>> Can someone give me some ideas/guidance, please?
>>>>>>>>>
>>>>>>>>> In a nutshell, you will first have to configure the OMAP3 ISP
>>>>>>>>> pipeline, and then capture video.
>>>>>>>>>
>>>>>>>>> Configuring the pipeline is done through the media controller API
>>>>>>>>> and the V4L2 subdev pad-level API. To experiment with those you
>>>>>>>>> can use the media-ctl command line application available at
>>>>>>>>> http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can
>>>>>>>>> run it with --print-dot and pipe the result to dot -Tps to get a
>>>>>>>>> postscript graphical view of your device.
>>>>>>>>>
>>>>>>>>> Here's a sample pipeline configuration to capture scaled-down YUV
>>>>>>>>> data from a sensor:
>>>>>>>>>
>>>>>>>>> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1],
>>>>>>>>> "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP
>>>>>>>>> preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP
>>>>>>>>> resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f
>>>>>>>>> '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10
>>>>>>>>> 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP
>>>>>>>>> resizer":1[YUYV 800x600]'
>>>>>>>>>
>>>>>>>>> After configuring your pipeline you will be able to capture video
>>>>>>>>> using the V4L2 API on the device node at the output of the
>>>>>>>>> pipeline.
>>>>>>>>
>>>>>>>> Getting somewhere now, thanks.  When I use this full pipeline, I can
>>>>>>>> get all the way into my driver where it's trying to start the data.
>>>>>>>>
>>>>>>>> What if I want to use less of the pipeline?  For example, I'd
>>>>>>>> normally be happy with just the CCDC output.  How would I do that?
>>>>>>>
>>>>>>> Then connect CCDC's pad 1 to the CCDC output video node and capture
>>>>>>> on that video node.
>>>>>>>
>>>>>>>> What pixel format would I use with ffmpeg?
>>>>>>>
>>>>>>> What does your subdev deliver ?
>>>>>>
>>>>>> It's a BT656 encoder - 8-bit UYVY 4:2:2
>>>>>
>>>>> Then you will first have to add YUV support to the CCDC. It wouldn't be
>>>>> fun if it worked out of the box, would it ? :-)
>>>>
>>>> So, functionality that was present in 2.6.32 (TI PSP version at least)
>>>> is not currently available?
>>>
>>> That's right. You can blame TI for not pushing it to mainline :-)
>>
>> Is this only important if I want to push data past the CCDC?  In the past,
>> we were happy with just using the CCDC like a frame grabber which
>> delivered YUV data to memory [raw data from /dev/videoN]  Is this possible
>> with the CCDC support as is?  The only discussion I could find about this
>> on this list was in early March 2011 and I think you implied that it
>> should work. I'm a bit concerned that it won't as the BT656 data has
>> embedded syncs that the CCDC needs to be set up for.
>
> The CCDC needs to be setup for BT.656 synchronization. That shouldn't be
> difficult.
>
>> I saw a reference to 'Add YUV support to CCDC' on 2010-11-15, but no
>> followup. That work seemed to be for a much older driver and not
>> applicable to the current work, or am I missing something?
>
> Sergio Aguirre worked on YUV support in the CCDC some time ago. The patch
> didn't make it as-is as some changes were needed, and it hasn't been reworked
> since.
>
>> Has there been other discussion on this topic (I didn't see it in onthis
>> list which I've been quietly monitoring for two years)?  Is the lack of
>> YUV support in CCDC for this current driver (drivers/media/video/omap3isp)
>> a concious decision, or just a lack of movement?
>
> Just a lack of movement. It should not be difficult to implement.
>
>> Is there someone at TI that I should contact?
>
> TI moved to the OMAP4, I'm not sure if there's anyone still working on the
> OMAP3 ISP there.

Ah the peril of being marketing (not necessarily market) driven.

>
>> I'm just trying to understand what I have to do to move forward on this. I
>> really hadn't planned/scheduled a large effort to recreate functionality
>> that we've already been using for years when we moved to a newer kernel.
>
> I've just sent three preliminary patches to the list to add YUYV support in
> the OMAP3 ISP CCDC.

Thanks!  I'll see if I can work through this (remember my sensor is also
early-days!).

>
>> That said though I can see that this new driver structure (with the
>> flexible elements and connections, etc) is a vast improvement on the old,
>> hard-wired stuff.  I only hope I can figure out how to make it work with
>> my sensor.
>

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31 15:15                 ` Laurent Pinchart
  2011-08-31 15:19                   ` Gary Thomas
@ 2011-08-31 16:25                   ` Enrico
  2011-08-31 16:33                     ` Laurent Pinchart
  1 sibling, 1 reply; 45+ messages in thread
From: Enrico @ 2011-08-31 16:25 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On Wed, Aug 31, 2011 at 5:15 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> I've just sent three preliminary patches to the list to add YUYV support in
> the OMAP3 ISP CCDC.

What tree are those based on?

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31 16:25                   ` Enrico
@ 2011-08-31 16:33                     ` Laurent Pinchart
  2011-08-31 22:34                       ` Gary Thomas
  2011-09-01  9:51                       ` Enrico
  0 siblings, 2 replies; 45+ messages in thread
From: Laurent Pinchart @ 2011-08-31 16:33 UTC (permalink / raw)
  To: Enrico; +Cc: linux-media

Hi Enrico,

On Wednesday 31 August 2011 18:25:28 Enrico wrote:
> On Wed, Aug 31, 2011 at 5:15 PM, Laurent Pinchart wrote:
> > I've just sent three preliminary patches to the list to add YUYV support
> > in the OMAP3 ISP CCDC.
> 
> What tree are those based on?

On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-next (sorry for not mentioning it), but the patch set was missing a 
patch. I've sent a v2.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31 16:33                     ` Laurent Pinchart
@ 2011-08-31 22:34                       ` Gary Thomas
  2011-09-01  8:11                         ` Laurent Pinchart
  2011-09-01  9:51                       ` Enrico
  1 sibling, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-08-31 22:34 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On 2011-08-31 10:33, Laurent Pinchart wrote:
> Hi Enrico,
>
> On Wednesday 31 August 2011 18:25:28 Enrico wrote:
>> On Wed, Aug 31, 2011 at 5:15 PM, Laurent Pinchart wrote:
>>> I've just sent three preliminary patches to the list to add YUYV support
>>> in the OMAP3 ISP CCDC.
>>
>> What tree are those based on?
>
> On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
> omap3isp-next (sorry for not mentioning it), but the patch set was missing a
> patch. I've sent a v2.
>

Sorry to be a pain, but is there an easy way to generate a patchset for this
tree against the vanilla released 3.0 tree?  (that's what my tree is using)

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31 22:34                       ` Gary Thomas
@ 2011-09-01  8:11                         ` Laurent Pinchart
  0 siblings, 0 replies; 45+ messages in thread
From: Laurent Pinchart @ 2011-09-01  8:11 UTC (permalink / raw)
  To: Gary Thomas; +Cc: linux-media

Hi Gary,

On Thursday 01 September 2011 00:34:20 Gary Thomas wrote:
> On 2011-08-31 10:33, Laurent Pinchart wrote:
> > On Wednesday 31 August 2011 18:25:28 Enrico wrote:
> >> On Wed, Aug 31, 2011 at 5:15 PM, Laurent Pinchart wrote:
> >>> I've just sent three preliminary patches to the list to add YUYV
> >>> support in the OMAP3 ISP CCDC.
> >> 
> >> What tree are those based on?
> > 
> > On
> > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
> > omap3isp-next (sorry for not mentioning it), but the patch set was
> > missing a patch. I've sent a v2.
> 
> Sorry to be a pain, but is there an easy way to generate a patchset for
> this tree against the vanilla released 3.0 tree?  (that's what my tree is
> using)

You can apply the 4 YUV patches I've sent to the list only. They won't apply 
cleanly though, you will need to fix them.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-08-31 16:33                     ` Laurent Pinchart
  2011-08-31 22:34                       ` Gary Thomas
@ 2011-09-01  9:51                       ` Enrico
  2011-09-01  9:55                         ` Laurent Pinchart
  2011-09-01 12:50                         ` Gary Thomas
  1 sibling, 2 replies; 45+ messages in thread
From: Enrico @ 2011-09-01  9:51 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media, Gary Thomas, Enric Balletbo i Serra

On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
> omap3isp-next (sorry for not mentioning it), but the patch set was missing a
> patch. I've sent a v2.

Thanks Laurent, i can confirm it is a step forward. With your tree and
patches (and my tvp5150 patch) i made a step forward:

Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
Setting up format UYVY 720x628 on pad tvp5150 2-005c/0
Format set: UYVY 720x628
Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0
Format set: UYVY 720x628

Now the problem is that i can't get a capture with yavta, it blocks on
the VIDIO_DQBUF ioctl. Probably something wrong in my patch.

I tried also to route it through the resizer but nothing changes.

Is it normal that --enum-formats returns this?

Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
- Available formats:
Video format:  (00000000) 0x0 buffer size 0

Thanks,

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01  9:51                       ` Enrico
@ 2011-09-01  9:55                         ` Laurent Pinchart
  2011-09-01 10:24                           ` Enrico
  2011-09-01 12:50                         ` Gary Thomas
  1 sibling, 1 reply; 45+ messages in thread
From: Laurent Pinchart @ 2011-09-01  9:55 UTC (permalink / raw)
  To: Enrico; +Cc: linux-media, Gary Thomas, Enric Balletbo i Serra

Hi Enrico,

On Thursday 01 September 2011 11:51:58 Enrico wrote:
> On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart wrote:
> > On
> > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
> > omap3isp-next (sorry for not mentioning it), but the patch set was
> > missing a patch. I've sent a v2.
> 
> Thanks Laurent, i can confirm it is a step forward. With your tree and
> patches (and my tvp5150 patch) i made a step forward:
> 
> Setting up link 16:0 -> 5:0 [1]
> Setting up link 5:1 -> 6:0 [1]
> Setting up format UYVY 720x628 on pad tvp5150 2-005c/0
> Format set: UYVY 720x628
> Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0
> Format set: UYVY 720x628
> 
> Now the problem is that i can't get a capture with yavta, it blocks on
> the VIDIO_DQBUF ioctl. Probably something wrong in my patch.

Does your tvp5150 generate progressive or interlaced images ?

> I tried also to route it through the resizer but nothing changes.
> 
> Is it normal that --enum-formats returns this?
> 
> Device /dev/video2 opened.
> Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
> - Available formats:
> Video format:  (00000000) 0x0 buffer size 0

Yes that's normal. Format enumeration on video device nodes isn't supported by 
the OMAP3 ISP driver.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01  9:55                         ` Laurent Pinchart
@ 2011-09-01 10:24                           ` Enrico
  2011-09-01 14:12                             ` Enrico
  0 siblings, 1 reply; 45+ messages in thread
From: Enrico @ 2011-09-01 10:24 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media, Gary Thomas, Enric Balletbo i Serra

On Thu, Sep 1, 2011 at 11:55 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Enrico,
>
> On Thursday 01 September 2011 11:51:58 Enrico wrote:
>> On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart wrote:
>> > On
>> > http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
>> > omap3isp-next (sorry for not mentioning it), but the patch set was
>> > missing a patch. I've sent a v2.
>>
>> Thanks Laurent, i can confirm it is a step forward. With your tree and
>> patches (and my tvp5150 patch) i made a step forward:
>>
>> Setting up link 16:0 -> 5:0 [1]
>> Setting up link 5:1 -> 6:0 [1]
>> Setting up format UYVY 720x628 on pad tvp5150 2-005c/0
>> Format set: UYVY 720x628
>> Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0
>> Format set: UYVY 720x628
>>
>> Now the problem is that i can't get a capture with yavta, it blocks on
>> the VIDIO_DQBUF ioctl. Probably something wrong in my patch.
>
> Does your tvp5150 generate progressive or interlaced images ?

In the driver it is setup to decode by default in bt656 mode, so interlaced.

I've read on the omap trm that the isp can deinterlace it setting
properly SDOFST, i just noticed in the register dump this:

omap3isp omap3isp: ###CCDC SDOFST=0x00000000

and maybe this is related too:

omap3isp omap3isp: ###CCDC REC656IF=0x00000000

Moreover i just found this [1] old thread about the same problem, i'm
reading it now.

Enrico

[1]: http://www.spinics.net/lists/linux-media/msg28079.html

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01  9:51                       ` Enrico
  2011-09-01  9:55                         ` Laurent Pinchart
@ 2011-09-01 12:50                         ` Gary Thomas
  2011-09-01 13:26                           ` Laurent Pinchart
  1 sibling, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-09-01 12:50 UTC (permalink / raw)
  To: Enrico; +Cc: Laurent Pinchart, linux-media, Enric Balletbo i Serra

On 2011-09-01 03:51, Enrico wrote:
> On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>  wrote:
>> On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
>> omap3isp-next (sorry for not mentioning it), but the patch set was missing a
>> patch. I've sent a v2.
>
> Thanks Laurent, i can confirm it is a step forward. With your tree and
> patches (and my tvp5150 patch) i made a step forward:
>
> Setting up link 16:0 ->  5:0 [1]
> Setting up link 5:1 ->  6:0 [1]
> Setting up format UYVY 720x628 on pad tvp5150 2-005c/0
> Format set: UYVY 720x628
> Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0
> Format set: UYVY 720x628

I'm at nearly the same point, but I'm getting a couple of strange messages:
# media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
Resetting all links to inactive
Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
# media-ctl -f '"tvp5150m1 2-005c":0[UYVY 720x480], "OMAP3 ISP CCDC":0[UYVY 720x480], "OMAP3 ISP CCDC":1[UYVY 720x480]'
Setting up format UYVY 720x480 on pad tvp5150m1 2-005c/0
Format set: unknown 720x480
Setting up format unknown 720x480 on pad OMAP3 ISP CCDC/0
Format set: unknown 720x480
Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0
Format set: UYVY 720x480
Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/1
Format set: UYVY 720x480

# yavta -f UYVY -s 720x480 -n 6 --capture=6 -F /dev/video2
Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
Video format set: UYVY (59565955) 720x480 buffer size 691200
Video format: UYVY (59565955) 720x480 buffer size 691200
6 buffers requested.
length: 691200 offset: 0
Buffer 0 mapped at address 0x40211000.
length: 691200 offset: 692224
Buffer 1 mapped at address 0x402dc000.
length: 691200 offset: 1384448
Buffer 2 mapped at address 0x4047f000.
length: 691200 offset: 2076672
Buffer 3 mapped at address 0x40614000.
length: 691200 offset: 2768896
Buffer 4 mapped at address 0x40792000.
Buffer 5 mapped at address 0x40854000.
Unable to start streaming: 32.

What does 'Format set: unknown 720x480' mean from media-ctl?
Why 'Unable to start streaming: 32' - is this an EPIPE error?

>
> Now the problem is that i can't get a capture with yavta, it blocks on
> the VIDIO_DQBUF ioctl. Probably something wrong in my patch.
>
> I tried also to route it through the resizer but nothing changes.
>
> Is it normal that --enum-formats returns this?
>
> Device /dev/video2 opened.
> Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
> - Available formats:
> Video format:  (00000000) 0x0 buffer size 0
>
> Thanks,
>
> Enrico

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 12:50                         ` Gary Thomas
@ 2011-09-01 13:26                           ` Laurent Pinchart
  2011-09-01 15:16                             ` Gary Thomas
  0 siblings, 1 reply; 45+ messages in thread
From: Laurent Pinchart @ 2011-09-01 13:26 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Enrico, linux-media, Enric Balletbo i Serra

Hi Gary,

On Thursday 01 September 2011 14:50:59 Gary Thomas wrote:
> On 2011-09-01 03:51, Enrico wrote:
> > On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart wrote:
> >> On
> >> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp
> >> - omap3isp-next (sorry for not mentioning it), but the patch set was
> >> missing a patch. I've sent a v2.
> > 
> > Thanks Laurent, i can confirm it is a step forward. With your tree and
> > patches (and my tvp5150 patch) i made a step forward:
> > 
> > Setting up link 16:0 ->  5:0 [1]
> > Setting up link 5:1 ->  6:0 [1]
> > Setting up format UYVY 720x628 on pad tvp5150 2-005c/0
> > Format set: UYVY 720x628
> > Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0
> > Format set: UYVY 720x628
> 
> I'm at nearly the same point, but I'm getting a couple of strange messages:
> # media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to inactive
> Setting up link 16:0 -> 5:0 [1]
> Setting up link 5:1 -> 6:0 [1]
> # media-ctl -f '"tvp5150m1 2-005c":0[UYVY 720x480], "OMAP3 ISP CCDC":0[UYVY
> 720x480], "OMAP3 ISP CCDC":1[UYVY 720x480]' Setting up format UYVY 720x480
> on pad tvp5150m1 2-005c/0
> Format set: unknown 720x480
> Setting up format unknown 720x480 on pad OMAP3 ISP CCDC/0
> Format set: unknown 720x480
> Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0
> Format set: UYVY 720x480
> Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/1
> Format set: UYVY 720x480
> 
> # yavta -f UYVY -s 720x480 -n 6 --capture=6 -F /dev/video2
> Device /dev/video2 opened.
> Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
> Video format set: UYVY (59565955) 720x480 buffer size 691200
> Video format: UYVY (59565955) 720x480 buffer size 691200
> 6 buffers requested.
> length: 691200 offset: 0
> Buffer 0 mapped at address 0x40211000.
> length: 691200 offset: 692224
> Buffer 1 mapped at address 0x402dc000.
> length: 691200 offset: 1384448
> Buffer 2 mapped at address 0x4047f000.
> length: 691200 offset: 2076672
> Buffer 3 mapped at address 0x40614000.
> length: 691200 offset: 2768896
> Buffer 4 mapped at address 0x40792000.
> Buffer 5 mapped at address 0x40854000.
> Unable to start streaming: 32.
> 
> What does 'Format set: unknown 720x480' mean from media-ctl?

That probably means that media-ctl got compiled against a different media 
controller API version than the one running on your system. Make sure you set 
the --with-kernel-headers= to the path to kernel headers for the kernel 
running on your system.

> Why 'Unable to start streaming: 32' - is this an EPIPE error?

That means the pipeline hasn't been configured properly. Either the pipeline 
is broken, or formats on two ends of a link don't match.

> > Now the problem is that i can't get a capture with yavta, it blocks on
> > the VIDIO_DQBUF ioctl. Probably something wrong in my patch.
> > 
> > I tried also to route it through the resizer but nothing changes.
> > 
> > Is it normal that --enum-formats returns this?
> > 
> > Device /dev/video2 opened.
> > Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
> > - Available formats:
> > Video format:  (00000000) 0x0 buffer size 0

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 10:24                           ` Enrico
@ 2011-09-01 14:12                             ` Enrico
  2011-09-01 14:24                               ` Laurent Pinchart
  0 siblings, 1 reply; 45+ messages in thread
From: Enrico @ 2011-09-01 14:12 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media, Gary Thomas, Enric Balletbo i Serra

On Thu, Sep 1, 2011 at 12:24 PM, Enrico <ebutera@users.berlios.de> wrote:
> On Thu, Sep 1, 2011 at 11:55 AM, Laurent Pinchart
>> Does your tvp5150 generate progressive or interlaced images ?
>
> In the driver it is setup to decode by default in bt656 mode, so interlaced.
>
> I've read on the omap trm that the isp can deinterlace it setting
> properly SDOFST, i just noticed in the register dump this:
>
> omap3isp omap3isp: ###CCDC SDOFST=0x00000000
>
> and maybe this is related too:
>
> omap3isp omap3isp: ###CCDC REC656IF=0x00000000
>
> Moreover i just found this [1] old thread about the same problem, i'm
> reading it now.
>
> Enrico
>
> [1]: http://www.spinics.net/lists/linux-media/msg28079.html

Still not working, and much more doubts :D

1) In board code isp_parallel_platform_data i added the bt656 = 1
setting and i see it gets applied, but reading code and omap trm i've
found that you must set ISPCCDC_REC656IF_ECCFVH flag too.

2) ispccdc.c:ccdc_config_outlineoffset(..) seems broken to me.

It is used only once in ccdc_configure:
ccdc_config_outlineoffset(ccdc, ccdc->video_out.bpl_value, 0, 0);

so the last two parameters are always set to 0, while they should be
(conditionally) set with for ex. EVENODD, 1

Moreover the implementation has this (hope it will keep formatting...):

switch (oddeven) {
        case EVENEVEN:
                isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
                            (numlines & 0x7) << ISPCCDC_SDOFST_LOFST0_SHIFT);
                break;
        case ODDEVEN:
                isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
                            (numlines & 0x7) << ISPCCDC_SDOFST_LOFST1_SHIFT);
                break;
        case EVENODD:
                isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
                            (numlines & 0x7) << ISPCCDC_SDOFST_LOFST2_SHIFT);
                break;
        case ODDODD:
                isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
                            (numlines & 0x7) << ISPCCDC_SDOFST_LOFST3_SHIFT);
                break;
        default:
                break;
        }

But reading the omap trm (Figure 12-77) it seems to me that all the
LOFSTX should be set.

3) Last but not least, i'm using V4L2_MBUS_FMT_UYVY8_1X16 format in
tvp5150, but i'm not sure it is correct. What is the proper format for
bt656? Maybe V4L2_MBUS_FMT_UYVY8_2X8?

Thanks,

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 14:12                             ` Enrico
@ 2011-09-01 14:24                               ` Laurent Pinchart
  0 siblings, 0 replies; 45+ messages in thread
From: Laurent Pinchart @ 2011-09-01 14:24 UTC (permalink / raw)
  To: Enrico; +Cc: linux-media, Gary Thomas, Enric Balletbo i Serra

Hi Enrico,

On Thursday 01 September 2011 16:12:42 Enrico wrote:
> On Thu, Sep 1, 2011 at 12:24 PM, Enrico <ebutera@users.berlios.de> wrote:
> > On Thu, Sep 1, 2011 at 11:55 AM, Laurent Pinchart
> > 
> >> Does your tvp5150 generate progressive or interlaced images ?
> > 
> > In the driver it is setup to decode by default in bt656 mode, so
> > interlaced.
> > 
> > I've read on the omap trm that the isp can deinterlace it setting
> > properly SDOFST, i just noticed in the register dump this:
> > 
> > omap3isp omap3isp: ###CCDC SDOFST=0x00000000
> > 
> > and maybe this is related too:
> > 
> > omap3isp omap3isp: ###CCDC REC656IF=0x00000000
> > 
> > Moreover i just found this [1] old thread about the same problem, i'm
> > reading it now.
> > 
> > Enrico
> > 
> > [1]: http://www.spinics.net/lists/linux-media/msg28079.html
> 
> Still not working, and much more doubts :D
> 
> 1) In board code isp_parallel_platform_data i added the bt656 = 1
> setting and i see it gets applied, but reading code and omap trm i've
> found that you must set ISPCCDC_REC656IF_ECCFVH flag too.

That's not mandatory, but I suppose it wouldn't hurt.

> 2) ispccdc.c:ccdc_config_outlineoffset(..) seems broken to me.
> 
> It is used only once in ccdc_configure:
> ccdc_config_outlineoffset(ccdc, ccdc->video_out.bpl_value, 0, 0);
> 
> so the last two parameters are always set to 0, while they should be
> (conditionally) set with for ex. EVENODD, 1
> 
> Moreover the implementation has this (hope it will keep formatting...):
> 
> switch (oddeven) {
>         case EVENEVEN:
>                 isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
>                             (numlines & 0x7) <<
> ISPCCDC_SDOFST_LOFST0_SHIFT); break;
>         case ODDEVEN:
>                 isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
>                             (numlines & 0x7) <<
> ISPCCDC_SDOFST_LOFST1_SHIFT); break;
>         case EVENODD:
>                 isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
>                             (numlines & 0x7) <<
> ISPCCDC_SDOFST_LOFST2_SHIFT); break;
>         case ODDODD:
>                 isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
>                             (numlines & 0x7) <<
> ISPCCDC_SDOFST_LOFST3_SHIFT); break;
>         default:
>                 break;
>         }
> 
> But reading the omap trm (Figure 12-77) it seems to me that all the
> LOFSTX should be set.

The driver currently has no support for interlaced video. This code has never 
been properly tested.

> 3) Last but not least, i'm using V4L2_MBUS_FMT_UYVY8_1X16 format in
> tvp5150, but i'm not sure it is correct. What is the proper format for
> bt656? Maybe V4L2_MBUS_FMT_UYVY8_2X8?

You should use V4L2_MBUS_FMT_UYVY8_2X8, as video data is transmitted on a 8-
bit bus with two samples per pixel.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 13:26                           ` Laurent Pinchart
@ 2011-09-01 15:16                             ` Gary Thomas
  2011-09-01 16:14                               ` Enrico
  0 siblings, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-09-01 15:16 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: Enrico, linux-media, Enric Balletbo i Serra

On 2011-09-01 07:26, Laurent Pinchart wrote:
> Hi Gary,
>
> On Thursday 01 September 2011 14:50:59 Gary Thomas wrote:
>> On 2011-09-01 03:51, Enrico wrote:
>>> On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart wrote:
>>>> On
>>>> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp
>>>> - omap3isp-next (sorry for not mentioning it), but the patch set was
>>>> missing a patch. I've sent a v2.
>>>
>>> Thanks Laurent, i can confirm it is a step forward. With your tree and
>>> patches (and my tvp5150 patch) i made a step forward:
>>>
>>> Setting up link 16:0 ->   5:0 [1]
>>> Setting up link 5:1 ->   6:0 [1]
>>> Setting up format UYVY 720x628 on pad tvp5150 2-005c/0
>>> Format set: UYVY 720x628
>>> Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0
>>> Format set: UYVY 720x628
>>
>> I'm at nearly the same point, but I'm getting a couple of strange messages:
>> # media-ctl -r -l '"tvp5150m1 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>> CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to inactive
>> Setting up link 16:0 ->  5:0 [1]
>> Setting up link 5:1 ->  6:0 [1]
>> # media-ctl -f '"tvp5150m1 2-005c":0[UYVY 720x480], "OMAP3 ISP CCDC":0[UYVY
>> 720x480], "OMAP3 ISP CCDC":1[UYVY 720x480]' Setting up format UYVY 720x480
>> on pad tvp5150m1 2-005c/0
>> Format set: unknown 720x480
>> Setting up format unknown 720x480 on pad OMAP3 ISP CCDC/0
>> Format set: unknown 720x480
>> Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0
>> Format set: UYVY 720x480
>> Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/1
>> Format set: UYVY 720x480
>>
>> # yavta -f UYVY -s 720x480 -n 6 --capture=6 -F /dev/video2
>> Device /dev/video2 opened.
>> Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
>> Video format set: UYVY (59565955) 720x480 buffer size 691200
>> Video format: UYVY (59565955) 720x480 buffer size 691200
>> 6 buffers requested.
>> length: 691200 offset: 0
>> Buffer 0 mapped at address 0x40211000.
>> length: 691200 offset: 692224
>> Buffer 1 mapped at address 0x402dc000.
>> length: 691200 offset: 1384448
>> Buffer 2 mapped at address 0x4047f000.
>> length: 691200 offset: 2076672
>> Buffer 3 mapped at address 0x40614000.
>> length: 691200 offset: 2768896
>> Buffer 4 mapped at address 0x40792000.
>> Buffer 5 mapped at address 0x40854000.
>> Unable to start streaming: 32.
>>
>> What does 'Format set: unknown 720x480' mean from media-ctl?
>
> That probably means that media-ctl got compiled against a different media
> controller API version than the one running on your system. Make sure you set
> the --with-kernel-headers= to the path to kernel headers for the kernel
> running on your system.

To make sure, I just rebuilt 'media-ctl' against my latest kernel (headers).
I'm using a OpenEmbedded derivative (Yocto) so this is all automatic.
   # bitbake virtual/kernel media-ctl -c cleansstate
   # bitbake virtual/kernel
   # bitbake media-ctl

Sadly, I still get the same error.

>
>> Why 'Unable to start streaming: 32' - is this an EPIPE error?
>
> That means the pipeline hasn't been configured properly. Either the pipeline
> is broken, or formats on two ends of a link don't match.

Probably because of the unknown (above).  Here's what the pertinent nodes say:

- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
             type V4L2 subdev subtype Unknown
             device node name /dev/v4l-subdev2
         pad0: Input [UYVY 720x480]
                 <- 'OMAP3 ISP CCP2':pad1 []
                 <- 'OMAP3 ISP CSI2a':pad1 []
                 <- 'tvp5150m1 2-005c':pad0 [ACTIVE]
         pad1: Output [UYVY 720x480]
                 -> 'OMAP3 ISP CCDC output':pad0 [ACTIVE]
                 -> 'OMAP3 ISP resizer':pad0 []
         pad2: Output [UYVY 720x479]
                 -> 'OMAP3 ISP preview':pad0 []
                 -> 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE]
                 -> 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE]
                 -> 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE]

- entity 16: tvp5150m1 2-005c (1 pad, 1 link)
              type V4L2 subdev subtype Unknown
              device node name /dev/v4l-subdev8
         pad0: Output [unknown 720x480 (1,1)/720x480]
                 -> 'OMAP3 ISP CCDC':pad0 [ACTIVE]

Ideas where to look for the 'unknown' mode?

>>> Now the problem is that i can't get a capture with yavta, it blocks on
>>> the VIDIO_DQBUF ioctl. Probably something wrong in my patch.
>>>
>>> I tried also to route it through the resizer but nothing changes.
>>>
>>> Is it normal that --enum-formats returns this?
>>>
>>> Device /dev/video2 opened.
>>> Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
>>> - Available formats:
>>> Video format:  (00000000) 0x0 buffer size 0
>

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 15:16                             ` Gary Thomas
@ 2011-09-01 16:14                               ` Enrico
  2011-09-01 17:24                                 ` Enrico
  0 siblings, 1 reply; 45+ messages in thread
From: Enrico @ 2011-09-01 16:14 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Laurent Pinchart, linux-media, Enric Balletbo i Serra

On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>
> - entity 16: tvp5150m1 2-005c (1 pad, 1 link)
>             type V4L2 subdev subtype Unknown
>             device node name /dev/v4l-subdev8
>        pad0: Output [unknown 720x480 (1,1)/720x480]
>                -> 'OMAP3 ISP CCDC':pad0 [ACTIVE]
>
> Ideas where to look for the 'unknown' mode?

I didn't notice that, if you are using UYVY8_2X8 the reason is in
media-ctl main.c:

{ "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },

You can add a line like:

{ "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },

recompile and it should work, i'll try it now.

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 16:14                               ` Enrico
@ 2011-09-01 17:24                                 ` Enrico
  2011-09-01 18:14                                   ` Laurent Pinchart
  0 siblings, 1 reply; 45+ messages in thread
From: Enrico @ 2011-09-01 17:24 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: Gary Thomas, linux-media, Enric Balletbo i Serra

On Thu, Sep 1, 2011 at 6:14 PM, Enrico <ebutera@users.berlios.de> wrote:
> On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>
>> - entity 16: tvp5150m1 2-005c (1 pad, 1 link)
>>             type V4L2 subdev subtype Unknown
>>             device node name /dev/v4l-subdev8
>>        pad0: Output [unknown 720x480 (1,1)/720x480]
>>                -> 'OMAP3 ISP CCDC':pad0 [ACTIVE]
>>
>> Ideas where to look for the 'unknown' mode?
>
> I didn't notice that, if you are using UYVY8_2X8 the reason is in
> media-ctl main.c:
>
> { "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },
>
> You can add a line like:
>
> { "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },
>
> recompile and it should work, i'll try it now.

That worked, but now there is another problem.

yavta will set UYVY (PIX_FMT), this will cause a call to
ispvideo.c:isp_video_pix_to_mbus(..), that will do this:

for (i = 0; i < ARRAY_SIZE(formats); ++i) {
                if (formats[i].pixelformat == pix->pixelformat)
                        break;
}

that is it will stop at the first matching array item, and that's:

{ V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
          V4L2_MBUS_FMT_UYVY8_1X16, 0,
          V4L2_PIX_FMT_UYVY, 16, 16, },


but you wanted this:

{ V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,
          V4L2_MBUS_FMT_UYVY8_2X8, 0,
          V4L2_PIX_FMT_UYVY, 8, 16, },

so a better check could be to check for width too, but i don't know if
it's possibile to pass a width requirement or if it's already there in
some struct passed to the function.

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 17:24                                 ` Enrico
@ 2011-09-01 18:14                                   ` Laurent Pinchart
  2011-09-01 18:18                                     ` Gary Thomas
  2011-09-02  9:02                                     ` Enrico
  0 siblings, 2 replies; 45+ messages in thread
From: Laurent Pinchart @ 2011-09-01 18:14 UTC (permalink / raw)
  To: Enrico; +Cc: Gary Thomas, linux-media, Enric Balletbo i Serra

Hi Enrico,

On Thursday 01 September 2011 19:24:54 Enrico wrote:
> On Thu, Sep 1, 2011 at 6:14 PM, Enrico <ebutera@users.berlios.de> wrote:
> > On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> >> - entity 16: tvp5150m1 2-005c (1 pad, 1 link)
> >>             type V4L2 subdev subtype Unknown
> >>             device node name /dev/v4l-subdev8
> >>        pad0: Output [unknown 720x480 (1,1)/720x480]
> >>                -> 'OMAP3 ISP CCDC':pad0 [ACTIVE]
> >> 
> >> Ideas where to look for the 'unknown' mode?
> > 
> > I didn't notice that, if you are using UYVY8_2X8 the reason is in
> > media-ctl main.c:
> > 
> > { "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },
> > 
> > You can add a line like:
> > 
> > { "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },
> > 
> > recompile and it should work, i'll try it now.
> 
> That worked, but now there is another problem.

That's correct. My bad for not spotting it sooner.

> yavta will set UYVY (PIX_FMT), this will cause a call to
> ispvideo.c:isp_video_pix_to_mbus(..), that will do this:
> 
> for (i = 0; i < ARRAY_SIZE(formats); ++i) {
>                 if (formats[i].pixelformat == pix->pixelformat)
>                         break;
> }
> 
> that is it will stop at the first matching array item, and that's:
> 
> { V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
>           V4L2_MBUS_FMT_UYVY8_1X16, 0,
>           V4L2_PIX_FMT_UYVY, 16, 16, },
> 
> 
> but you wanted this:
> 
> { V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,
>           V4L2_MBUS_FMT_UYVY8_2X8, 0,
>           V4L2_PIX_FMT_UYVY, 8, 16, },
> 
> so a better check could be to check for width too, but i don't know if
> it's possibile to pass a width requirement or if it's already there in
> some struct passed to the function.

That's not really an issue, as the isp_video_pix_to_mbus() and 
isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to fill 
the bytesperline and sizeimage fields. From a quick look at the code 
isp_video_check_format() should succeed as well.

Have you run into any specific issue with isp_video_pix_to_mbus() when using 
V4L2_MBUS_FMT_UYVY8_2X8 ?

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 18:14                                   ` Laurent Pinchart
@ 2011-09-01 18:18                                     ` Gary Thomas
  2011-09-02  8:09                                       ` Laurent Pinchart
  2011-09-02  9:02                                     ` Enrico
  1 sibling, 1 reply; 45+ messages in thread
From: Gary Thomas @ 2011-09-01 18:18 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: Enrico, linux-media, Enric Balletbo i Serra

On 2011-09-01 12:14, Laurent Pinchart wrote:
> Hi Enrico,
>
> On Thursday 01 September 2011 19:24:54 Enrico wrote:
>> On Thu, Sep 1, 2011 at 6:14 PM, Enrico<ebutera@users.berlios.de>  wrote:
>>> On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomas<gary@mlbassoc.com>  wrote:
>>>> - entity 16: tvp5150m1 2-005c (1 pad, 1 link)
>>>>              type V4L2 subdev subtype Unknown
>>>>              device node name /dev/v4l-subdev8
>>>>         pad0: Output [unknown 720x480 (1,1)/720x480]
>>>>                 ->  'OMAP3 ISP CCDC':pad0 [ACTIVE]
>>>>
>>>> Ideas where to look for the 'unknown' mode?
>>>
>>> I didn't notice that, if you are using UYVY8_2X8 the reason is in
>>> media-ctl main.c:
>>>
>>> { "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },
>>>
>>> You can add a line like:
>>>
>>> { "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },
>>>
>>> recompile and it should work, i'll try it now.
>>
>> That worked, but now there is another problem.
>
> That's correct. My bad for not spotting it sooner.

Will you be adding this to the media-ctl tree?  Would you like a patch?

>
>> yavta will set UYVY (PIX_FMT), this will cause a call to
>> ispvideo.c:isp_video_pix_to_mbus(..), that will do this:
>>
>> for (i = 0; i<  ARRAY_SIZE(formats); ++i) {
>>                  if (formats[i].pixelformat == pix->pixelformat)
>>                          break;
>> }
>>
>> that is it will stop at the first matching array item, and that's:
>>
>> { V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
>>            V4L2_MBUS_FMT_UYVY8_1X16, 0,
>>            V4L2_PIX_FMT_UYVY, 16, 16, },
>>
>>
>> but you wanted this:
>>
>> { V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,
>>            V4L2_MBUS_FMT_UYVY8_2X8, 0,
>>            V4L2_PIX_FMT_UYVY, 8, 16, },
>>
>> so a better check could be to check for width too, but i don't know if
>> it's possibile to pass a width requirement or if it's already there in
>> some struct passed to the function.
>
> That's not really an issue, as the isp_video_pix_to_mbus() and
> isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to fill
> the bytesperline and sizeimage fields. From a quick look at the code
> isp_video_check_format() should succeed as well.
>
> Have you run into any specific issue with isp_video_pix_to_mbus() when using
> V4L2_MBUS_FMT_UYVY8_2X8 ?
>

Not yet - I was able to configure the pipeline as
   # media-ctl -f '"tvp5150m1 2-005c":0[UYVY2X8 720x480], "OMAP3 ISP CCDC":0[UYVY2X8 720x480], "OMAP3 ISP CCDC":1[UYVY2X8 720x480]'
and this gets me all the way into my driver (which I'm now working on)

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

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 18:18                                     ` Gary Thomas
@ 2011-09-02  8:09                                       ` Laurent Pinchart
  0 siblings, 0 replies; 45+ messages in thread
From: Laurent Pinchart @ 2011-09-02  8:09 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Enrico, linux-media, Enric Balletbo i Serra

Hi Gary,

On Thursday 01 September 2011 20:18:59 Gary Thomas wrote:
> On 2011-09-01 12:14, Laurent Pinchart wrote:
> > On Thursday 01 September 2011 19:24:54 Enrico wrote:
> >> On Thu, Sep 1, 2011 at 6:14 PM, Enrico<ebutera@users.berlios.de>  wrote:
> >>> On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomas<gary@mlbassoc.com>  wrote:
> >>>> - entity 16: tvp5150m1 2-005c (1 pad, 1 link)
> >>>> 
> >>>>              type V4L2 subdev subtype Unknown
> >>>>              device node name /dev/v4l-subdev8
> >>>>         
> >>>>         pad0: Output [unknown 720x480 (1,1)/720x480]
> >>>>         
> >>>>                 ->  'OMAP3 ISP CCDC':pad0 [ACTIVE]
> >>>> 
> >>>> Ideas where to look for the 'unknown' mode?
> >>> 
> >>> I didn't notice that, if you are using UYVY8_2X8 the reason is in
> >>> media-ctl main.c:
> >>> 
> >>> { "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },
> >>> 
> >>> You can add a line like:
> >>> 
> >>> { "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },
> >>> 
> >>> recompile and it should work, i'll try it now.
> >> 
> >> That worked, but now there is another problem.
> > 
> > That's correct. My bad for not spotting it sooner.
> 
> Will you be adding this to the media-ctl tree?  Would you like a patch?

I need to think about format names. I've used V4L2 FOURCC names so far to 
refer to media bus format codes, that proved not to be the best idea. I will 
fix that.

> >> yavta will set UYVY (PIX_FMT), this will cause a call to
> >> ispvideo.c:isp_video_pix_to_mbus(..), that will do this:
> >> 
> >> for (i = 0; i<  ARRAY_SIZE(formats); ++i) {
> >> 
> >>                  if (formats[i].pixelformat == pix->pixelformat)
> >>                  
> >>                          break;
> >> 
> >> }
> >> 
> >> that is it will stop at the first matching array item, and that's:
> >> 
> >> { V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
> >> 
> >>            V4L2_MBUS_FMT_UYVY8_1X16, 0,
> >>            V4L2_PIX_FMT_UYVY, 16, 16, },
> >> 
> >> but you wanted this:
> >> 
> >> { V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,
> >> 
> >>            V4L2_MBUS_FMT_UYVY8_2X8, 0,
> >>            V4L2_PIX_FMT_UYVY, 8, 16, },
> >> 
> >> so a better check could be to check for width too, but i don't know if
> >> it's possibile to pass a width requirement or if it's already there in
> >> some struct passed to the function.
> > 
> > That's not really an issue, as the isp_video_pix_to_mbus() and
> > isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to
> > fill the bytesperline and sizeimage fields. From a quick look at the
> > code isp_video_check_format() should succeed as well.
> > 
> > Have you run into any specific issue with isp_video_pix_to_mbus() when
> > using V4L2_MBUS_FMT_UYVY8_2X8 ?
> 
> Not yet - I was able to configure the pipeline as
>    # media-ctl -f '"tvp5150m1 2-005c":0[UYVY2X8 720x480], "OMAP3 ISP
> CCDC":0[UYVY2X8 720x480], "OMAP3 ISP CCDC":1[UYVY2X8 720x480]' and this
> gets me all the way into my driver (which I'm now working on)

OK.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-01 18:14                                   ` Laurent Pinchart
  2011-09-01 18:18                                     ` Gary Thomas
@ 2011-09-02  9:02                                     ` Enrico
  2011-09-02 11:27                                       ` Laurent Pinchart
  1 sibling, 1 reply; 45+ messages in thread
From: Enrico @ 2011-09-02  9:02 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: Gary Thomas, linux-media, Enric Balletbo i Serra

On Thu, Sep 1, 2011 at 8:14 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 01 September 2011 19:24:54 Enrico wrote:
>> yavta will set UYVY (PIX_FMT), this will cause a call to
>> ispvideo.c:isp_video_pix_to_mbus(..), that will do this:
>>
>> for (i = 0; i < ARRAY_SIZE(formats); ++i) {
>>                 if (formats[i].pixelformat == pix->pixelformat)
>>                         break;
>> }
>>
>> that is it will stop at the first matching array item, and that's:
>>
>> { V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
>>           V4L2_MBUS_FMT_UYVY8_1X16, 0,
>>           V4L2_PIX_FMT_UYVY, 16, 16, },
>>
>>
>> but you wanted this:
>>
>> { V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,
>>           V4L2_MBUS_FMT_UYVY8_2X8, 0,
>>           V4L2_PIX_FMT_UYVY, 8, 16, },
>>
>> so a better check could be to check for width too, but i don't know if
>> it's possibile to pass a width requirement or if it's already there in
>> some struct passed to the function.
>
> That's not really an issue, as the isp_video_pix_to_mbus() and
> isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to fill
> the bytesperline and sizeimage fields. From a quick look at the code
> isp_video_check_format() should succeed as well.
>
> Have you run into any specific issue with isp_video_pix_to_mbus() when using
> V4L2_MBUS_FMT_UYVY8_2X8 ?

No, i assumed it was used to set the format on the pad too but this is
not the case, sorry for the noise.

Right now my problem is that i can't get the isp to generate
interrupts, i think there is some isp configuration error.

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-02  9:02                                     ` Enrico
@ 2011-09-02 11:27                                       ` Laurent Pinchart
  2011-09-05 16:37                                         ` Enrico
  0 siblings, 1 reply; 45+ messages in thread
From: Laurent Pinchart @ 2011-09-02 11:27 UTC (permalink / raw)
  To: Enrico; +Cc: Gary Thomas, linux-media, Enric Balletbo i Serra

Hi Enrico,

On Friday 02 September 2011 11:02:23 Enrico wrote:
> On Thu, Sep 1, 2011 at 8:14 PM, Laurent Pinchart wrote:
> > On Thursday 01 September 2011 19:24:54 Enrico wrote:
> >> yavta will set UYVY (PIX_FMT), this will cause a call to
> >> ispvideo.c:isp_video_pix_to_mbus(..), that will do this:
> >> 
> >> for (i = 0; i < ARRAY_SIZE(formats); ++i) {
> >>                 if (formats[i].pixelformat == pix->pixelformat)
> >>                         break;
> >> }
> >> 
> >> that is it will stop at the first matching array item, and that's:
> >> 
> >> { V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
> >>           V4L2_MBUS_FMT_UYVY8_1X16, 0,
> >>           V4L2_PIX_FMT_UYVY, 16, 16, },
> >> 
> >> 
> >> but you wanted this:
> >> 
> >> { V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,
> >>           V4L2_MBUS_FMT_UYVY8_2X8, 0,
> >>           V4L2_PIX_FMT_UYVY, 8, 16, },
> >> 
> >> so a better check could be to check for width too, but i don't know if
> >> it's possibile to pass a width requirement or if it's already there in
> >> some struct passed to the function.
> > 
> > That's not really an issue, as the isp_video_pix_to_mbus() and
> > isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to
> > fill the bytesperline and sizeimage fields. From a quick look at the
> > code isp_video_check_format() should succeed as well.
> > 
> > Have you run into any specific issue with isp_video_pix_to_mbus() when
> > using V4L2_MBUS_FMT_UYVY8_2X8 ?
> 
> No, i assumed it was used to set the format on the pad too but this is
> not the case, sorry for the noise.
> 
> Right now my problem is that i can't get the isp to generate
> interrupts, i think there is some isp configuration error.

If your device generates interlaced images that's not surprising, as the CCDC 
will only receive half the number of lines it expects.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-02 11:27                                       ` Laurent Pinchart
@ 2011-09-05 16:37                                         ` Enrico
  2011-09-06  8:48                                           ` Laurent Pinchart
       [not found]                                           ` <201109061049.32114.laurent.pinchart@ideasonboard.com>
  0 siblings, 2 replies; 45+ messages in thread
From: Enrico @ 2011-09-05 16:37 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: Gary Thomas, linux-media, Enric Balletbo i Serra

On Fri, Sep 2, 2011 at 1:27 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 02 September 2011 11:02:23 Enrico wrote:
>> Right now my problem is that i can't get the isp to generate
>> interrupts, i think there is some isp configuration error.
>
> If your device generates interlaced images that's not surprising, as the CCDC
> will only receive half the number of lines it expects.

Yes that was the first thing i tried, anyway now i have it finally
working. Well at least yavta doesn't hang, do you know some
application to see raw yuv images?

Now the problem is that the fix is weird...as you suggested you must
use half height values for VD0 and VD1 (2/3) interrupts, problem is
that it only works if you DISABLE vd1 interrupt.
If it is enabled the vd1_isr is run (once) and nothing else happens.

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-05 16:37                                         ` Enrico
@ 2011-09-06  8:48                                           ` Laurent Pinchart
  2011-09-06  9:04                                             ` Enrico
       [not found]                                           ` <201109061049.32114.laurent.pinchart@ideasonboard.com>
  1 sibling, 1 reply; 45+ messages in thread
From: Laurent Pinchart @ 2011-09-06  8:48 UTC (permalink / raw)
  To: Enrico; +Cc: Gary Thomas, linux-media, Enric Balletbo i Serra, Hans de Goede

Hi Enrico,

(CC'ing Hans de Goede)

On Monday 05 September 2011 18:37:04 Enrico wrote:
> On Fri, Sep 2, 2011 at 1:27 PM, Laurent Pinchart wrote:
> > On Friday 02 September 2011 11:02:23 Enrico wrote:
> >> Right now my problem is that i can't get the isp to generate
> >> interrupts, i think there is some isp configuration error.
> > 
> > If your device generates interlaced images that's not surprising, as the
> > CCDC will only receive half the number of lines it expects.
> 
> Yes that was the first thing i tried, anyway now i have it finally
> working. Well at least yavta doesn't hang, do you know some
> application to see raw yuv images?

Hans, could libv4lconvert be used to implement a command line format 
conversion tool ? From a quick look at it it requires a V4L2 device, could 
that limitation be easily lifted ?

> Now the problem is that the fix is weird...as you suggested you must
> use half height values for VD0 and VD1 (2/3) interrupts, problem is
> that it only works if you DISABLE vd1 interrupt.
> If it is enabled the vd1_isr is run (once) and nothing else happens.

Have you set VD0 at half height and VD1 at 1/3 height ?

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
  2011-09-06  8:48                                           ` Laurent Pinchart
@ 2011-09-06  9:04                                             ` Enrico
  0 siblings, 0 replies; 45+ messages in thread
From: Enrico @ 2011-09-06  9:04 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Gary Thomas, linux-media, Enric Balletbo i Serra, Hans de Goede

On Tue, Sep 6, 2011 at 10:48 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Monday 05 September 2011 18:37:04 Enrico wrote:
>> Now the problem is that the fix is weird...as you suggested you must
>> use half height values for VD0 and VD1 (2/3) interrupts, problem is
>> that it only works if you DISABLE vd1 interrupt.
>> If it is enabled the vd1_isr is run (once) and nothing else happens.
>
> Have you set VD0 at half height and VD1 at 1/3 height ?

Yes, i also tried some "offset" on vd1 / 3 to see if the vd0 interrupt
was just being lost but with no success.

Maybe disabling the ccdc ( __cdc_enable(.. , 0) ) in vd1_isr makes the
vd0 interrupt to not be triggered, i don't know...

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
       [not found]                                           ` <201109061049.32114.laurent.pinchart@ideasonboard.com>
@ 2011-09-06  9:10                                             ` Enrico
  0 siblings, 0 replies; 45+ messages in thread
From: Enrico @ 2011-09-06  9:10 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media

On Tue, Sep 6, 2011 at 10:49 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Monday 05 September 2011 18:37:04 you wrote:
>> Yes that was the first thing i tried, anyway now i have it finally
>> working. Well at least yavta doesn't hang, do you know some
>> application to see raw yuv images?

I made a typo since in fact it's uyvy ( so a tool to covert from yuv
will not work ;) ), but if someone will ever need it:

ffmpeg -f rawvideo -pix_fmt uyvy422 -s 720x628 -i frame-000001.bin frame-1.png

Enrico

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: Getting started with OMAP3 ISP
@ 2011-10-05 10:46 Adam Pledger
  0 siblings, 0 replies; 45+ messages in thread
From: Adam Pledger @ 2011-10-05 10:46 UTC (permalink / raw)
  To: ebutera, gary; +Cc: linux-media

> On Tue, Sep 6, 2011 at 10:49 AM, Laurent Pinchart
> <laurent.pinch...@ideasonboard.com>  wrote:
> >  On Monday 05 September 2011 18:37:04 you wrote:
> >>  Yes that was the first thing i tried, anyway now i have it finally
> >>  working. Well at least yavta doesn't hang, do you know some
> >>  application to see raw yuv images?
>
> I made a typo since in fact it's uyvy ( so a tool to covert from yuv
> will not work ;) ), but if someone will ever need it:
>
> ffmpeg -f rawvideo -pix_fmt uyvy422 -s 720x628 -i frame-000001.bin frame-1.png
>
> Enrico

Enrico, Gary,

I am in an identical situation to you both in that I am migrating to a newer kernel and am faced with the task of getting a driver for the tvp5150 working with the new MC framework and omap3 ISP.
I understand from reading this thread that you have both had some success in modifying an existing / writing a driver and configuring a MC pipeline.
If you are able to share your driver(s) or any insights, I would be very grateful and I am happy to help out with further testing or polishing as required.

Best Regards

Adam


^ permalink raw reply	[flat|nested] 45+ messages in thread

end of thread, other threads:[~2011-10-05 11:11 UTC | newest]

Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-25 16:07 Getting started with OMAP3 ISP Gary Thomas
2011-08-29 10:49 ` Laurent Pinchart
2011-08-30 14:08   ` Gary Thomas
2011-08-30 14:18     ` Gary Thomas
2011-08-30 14:20       ` Laurent Pinchart
2011-08-30 14:56         ` Gary Thomas
2011-08-30 15:48           ` Laurent Pinchart
2011-08-30 16:07           ` Enrico
2011-08-30 16:23             ` Gary Thomas
2011-08-30 16:36               ` Enrico
2011-08-30 16:48                 ` Gary Thomas
2011-08-30 21:19               ` Sakari Ailus
2011-08-30 22:45   ` Gary Thomas
2011-08-30 22:50     ` Laurent Pinchart
2011-08-31  0:07       ` Gary Thomas
2011-08-31  8:13         ` Laurent Pinchart
2011-08-31 10:56           ` Gary Thomas
2011-08-31 11:00             ` Laurent Pinchart
2011-08-31 12:01               ` Gary Thomas
2011-08-31 15:15                 ` Laurent Pinchart
2011-08-31 15:19                   ` Gary Thomas
2011-08-31 16:25                   ` Enrico
2011-08-31 16:33                     ` Laurent Pinchart
2011-08-31 22:34                       ` Gary Thomas
2011-09-01  8:11                         ` Laurent Pinchart
2011-09-01  9:51                       ` Enrico
2011-09-01  9:55                         ` Laurent Pinchart
2011-09-01 10:24                           ` Enrico
2011-09-01 14:12                             ` Enrico
2011-09-01 14:24                               ` Laurent Pinchart
2011-09-01 12:50                         ` Gary Thomas
2011-09-01 13:26                           ` Laurent Pinchart
2011-09-01 15:16                             ` Gary Thomas
2011-09-01 16:14                               ` Enrico
2011-09-01 17:24                                 ` Enrico
2011-09-01 18:14                                   ` Laurent Pinchart
2011-09-01 18:18                                     ` Gary Thomas
2011-09-02  8:09                                       ` Laurent Pinchart
2011-09-02  9:02                                     ` Enrico
2011-09-02 11:27                                       ` Laurent Pinchart
2011-09-05 16:37                                         ` Enrico
2011-09-06  8:48                                           ` Laurent Pinchart
2011-09-06  9:04                                             ` Enrico
     [not found]                                           ` <201109061049.32114.laurent.pinchart@ideasonboard.com>
2011-09-06  9:10                                             ` Enrico
2011-10-05 10:46 Adam Pledger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.