On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
> Hi Ivan,
Hi all,
> On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
> > On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
> > > On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
> > > > On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
> > > > > On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I've been having trouble getting the resizer to work, and mainly
> > > > > > because I don't know how to correctly configure it.
> > > > > > I'm using kernel 2.6.37 on arm DM37x board.
> > > > > >
> > > > > > I've been able to configure the media links
> > > > > > sensor=>ccdc=>ccdc_output (all with 640x480
> > > > > > V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on /dev/video2.
> > > > > > But if I configure media links
> > > > > > sensor=>ccdc=>resizer=>resizer_output, then VIDIOC_STREAMON fails
> > > > > > on /dev/video6 (with pixelformat mismatch). I noticed that the
> > > > > > resizer driver only supports
> > > > > > V4L2_MBUS_FMT_UYVY8_1X16 & V4L2_MBUS_FMT_YUYV8_1X16, so I tried
> > > > > > again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead,
> > > > > > but then ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8,
> > > > > > because the sensor driver doesn't support 1X16.
> > > > > > Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
> > > > > > V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
> > > > > > pixelformat mismatch or link pipeline mismatch, depending on which
> > > > > > pads were different.
> > > > > >
> > > > > > Can someone please tell me what I need to do to make this work?
> > > > >
> > > > > Long story short, I don't think that pipeline has ever been tested.
> > > > > I'm unfortunately lacking hardware to work on that, as none of my
> > > > > OMAP3 hardware has a YUV input.
> > > >
> > > > If i am not mistaken currently resizer sub device supports only:
> > > >
> > > > /* resizer pixel formats */
> > > > static const unsigned int resizer_formats[] = {
> > > >
> > > > V4L2_MBUS_FMT_UYVY8_1X16,
> > > > V4L2_MBUS_FMT_YUYV8_1X16,
> > > >
> > > > };
> > > >
> > > > Adding something like this [1] in ispresizer.c should add
> > > > support 2X8 formats. Completely untested :-).
> > > >
> > > > Regards,
> > > > iivanov
> > > >
> > > >
> > > > [1]
> > > >
> > > > @@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct v4l2_subdev
> > > > *sd, struct v4l2_subdev_fh *fh, static const unsigned int
> > > > resizer_formats[] = {
> > > >
> > > > V4L2_MBUS_FMT_UYVY8_1X16,
> > > > V4L2_MBUS_FMT_YUYV8_1X16,
> > > >
> > > > + V4L2_MBUS_FMT_UYVY8_2X8,
> > > > + V4L2_MBUS_FMT_VYUY8_2X8,
> > > > + V4L2_MBUS_FMT_YUYV8_2X8,
> > > > + V4L2_MBUS_FMT_YVYU8_2X8,
> > > >
> > > > };
> > >
> > > I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What do
> > > you think ?
> >
> > For memory->Resizer->memory use cases, CCDC is no involved in pipeline.
>
> But the original poster wants to use the sensor -> ccdc -> resizer -> resizer
> output pipeline.
>
> > Also several sensor drivers that i have checked, usually define its
> > output as 2X8 output. I think is more natural to add 2X8 support to
> > CCDC and Resizer engines instead to modifying exiting drivers.
>
> Sure, sensor drivers should not be modified. What I was talking about was to
> configure the pipeline as
>
> sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0
> [YUYV8_1X16]
Looks good to me. This also does reflect the real bus formats in the device
quite well; the links from ccdc onwards only use one clock cycle for sample.
--
Sakari Ailus
e-mail: sakari.ailus@xxxxxx jabber/XMPP/Gmail: sailus@xxxxxxxxxxxxxx
--
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
