Re: Help with omap3isp resizing from CCDC
Hi Samuel, On Friday 02 August 2013 13:12:24 samuel.rasmus...@gdc4s.com wrote: > Hi, > > I've been having problems getting the resizer to take its input from the > CCDC. From the linux-media mail-archive, it looks like Paul Chiha ran into a > similar problem in Oct 2011 with his message "Help with omap3isp resizing". > Paul had a patch at the end of the discussion, but even his patch hasn't > fixed my problem yet. I might have made a mistake porting the patch since > I'm on a newer kernel, or perhaps it doesn't work with my TVP5151 decoder. > > My setup: DM 3730 board, 3.5 kernel, and TVP5151 decoder. > > The video looks great with a 640x480 resolution, and the CCDC is de- > interlacing the video. However, for my needs the video must be resized to > 320x240 or 160x120. The video, coming from the resizer, is split into a top > and bottom half. Both halves are identical where everything in the video is > too wide and too short. The CCDC must not be de-interlacing the video going > to the resizer. I tried setting up the pipeline to send the CCDC to the > resizer, but something must have gone wrong. Unfortunately the CCDC can't deinterlace frames sent to the resizer. The deinterlacing process takes place at the CCDC output DMA engine when writing the frames to memory. There's two solutions to resize interlaced video. The first one would be to capture the deinterlaced frames at the CCDC output to memory and then use the resizer in memory-to-memory mode. The second one would be to modify the driver to support deinterlacing at the resizer output, by doubling the line offset and computing the correct start address for each odd/even frame. As you only need to downscale by two or four, another much simpler solution would be to drop every other interlaced frame. You would then get 640x240 frames that you could resize to 320x240 or 160x120 with the resizer. > Up until this point, I was using the UYVY2X8 format. Then I saw the > > discussion Paul Chiha created. In that discussion Laurent said: > > But the original poster wants to use the sensor -> ccdc -> resizer -> > > resizeroutput 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] > > I wasn't sure if Laurent's advice would also apply to the TVP5151, but I > wanted to test it out. I implemented Paul's patch so I could use the > YUYV8_2X8 and YUYV8_1X16 formats. The 640x480 resolution looked good in > the YUYV8_2X8 format. However, once again the video from the resizer > was not de-interlaced so it had a top and bottom half (using YUYV8_2X8 > and YUYV8_1X16). This time it was even worse because the video from the > resizer was very green. > > Does anyone have suggestions for resizing video from the TVP5151? > > Thanks for taking the time to read this, > Samuel > > I'm adding some media-ctl details below. > media-ctl commands I'm using: > > media-ctl -v -l '"tvp5150 3-005c":0->"OMAP3 ISP CCDC":0[1]' > media-ctl -v -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP resizer":0[1]' > media-ctl -v -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' > media-ctl -v -f '"tvp5150 3-005c":0 [YUYV2X8 640x480]' > media-ctl -v -f '"OMAP3 ISP CCDC":0 [YUYV2X8 640x480]' > media-ctl -v -f '"OMAP3 ISP CCDC":1 [YUYV 640x480]' > media-ctl -v -f '"OMAP3 ISP resizer":1 [YUYV 320x240]' > LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so mplayer tv:// -tv > driver=v4l2:device=/dev/video6 > > Output of medi-ctl -p: > > Opening media device /dev/media0 > Enumerating entities > Found 16 entities > Enumerating pads and links > Media controller API version 0.0.0 > > Media device information > > driver omap3isp > model TI OMAP3 ISP > serial > bus info > hw revision 0xf0 > driver version 0.0.0 > > Device topology > - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) > type V4L2 subdev subtype Unknown flags 0 > device node name /dev/v4l-subdev0 > pad0: Sink > [fmt:SGRBG10/4096x4096] > <- "OMAP3 ISP CCP2 input":0 [] > pad
Help with omap3isp resizing from CCDC
Hi, I've been having problems getting the resizer to take its input from the CCDC. From the linux-media mail-archive, it looks like Paul Chiha ran into a similar problem in Oct 2011 with his message "Help with omap3isp resizing". Paul had a patch at the end of the discussion, but even his patch hasn't fixed my problem yet. I might have made a mistake porting the patch since I'm on a newer kernel, or perhaps it doesn't work with my TVP5151 decoder. My setup: DM 3730 board, 3.5 kernel, and TVP5151 decoder. The video looks great with a 640x480 resolution, and the CCDC is de-interlacing the video. However, for my needs the video must be resized to 320x240 or 160x120. The video, coming from the resizer, is split into a top and bottom half. Both halves are identical where everything in the video is too wide and too short. The CCDC must not be de-interlacing the video going to the resizer. I tried setting up the pipeline to send the CCDC to the resizer, but something must have gone wrong. Up until this point, I was using the UYVY2X8 format. Then I saw the discussion Paul Chiha created. In that discussion Laurent said: >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] I wasn't sure if Laurent's advice would also apply to the TVP5151, but I wanted to test it out. I implemented Paul's patch so I could use the YUYV8_2X8 and YUYV8_1X16 formats. The 640x480 resolution looked good in the YUYV8_2X8 format. However, once again the video from the resizer was not de-interlaced so it had a top and bottom half (using YUYV8_2X8 and YUYV8_1X16). This time it was even worse because the video from the resizer was very green. Does anyone have suggestions for resizing video from the TVP5151? Thanks for taking the time to read this, Samuel I'm adding some media-ctl details below. media-ctl commands I'm using: media-ctl -v -l '"tvp5150 3-005c":0->"OMAP3 ISP CCDC":0[1]' media-ctl -v -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP resizer":0[1]' media-ctl -v -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' media-ctl -v -f '"tvp5150 3-005c":0 [YUYV2X8 640x480]' media-ctl -v -f '"OMAP3 ISP CCDC":0 [YUYV2X8 640x480]' media-ctl -v -f '"OMAP3 ISP CCDC":1 [YUYV 640x480]' media-ctl -v -f '"OMAP3 ISP resizer":1 [YUYV 320x240]' LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so mplayer tv:// -tv driver=v4l2:device=/dev/video6 Output of medi-ctl -p: Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver omap3isp model TI OMAP3 ISP serial bus info hw revision 0xf0 driver version 0.0.0 Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 pad0: Sink [fmt:SGRBG10/4096x4096] <- "OMAP3 ISP CCP2 input":0 [] pad1: Source [fmt:SGRBG10/4096x4096] -> "OMAP3 ISP CCDC":0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: Source -> "OMAP3 ISP CCP2":0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Sink [fmt:SGRBG10/4096x4096] pad1: Source [fmt:SGRBG10/4096x4096] -> "OMAP3 ISP CSI2a output":0 [] -> "OMAP3 ISP CCDC":0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video1 pad0: Sink <- "OMAP3 ISP CSI2a":1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:YUYV2X8/640x480] <- "OMAP3 ISP CCP2":1 [] <- "OMAP3 ISP CSI2a":1 [] <- "tvp5150 3-005c":0 [ENABLED]
Re: Help with omap3isp resizing
On Wednesday, 5 October 2011 9:55 PM Sakari Ailus wrote:
> On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote:
> > 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?
>
> If I remember corretly, it's because there's nothing the CCDC may do
to the size
> of the image --- the driver doesn't either support cropping on the
CCDC. The sink
> format used to be always the same as the source format, the assumption
which
> no longer is valid when YUYV8_2X8 etc. formats are supported. This
must be
> taken into account, i.e. YUYV8_2X8 must be converted to YUYV8_
Re: Help with omap3isp resizing
On Wed, Oct 5, 2011 at 3:42 PM, Sakari Ailus wrote: > On Wed, Oct 05, 2011 at 03:09:48PM +0200, Enrico wrote: >> On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus wrote: >> > On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote: >> >> 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? >> > >> > If I remember corretly, it's because there's nothing the CCDC may do to the >> > size of the image --- the driver doesn't either support cropping on the >> > CCDC. The sink format used to be always the same as the source format, the >> > assumption which no longer is valid when YUYV8_2X8 etc. formats are >> > supported. This must be taken into account, i.e. YUYV8_2X8 must be >> > converted >> > to YUYV8_1X16 instead of just copying the format as such. >> >> Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems >> possible to set some registers (start pixel horizontal/vertical and so >> on...) to crop the "final" image, but i never tested it. > > Yeah; cropping should work fine on the CCDC as well but the driver doesn't > implement it. > Hello, Yes, cropping with the CCDC is possible, we modified the driver to only get the active lines of a frame. This is a small part of our patch that configures the CCDC to decide what is the first line to output to memory for both even and odd fields. + if (pdata->is_bt656) + if (format->priv == V4L2_STD_PAL) + isp_reg_writel(isp, (PAL_NON_ACTIVE << +ISPCCDC_VERT_START_SLV0_SHIFT | +PAL_NON_ACTIVE << +ISPCCDC_VERT_START_SLV1_SHIFT), + OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START); + else if (format->priv == V4L2_STD_NTSC) + isp_reg_writel(isp, (NTSC_NON_ACTIVE << +ISPCCDC_VERT_START_SLV0_SHIFT | +NTSC_NON_ACTIVE << +ISPCCDC_VERT_START_SLV1_SHIFT), + OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START); As I told in a previous email [1] we are working to get add proper support for ITU-R BT656 video data using the ISP and a TVP5151 video encoder. We are kind of busy to get this working for our tree. But once it is done, I'll forward port to the last ISP driver and post for review. [1]: http://www.spinics.net/lists/linux-media/msg38715.html Best regards, > -- > Sakari Ailus > e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk > -- > 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 > -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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
Re: Help with omap3isp resizing
On Wed, Oct 05, 2011 at 03:09:48PM +0200, Enrico wrote: > On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus wrote: > > On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote: > >> 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? > > > > If I remember corretly, it's because there's nothing the CCDC may do to the > > size of the image --- the driver doesn't either support cropping on the > > CCDC. The sink format used to be always the same as the source format, the > > assumption which no longer is valid when YUYV8_2X8 etc. formats are > > supported. This must be taken into account, i.e. YUYV8_2X8 must be converted > > to YUYV8_1X16 instead of just copying the format as such. > > Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems > possible to set some registers (start pixel horizontal/vertical and so > on...) to crop the "final" image, but i never tested it. Yeah; cropping should work fine on the CCDC as well but the driver doesn't implement it. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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
Re: Help with omap3isp resizing
On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus wrote: > On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote: >> 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? > > If I remember corretly, it's because there's nothing the CCDC may do to the > size of the image --- the driver doesn't either support cropping on the > CCDC. The sink format used to be always the same as the source format, the > assumption which no longer is valid when YUYV8_2X8 etc. formats are > supported. This must be taken into account, i.e. YUYV8_2X8 must be converted > to YUYV8_1X16 instead of just copying the format as such. Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems possible to set some registers (start pixel horizontal/vertical and so on...) to crop the "final" image, but i never tested it. Enrico -- 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
Re: Help with omap3isp resizing
On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote:
> 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?
If I remember corretly, it's because there's nothing the CCDC may do to the
size of the image --- the driver doesn't either support cropping on the
CCDC. The sink format used to be always the same as the source format, the
assumption which no longer is valid when YUYV8_2X8 etc. formats are
supported. This must be taken into account, i.e. YUYV8_2X8 must be converted
to YUYV8_1X16 instead of just copying the format as such.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More maj
RE: Help with omap3isp resizing
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�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: Help with omap3isp resizing
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.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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
Re: Help with omap3isp resizing
Hi Laurent,
On Tue, 2011-10-04 at 15:00 +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.
Ah, right, i have miss that,
>
> > 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]
>
This sound simpler and reasonable. In this case maybe for every
reference to V4L2_MBUS_FMT_8_2X8 in ispccdc.c, additional
V4L2_MBUS_FMT_xxx8_1X16 can be added.
Regards,
iivanov
--
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
Re: Help with omap3isp resizing
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
Re: Help with omap3isp resizing
Hi Paul,
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
> Hi Paul,
>
> 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,
};
static unsigned int resizer_max_in_width(struct isp_res_device *res)
@@ -1340,12 +1348,21 @@ static void resizer_try_format(struct isp_res_device
*res,
struct resizer_ratio ratio;
struct v4l2_rect crop;
+ switch (fmt->code) {
+
+ case V4L2_MBUS_FMT_YUYV8_1X16:
+ case V4L2_MBUS_FMT_UYVY8_1X16:
+ case V4L2_MBUS_FMT_UYVY8_2X8:
+ case V4L2_MBUS_FMT_VYUY8_2X8:
+ case V4L2_MBUS_FMT_YUYV8_2X8:
+ case V4L2_MBUS_FMT_YVYU8_2X8:
+ break;
+ default:
+ fmt->code = V4L2_MBUS_FMT_YUYV8_1X16;
+ }
+
switch (pad) {
case RESZ_PAD_SINK:
- if (fmt->code != V4L2_MBUS_FMT_YUYV8_1X16 &&
- fmt->code != V4L2_MBUS_FMT_UYVY8_1X16)
- fmt->code = V4L2_MBUS_FMT_YUYV8_1X16;
-
fmt->width = clamp_t(u32, fmt->width, MIN_IN_WIDTH,
resizer_max_in_width(res));
fmt->height = clamp_t(u32, fmt->height, MIN_IN_HEIGHT,
--
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
Re: Help with omap3isp resizing
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with omap3isp resizing
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 ?
> static unsigned int resizer_max_in_width(struct isp_res_device *res)
> @@ -1340,12 +1348,21 @@ static void resizer_try_format(struct
> isp_res_device *res, struct resizer_ratio ratio;
> struct v4l2_rect crop;
>
> + switch (fmt->code) {
> +
> + case V4L2_MBUS_FMT_YUYV8_1X16:
> + case V4L2_MBUS_FMT_UYVY8_1X16:
> + case V4L2_MBUS_FMT_UYVY8_2X8:
> + case V4L2_MBUS_FMT_VYUY8_2X8:
> + case V4L2_MBUS_FMT_YUYV8_2X8:
> + case V4L2_MBUS_FMT_YVYU8_2X8:
> + break;
> + default:
> + fmt->code = V4L2_MBUS_FMT_YUYV8_1X16;
> + }
> +
> switch (pad) {
> case RESZ_PAD_SINK:
> - if (fmt->code != V4L2_MBUS_FMT_YUYV8_1X16 &&
> - fmt->code != V4L2_MBUS_FMT_UYVY8_1X16)
> - fmt->code = V4L2_MBUS_FMT_YUYV8_1X16;
> -
> fmt->width = clamp_t(u32, fmt->width, MIN_IN_WIDTH,
>resizer_max_in_width(res));
> fmt->height = clamp_t(u32, fmt->height, MIN_IN_HEIGHT,
--
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
Re: Help with omap3isp resizing
Hi Paul, 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. -- 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
Help with omap3isp resizing
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? Thanks, Paul -- 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
