From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: video4linux-list@redhat.com
Subject: Re: [PATCH 2/2 v3] pxa-camera: pixel format negotiation
Date: Wed, 19 Nov 2008 22:29:59 +0100 [thread overview]
Message-ID: <87y6zf76aw.fsf@free.fr> (raw)
In-Reply-To: <Pine.LNX.4.64.0811182010460.8628@axis700.grange> (Guennadi Liakhovetski's message of "Tue\, 18 Nov 2008 20\:25\:56 +0100 \(CET\)")
Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:
> Use the new format-negotiation infrastructure, support all four YUV422
> packed and the planar formats.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>
> ---
Hi Guennadi,
Please find my review here.
> diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
> index 37afdfa..1bcdb5d 100644
> --- a/drivers/media/video/pxa_camera.c
> +++ b/drivers/media/video/pxa_camera.c
> @@ -765,6 +765,9 @@ static int test_platform_param(struct pxa_camera_dev *pcdev,
> if (!(pcdev->platform_flags & PXA_CAMERA_DATAWIDTH_8))
> return -EINVAL;
> *flags |= SOCAM_DATAWIDTH_8;
> + break;
> + default:
> + return -EINVAL;
If we're in pass-through mode, and depth is 16 (example: a today unknown RYB
format), we return -EINVAL. Is that on purpose ?
> -static int pxa_camera_try_bus_param(struct soc_camera_device *icd, __u32 pixfmt)
> +static int pxa_camera_try_bus_param(struct soc_camera_device *icd,
> + unsigned char buswidth)
> {
> struct soc_camera_host *ici =
> to_soc_camera_host(icd->dev.parent);
> struct pxa_camera_dev *pcdev = ici->priv;
> unsigned long bus_flags, camera_flags;
> - int ret = test_platform_param(pcdev, icd->buswidth, &bus_flags);
> + int ret = test_platform_param(pcdev, buswidth, &bus_flags);
Why do we bother testing it ? If format negociation was done before, a format
asked for is necessarily available, otherwise it should have been removed at
format generation.
Likewise, is bus param matching necessary here, or should it be done at format
generation ? Can that be really be dynamic, or is it constrained by hardware,
and thus only necessary at startup, and not at each format try ?
<snip>
> +static int pxa_camera_get_formats(struct soc_camera_device *icd, int idx,
> + const struct soc_camera_data_format **fmt)
> +{
> + struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
> + struct pxa_camera_dev *pcdev = ici->priv;
> + int formats = 0;
> +
> + switch (icd->formats[idx].fourcc) {
> + case V4L2_PIX_FMT_UYVY:
> + formats++;
> + if (fmt && (pcdev->platform_flags & PXA_CAMERA_DATAWIDTH_8)) {
> + *fmt++ = &pxa_camera_formats[0];
> + dev_dbg(&ici->dev, "Providing format %s using %s\n",
> + pxa_camera_formats[0].name,
> + icd->formats[idx].name);
> + }
> + case V4L2_PIX_FMT_VYUY:
> + case V4L2_PIX_FMT_YUYV:
> + case V4L2_PIX_FMT_YVYU:
> + case V4L2_PIX_FMT_RGB565:
> + case V4L2_PIX_FMT_RGB555:
> + formats++;
> + if (fmt && (pcdev->platform_flags & PXA_CAMERA_DATAWIDTH_8)) {
> + *fmt++ = &icd->formats[idx];
> + dev_dbg(&ici->dev, "Providing format %s packed\n",
> + icd->formats[idx].name);
> + }
> + break;
What if pcdev->platform_flags is 9 bits wide and sensor provides RGB565 ?
Variable formats will be incremented, but fmt will never be filled in. So there
will be holes in fmt. Shouldn't the formats++ depend on platform_flags &
PXA_CAMERA_DATAWIDTH_8 ?
> + default:
> + /* Generic pass-through */
> + if (depth_supported(icd, icd->formats[idx].depth)) {
> + formats++;
> + if (fmt) {
> + *fmt++ = &icd->formats[idx];
> + dev_dbg(&ici->dev,
> + "Providing format %s in pass-through mode\n",
> + icd->formats[idx].name);
> + }
> + }
> + }
Dito for formats++.
> static int pxa_camera_set_fmt(struct soc_camera_device *icd,
> __u32 pixfmt, struct v4l2_rect *rect)
<snip>
> + case V4L2_PIX_FMT_UYVY:
> + case V4L2_PIX_FMT_VYUY:
> + case V4L2_PIX_FMT_YUYV:
> + case V4L2_PIX_FMT_YVYU:
> + case V4L2_PIX_FMT_RGB565:
> + case V4L2_PIX_FMT_RGB555:
> + if (!(pcdev->platform_flags & PXA_CAMERA_DATAWIDTH_8)) {
> + dev_warn(&ici->dev,
> + "8 bit bus unsupported, but required for format %x\n",
> + pixfmt);
> + return -EINVAL;
Shouldn't that be already computed by format generation ?
> + /* Generic pass-through */
> + host_fmt = soc_camera_format_by_fourcc(icd, pixfmt);
> + if (!host_fmt || !depth_supported(icd, host_fmt->depth)) {
> + dev_warn(&ici->dev,
> + "Format %x unsupported in pass-through mode\n",
> + pixfmt);
> + return -EINVAL;
> + }
Ditto.
> @@ -930,34 +1049,70 @@ static int pxa_camera_set_fmt(struct soc_camera_device *icd,
> static int pxa_camera_try_fmt(struct soc_camera_device *icd,
> struct v4l2_format *f)
> {
> + struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
> + struct pxa_camera_dev *pcdev = ici->priv;
> const struct soc_camera_data_format *cam_fmt;
> - int ret = pxa_camera_try_bus_param(icd, f->fmt.pix.pixelformat);
> + struct v4l2_pix_format *pix = &f->fmt.pix;
> + __u32 pixfmt = pix->pixelformat;
> + unsigned char buswidth;
> + int ret;
>
> - if (ret < 0)
> - return ret;
> + switch (pixfmt) {
> + case V4L2_PIX_FMT_YUV422P:
> + pixfmt = V4L2_PIX_FMT_UYVY;
> + case V4L2_PIX_FMT_UYVY:
> + case V4L2_PIX_FMT_VYUY:
> + case V4L2_PIX_FMT_YUYV:
> + case V4L2_PIX_FMT_YVYU:
> + case V4L2_PIX_FMT_RGB565:
> + case V4L2_PIX_FMT_RGB555:
> + if (!(pcdev->platform_flags & PXA_CAMERA_DATAWIDTH_8)) {
> + dev_warn(&ici->dev,
> + "try-fmt: 8 bit bus unsupported for format %x\n",
> + pixfmt);
> + return -EINVAL;
> + }
Ditto.
>
> - /*
> - * TODO: find a suitable supported by the SoC output format, check
> - * whether the sensor supports one of acceptable input formats.
> - */
> - cam_fmt = soc_camera_format_by_fourcc(icd, f->fmt.pix.pixelformat);
> - if (!cam_fmt)
> - return -EINVAL;
> + cam_fmt = soc_camera_format_by_fourcc(icd, pixfmt);
> + if (!cam_fmt) {
> + dev_warn(&ici->dev, "try-fmt: format %x not found\n",
> + pixfmt);
> + return -EINVAL;
> + }
> + buswidth = 8;
> + break;
> + default:
> + /* Generic pass-through */
> + cam_fmt = soc_camera_format_by_fourcc(icd, pixfmt);
> + if (!cam_fmt || !depth_supported(icd, cam_fmt->depth)) {
> + dev_warn(&ici->dev,
> + "try-fmt: Format %x unsupported in pass-through\n",
> + pixfmt);
> + return -EINVAL;
> + }
> + buswidth = cam_fmt->depth;
> + }
> +
> + ret = pxa_camera_try_bus_param(icd, buswidth);
Ditto.
All in all, I wonder why we need that many tests, and if we could reduce them at
format generation (under hypothesis that platform_flags are constant and sensor
flags are constant).
--
Robert
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
next prev parent reply other threads:[~2008-11-19 23:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-18 19:25 [PATCH 0/2 v3] soc-camera: pixel format negotiation Guennadi Liakhovetski
2008-11-18 19:25 ` [PATCH 1/2 v3] soc-camera: pixel format negotiation - core support Guennadi Liakhovetski
2008-11-19 20:47 ` Robert Jarzmik
2008-11-20 19:53 ` Guennadi Liakhovetski
2008-11-18 19:25 ` [PATCH 2/2 v3] pxa-camera: pixel format negotiation Guennadi Liakhovetski
2008-11-19 21:29 ` Robert Jarzmik [this message]
2008-11-20 20:43 ` Guennadi Liakhovetski
2008-11-21 19:22 ` Robert Jarzmik
2008-11-21 20:03 ` Guennadi Liakhovetski
2008-11-21 20:53 ` Robert Jarzmik
2008-11-21 22:16 ` Guennadi Liakhovetski
2008-11-23 10:46 ` Robert Jarzmik
2008-11-23 15:26 ` Robert Jarzmik
2008-11-23 16:32 ` Guennadi Liakhovetski
2008-11-24 19:28 ` [PATCH 1/2] soc_camera: add format translation structure Robert Jarzmik
2008-11-24 19:28 ` [PATCH 2/2] pxa_camera: use the new " Robert Jarzmik
2008-11-27 23:00 ` Guennadi Liakhovetski
2008-11-28 23:27 ` Guennadi Liakhovetski
2008-11-29 12:30 ` Robert Jarzmik
2008-11-25 18:21 ` [PATCH 1/2] soc_camera: add format " Guennadi Liakhovetski
2008-11-27 21:27 ` Robert Jarzmik
2008-11-27 23:13 ` Guennadi Liakhovetski
2008-11-29 17:31 ` [PATCH v4 1/2] soc-camera: pixel format negotiation - core support Guennadi Liakhovetski
2008-11-30 17:33 ` Robert Jarzmik
2008-11-29 14:17 ` Robert Jarzmik
2008-11-29 14:17 ` [PATCH v4 2/2] pxa-camera: pixel format negotiation Robert Jarzmik
2008-11-29 15:49 ` Guennadi Liakhovetski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y6zf76aw.fsf@free.fr \
--to=robert.jarzmik@free.fr \
--cc=g.liakhovetski@gmx.de \
--cc=video4linux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.