Re: omap34xxcam question?

2010-02-04 Thread 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.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap34xxcam question?

2010-02-04 Thread 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


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


Re: omap34xxcam question?

2010-02-04 Thread 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.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap34xxcam question?

2010-01-19 Thread Michael Trimarchi

Michael Trimarchi wrote:

Aguirre, Sergio wrote:



-Original Message-
From: Michael Trimarchi [mailto:mich...@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:mich...@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:mich...@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 majord...@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 majord...@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 majord...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap34xxcam question?

2010-01-15 Thread Michael Trimarchi

Aguirre, Sergio wrote:



-Original Message-
From: Michael Trimarchi [mailto:mich...@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:mich...@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:mich...@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 majord...@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 majord...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: omap34xxcam question?

2010-01-14 Thread Aguirre, Sergio


 -Original Message-
 From: Michael Trimarchi [mailto:mich...@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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap34xxcam question?

2010-01-14 Thread Michael Trimarchi

Hi,

Aguirre, Sergio wrote:



-Original Message-
From: Michael Trimarchi [mailto:mich...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: omap34xxcam question?

2010-01-14 Thread Aguirre, Sergio


 -Original Message-
 From: Michael Trimarchi [mailto:mich...@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:mich...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap34xxcam question?

2010-01-14 Thread Michael Trimarchi

Aguirre, Sergio wrote:



-Original Message-
From: Michael Trimarchi [mailto:mich...@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:mich...@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 majord...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: omap34xxcam question?

2010-01-14 Thread Aguirre, Sergio


 -Original Message-
 From: Michael Trimarchi [mailto:mich...@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:mich...@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:mich...@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 majord...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html