RE: Help with omap3isp resizing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
> 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

Thanks for your help.
I've updated ispccdc.c to support the _1X16 codes and the pipeline seems to work now.
However, I needed to take out the memcpy in ccdc_try_format(), because otherwise pad 0 format was being copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to.
I'm not sure why it was done that way.  I think it's better that the given code gets checked to see if it's in the list and if so use it.  Do you know of any valid reason why this copy is done?

Paul
��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux