Hi Laurent,
On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
> Hi Ivan,
>
> 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.
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.
Regards,
iivanov
--
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
