Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[James]

Hi all,

I'm using an OMAP3530 board and a monochrome 12-bit grey sensor.

Can anyone enlighten me why is the 12-bit grey formats at the CCDC
input (Y12) is truncated to Y10 at the CCDC output?

I need to read the entire RAW 12-bit grey value from the CCDC to
memory and the data does not pass through other OMAP3ISP sub-devices.

I intend to use Laurent's yavta to capture the data to file to verify
its operation for the moment.

Can this 12-bit (Y12) raw capture be done?

Thank you in adv.

--
Regards,
James

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[Michael Jones]

Hi James,

On 12/15/2011 08:14 AM, James wrote:
> Hi all,
>
> I'm using an OMAP3530 board and a monochrome 12-bit grey sensor.
>
> Can anyone enlighten me why is the 12-bit grey formats at the CCDC
> input (Y12) is truncated to Y10 at the CCDC output?

There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP. 
Only the VP (video port) truncates data to 10 bits, and it does that 
because the subdevs it feeds can only handle 10 bits max.

>
> I need to read the entire RAW 12-bit grey value from the CCDC to
> memory and the data does not pass through other OMAP3ISP sub-devices.
>
> I intend to use Laurent's yavta to capture the data to file to verify
> its operation for the moment.
>
> Can this 12-bit (Y12) raw capture be done?

Yes. If you are writing the 12-bit gray value directly into memory, you 
will use SOURCE_OF and can write the full 12-bits into memory.  You need 
to set up your media pipeline to do sensor->CCDC->OMAP3 ISP CCDC output.

>
> Thank you in adv.
>
> --
> Regards,
> James

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[James]

Hi Michael,

On Thu, Dec 15, 2011 at 3:58 PM, Michael Jones
<michael.jones@matrix-vision.de> wrote:
> Hi James,
>
>
> On 12/15/2011 08:14 AM, James wrote:
>>
>> Hi all,
>>
>> I'm using an OMAP3530 board and a monochrome 12-bit grey sensor.
>>
>> Can anyone enlighten me why is the 12-bit grey formats at the CCDC
>> input (Y12) is truncated to Y10 at the CCDC output?
>
>
> There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP. Only
> the VP (video port) truncates data to 10 bits, and it does that because the
> subdevs it feeds can only handle 10 bits max.

Thank you for the clarification.

>> I need to read the entire RAW 12-bit grey value from the CCDC to
>> memory and the data does not pass through other OMAP3ISP sub-devices.
>>
>> I intend to use Laurent's yavta to capture the data to file to verify
>> its operation for the moment.
>>
>> Can this 12-bit (Y12) raw capture be done?
>
>
> Yes. If you are writing the 12-bit gray value directly into memory, you will
> use SOURCE_OF and can write the full 12-bits into memory.  You need to set
> up your media pipeline to do sensor->CCDC->OMAP3 ISP CCDC output.

Is there further modification needed to apply to the OMAP3ISP to achieve this?

Do you have an application to test the pipeline for this setting to
simple display?

Many thanks in adv.

-- 
Regards,
James

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[Michael Jones]

Hi James,

On 12/15/2011 10:49 AM, James wrote:
> Hi Michael,
>
> On Thu, Dec 15, 2011 at 3:58 PM, Michael Jones
> <michael.jones@matrix-vision.de>  wrote:
>> Hi James,
>>
>>
>> On 12/15/2011 08:14 AM, James wrote:
>>>
>>> Hi all,
>>>
>>> I'm using an OMAP3530 board and a monochrome 12-bit grey sensor.
>>>
>>> Can anyone enlighten me why is the 12-bit grey formats at the CCDC
>>> input (Y12) is truncated to Y10 at the CCDC output?
>>
>>
>> There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP. Only
>> the VP (video port) truncates data to 10 bits, and it does that because the
>> subdevs it feeds can only handle 10 bits max.
>
> Thank you for the clarification.
>
>>> I need to read the entire RAW 12-bit grey value from the CCDC to
>>> memory and the data does not pass through other OMAP3ISP sub-devices.
>>>
>>> I intend to use Laurent's yavta to capture the data to file to verify
>>> its operation for the moment.
>>>
>>> Can this 12-bit (Y12) raw capture be done?
>>
>>
>> Yes. If you are writing the 12-bit gray value directly into memory, you will
>> use SOURCE_OF and can write the full 12-bits into memory.  You need to set
>> up your media pipeline to do sensor->CCDC->OMAP3 ISP CCDC output.
>
> Is there further modification needed to apply to the OMAP3ISP to achieve this?
>
> Do you have an application to test the pipeline for this setting to
> simple display?

Let's establish where you're coming from.  Are you familiar with the 
media controller?  Laurent has a program 'media-ctl' to set up the 
pipeline (see http://git.ideasonboard.org/?p=media-ctl.git).  You will 
find many examples of its usage in the archives of this mailing list. 
It will look something like:
media-ctl -r
media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]'
media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]'

you will also need to set the formats through the pipeline with 
'media-ctl --set-format'.

After you use media-ctl to set up the pipeline, you can use yavta to 
capture the data from the CCDC output (for me, this is /dev/video2).

-Michael


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[James]

Hi Michael,

On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones
<michael.jones@matrix-vision.de> wrote:
> Hi James,
>
>
> On 12/15/2011 10:49 AM, James wrote:
>>
>> Hi Michael,
>>
>> On Thu, Dec 15, 2011 at 3:58 PM, Michael Jones
>> <michael.jones@matrix-vision.de>  wrote:
>>>
>>> Hi James,
>>>
>>>
>>> On 12/15/2011 08:14 AM, James wrote:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I'm using an OMAP3530 board and a monochrome 12-bit grey sensor.
>>>>
>>>> Can anyone enlighten me why is the 12-bit grey formats at the CCDC
>>>> input (Y12) is truncated to Y10 at the CCDC output?
>>>
>>>
>>>
>>> There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP. Only
>>> the VP (video port) truncates data to 10 bits, and it does that because
>>> the
>>> subdevs it feeds can only handle 10 bits max.
>>
>>
>> Thank you for the clarification.
>>
>>>> I need to read the entire RAW 12-bit grey value from the CCDC to
>>>> memory and the data does not pass through other OMAP3ISP sub-devices.
>>>>
>>>> I intend to use Laurent's yavta to capture the data to file to verify
>>>> its operation for the moment.
>>>>
>>>> Can this 12-bit (Y12) raw capture be done?
>>>
>>>
>>>
>>> Yes. If you are writing the 12-bit gray value directly into memory, you
>>> will
>>> use SOURCE_OF and can write the full 12-bits into memory.  You need to
>>> set
>>> up your media pipeline to do sensor->CCDC->OMAP3 ISP CCDC output.
>>
>>
>> Is there further modification needed to apply to the OMAP3ISP to achieve
>> this?
>>
>> Do you have an application to test the pipeline for this setting to
>> simple display?
>
>
> Let's establish where you're coming from.  Are you familiar with the media
> controller?  Laurent has a program 'media-ctl' to set up the pipeline (see
> http://git.ideasonboard.org/?p=media-ctl.git).  You will find many examples
> of its usage in the archives of this mailing list. It will look something
> like:
> media-ctl -r
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]'
> media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]'
>
> you will also need to set the formats through the pipeline with 'media-ctl
> --set-format'.
>
> After you use media-ctl to set up the pipeline, you can use yavta to capture
> the data from the CCDC output (for me, this is /dev/video2).
>

Yes, I've been using Laurent's media-ctl & yavta to test out MT9V032
on the Overo board.
He has been helping and guiding me with it as there isn't any success
with using MT9V032 on the Overo board then. (^^)

What I've been looking for since then is any other application such as
GUI MPlayer or gst-launch that can open the device and playback the
data to either LCD or DVI display on the board. (i.e. direct
'streaming')

Do you know of any? I wish to avoid any further components (e.g.
ffmpeg) that modify/convert the raw data as much as possible.

sensor->CCDC->application->display

Many thanks in adv.

-- 
Regards,
James

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[Laurent Pinchart]

Hi James,

On Friday 16 December 2011 01:53:59 James wrote:
> On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones wrote:
> > On 12/15/2011 10:49 AM, James wrote:
> >> On Thu, Dec 15, 2011 at 3:58 PM, Michael Jones wrote:
> >>> On 12/15/2011 08:14 AM, James wrote:
> >>>> Hi all,
> >>>> 
> >>>> I'm using an OMAP3530 board and a monochrome 12-bit grey sensor.
> >>>> 
> >>>> Can anyone enlighten me why is the 12-bit grey formats at the CCDC
> >>>> input (Y12) is truncated to Y10 at the CCDC output?
> >>> 
> >>> There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP.
> >>> Only the VP (video port) truncates data to 10 bits, and it does that
> >>> because the
> >>> subdevs it feeds can only handle 10 bits max.
> >> 
> >> Thank you for the clarification.
> >> 
> >>>> I need to read the entire RAW 12-bit grey value from the CCDC to
> >>>> memory and the data does not pass through other OMAP3ISP sub-devices.
> >>>> 
> >>>> I intend to use Laurent's yavta to capture the data to file to verify
> >>>> its operation for the moment.
> >>>> 
> >>>> Can this 12-bit (Y12) raw capture be done?
> >>> 
> >>> Yes. If you are writing the 12-bit gray value directly into memory, you
> >>> will
> >>> use SOURCE_OF and can write the full 12-bits into memory.  You need to
> >>> set
> >>> up your media pipeline to do sensor->CCDC->OMAP3 ISP CCDC output.
> >> 
> >> Is there further modification needed to apply to the OMAP3ISP to achieve
> >> this?
> >> 
> >> Do you have an application to test the pipeline for this setting to
> >> simple display?
> > 
> > Let's establish where you're coming from.  Are you familiar with the
> > media controller?  Laurent has a program 'media-ctl' to set up the
> > pipeline (see http://git.ideasonboard.org/?p=media-ctl.git).  You will
> > find many examples of its usage in the archives of this mailing list. It
> > will look something like:
> > media-ctl -r
> > media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]'
> > media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]'
> > 
> > you will also need to set the formats through the pipeline with
> > 'media-ctl --set-format'.
> > 
> > After you use media-ctl to set up the pipeline, you can use yavta to
> > capture the data from the CCDC output (for me, this is /dev/video2).
> 
> Yes, I've been using Laurent's media-ctl & yavta to test out MT9V032
> on the Overo board.
> He has been helping and guiding me with it as there isn't any success
> with using MT9V032 on the Overo board then. (^^)
> 
> What I've been looking for since then is any other application such as
> GUI MPlayer or gst-launch that can open the device and playback the
> data to either LCD or DVI display on the board. (i.e. direct
> 'streaming')
> 
> Do you know of any? I wish to avoid any further components (e.g.
> ffmpeg) that modify/convert the raw data as much as possible.
> 
> sensor->CCDC->application->display

If you're going to display the data, the 12-bit resolution is overkill. You 
can thus limit it to 10-bits in the CCDC, and you should feed it to the 
preview engine (and possibly resizer) to get YUV which could easily be played 
on screen.

However, the preview engine doesn't support Y10 input yet, so this will need 
to be implemented. You can work around the problem by hacking the sensor 
driver to report SGRBG10. You will get a resulting YUV image that will look 
more or less correct, but with color artifacts. That's at least a temporary 
solution to make sure the pipeline + display are working.

-- 
Regards,

Laurent Pinchart

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[James]

Hi Laurent,

On Fri, Dec 16, 2011 at 5:40 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi James,
>
> On Friday 16 December 2011 01:53:59 James wrote:
>> On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones wrote:
>> > On 12/15/2011 10:49 AM, James wrote:
>> >> On Thu, Dec 15, 2011 at 3:58 PM, Michael Jones wrote:
>> >>> On 12/15/2011 08:14 AM, James wrote:
>> >>>> Hi all,
>> >>>>
>> >>>> I'm using an OMAP3530 board and a monochrome 12-bit grey sensor.
>> >>>>
>> >>>> Can anyone enlighten me why is the 12-bit grey formats at the CCDC
>> >>>> input (Y12) is truncated to Y10 at the CCDC output?
>> >>>
>> >>> There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP.
>> >>> Only the VP (video port) truncates data to 10 bits, and it does that
>> >>> because the
>> >>> subdevs it feeds can only handle 10 bits max.
>> >>
>> >> Thank you for the clarification.
>> >>
>> >>>> I need to read the entire RAW 12-bit grey value from the CCDC to
>> >>>> memory and the data does not pass through other OMAP3ISP sub-devices.
>> >>>>
>> >>>> I intend to use Laurent's yavta to capture the data to file to verify
>> >>>> its operation for the moment.
>> >>>>
>> >>>> Can this 12-bit (Y12) raw capture be done?
>> >>>
>> >>> Yes. If you are writing the 12-bit gray value directly into memory, you
>> >>> will
>> >>> use SOURCE_OF and can write the full 12-bits into memory.  You need to
>> >>> set
>> >>> up your media pipeline to do sensor->CCDC->OMAP3 ISP CCDC output.
>> >>
>> >> Is there further modification needed to apply to the OMAP3ISP to achieve
>> >> this?
>> >>
>> >> Do you have an application to test the pipeline for this setting to
>> >> simple display?
>> >
>> > Let's establish where you're coming from.  Are you familiar with the
>> > media controller?  Laurent has a program 'media-ctl' to set up the
>> > pipeline (see http://git.ideasonboard.org/?p=media-ctl.git).  You will
>> > find many examples of its usage in the archives of this mailing list. It
>> > will look something like:
>> > media-ctl -r
>> > media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]'
>> > media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]'
>> >
>> > you will also need to set the formats through the pipeline with
>> > 'media-ctl --set-format'.
>> >
>> > After you use media-ctl to set up the pipeline, you can use yavta to
>> > capture the data from the CCDC output (for me, this is /dev/video2).
>>
>> Yes, I've been using Laurent's media-ctl & yavta to test out MT9V032
>> on the Overo board.
>> He has been helping and guiding me with it as there isn't any success
>> with using MT9V032 on the Overo board then. (^^)
>>
>> What I've been looking for since then is any other application such as
>> GUI MPlayer or gst-launch that can open the device and playback the
>> data to either LCD or DVI display on the board. (i.e. direct
>> 'streaming')
>>
>> Do you know of any? I wish to avoid any further components (e.g.
>> ffmpeg) that modify/convert the raw data as much as possible.
>>
>> sensor->CCDC->application->display
>
> If you're going to display the data, the 12-bit resolution is overkill. You
> can thus limit it to 10-bits in the CCDC, and you should feed it to the
> preview engine (and possibly resizer) to get YUV which could easily be played
> on screen.

Yup. The main purpose of grabbing at 12-bit is for soft
post-processing before being fed to the display at its optimal
resolution. Thus, I've to bypass all the HW ISP blocks available in
the OMAP3530.

For now, I just need a method to validate the proof-of-concept of the
pipeline with a 'grab-n-dump' streaming playback without any
post-processing onto the display (LCD/DVI).

> However, the preview engine doesn't support Y10 input yet, so this will need
> to be implemented.

Noted.

> You can work around the problem by hacking the sensor
> driver to report SGRBG10. You will get a resulting YUV image that will look
> more or less correct, but with color artifacts. That's at least a temporary
> solution to make sure the pipeline + display are working.

The hack is to keep the constant (V4L2_MBUS_FMT_SGRBG10_1X10) instead
of changing to V4L2_MBUS_FMT_Y12_1x12?

Many thanks in adv.

-- 
Regards,
James

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[James]

Hi Michael & Laurent,

On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones
<michael.jones@matrix-vision.de> wrote:
> Hi James,

> Laurent has a program 'media-ctl' to set up the pipeline (see
> http://git.ideasonboard.org/?p=media-ctl.git).  You will find many examples
> of its usage in the archives of this mailing list. It will look something
> like:
> media-ctl -r
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]'
> media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]'
>
> you will also need to set the formats through the pipeline with 'media-ctl
> --set-format'.
>
> After you use media-ctl to set up the pipeline, you can use yavta to capture
> the data from the CCDC output (for me, this is /dev/video2).
>
>
> -Michael

I encountered some obstacles with the driver testing of my monochrome
sensor on top of Steve's 3.0-pm branch. An NXP SC16IS750 I2C-UART
bridge is used to 'transform' the sensor into a I2C device.

The PCLK, VSYNC, HSYNC (640x512, 30Hz, fixed output format) are free
running upon power-on the sensor unlike MT9V032 which uses the XCLKA
to 'power-on/off' it.

My steps,

1) media-ctl -r -l '"mono640":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]

2) media-ctl -f '"mono640":0[Y12 640x512]", "OMAP3 ISP CCDC":1[Y12 640x512]'

Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0
Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1

3) yavta -p -f Y12 -s 640x512 -n 4 --capture=61 --skip 1 -F `media-ctl
-e "OMAP3 ISP CCDC output"` --file=./DCIM/Y12

Unsupported video format 'Y12'

Did I missed something?
What parameters did you supplied to yavta to test the Y10/Y12

Many thanks in adv.
Sorry if duplicated emails received.

--
Regards,
James

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[James]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

Hi Laurent & Michael,

On Wed, Dec 21, 2011 at 10:50 AM, James <angweiyang@gmail.com> wrote:
> Hi Michael & Laurent,
>
> On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones
> <michael.jones@matrix-vision.de> wrote:
>> Hi James,
>
>> Laurent has a program 'media-ctl' to set up the pipeline (see
>> http://git.ideasonboard.org/?p=media-ctl.git).  You will find many examples
>> of its usage in the archives of this mailing list. It will look something
>> like:
>> media-ctl -r
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]'
>> media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]'
>>
>> you will also need to set the formats through the pipeline with 'media-ctl
>> --set-format'.
>>
>> After you use media-ctl to set up the pipeline, you can use yavta to capture
>> the data from the CCDC output (for me, this is /dev/video2).
>>
>>
>> -Michael
>
> I encountered some obstacles with the driver testing of my monochrome
> sensor on top of Steve's 3.0-pm branch. An NXP SC16IS750 I2C-UART
> bridge is used to 'transform' the sensor into a I2C device.
>
> The PCLK, VSYNC, HSYNC (640x512, 30Hz, fixed output format) are free
> running upon power-on the sensor unlike MT9V032 which uses the XCLKA
> to 'power-on/off' it.
>
> My steps,
>
> 1) media-ctl -r -l '"mono640":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]
>
> 2) media-ctl -f '"mono640":0[Y12 640x512]", "OMAP3 ISP CCDC":1[Y12 640x512]'
>
> Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0
> Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1
>
> 3) yavta -p -f Y12 -s 640x512 -n 4 --capture=61 --skip 1 -F `media-ctl
> -e "OMAP3 ISP CCDC output"` --file=./DCIM/Y12
>
> Unsupported video format 'Y12'
>
> Did I missed something?
> What parameters did you supplied to yavta to test the Y10/Y12
>
> Many thanks in adv.
> Sorry if duplicated emails received.
>
> --
> Regards,
> James

I changed the parameters for yavta from "-f Y12" to "-f Y16"

yavta -p -f Y16 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e
"OMAP3 ISP CCDC output"` --file=./DCIM/Y16

and there are 2 chunks of message at the console now and it ended with
"Unable to request buffers: Invalid argument (22).".

I've attached the logfile here. (mono640.log)

Hope you can assist me to grab the raw Y12 data to file.

Many thanks in adv.

-- 
Regards,
James

[-- Attachment #2: mono640.log --]
[-- Type: text/x-log, Size: 3700 bytes --]

root@overo:media-ctl -r -v -l '"mono640":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'

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

root@overo:media-ctl -v -f '"mono640":0[Y12 640x512], "OMAP3 ISP CCDC":1[SGRBG12 640x512]'

Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Setting up format Y12 640x512 on pad mono640 3-004d/0
Format set: Y12 640x512
Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0
Format set: Y12 640x512
Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1
Format set: Y12 640x512


root@overo:yavta -p -f Y16 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e "OMAP3 ISP CCDC output"` --file=./DCIM/Y16

Device /dev/video2 opened.
------------[ cut here ]------------
WARNING: at drivers/media/video/omap3isp/ispvideo.c:218 isp_video_set_format+0x50/0x88 [omap3_isp]()
Device `OMAP3 ISP CCDC output' on `media' is a video omaplfb capture device.
Modules linked in: bufferclass_ti pvrsrvkm ipv6 mono640 libertas_sdio omap3_isp libertas v4l2_common cfg80211 videodev media lib80211 firmware_class ads7846
[<c0045dc4>] (unwind_backtrace+0x0/0x128) from [<c006ba9c>] (warn_slowpath_common+0x4c/0x64)
[<c006ba9c>] (warn_slowpath_common+0x4c/0x64) from [<c006bad0>] (warn_slowpath_null+0x1c/0x24)
[<c006bad0>] (warn_slowpath_null+0x1c/0x24) from [<bf099e90>] (isp_video_set_format+0x50/0x88 [omap3_isp])
[<bf099e90>] (isp_video_set_format+0x50/0x88 [omap3_isp]) from [<bf01d778>] (__video_do_ioctl+0x11a4/0x516c [videodev])
[<bf01d778>] (__video_do_ioctl+0x11a4/0x516c [videodev]) from [<bf01c458>] (video_usercopy+0x340/0x450 [videodev])
[<bf01c458>] (video_usercopy+0x340/0x450 [videodev]) from [<bf01b448>] (v4l2_ioctl+0x7c/0x12c [videodev])
[<bf01b448>] (v4l2_ioctl+0x7c/0x12c [videodev]) from [<c00e4110>] (do_vfs_ioctl+0x4b0/0x51c)
[<c00e4110>] (do_vfs_ioctl+0x4b0/0x51c) from [<c00e41b4>] (sys_ioctl+0x38/0x5c)
[<c00e41b4>] (sys_ioctl+0x38/0x5c) from [<c0041240>] (ret_fast_syscall+0x0/0x30)
---[ end trace 6824b735bee150b5 ]---
------------[ cut here ]------------
WARNING: at drivers/media/video/omap3isp/ispvideo.c:178 isp_video_mbus_to_pix+0x78/0x144 [omap3_isp]()
Modules linked in: bufferclass_ti omaplfb pvrsrvkm ipv6 mono640 libertas_sdio omap3_isp libertas v4l2_common cfg80211 videodev media lib80211 firmware_class ads7846
[<c0045dc4>] (unwind_backtrace+0x0/0x128) from [<c006ba9c>] (warn_slowpath_common+0x4c/0x64)
[<c006ba9c>] (warn_slowpath_common+0x4c/0x64) from [<c006bad0>] (warn_slowpath_null+0x1c/0x24)
[<c006bad0>] (warn_slowpath_null+0x1c/0x24) from [<bf099bfc>] (isp_video_mbus_to_pix+0x78/0x144 [omap3_isp])
[<bf099bfc>] (isp_video_mbus_to_pix+0x78/0x144 [omap3_isp]) from [<bf099ea0>] (isp_video_set_format+0x60/0x88 [omap3_isp])
[<bf099ea0>] (isp_video_set_format+0x60/0x88 [omap3_isp]) from [<bf01d778>] (__video_do_ioctl+0x11a4/0x516c [videodev])
[<bf01d778>] (__video_do_ioctl+0x11a4/0x516c [videodev]) from [<bf01c458>] (video_usercopy+0x340/0x450 [videodev])
[<bf01c458>] (video_usercopy+0x340/0x450 [videodev]) from [<bf01b448>] (v4l2_ioctl+0x7c/0x12c [videodev])
[<bf01b448>] (v4l2_ioctl+0x7c/0x12c [videodev]) from [<c00e4110>] (do_vfs_ioctl+0x4b0/0x51c)
[<c00e4110>] (do_vfs_ioctl+0x4b0/0x51c) from [<c00e41b4>] (sys_ioctl+0x38/0x5c)
[<c00e41b4>] (sys_ioctl+0x38/0x5c) from [<c0041240>] (ret_fast_syscall+0x0/0x30)
---[ end trace 6824b735bee150b6 ]---
Video format set:  (00000000) 640x512 buffer size 0
Video format:  (00000000) 640x512 buffer size 0
Unable to request buffers: Invalid argument (22).

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[Laurent Pinchart]

Hi James,

On Wednesday 21 December 2011 04:06:33 James wrote:
> On Wed, Dec 21, 2011 at 10:50 AM, James wrote:
> > On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones wrote:
> >> Hi James,
> >> 
> >> Laurent has a program 'media-ctl' to set up the pipeline (see
> >> http://git.ideasonboard.org/?p=media-ctl.git).  You will find many
> >> examples of its usage in the archives of this mailing list. It will
> >> look something like:
> >> media-ctl -r
> >> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]'
> >> media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]'
> >> 
> >> you will also need to set the formats through the pipeline with
> >> 'media-ctl --set-format'.
> >> 
> >> After you use media-ctl to set up the pipeline, you can use yavta to
> >> capture the data from the CCDC output (for me, this is /dev/video2).
> >> 
> >> 
> >> -Michael
> > 
> > I encountered some obstacles with the driver testing of my monochrome
> > sensor on top of Steve's 3.0-pm branch. An NXP SC16IS750 I2C-UART
> > bridge is used to 'transform' the sensor into a I2C device.
> > 
> > The PCLK, VSYNC, HSYNC (640x512, 30Hz, fixed output format) are free
> > running upon power-on the sensor unlike MT9V032 which uses the XCLKA
> > to 'power-on/off' it.
> > 
> > My steps,
> > 
> > 1) media-ctl -r -l '"mono640":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]
> > 
> > 2) media-ctl -f '"mono640":0[Y12 640x512]", "OMAP3 ISP CCDC":1[Y12
> > 640x512]'
> > 
> > Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0
> > Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1
> > 
> > 3) yavta -p -f Y12 -s 640x512 -n 4 --capture=61 --skip 1 -F `media-ctl
> > -e "OMAP3 ISP CCDC output"` --file=./DCIM/Y12
> > 
> > Unsupported video format 'Y12'
> > 
> > Did I missed something?

I've just pushed a patch to the yavta repository to support Y10 and Y12. 
Please update.

> > What parameters did you supplied to yavta to test the Y10/Y12
> > 
> > Many thanks in adv.
> > Sorry if duplicated emails received.
> 
> I changed the parameters for yavta from "-f Y12" to "-f Y16"
> 
> yavta -p -f Y16 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e
> "OMAP3 ISP CCDC output"` --file=./DCIM/Y16
> 
> and there are 2 chunks of message at the console now and it ended with
> "Unable to request buffers: Invalid argument (22).".
> 
> I've attached the logfile here. (mono640.log)
> 
> Hope you can assist me to grab the raw Y12 data to file.

-- 
Regards,

Laurent Pinchart

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[James]

[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]

Hi Laurent,

On Wed, Dec 21, 2011 at 6:55 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi James,
>
> On Wednesday 21 December 2011 04:06:33 James wrote:
>> On Wed, Dec 21, 2011 at 10:50 AM, James wrote:
>> > On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones wrote:
>> >> Hi James,
>> >>
>> >> Laurent has a program 'media-ctl' to set up the pipeline (see
>> >> http://git.ideasonboard.org/?p=media-ctl.git).  You will find many
>> >> examples of its usage in the archives of this mailing list. It will
>> >> look something like:
>> >> media-ctl -r
>> >> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]'
>> >> media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]'
>> >>
>> >> you will also need to set the formats through the pipeline with
>> >> 'media-ctl --set-format'.
>> >>
>> >> After you use media-ctl to set up the pipeline, you can use yavta to
>> >> capture the data from the CCDC output (for me, this is /dev/video2).
>> >>
>> >>
>> >> -Michael
>> >
>> > I encountered some obstacles with the driver testing of my monochrome
>> > sensor on top of Steve's 3.0-pm branch. An NXP SC16IS750 I2C-UART
>> > bridge is used to 'transform' the sensor into a I2C device.
>> >
>> > The PCLK, VSYNC, HSYNC (640x512, 30Hz, fixed output format) are free
>> > running upon power-on the sensor unlike MT9V032 which uses the XCLKA
>> > to 'power-on/off' it.
>> >
>> > My steps,
>> >
>> > 1) media-ctl -r -l '"mono640":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]
>> >
>> > 2) media-ctl -f '"mono640":0[Y12 640x512]", "OMAP3 ISP CCDC":1[Y12
>> > 640x512]'
>> >
>> > Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0
>> > Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1
>> >
>> > 3) yavta -p -f Y12 -s 640x512 -n 4 --capture=61 --skip 1 -F `media-ctl
>> > -e "OMAP3 ISP CCDC output"` --file=./DCIM/Y12
>> >
>> > Unsupported video format 'Y12'
>> >
>> > Did I missed something?
>
> I've just pushed a patch to the yavta repository to support Y10 and Y12.
> Please update.
>
>> > What parameters did you supplied to yavta to test the Y10/Y12
>> >
>> > Many thanks in adv.
>> > Sorry if duplicated emails received.
>>
>> I changed the parameters for yavta from "-f Y12" to "-f Y16"
>>
>> yavta -p -f Y16 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e
>> "OMAP3 ISP CCDC output"` --file=./DCIM/Y16
>>
>> and there are 2 chunks of message at the console now and it ended with
>> "Unable to request buffers: Invalid argument (22).".
>>
>> I've attached the logfile here. (mono640.log)
>>
>> Hope you can assist me to grab the raw Y12 data to file.
>
> --
> Regards,
>
> Laurent Pinchart

Tried the new yavta but encountered a different situation.

yavta -p -f Y12 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e
"OMAP3 ISP CCDC output"` --file=./DCIM/Y12

yavta will hang for infinite time and only Ctrl+C will break out of
the wait and a new error message appears.

yavta: video_do_capture:  calling ioctl..
^C
omap3isp omap3isp: CCDC stop timeout!

I placed some debugging printf() and yavta wait at

ret = ioctl(dev->fd, VIDIOC_DQBUF, &buf);

Attached is the logfile (mono640.yavta-y12.1.log)

What should be the remedies?

Many thanks in adv.
-- 
Regards,
James

[-- Attachment #2: mono640.yavta-y12.1.log --]
[-- Type: text/x-log, Size: 2156 bytes --]

root@overo:~# lsmod
Module                  Size  Used by
bufferclass_ti          4976  0 
omaplfb                 8280  0 
pvrsrvkm              155471  2 bufferclass_ti,omaplfb
ipv6                  229162  18 
mono640                10309  1 
libertas_sdio          14851  0 
libertas               92190  1 libertas_sdio
omap3_isp             106957  0 
cfg80211              161767  1 libertas
v4l2_common             8885  2 mono640,omap3_isp
videodev               78776  3 mono640,omap3_isp,v4l2_common
media                  12192  3 mono640,omap3_isp,videodev
lib80211                5435  1 libertas
firmware_class          6327  2 libertas_sdio,libertas
ads7846                10524  0 
root@overo:~# media-ctl -r -v -l '"mono640":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
 CCDC":1->"OMAP3 ISP CCDC output":0[1]'
Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Resetting all links to inactive
Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]
root@overo:~# media-ctl -v -f '"mono640":0[Y12 640x512], "OMAP3 ISP CCDC":1[Y12 
640x512]'
Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Setting up format Y12 640x512 on pad mono640 3-004d/0
overo: setting xclk to 25000000 hz
Format set: Y12 640x512
Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0
Format set: Y12 640x512
overo: setting xclk to 0 hz
Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1
Format set: Y12 640x512
root@overo:~# yavta -p -f Y12 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ct
l -e "OMAP3 ISP CCDC output"` --file=./DCIM/Y12
overo: setting xclk to 25000000 hz
Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
Video format set: Y12 (20323159) 640x512 buffer size 655360
Video format: Y12 (20323159) 640x512 buffer size 655360
2 buffers requested.
length: 655360 offset: 0
MMAP: Buffer 0 mapped at address 0x4010b000.
length: 655360 offset: 655360
MMAP: Buffer 1 mapped at address 0x40319000.
Press enter to start capture
yavta: video_do_capture:  calling ioctl..
^C
omap3isp omap3isp: CCDC stop timeout!

Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?

[Laurent Pinchart]

Hi James,

On Thursday 22 December 2011 07:23:56 James wrote:
>
> Tried the new yavta but encountered a different situation.
> 
> yavta -p -f Y12 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e
> "OMAP3 ISP CCDC output"` --file=./DCIM/Y12
> 
> yavta will hang for infinite time and only Ctrl+C will break out of
> the wait and a new error message appears.
> 
> yavta: video_do_capture:  calling ioctl..
> ^C
> omap3isp omap3isp: CCDC stop timeout!
> 
> I placed some debugging printf() and yavta wait at
> 
> ret = ioctl(dev->fd, VIDIOC_DQBUF, &buf);
> 
> Attached is the logfile (mono640.yavta-y12.1.log)
> 
> What should be the remedies?

The pipeline seems to be configured correctly. My guess would be that the 
sensor doesn't send what the ISP expects. You should check the sensor 
configuration, and maybe verify the pixel clock, hsync and vsync signals with 
a scope.

-- 
Regards,

Laurent Pinchart