Hi Ivan,
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]
--
Regards,
Laurent Pinchart
--
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
