Michael Trimarchi wrote:
Aguirre, Sergio wrote:
-----Original Message-----
From: Michael Trimarchi [mailto:michael@xxxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, January 14, 2010 11:39 AM
To: Aguirre, Sergio
Cc: linux-media@xxxxxxxxxxxxxxx
Subject: Re: omap34xxcam question?
Aguirre, Sergio wrote:
-----Original Message-----
From: Michael Trimarchi [mailto:michael@xxxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, January 14, 2010 11:25 AM
To: Aguirre, Sergio
Cc: linux-media@xxxxxxxxxxxxxxx
Subject: Re: omap34xxcam question?
Hi,
Aguirre, Sergio wrote:
-----Original Message-----
From: Michael Trimarchi [mailto:michael@xxxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, January 14, 2010 6:01 AM
To: linux-media@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
