omap34xxcam question?

omap34xxcam question?

[Michael Trimarchi]

Hi

Is ok that it try only the first format and size? why does it not continue and find a matching?

@@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev,
                        pix_tmp_out = *wanted_pix_out;
                        rval = isp_try_fmt_cap(isp, &pix_tmp_in, &pix_tmp_out);
                        if (rval)
-                               return rval;
+                               continue;

Michael

RE: omap34xxcam question?

[Aguirre, Sergio]

> -----Original Message-----
> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
> Sent: Thursday, January 14, 2010 6:01 AM
> To: linux-media@vger.kernel.org
> Cc: Aguirre, Sergio
> Subject: omap34xxcam question?
> 
> Hi
> 
> Is ok that it try only the first format and size? why does it not continue
> and find a matching?

Actually, that was the intention, but I guess it was badly implemented.

Thanks for the catch, and the contribution!

Regards,
Sergio
> 
> @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev
> *vdev,
>                         pix_tmp_out = *wanted_pix_out;
>                         rval = isp_try_fmt_cap(isp, &pix_tmp_in,
> &pix_tmp_out);
>                         if (rval)
> -                               return rval;
> +                               continue;
> 
> Michael

Re: omap34xxcam question?

[Michael Trimarchi]

Hi,

Aguirre, Sergio wrote:
> 
>> -----Original Message-----
>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
>> Sent: Thursday, January 14, 2010 6:01 AM
>> To: linux-media@vger.kernel.org
>> Cc: Aguirre, Sergio
>> Subject: omap34xxcam question?
>>
>> Hi
>>
>> Is ok that it try only the first format and size? why does it not continue
>> and find a matching?
> 
> Actually, that was the intention, but I guess it was badly implemented.
> 
> Thanks for the catch, and the contribution!
> 
> Regards,
> Sergio
>> @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev
>> *vdev,
>>                         pix_tmp_out = *wanted_pix_out;
>>                         rval = isp_try_fmt_cap(isp, &pix_tmp_in,
>> &pix_tmp_out);
>>                         if (rval)
>> -                               return rval;
>> +                               continue;
>>

Is the patch good? or you are going to provide a better fix

Michael

>> Michael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: omap34xxcam question?

[Aguirre, Sergio]

> -----Original Message-----
> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
> Sent: Thursday, January 14, 2010 11:25 AM
> To: Aguirre, Sergio
> Cc: linux-media@vger.kernel.org
> Subject: Re: omap34xxcam question?
> 
> Hi,
> 
> Aguirre, Sergio wrote:
> >
> >> -----Original Message-----
> >> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
> >> Sent: Thursday, January 14, 2010 6:01 AM
> >> To: linux-media@vger.kernel.org
> >> Cc: Aguirre, Sergio
> >> Subject: omap34xxcam question?
> >>
> >> Hi
> >>
> >> Is ok that it try only the first format and size? why does it not
> continue
> >> and find a matching?
> >
> > Actually, that was the intention, but I guess it was badly implemented.
> >
> > Thanks for the catch, and the contribution!
> >
> > Regards,
> > Sergio
> >> @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev
> >> *vdev,
> >>                         pix_tmp_out = *wanted_pix_out;
> >>                         rval = isp_try_fmt_cap(isp, &pix_tmp_in,
> >> &pix_tmp_out);
> >>                         if (rval)
> >> -                               return rval;
> >> +                               continue;
> >>
> 
> Is the patch good? or you are going to provide a better fix

Yes. Sorry if I wasn't clear enough.

Looks good to me, and I don't have a better fix on top of my head for the moment...

I'm assuming you tested it in your environment, right?

If yes, then I'll take the patch in my queue for submission to Sakari's tree.

Thanks for your time.

Regards,
Sergio

> 
> Michael
> 
> >> Michael
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

Re: omap34xxcam question?

[Michael Trimarchi]

Aguirre, Sergio wrote:
> 
>> -----Original Message-----
>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
>> Sent: Thursday, January 14, 2010 11:25 AM
>> To: Aguirre, Sergio
>> Cc: linux-media@vger.kernel.org
>> Subject: Re: omap34xxcam question?
>>
>> Hi,
>>
>> Aguirre, Sergio wrote:
>>>> -----Original Message-----
>>>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
>>>> Sent: Thursday, January 14, 2010 6:01 AM
>>>> To: linux-media@vger.kernel.org
>>>> Cc: Aguirre, Sergio
>>>> Subject: omap34xxcam question?
>>>>
>>>> Hi
>>>>
>>>> Is ok that it try only the first format and size? why does it not
>> continue
>>>> and find a matching?
>>> Actually, that was the intention, but I guess it was badly implemented.
>>>
>>> Thanks for the catch, and the contribution!
>>>
>>> Regards,
>>> Sergio
>>>> @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev
>>>> *vdev,
>>>>                         pix_tmp_out = *wanted_pix_out;
>>>>                         rval = isp_try_fmt_cap(isp, &pix_tmp_in,
>>>> &pix_tmp_out);
>>>>                         if (rval)
>>>> -                               return rval;
>>>> +                               continue;
>>>>
>> Is the patch good? or you are going to provide a better fix
> 
> Yes. Sorry if I wasn't clear enough.
> 
> Looks good to me, and I don't have a better fix on top of my head for the moment...
> 
> I'm assuming you tested it in your environment, right?

Ok, my enviroment is not pretty stable but for sure this is required. There is one problem:

Suppose that the camera support this format:

YUV and RAW10

The video4linux enumeration is done in this order. 
We know that if you want to use resizer and previewer we can't use the YUV (go straight to memory)
but it is selected because is the first. So maybe the best thing is to find the one that is suggest in the csi 
configuration first. Hope that is clear.

Michael

> 
> If yes, then I'll take the patch in my queue for submission to Sakari's tree.
> 
> Thanks for your time.
> 
> Regards,
> Sergio
> 
>> Michael
>>
>>>> Michael
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media"
>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[RFC PATCH] fix try_pix_parm loop

[Michael Trimarchi]

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



[-- Attachment #2: dont-skip-format.patch --]
[-- Type: text/x-diff, Size: 765 bytes --]

This patch fix try_pix_parm loop that try to find a suitable format for
the isp engine

Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
Cc: akari Ailus <sakari.ailus@maxwell.research.nokia.com>
Cc: Sergio Aguirre <saaguirre@ti.com>

---
diff --git a/drivers/media/video/omap34xxcam.c b/drivers/media/video/omap34xxcam.c
index 53b587e..bf7db71 100644
--- a/drivers/media/video/omap34xxcam.c
+++ b/drivers/media/video/omap34xxcam.c
@@ -470,7 +470,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev,
 			pix_tmp_out = *wanted_pix_out;
 			rval = isp_try_fmt_cap(isp, &pix_tmp_in, &pix_tmp_out);
 			if (rval)
-				return rval;
+				continue;
 
 			dev_dbg(&vdev->vfd->dev, "this w %d\th %d\tfmt %8.8x\t"
 				"-> w %d\th %d\t fmt %8.8x"

RE: omap34xxcam question?

[Aguirre, Sergio]

> -----Original Message-----
> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
> Sent: Thursday, January 14, 2010 11:39 AM
> To: Aguirre, Sergio
> Cc: linux-media@vger.kernel.org
> Subject: Re: omap34xxcam question?
> 
> Aguirre, Sergio wrote:
> >
> >> -----Original Message-----
> >> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
> >> Sent: Thursday, January 14, 2010 11:25 AM
> >> To: Aguirre, Sergio
> >> Cc: linux-media@vger.kernel.org
> >> Subject: Re: omap34xxcam question?
> >>
> >> Hi,
> >>
> >> Aguirre, Sergio wrote:
> >>>> -----Original Message-----
> >>>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
> >>>> Sent: Thursday, January 14, 2010 6:01 AM
> >>>> To: linux-media@vger.kernel.org
> >>>> Cc: Aguirre, Sergio
> >>>> Subject: omap34xxcam question?
> >>>>
> >>>> Hi
> >>>>
> >>>> Is ok that it try only the first format and size? why does it not
> >> continue
> >>>> and find a matching?
> >>> Actually, that was the intention, but I guess it was badly
> implemented.
> >>>
> >>> Thanks for the catch, and the contribution!
> >>>
> >>> Regards,
> >>> Sergio
> >>>> @@ -470,7 +471,7 @@ static int try_pix_parm(struct
> omap34xxcam_videodev
> >>>> *vdev,
> >>>>                         pix_tmp_out = *wanted_pix_out;
> >>>>                         rval = isp_try_fmt_cap(isp, &pix_tmp_in,
> >>>> &pix_tmp_out);
> >>>>                         if (rval)
> >>>> -                               return rval;
> >>>> +                               continue;
> >>>>
> >> Is the patch good? or you are going to provide a better fix
> >
> > Yes. Sorry if I wasn't clear enough.
> >
> > Looks good to me, and I don't have a better fix on top of my head for
> the moment...
> >
> > I'm assuming you tested it in your environment, right?
> 
> Ok, my enviroment is not pretty stable but for sure this is required.
> There is one problem:
> 
> Suppose that the camera support this format:
> 
> YUV and RAW10
> 
> The video4linux enumeration is done in this order.
> We know that if you want to use resizer and previewer we can't use the YUV
> (go straight to memory)
> but it is selected because is the first. So maybe the best thing is to
> find the one that is suggest in the csi
> configuration first. Hope that is clear.

Hmm.. I see.

So, if I got you right, you're saying that, there should be priorities for sensor baseformats, depending on the preference specified somewhere in the boardfile?

Regards,
Sergio
> 
> Michael
> 
> >
> > If yes, then I'll take the patch in my queue for submission to Sakari's
> tree.
> >
> > Thanks for your time.
> >
> > Regards,
> > Sergio
> >
> >> Michael
> >>
> >>>> Michael
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-media"
> >> in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

Re: omap34xxcam question?

[Michael Trimarchi]

Aguirre, Sergio wrote:
> 
>> -----Original Message-----
>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
>> Sent: Thursday, January 14, 2010 11:39 AM
>> To: Aguirre, Sergio
>> Cc: linux-media@vger.kernel.org
>> Subject: Re: omap34xxcam question?
>>
>> Aguirre, Sergio wrote:
>>>> -----Original Message-----
>>>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
>>>> Sent: Thursday, January 14, 2010 11:25 AM
>>>> To: Aguirre, Sergio
>>>> Cc: linux-media@vger.kernel.org
>>>> Subject: Re: omap34xxcam question?
>>>>
>>>> Hi,
>>>>
>>>> Aguirre, Sergio wrote:
>>>>>> -----Original Message-----
>>>>>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
>>>>>> Sent: Thursday, January 14, 2010 6:01 AM
>>>>>> To: linux-media@vger.kernel.org
>>>>>> Cc: Aguirre, Sergio
>>>>>> Subject: omap34xxcam question?
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Is ok that it try only the first format and size? why does it not
>>>> continue
>>>>>> and find a matching?
>>>>> Actually, that was the intention, but I guess it was badly
>> implemented.
>>>>> Thanks for the catch, and the contribution!
>>>>>
>>>>> Regards,
>>>>> Sergio
>>>>>> @@ -470,7 +471,7 @@ static int try_pix_parm(struct
>> omap34xxcam_videodev
>>>>>> *vdev,
>>>>>>                         pix_tmp_out = *wanted_pix_out;
>>>>>>                         rval = isp_try_fmt_cap(isp, &pix_tmp_in,
>>>>>> &pix_tmp_out);
>>>>>>                         if (rval)
>>>>>> -                               return rval;
>>>>>> +                               continue;
>>>>>>
>>>> Is the patch good? or you are going to provide a better fix
>>> Yes. Sorry if I wasn't clear enough.
>>>
>>> Looks good to me, and I don't have a better fix on top of my head for
>> the moment...
>>> I'm assuming you tested it in your environment, right?
>> Ok, my enviroment is not pretty stable but for sure this is required.
>> There is one problem:
>>
>> Suppose that the camera support this format:
>>
>> YUV and RAW10
>>
>> The video4linux enumeration is done in this order.
>> We know that if you want to use resizer and previewer we can't use the YUV
>> (go straight to memory)
>> but it is selected because is the first. So maybe the best thing is to
>> find the one that is suggest in the csi
>> configuration first. Hope that is clear.
> 
> Hmm.. I see.
> 
> So, if I got you right, you're saying that, there should be priorities for sensor baseformats, depending on the preference specified somewhere in the boardfile?

Yes, that is the idea. Try to provide a better patch later, I'm working hard on the sensor part :)

Michael

> 
> Regards,
> Sergio
>> Michael
>>
>>> If yes, then I'll take the patch in my queue for submission to Sakari's
>> tree.
>>> Thanks for your time.
>>>
>>> Regards,
>>> Sergio
>>>
>>>> Michael
>>>>
>>>>>> Michael
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-media"
>>>> in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media"
>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: omap34xxcam question?

[Michael Trimarchi]

Michael Trimarchi wrote:
> Aguirre, Sergio wrote:
>>
>>> -----Original Message-----
>>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
>>> Sent: Thursday, January 14, 2010 11:39 AM
>>> To: Aguirre, Sergio
>>> Cc: linux-media@vger.kernel.org
>>> Subject: Re: omap34xxcam question?
>>>
>>> Aguirre, Sergio wrote:
>>>>> -----Original Message-----
>>>>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
>>>>> Sent: Thursday, January 14, 2010 11:25 AM
>>>>> To: Aguirre, Sergio
>>>>> Cc: linux-media@vger.kernel.org
>>>>> Subject: Re: omap34xxcam question?
>>>>>
>>>>> Hi,
>>>>>
>>>>> Aguirre, Sergio wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Michael Trimarchi [mailto:michael@panicking.kicks-ass.org]
>>>>>>> Sent: Thursday, January 14, 2010 6:01 AM
>>>>>>> To: linux-media@vger.kernel.org
>>>>>>> Cc: Aguirre, Sergio
>>>>>>> Subject: omap34xxcam question?
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Is ok that it try only the first format and size? why does it not
>>>>> continue
>>>>>>> and find a matching?
>>>>>> Actually, that was the intention, but I guess it was badly
>>> implemented.
>>>>>> Thanks for the catch, and the contribution!
>>>>>>
>>>>>> Regards,
>>>>>> Sergio
>>>>>>> @@ -470,7 +471,7 @@ static int try_pix_parm(struct
>>> omap34xxcam_videodev
>>>>>>> *vdev,
>>>>>>>                         pix_tmp_out = *wanted_pix_out;
>>>>>>>                         rval = isp_try_fmt_cap(isp, &pix_tmp_in,
>>>>>>> &pix_tmp_out);
>>>>>>>                         if (rval)
>>>>>>> -                               return rval;
>>>>>>> +                               continue;
>>>>>>>
>>>>> Is the patch good? or you are going to provide a better fix
>>>> Yes. Sorry if I wasn't clear enough.
>>>>
>>>> Looks good to me, and I don't have a better fix on top of my head for
>>> the moment...
>>>> I'm assuming you tested it in your environment, right?
>>> Ok, my enviroment is not pretty stable but for sure this is required.
>>> There is one problem:
>>>
>>> Suppose that the camera support this format:
>>>
>>> YUV and RAW10
>>>
>>> The video4linux enumeration is done in this order.
>>> We know that if you want to use resizer and previewer we can't use 
>>> the YUV
>>> (go straight to memory)
>>> but it is selected because is the first. So maybe the best thing is to
>>> find the one that is suggest in the csi
>>> configuration first. Hope that is clear.
>>
>> Hmm.. I see.
>>
>> So, if I got you right, you're saying that, there should be priorities 
>> for sensor baseformats, depending on the preference specified 
>> somewhere in the boardfile?
> 
> Yes, that is the idea. Try to provide a better patch later, I'm working 
> hard on the sensor part :)
> 

diff --git a/drivers/media/video/omap34xxcam.c b/drivers/media/video/omap34xxcam
index 53b587e..75bd858 100644
--- a/drivers/media/video/omap34xxcam.c
+++ b/drivers/media/video/omap34xxcam.c
@@ -448,6 +448,10 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev,
                        break;
                dev_dbg(&vdev->vfd->dev, "trying fmt %8.8x (%d)\n",
                        fmtd.pixelformat, fmtd_index);
+
+               if (fmtd.pixelformat != best_pix_in->pixelformat)
+                       continue;
+
                /*
                 * Get supported resolutions.
                 */
@@ -470,7 +474,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev,
                        pix_tmp_out = *wanted_pix_out;
                        rval = isp_try_fmt_cap(isp, &pix_tmp_in, &pix_tmp_out);
                        if (rval)
-                               return rval;
+                               continue;
 
                        dev_dbg(&vdev->vfd->dev, "this w %d\th %d\tfmt %8.8x\t"

Somenthing like that.

michael
> Michael
> 
>>
>> Regards,
>> Sergio
>>> Michael
>>>
>>>> If yes, then I'll take the patch in my queue for submission to Sakari's
>>> tree.
>>>> Thanks for your time.
>>>>
>>>> Regards,
>>>> Sergio
>>>>
>>>>> Michael
>>>>>
>>>>>>> Michael
>>>>>> -- 
>>>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>>>> linux-media"
>>>>> in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>> -- 
>>>> To unsubscribe from this list: send the line "unsubscribe linux-media"
>>> in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: omap34xxcam question?

[Sakari Ailus]

Hi Michael,

Michael Trimarchi wrote:
> Aguirre, Sergio wrote:
...
>> So, if I got you right, you're saying that, there should be priorities
>> for sensor baseformats, depending on the preference specified
>> somewhere in the boardfile?
> 
> Yes, that is the idea. Try to provide a better patch later, I'm working
> hard on the sensor part :)

Apologies for my late answer.

The frame sizes in our sensor drivers are in width descending order. The
selection has been working somehow so far but it's definitely not perfect.

We're converting the ISP driver to use the Media controller so this code
will be dropped in near future probably. In that case the user space has
to select the sensor mode it wants to use as well.

Regular V4L2 applications of course cannot be expected to do that. But
it probably should be handled in user space (i.e. libv4l) or by offering
a dummy video node that just produces some kind of images.

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

Re: omap34xxcam question?

[Michael Trimarchi]

Hi,

Sakari Ailus wrote:
> Hi Michael,
> 
> Michael Trimarchi wrote:
>> Aguirre, Sergio wrote:
> ...
>>> So, if I got you right, you're saying that, there should be priorities
>>> for sensor baseformats, depending on the preference specified
>>> somewhere in the boardfile?
>> Yes, that is the idea. Try to provide a better patch later, I'm working
>> hard on the sensor part :)
> 
> Apologies for my late answer.

No problem on that

> 
> The frame sizes in our sensor drivers are in width descending order. The
> selection has been working somehow so far but it's definitely not perfect.
> 

Ok for the frame size but you need to test all the possible sensor output
too and continue in case of error.

> We're converting the ISP driver to use the Media controller so this code
> will be dropped in near future probably. In that case the user space has
> to select the sensor mode it wants to use as well.
> 

Good.

Maybe I can test the framework on the FLOW1.5 mobile device using the TCM8240MD

What is your git for the camera framework?


Michael

Re: omap34xxcam question?

[Sakari Ailus]

Michael Trimarchi wrote:
> Hi,

Hi,

> Sakari Ailus wrote:
>> Hi Michael,
...
>> The frame sizes in our sensor drivers are in width descending order. The
>> selection has been working somehow so far but it's definitely not
>> perfect.
>>
> 
> Ok for the frame size but you need to test all the possible sensor output
> too and continue in case of error.

The try function should return an error only in real error cases, not
otherwise.

But as I said, this code will be removed soon from that driver...

>> We're converting the ISP driver to use the Media controller so this code
>> will be dropped in near future probably. In that case the user space has
>> to select the sensor mode it wants to use as well.
>>
> 
> Good.
> 
> Maybe I can test the framework on the FLOW1.5 mobile device using the
> TCM8240MD
> 
> What is your git for the camera framework?

It's all available here but I'm afraid you'll have to wait a bit first.
The legacy nodes (per sensor devices) are the only ones in existence at
the moment.

<URL:http://www.gitorious.org/projects/omap3camera>

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com