Re: SoC Camera driver and TV decoder

Re: SoC Camera driver and TV decoder

[Janusz Uzycki]

Hello Guennadi again.

I patched tvp5150.c according to tw9910 driver (without real cropping 
support yet).
Unfortunately I got the messages:
camera 0-0: Probing 0-0
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
tvp5150 0-005d: chip found @ 0xba (i2c-sh_mobile)
tvp5150 0-005d: tvp5150am1 detected.
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 
0
camera: probe of 0-0 failed with error -515

I have also found 2 patches here http://www.sleepyrobot.com/?cat=3 but it 
does not support soc camera also.

kind regards
Janusz

my "copy-paste" patch:
--- tvp5150.c.orig      2011-01-27 08:56:34.454572019 +0100
+++ tvp5150.c   2011-01-27 17:04:38.786072092 +0100
@@ -2,6 +2,7 @@
  * tvp5150 - Texas Instruments TVP5150A/AM1 video decoder driver
  *
  * Copyright (c) 2005,2006 Mauro Carvalho Chehab (mchehab@infradead.org)
+ * Copyright (c) 2011 Janusz Uzycki (j.uzycki@elproma.com.pl) - SoC camera 
API
  * This code is placed under the terms of the GNU General Public License v2
  */

@@ -13,6 +14,7 @@
 #include <media/tvp5150.h>
 #include <media/v4l2-i2c-drv.h>
 #include <media/v4l2-chip-ident.h>
+#include <media/soc_camera.h>

 #include "tvp5150_reg.h"

@@ -25,6 +27,135 @@
 module_param(debug, int, 0);
 MODULE_PARM_DESC(debug, "Debug level (0-2)");

+struct tvp5150_scale_ctrl {
+       char           *name;
+       unsigned short  width;
+       unsigned short  height;
+       u16             hscale;
+       u16             vscale;
+};
+
+static const struct tvp5150_scale_ctrl tvp5150_ntsc_scales[] = {
+       {
+               .name   = "NTSC SQ",
+               .width  = 640,
+               .height = 480,
+               .hscale = 0x0100,
+               .vscale = 0x0100,
+       },
+       {
+               .name   = "NTSC CCIR601",
+               .width  = 720,
+               .height = 480,
+               .hscale = 0x0100,
+               .vscale = 0x0100,
+       },
+       {
+               .name   = "NTSC SQ (CIF)",
+               .width  = 320,
+               .height = 240,
+               .hscale = 0x0200,
+               .vscale = 0x0200,
+       },
+       {
+               .name   = "NTSC CCIR601 (CIF)",
+               .width  = 360,
+               .height = 240,
+               .hscale = 0x0200,
+               .vscale = 0x0200,
+       },
+       {
+               .name   = "NTSC SQ (QCIF)",
+               .width  = 160,
+               .height = 120,
+               .hscale = 0x0400,
+               .vscale = 0x0400,
+       },
+       {
+               .name   = "NTSC CCIR601 (QCIF)",
+               .width  = 180,
+               .height = 120,
+               .hscale = 0x0400,
+               .vscale = 0x0400,
+       },
+};
+
+static const struct tvp5150_scale_ctrl tvp5150_pal_scales[] = {
+       {
+               .name   = "PAL SQ",
+               .width  = 768,
+               .height = 576,
+               .hscale = 0x0100,
+               .vscale = 0x0100,
+       },
+       {
+               .name   = "PAL CCIR601",
+               .width  = 720,
+               .height = 576,
+               .hscale = 0x0100,
+               .vscale = 0x0100,
+       },
+       {
+               .name   = "PAL SQ (CIF)",
+               .width  = 384,
+               .height = 288,
+               .hscale = 0x0200,
+               .vscale = 0x0200,
+       },
+       {
+               .name   = "PAL CCIR601 (CIF)",
+               .width  = 360,
+               .height = 288,
+               .hscale = 0x0200,
+               .vscale = 0x0200,
+       },
+       {
+               .name   = "PAL SQ (QCIF)",
+               .width  = 192,
+               .height = 144,
+               .hscale = 0x0400,
+               .vscale = 0x0400,
+       },
+       {
+               .name   = "PAL CCIR601 (QCIF)",
+               .width  = 180,
+               .height = 144,
+               .hscale = 0x0400,
+               .vscale = 0x0400,
+       },
+};
+
+static const struct tvp5150_scale_ctrl*
+tvp5150_select_norm(struct soc_camera_device *icd, u32 width, u32 height)
+{
+       const struct tvp5150_scale_ctrl *scale;
+       const struct tvp5150_scale_ctrl *ret = NULL;
+       v4l2_std_id norm = icd->vdev->current_norm;
+       __u32 diff = 0xffffffff, tmp;
+       int size, i;
+
+       if (norm & V4L2_STD_NTSC) {
+               scale = tvp5150_ntsc_scales;
+               size = ARRAY_SIZE(tvp5150_ntsc_scales);
+       } else if (norm & V4L2_STD_PAL) {
+               scale = tvp5150_pal_scales;
+               size = ARRAY_SIZE(tvp5150_pal_scales);
+       } else {
+               return NULL;
+       }
+
+       for (i = 0; i < size; i++) {
+               tmp = abs(width - scale[i].width) +
+                       abs(height - scale[i].height);
+               if (tmp < diff) {
+                       diff = tmp;
+                       ret = scale + i;
+               }
+       }
+
+       return ret;
+}
+
 /* supported controls */
 static struct v4l2_queryctrl tvp5150_qctrl[] = {
        {
@@ -1016,6 +1147,194 @@

 /* -----------------------------------------------------------------------  
*/

+static int tvp5150_set_bus_param(struct soc_camera_device *icd,
+                               unsigned long flags)
+{
+/*     struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+       struct i2c_client *client = sd->priv;*/
+/*     u8 val = VSSL_VVALID | HSSL_DVALID;*/
+
+       /*
+        * set OUTCTR1
+        *
+        * We use VVALID and DVALID signals to control VSYNC and HSYNC
+        * outputs, in this mode their polarity is inverted.
+        */
+/*     if (flags & SOCAM_HSYNC_ACTIVE_LOW)
+               val |= HSP_HI;
+
+       if (flags & SOCAM_VSYNC_ACTIVE_LOW)
+               val |= VSP_HI;
+
+       return i2c_smbus_write_byte_data(client, OUTCTR1, val);
+*/
+       return 0;
+}
+
+static unsigned long tvp5150_query_bus_param(struct soc_camera_device *icd)
+{
+/*     struct i2c_client *client = 
to_i2c_client(to_soc_camera_control(icd));*/
+/*     struct tw9910_priv *priv = to_tw9910(client);*/
+       struct soc_camera_link *icl = to_soc_camera_link(icd);
+       unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
+               SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
+       /*      SOCAM_VSYNC_ACTIVE_LOW  | SOCAM_HSYNC_ACTIVE_LOW  |*/
+               SOCAM_DATA_ACTIVE_HIGH |
+               SOCAM_DATAWIDTH_8; /*priv->info->buswidth*/
+
+       return soc_camera_apply_sensor_flags(icl, flags);
+}
+
+static int tvp5150_enum_input(struct soc_camera_device *icd,
+                            struct v4l2_input *inp)
+{
+       inp->type = V4L2_INPUT_TYPE_TUNER;
+       inp->std  = V4L2_STD_UNKNOWN;
+       strcpy(inp->name, "Video");
+
+       return 0;
+}
+
+static struct soc_camera_ops tvp5150_soc_ops = {
+       .set_bus_param          = tvp5150_set_bus_param,
+       .query_bus_param        = tvp5150_query_bus_param,
+       .enum_input             = tvp5150_enum_input,
+};
+
+/* -----------------------------------------------------------------------  
*/
+
+static int tvp5150_s_stream(struct v4l2_subdev *sd, int enable)
+{
+/*     struct i2c_client *client = sd->priv;*/
+
+       if (enable) {
+               tvp5150_reset(sd, 0);
+       } else {
+               tvp5150_write(sd, TVP5150_MISC_CTL, tvp5150_read(sd, 
TVP5150_MISC_CTL) & 0 );   /* 0x03 register, turn off outputs */
+               tvp5150_write(sd, TVP5150_INT_CONF, tvp5150_read(sd, 
TVP5150_INT_CONF) & 3 );   /* 0xC2 register, turn off output */
+               tvp5150_write(sd, TVP5150_OP_MODE_CTL, tvp5150_read(sd, 
TVP5150_OP_MODE_CTL) | 1 );     /* 0x02 register, power down */
+       }
+       return 0;
+}
+
+static int tvp5150_g_fmt(struct v4l2_subdev *sd,
+                       struct v4l2_mbus_framefmt *mf)
+{
+       const struct tvp5150_scale_ctrl *pscale;
+       struct i2c_client *client = sd->priv;
+       struct soc_camera_device *icd = client->dev.platform_data;
+/*     struct tw9910_priv *priv = to_tw9910(client);
+
+       if (!priv->scale) {
+               int ret;
+               struct v4l2_crop crop = {
+                       .c = {
+                               .left   = 0,
+                               .top    = 0,
+                               .width  = 640,
+                               .height = 480,
+                       },
+               };
+               ret = tw9910_s_crop(sd, &crop);
+               if (ret < 0)
+                       return ret;
+       }*/
+       pscale = tvp5150_select_norm(icd, 640, 480);
+       if (!pscale) return -EINVAL;
+
+       mf->width       = pscale->width;
+       mf->height      = pscale->height;
+       mf->code        = V4L2_MBUS_FMT_YUYV8_2X8_BE;
+       mf->colorspace  = V4L2_COLORSPACE_JPEG;
+       mf->field       = V4L2_FIELD_INTERLACED_BT;
+
+       return 0;
+}
+
+static int tvp5150_s_fmt(struct v4l2_subdev *sd,
+                       struct v4l2_mbus_framefmt *mf)
+{
+       const struct tvp5150_scale_ctrl *pscale;
+       struct i2c_client *client = sd->priv;
+       struct soc_camera_device *icd = client->dev.platform_data;
+/*     struct tw9910_priv *priv = to_tw9910(client);*/
+       /* See tw9910_s_crop() - no proper cropping support */
+       struct v4l2_crop a = {
+               .c = {
+                       .left   = 0,
+                       .top    = 0,
+                       .width  = mf->width,
+                       .height = mf->height,
+               },
+       };
+       int ret = 0;
+
+       WARN_ON(mf->field != V4L2_FIELD_ANY &&
+               mf->field != V4L2_FIELD_INTERLACED_BT);
+
+       /*
+        * check color format
+        */
+       if (mf->code != V4L2_MBUS_FMT_YUYV8_2X8_BE)
+               return -EINVAL;
+
+       mf->colorspace = V4L2_COLORSPACE_JPEG;
+/*
+       ret = tw9910_s_crop(sd, &a);
+       if (!ret) {
+               mf->width       = priv->scale->width;
+               mf->height      = priv->scale->height;
+       }*/
+       pscale = tvp5150_select_norm(icd, a.c.width, a.c.height);
+       if (!pscale) {
+               mf->width       = pscale->width;
+               mf->height      = pscale->height;
+       }
+       return ret;
+}
+
+static int tvp5150_try_fmt(struct v4l2_subdev *sd,
+                         struct v4l2_mbus_framefmt *mf)
+{
+       struct i2c_client *client = sd->priv;
+       struct soc_camera_device *icd = client->dev.platform_data;
+       const struct tvp5150_scale_ctrl *pscale;
+
+       if (V4L2_FIELD_ANY == mf->field) {
+               mf->field = V4L2_FIELD_INTERLACED_BT;
+       } else if (V4L2_FIELD_INTERLACED_BT != mf->field) {
+               dev_err(&client->dev, "Field type %d invalid.\n", 
mf->field);
+               return -EINVAL;
+       }
+
+       mf->code = V4L2_MBUS_FMT_YUYV8_2X8_BE;
+       mf->colorspace = V4L2_COLORSPACE_JPEG;
+
+       /*
+        * select suitable norm
+        */
+       pscale = tvp5150_select_norm(icd, mf->width, mf->height);
+       if (!pscale)
+               return -EINVAL;
+
+       mf->width       = pscale->width;
+       mf->height      = pscale->height;
+
+       return 0;
+}
+
+static int tvp5150_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
+                          enum v4l2_mbus_pixelcode *code)
+{
+       if (index)
+               return -EINVAL;
+
+       *code = V4L2_MBUS_FMT_YUYV8_2X8_BE;
+       return 0;
+}
+
+/* -----------------------------------------------------------------------  
*/
+
 static const struct v4l2_subdev_core_ops tvp5150_core_ops = {
        .log_status = tvp5150_log_status,
        .g_ctrl = tvp5150_g_ctrl,
@@ -1036,6 +1355,16 @@

 static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
        .s_routing = tvp5150_s_routing,
+
+       /* SoC camera: */
+       .s_stream       = tvp5150_s_stream,
+       .g_mbus_fmt     = tvp5150_g_fmt,
+       .s_mbus_fmt     = tvp5150_s_fmt,
+       .try_mbus_fmt   = tvp5150_try_fmt,
+       .enum_mbus_fmt  = tvp5150_enum_fmt,
+/*     .cropcap        = tw9910_cropcap,
+       .g_crop         = tw9910_g_crop,
+       .s_crop         = tw9910_s_crop,*/
 };

 static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
@@ -1045,7 +1374,7 @@
        .s_raw_fmt = tvp5150_s_raw_fmt,
 };

-static const struct v4l2_subdev_ops tvp5150_ops = {
+static const struct v4l2_subdev_ops tvp5150_subdev_ops = {
        .core = &tvp5150_core_ops,
        .tuner = &tvp5150_tuner_ops,
        .video = &tvp5150_video_ops,
@@ -1056,12 +1385,68 @@
 /****************************************************************************                        I2C Client & Driver  ****************************************************************************/+static int tvp5150_video_probe(struct soc_camera_device *icd,+                             struct i2c_client *client,+                               struct v4l2_subdev *sd)+{+{+/*     struct tw9910_priv *priv = to_tw9910(client);*/+/*     s32 id;*/++       /*+        * We must have a parent by now. And it cannot be a wrong one.+        * So this entire test is completely redundant.+        */+       if (!icd->dev.parent ||+           to_soc_camera_host(icd->dev.parent)->nr != icd->iface)+               return -ENODEV;++       /*+        * tw9910 only use 8 or 16 bit bus width+        */+/*     if (SOCAM_DATAWIDTH_16 != priv->info->buswidth &&+           SOCAM_DATAWIDTH_8  != priv->info->buswidth) {+               dev_err(&client->dev, "bus width error\n");+               return -ENODEV;+       }*/++       /*+        * check and show Product ID+        * So far only revisions 0 and 1 have been seen+        */+       /*id = i2c_smbus_read_byte_data(client, ID);+       priv->revision = GET_REV(id);+       id = GET_ID(id);++       if (0x0B != id ||+           0x01 < priv->revision) {+               dev_err(&client->dev,+                       "Product ID error %x:%x\n",+                       id, priv->revision);+               return -ENODEV;+       }++       dev_info(&client->dev,+                "tw9910 Product ID %0x:%0x\n", id, priv->revision);+       */+       if (tvp5150_reset(sd, 0)) {     /*and/or tvp5150_g_chip_ident()*/+               dev_err(&client->dev,+                       "Reset error\n");+               return -ENODEV;+       }+       icd->vdev->tvnorms      = V4L2_STD_NTSC | V4L2_STD_PAL;+       icd->vdev->current_norm = V4L2_STD_NTSC;++       return 0;+} static int tvp5150_probe(struct i2c_client *c,                         const struct i2c_device_id *id) {        struct tvp5150 *core;        struct v4l2_subdev *sd;+       struct soc_camera_device       *icd = c->dev.platform_data;+       struct soc_camera_link         *icl;+       int                             ret;        /* Check if the adapter supports the needed features */        if (!i2c_check_functionality(c->adapter,@@ -1073,7 +1458,7 @@                return -ENOMEM;        }        sd = &core->sd;-       v4l2_i2c_subdev_init(sd, c, &tvp5150_ops);+       v4l2_i2c_subdev_init(sd, c, &tvp5150_subdev_ops);        v4l_info(c, "chip found @ 0x%02x (%s)\n",                 c->addr << 1, c->adapter->name);@@ -1087,17 +1472,33 @@        if (debug > 1)                tvp5150_log_status(sd);++       if (icd) {                              /* attach SoC camera API */+               icl = to_soc_camera_link(icd);+               if (icl) {+                       /*icl->priv - platform data*/+                       icd->iface   = icl->bus_id;+                       icd->ops     = &tvp5150_soc_ops;+                       ret = tvp5150_video_probe(icd, c, sd);+                       if (ret) {+                               icd->ops = NULL;+                               return ret;+                       }+               }+       }        return 0; } static int tvp5150_remove(struct i2c_client *c) {        struct v4l2_subdev *sd = i2c_get_clientdata(c);+       struct soc_camera_device *icd = c->dev.platform_data;        v4l2_dbg(1, debug, sd,                "tvp5150.c: removing tvp5150 adapter on address 0x%x\n",                c->addr << 1);+       if (icd) icd->ops = NULL;               /* detach SoC camera API */        v4l2_device_unregister_subdev(sd);        kfree(to_tvp5150(sd));        return 0;----- Original Message -----From: "Guennadi Liakhovetski" <g.liakhovetski@gmx.de>To: "Janusz Uzycki" <janusz.uzycki@elproma.com.pl>Cc: <g.daniluk@elproma.com.pl>Sent: Wednesday, January 26, 2011 8:47 PMSubject: Re: SoC Camera driver and TV decoder> On Wed, 26 Jan 2011, Janusz Uzycki wrote:>>> Thanks for the help. I found your post at>> http://www.spinics.net/lists/linux-media/msg16346.html and>>http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11486/focus=11493>> Do you remember some similar threads or guide? It will be better to read>> before to ask :)>> There have been a couple of threads with similar content, and no, there is> no guide.>> Regards> Guennadi>>>>> best regards>> Janusz Uzycki>> ELPROMA>>>> ----- Original Message ----- From: "Guennadi Liakhovetski">> <g.liakhovetski@gmx.de>>> To: "Janusz Uzycki" <janusz.uzycki@elproma.com.pl>>> Cc: <g.daniluk@elproma.com.pl>>> Sent: Monday, January 24, 2011 5:25 PM>> Subject: Re: SoC Camera driver and TV decoder>>>>>> > On Mon, 24 Jan 2011, Janusz Uzycki wrote:>> >>> > > Hello.>> > >>> > > We are developing a customized system based on Renesas SH7724 CPU. In>> > > dev.kit of that CPU video input (TV decoder) is powered by TW9910chip.>> > > Our customized board contains TVP5150 chip instead. Unfortunately>> > > SoC-camera driver supports SH-mobile host but not the our client.>> > > TVP5150 is supported in Linux kernel via default video decodersdriver>> > > but we weren't able to link SoC-camera and V4L2 driver of TVP5150 to>> > > work together. Both modules are loaded but /dev/video0 has notappeared.>> > > Could you point how to do it right? Does we need to rewrite TVP5150>> > > driver using TW9910 driver as template?>> >>> > Yes, you will have to adjust / extend the tvp5150.c driver to (also)work>> > with soc-camera. Unfortunately, the soc-camera framework is still not>> > completely compatible with the plain v4l2-subdev API. Yes, use any of>> > existing soc-camera sensor or tv-decoder drivers as an example. Theonly>> > soc-camera tv-decoder driver currently available, as you've correctly>> > recognised, is tw9910.>> >>> > With more detailed questions please CC the>> >>> > Linux Media Mailing List <linux-media@vger.kernel.org>>> >>> > mailing list.>> >>> > Thanks>> > Guennadi>> >>> > >>> > > Current our part for SoC in /arch/sh/boards/mach-ecovec24/setup.c is:>> > >>> > > static struct i2c_board_info i2c_camera[] = {>> > >         {>> > >                 I2C_BOARD_INFO("tvp5150", 0x5d),>> > >         },>> > > };>> > >>> > > static struct soc_camera_link tvp5150_link = {>> > >         .i2c_adapter_id = 0,>> > >         .bus_id         = 0,>> > >         .board_info     = &i2c_camera[0],>> > >          /*.priv           = &tw9910_info,*/            /* notsupported>> > > */>> > >          /*.power          = tw9910_power,*/        /* not supported*/>> > >         .module_name    = "tvp5150">> > > };>> > >>> > > static struct platform_device camera_devices[] = {>> > >         {>> > >                 .name   = "soc-camera-pdrv",>> > >                 .id     = 0,>> > >                 .dev    = {>> > >                         .platform_data = &tvp5150_link,>> > >                 },>> > >         },>> > > };>> > >>> > > kind regards>> > > Janusz Uzycki>> > > ELPROMA>> > >>> >>> > --->> > Guennadi Liakhovetski, Ph.D.>> > Freelance Open-Source Software Developer>> > http://www.open-technology.de/>> >>>>> ---> Guennadi Liakhovetski>

Re: SoC Camera driver and TV decoder

[Guennadi Liakhovetski]

On Thu, 27 Jan 2011, Janusz Uzycki wrote:

> Hello Guennadi again.
> 
> I patched tvp5150.c according to tw9910 driver (without real cropping
> support yet).
> Unfortunately I got the messages:
> camera 0-0: Probing 0-0
> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
> tvp5150 0-005d: chip found @ 0xba (i2c-sh_mobile)
> tvp5150 0-005d: tvp5150am1 detected.

This looks good - i2c to the chip works!

> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 0
> camera: probe of 0-0 failed with error -515

This is strange, however - error code 515... Can you try to find out where 
it is coming from?

Thanks
Guennadi

> 
> I have also found 2 patches here http://www.sleepyrobot.com/?cat=3 but it
> does not support soc camera also.
> 
> My "copy-paste" patch in attachement this time.
> 
> kind regards
> Janusz
> 
> ----- Original Message ----- From: "Guennadi Liakhovetski"
> <g.liakhovetski@gmx.de>
> To: "Janusz Uzycki" <janusz.uzycki@elproma.com.pl>
> Cc: <g.daniluk@elproma.com.pl>
> Sent: Wednesday, January 26, 2011 8:47 PM
> Subject: Re: SoC Camera driver and TV decoder
> 
> 
> > On Wed, 26 Jan 2011, Janusz Uzycki wrote:
> > 
> > > Thanks for the help. I found your post at
> > > http://www.spinics.net/lists/linux-media/msg16346.html and
> > > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11486/focus=11493
> > > Do you remember some similar threads or guide? It will be better to read
> > > before to ask :)
> > 
> > There have been a couple of threads with similar content, and no, there is
> > no guide.
> > 
> > Regards
> > Guennadi
> > 
> > > 
> > > best regards
> > > Janusz Uzycki
> > > ELPROMA
> > > 
> > > ----- Original Message ----- From: "Guennadi Liakhovetski"
> > > <g.liakhovetski@gmx.de>
> > > To: "Janusz Uzycki" <janusz.uzycki@elproma.com.pl>
> > > Cc: <g.daniluk@elproma.com.pl>
> > > Sent: Monday, January 24, 2011 5:25 PM
> > > Subject: Re: SoC Camera driver and TV decoder
> > > 
> > > 
> > > > On Mon, 24 Jan 2011, Janusz Uzycki wrote:
> > > >
> > > > > Hello.
> > > > >
> > > > > We are developing a customized system based on Renesas SH7724 CPU. In
> > > > > dev.kit of that CPU video input (TV decoder) is powered by TW9910 > >
> > > chip.
> > > > > Our customized board contains TVP5150 chip instead. Unfortunately
> > > > > SoC-camera driver supports SH-mobile host but not the our client.
> > > > > TVP5150 is supported in Linux kernel via default video decoders > >
> > > driver
> > > > > but we weren't able to link SoC-camera and V4L2 driver of TVP5150 to
> > > > > work together. Both modules are loaded but /dev/video0 has not > >
> > > appeared.
> > > > > Could you point how to do it right? Does we need to rewrite TVP5150
> > > > > driver using TW9910 driver as template?
> > > >
> > > > Yes, you will have to adjust / extend the tvp5150.c driver to (also) >
> > > work
> > > > with soc-camera. Unfortunately, the soc-camera framework is still not
> > > > completely compatible with the plain v4l2-subdev API. Yes, use any of
> > > > existing soc-camera sensor or tv-decoder drivers as an example. The >
> > > only
> > > > soc-camera tv-decoder driver currently available, as you've correctly
> > > > recognised, is tw9910.
> > > >
> > > > With more detailed questions please CC the
> > > >
> > > > Linux Media Mailing List <linux-media@vger.kernel.org>
> > > >
> > > > mailing list.
> > > >
> > > > Thanks
> > > > Guennadi
> > > >
> > > > >
> > > > > Current our part for SoC in /arch/sh/boards/mach-ecovec24/setup.c is:
> > > > >
> > > > > static struct i2c_board_info i2c_camera[] = {
> > > > >         {
> > > > >                 I2C_BOARD_INFO("tvp5150", 0x5d),
> > > > >         },
> > > > > };
> > > > >
> > > > > static struct soc_camera_link tvp5150_link = {
> > > > >         .i2c_adapter_id = 0,
> > > > >         .bus_id         = 0,
> > > > >         .board_info     = &i2c_camera[0],
> > > > >          /*.priv           = &tw9910_info,*/            /* not > >
> > > supported
> > > > > */
> > > > >          /*.power          = tw9910_power,*/        /* not supported >
> > > > */
> > > > >         .module_name    = "tvp5150"
> > > > > };
> > > > >
> > > > > static struct platform_device camera_devices[] = {
> > > > >         {
> > > > >                 .name   = "soc-camera-pdrv",
> > > > >                 .id     = 0,
> > > > >                 .dev    = {
> > > > >                         .platform_data = &tvp5150_link,
> > > > >                 },
> > > > >         },
> > > > > };
> > > > >
> > > > > kind regards
> > > > > Janusz Uzycki
> > > > > ELPROMA
> > > > >
> > > >
> > > > ---
> > > > Guennadi Liakhovetski, Ph.D.
> > > > Freelance Open-Source Software Developer
> > > > http://www.open-technology.de/
> > > >
> > > 
> > 
> > ---
> > Guennadi Liakhovetski
> > 
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: SoC Camera driver and TV decoder

[Janusz Uzycki]

>> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from 
>> camera 0
>> camera: probe of 0-0 failed with error -515
>
> This is strange, however - error code 515... Can you try to find out where
> it is coming from?

Something is really wrong:
drivers/base/dd.c:                     "%s: probe of %s failed with error 
%d\n",
in
static int really_probe(struct device *dev, struct device_driver *drv)


Bus probe or "camera" probe failed.

regards
Janusz

Re: SoC Camera driver and TV decoder

[Janusz Uzycki]

include/linux/errno.h:#define ENOIOCTLCMD       515     /* No ioctl command 
*/

What did I forget below?
static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
        .s_routing = tvp5150_s_routing,

        /* SoC camera: */
        .s_stream       = tvp5150_s_stream,
        .g_mbus_fmt     = tvp5150_g_fmt,
        .s_mbus_fmt     = tvp5150_s_fmt,
        .try_mbus_fmt   = tvp5150_try_fmt,
        .enum_mbus_fmt  = tvp5150_enum_fmt,
/*      .cropcap        = tw9910_cropcap,
        .g_crop         = tw9910_g_crop,
        .s_crop         = tw9910_s_crop,*/
};

cropcap/g_crop/s_cros are necessary? why and when?

thanks
Janusz


> On Thu, 27 Jan 2011, Janusz Uzycki wrote:
>
>> Hello Guennadi again.
>>
>> I patched tvp5150.c according to tw9910 driver (without real cropping
>> support yet).
>> Unfortunately I got the messages:
>> camera 0-0: Probing 0-0
>> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to 
>> camera 0
>> tvp5150 0-005d: chip found @ 0xba (i2c-sh_mobile)
>> tvp5150 0-005d: tvp5150am1 detected.
>
> This looks good - i2c to the chip works!
>
>> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from 
>> camera 0
>> camera: probe of 0-0 failed with error -515
>
> This is strange, however - error code 515... Can you try to find out where
> it is coming from?
>
> Thanks
> Guennadi
>

Re: SoC Camera driver and TV decoder

[Guennadi Liakhovetski]

On Tue, 1 Feb 2011, Janusz Uzycki wrote:

> include/linux/errno.h:#define ENOIOCTLCMD       515     /* No ioctl command */
> 
> What did I forget below?
> static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
>        .s_routing = tvp5150_s_routing,
> 
>        /* SoC camera: */
>        .s_stream       = tvp5150_s_stream,
>        .g_mbus_fmt     = tvp5150_g_fmt,
>        .s_mbus_fmt     = tvp5150_s_fmt,
>        .try_mbus_fmt   = tvp5150_try_fmt,
>        .enum_mbus_fmt  = tvp5150_enum_fmt,
> /*      .cropcap        = tw9910_cropcap,
>        .g_crop         = tw9910_g_crop,
>        .s_crop         = tw9910_s_crop,*/
> };
> 
> cropcap/g_crop/s_cros are necessary? why and when?

cropcap and g_crop might be necessary - at least minimal static versions.

Thanks
Guennadi

> 
> thanks
> Janusz
> 
> 
> > On Thu, 27 Jan 2011, Janusz Uzycki wrote:
> > 
> > > Hello Guennadi again.
> > > 
> > > I patched tvp5150.c according to tw9910 driver (without real cropping
> > > support yet).
> > > Unfortunately I got the messages:
> > > camera 0-0: Probing 0-0
> > > sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera
> > > 0
> > > tvp5150 0-005d: chip found @ 0xba (i2c-sh_mobile)
> > > tvp5150 0-005d: tvp5150am1 detected.
> > 
> > This looks good - i2c to the chip works!
> > 
> > > sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from
> > > camera 0
> > > camera: probe of 0-0 failed with error -515
> > 
> > This is strange, however - error code 515... Can you try to find out where
> > it is coming from?
> > 
> > Thanks
> > Guennadi
> > 
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: SoC Camera driver and TV decoder

[Janusz Uzycki]

camera 0-0: Probing 0-0
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
tvp5150 0-005d: chip found @ 0xba (i2c-sh_mobile)
tvp5150 0-005d: tvp5150am1 detected.
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 
0

There is no error 515 but the driver is still detached.
drivers/media/video/sh_mobile_ceu_camera.c:
sh_mobile_ceu_remove_device() is called /* Called with .video_lock held */
static struct soc_camera_host_ops sh_mobile_ceu_host_ops = {
        .owner          = THIS_MODULE,
        .add            = sh_mobile_ceu_add_device,
        .remove         = sh_mobile_ceu_remove_device,
It seems sh_mobile_ceu_add_device() was failed.
I will try to explore that.

Janusz

----- Original Message ----- 
From: "Guennadi Liakhovetski" <g.liakhovetski@gmx.de>
To: "Janusz Uzycki" <janusz.uzycki@elproma.com.pl>
Cc: <g.daniluk@elproma.com.pl>; "Linux Media Mailing List" 
<linux-media@vger.kernel.org>
Sent: Tuesday, February 01, 2011 2:21 PM
Subject: Re: SoC Camera driver and TV decoder


> On Tue, 1 Feb 2011, Janusz Uzycki wrote:
>
>> include/linux/errno.h:#define ENOIOCTLCMD       515     /* No ioctl 
>> command */
>>
>> What did I forget below?
>> static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
>>        .s_routing = tvp5150_s_routing,
>>
>>        /* SoC camera: */
>>        .s_stream       = tvp5150_s_stream,
>>        .g_mbus_fmt     = tvp5150_g_fmt,
>>        .s_mbus_fmt     = tvp5150_s_fmt,
>>        .try_mbus_fmt   = tvp5150_try_fmt,
>>        .enum_mbus_fmt  = tvp5150_enum_fmt,
>> /*      .cropcap        = tw9910_cropcap,
>>        .g_crop         = tw9910_g_crop,
>>        .s_crop         = tw9910_s_crop,*/
>> };
>>
>> cropcap/g_crop/s_cros are necessary? why and when?
>
> cropcap and g_crop might be necessary - at least minimal static versions.
>
> Thanks
> Guennadi
>
>>
>> thanks
>> Janusz
>>
>>
>> > On Thu, 27 Jan 2011, Janusz Uzycki wrote:
>> >
>> > > Hello Guennadi again.
>> > >
>> > > I patched tvp5150.c according to tw9910 driver (without real cropping
>> > > support yet).
>> > > Unfortunately I got the messages:
>> > > camera 0-0: Probing 0-0
>> > > sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to 
>> > > camera
>> > > 0
>> > > tvp5150 0-005d: chip found @ 0xba (i2c-sh_mobile)
>> > > tvp5150 0-005d: tvp5150am1 detected.
>> >
>> > This looks good - i2c to the chip works!
>> >
>> > > sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from
>> > > camera 0
>> > > camera: probe of 0-0 failed with error -515
>> >
>> > This is strange, however - error code 515... Can you try to find out 
>> > where
>> > it is coming from?
>> >
>> > Thanks
>> > Guennadi
>> >
>>
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> 

Re: SoC Camera driver and TV decoder

[Guennadi Liakhovetski]

On Tue, 1 Feb 2011, Janusz Uzycki wrote:

> camera 0-0: Probing 0-0
> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
> tvp5150 0-005d: chip found @ 0xba (i2c-sh_mobile)
> tvp5150 0-005d: tvp5150am1 detected.
> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 0
> 
> There is no error 515 but the driver is still detached.

Good, this is correct. It will be re-attached when you open it.

Thanks
Guennadi

> drivers/media/video/sh_mobile_ceu_camera.c:
> sh_mobile_ceu_remove_device() is called /* Called with .video_lock held */
> static struct soc_camera_host_ops sh_mobile_ceu_host_ops = {
>        .owner          = THIS_MODULE,
>        .add            = sh_mobile_ceu_add_device,
>        .remove         = sh_mobile_ceu_remove_device,
> It seems sh_mobile_ceu_add_device() was failed.
> I will try to explore that.
> 
> Janusz
> 
> ----- Original Message ----- From: "Guennadi Liakhovetski"
> <g.liakhovetski@gmx.de>
> To: "Janusz Uzycki" <janusz.uzycki@elproma.com.pl>
> Cc: <g.daniluk@elproma.com.pl>; "Linux Media Mailing List"
> <linux-media@vger.kernel.org>
> Sent: Tuesday, February 01, 2011 2:21 PM
> Subject: Re: SoC Camera driver and TV decoder
> 
> 
> > On Tue, 1 Feb 2011, Janusz Uzycki wrote:
> > 
> > > include/linux/errno.h:#define ENOIOCTLCMD       515     /* No ioctl
> > > command */
> > > 
> > > What did I forget below?
> > > static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
> > >        .s_routing = tvp5150_s_routing,
> > > 
> > >        /* SoC camera: */
> > >        .s_stream       = tvp5150_s_stream,
> > >        .g_mbus_fmt     = tvp5150_g_fmt,
> > >        .s_mbus_fmt     = tvp5150_s_fmt,
> > >        .try_mbus_fmt   = tvp5150_try_fmt,
> > >        .enum_mbus_fmt  = tvp5150_enum_fmt,
> > > /*      .cropcap        = tw9910_cropcap,
> > >        .g_crop         = tw9910_g_crop,
> > >        .s_crop         = tw9910_s_crop,*/
> > > };
> > > 
> > > cropcap/g_crop/s_cros are necessary? why and when?
> > 
> > cropcap and g_crop might be necessary - at least minimal static versions.
> > 
> > Thanks
> > Guennadi
> > 
> > > 
> > > thanks
> > > Janusz
> > > 
> > > 
> > > > On Thu, 27 Jan 2011, Janusz Uzycki wrote:
> > > >
> > > > > Hello Guennadi again.
> > > > >
> > > > > I patched tvp5150.c according to tw9910 driver (without real cropping
> > > > > support yet).
> > > > > Unfortunately I got the messages:
> > > > > camera 0-0: Probing 0-0
> > > > > sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to >
> > > > camera
> > > > > 0
> > > > > tvp5150 0-005d: chip found @ 0xba (i2c-sh_mobile)
> > > > > tvp5150 0-005d: tvp5150am1 detected.
> > > >
> > > > This looks good - i2c to the chip works!
> > > >
> > > > > sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from
> > > > > camera 0
> > > > > camera: probe of 0-0 failed with error -515
> > > >
> > > > This is strange, however - error code 515... Can you try to find out >
> > > where
> > > > it is coming from?
> > > >
> > > > Thanks
> > > > Guennadi
> > > >
> > > 
> > 
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> > 
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

SH7724, VOU, PAL mode

[Janusz Uzycki]

Hi Guennadi.

I am trying to force to proper work CS4954 encoder with sh4.
I want to use sh4 VOU in PAL mode (kernel 3.2.7). Do you have any experience 
with AK881x and PAL?
If I set PAL mode (v4l2-ctl -s) VOUCR::MD is still configured for NTSC. I 
noticed that VOU is limited to NTSC resolution: "Maximum destination image 
size: 720 x 240 per field". And indeed I had to change my encoder settings 
to NTSC-M CCIR601 timing 720x480 (PAL synch freq. only) for synced (stable) 
color video picture of BAR generated by the encoder (not VOU). On the other 
hand VOUDSR register has bit-limit 1024x512 (enough for PAL 768x576 
interlaced).
Another method for stable PAL picture (but 768x576) is change both VOUCR::MD 
to PAL output mode and set the encoder to PAL mode. Then the green picture 
has a bound about 480 line I think.
Unfortunately I can't still manage to work video data from VOU to the 
encoder - green picture only. Do you have any test program for video v4l2 
output? Does the idea fb->v4l2 output 
http://www.spinics.net/lists/linux-fbdev/msg01102.html is alive?

best regards
Janusz Uzycki
ELPROMA

Re: SH7724, VOU, PAL mode

[Guennadi Liakhovetski]

Hi Janusz

Sorry, this is not going to be a very detailed reply. It's been a long 
time since I've worked with VOU and AK8813(4).

On Mon, 4 Jun 2012, Janusz Uzycki wrote:

> Hi Guennadi.
> 
> I am trying to force to proper work CS4954 encoder with sh4.
> I want to use sh4 VOU in PAL mode (kernel 3.2.7). Do you have any experience
> with AK881x and PAL?

Yes, I think, I tested both PAL and NTSC modes.

> If I set PAL mode (v4l2-ctl -s) VOUCR::MD is still configured for NTSC.

This shouldn't be the case: look at sh_vou_s_std(). Can you try to add 
debugging to the driver to see, whether that function gets called, when 
you run v4l2-ctl? If not - either you're calling it wrongly, or there's a 
bug in it. If it is - see, whether it's not configuring VOUCR properly or 
somehow it gets reset again later.

> I
> noticed that VOU is limited to NTSC resolution: "Maximum destination image
> size: 720 x 240 per field".

You mean in the datasheet? I don't have it currently at hand, but I seem 
to remember, that there was a bug and the VOU does actually support a full 
PAL resolution too. I'm not 100% certain, though.

> And indeed I had to change my encoder settings to
> NTSC-M CCIR601 timing 720x480 (PAL synch freq. only) for synced (stable) color
> video picture of BAR generated by the encoder (not VOU). On the other hand
> VOUDSR register has bit-limit 1024x512 (enough for PAL 768x576 interlaced).
> Another method for stable PAL picture (but 768x576) is change both VOUCR::MD
> to PAL output mode and set the encoder to PAL mode. Then the green picture has
> a bound about 480 line I think.
> Unfortunately I can't still manage to work video data from VOU to the encoder
> - green picture only. Do you have any test program for video v4l2 output?

You can use gstreamer, e.g.:

gst-launch -v filesrc location=x.avi ! decodebin ! ffmpegcolorspace ! \ 
video/x-raw-rgb,bpp=24 ! v4l2sink device=/dev/video0 tv-norm=PAL-B

I also used a (possibly modified) program by Laurent (cc'ed) which either 
I - with his agreement - can re-send to you, or maybe he'd send you the 
original.

> Does
> the idea fb->v4l2 output
> http://www.spinics.net/lists/linux-fbdev/msg01102.html is alive?

More dead, than alive, I think.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: SH7724, VOU, PAL mode

[Janusz Uzycki]

Hi.

> Sorry, this is not going to be a very detailed reply. It's been a long
> time since I've worked with VOU and AK8813(4).

I see.

>> If I set PAL mode (v4l2-ctl -s) VOUCR::MD is still configured for NTSC.
>
> This shouldn't be the case: look at sh_vou_s_std(). Can you try to add
> debugging to the driver to see, whether that function gets called, when
> you run v4l2-ctl? If not - either you're calling it wrongly, or there's a
> bug in it. If it is - see, whether it's not configuring VOUCR properly or
> somehow it gets reset again later.

Before I turned on CONFIG_VIDEO_ADV_DEBUG only for I2C debug (v4l2-dbg). Now 
I turned on dynamic printk (dev_dbg) for sh_vou.c and observed that 
sh_vou_open() calls sh_vou_hw_init() what causes VOU reset:
v4l2-ctl  -s 5
sh-vou sh-vou: sh_vou_open()
sh-vou sh-vou: Reset took 1us
sh-vou sh-vou: sh_vou_querycap()
sh-vou sh-vou: sh_vou_s_std(): 0xff
CS495X-set: VOUER was 0x00000000, now SEN and ST bits are set
CS495X set format: 000000ff
CS495X-set: VOUER 0x00000000 restored
sh-vou sh-vou: sh_vou_release()
Standard set to 000000ff

This is why "v4l2-ctl -s 5" used before my simple test program (modified 
capture example with mmap method) finally has no effect for VOU.
When the test program opens video device it causes reset PAL mode in VOU and 
does not in TV encoder. Thanks Guennadi for the hints.
(VOUER messages explanation: I have to set SEN and ST bits in CS49X driver 
because the chip needs 27MHz clock to I2C block operate)

>> I noticed that VOU is limited to NTSC resolution: "Maximum destination 
>> image
>> size: 720 x 240 per field".
>
> You mean in the datasheet?

Yes, exactly.

>I don't have it currently at hand, but I seem
> to remember, that there was a bug and the VOU does actually support a full
> PAL resolution too. I'm not 100% certain, though.

OK, I will test it. Do you remember how you discovered that?

>> Unfortunately I can't still manage to work video data from VOU to the 
>> encoder
>> - green picture only. Do you have any test program for video v4l2 output?
>
> You can use gstreamer, e.g.:
>
> gst-launch -v filesrc location=x.avi ! decodebin ! ffmpegcolorspace ! \
> video/x-raw-rgb,bpp=24 ! v4l2sink device=/dev/video0 tv-norm=PAL-B

thanks

> I also used a (possibly modified) program by Laurent (cc'ed) which either
> I - with his agreement - can re-send to you, or maybe he'd send you the
> original.

ok, is it media-ctl (git://git.ideasonboard.org/media-ctl.git)?

>> Does
>> the idea fb->v4l2 output
>> http://www.spinics.net/lists/linux-fbdev/msg01102.html is alive?
>
> More dead, than alive, I think.

Ok. Did you find another solution (software/library like DirectFB) for 
common and easier video output support in userspace?

best regards
Janusz

>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> 

Re: SH7724, VOU, PAL mode

[Guennadi Liakhovetski]

On Wed, 6 Jun 2012, Janusz Uzycki wrote:

> Hi.
> 
> > Sorry, this is not going to be a very detailed reply. It's been a long
> > time since I've worked with VOU and AK8813(4).
> 
> I see.
> 
> > > If I set PAL mode (v4l2-ctl -s) VOUCR::MD is still configured for NTSC.
> > 
> > This shouldn't be the case: look at sh_vou_s_std(). Can you try to add
> > debugging to the driver to see, whether that function gets called, when
> > you run v4l2-ctl? If not - either you're calling it wrongly, or there's a
> > bug in it. If it is - see, whether it's not configuring VOUCR properly or
> > somehow it gets reset again later.
> 
> Before I turned on CONFIG_VIDEO_ADV_DEBUG only for I2C debug (v4l2-dbg). Now I
> turned on dynamic printk (dev_dbg) for sh_vou.c and observed that
> sh_vou_open() calls sh_vou_hw_init() what causes VOU reset:
> v4l2-ctl  -s 5
> sh-vou sh-vou: sh_vou_open()
> sh-vou sh-vou: Reset took 1us
> sh-vou sh-vou: sh_vou_querycap()
> sh-vou sh-vou: sh_vou_s_std(): 0xff
> CS495X-set: VOUER was 0x00000000, now SEN and ST bits are set
> CS495X set format: 000000ff
> CS495X-set: VOUER 0x00000000 restored
> sh-vou sh-vou: sh_vou_release()
> Standard set to 000000ff
> 
> This is why "v4l2-ctl -s 5" used before my simple test program (modified
> capture example with mmap method) finally has no effect for VOU.
> When the test program opens video device it causes reset PAL mode in VOU and
> does not in TV encoder.

Right, this is actually a bug in the VOU driver. It didn't affect me, 
because I was opening the device only once before all the configuration 
and streaming. Could you create and submit a patch to save the standard in 
driver private data and restore it on open() after the reset? I guess, 
other configuration parameters are lost too, feel free to fix them as 
well.

> Thanks Guennadi for the hints.
> (VOUER messages explanation: I have to set SEN and ST bits in CS49X driver
> because the chip needs 27MHz clock to I2C block operate)
> 
> > > I noticed that VOU is limited to NTSC resolution: "Maximum destination
> > > image
> > > size: 720 x 240 per field".
> > 
> > You mean in the datasheet?
> 
> Yes, exactly.
> 
> > I don't have it currently at hand, but I seem
> > to remember, that there was a bug and the VOU does actually support a full
> > PAL resolution too. I'm not 100% certain, though.
> 
> OK, I will test it. Do you remember how you discovered that?

Asked the manufacturer company :)

> > > Unfortunately I can't still manage to work video data from VOU to the
> > > encoder
> > > - green picture only. Do you have any test program for video v4l2 output?
> > 
> > You can use gstreamer, e.g.:
> > 
> > gst-launch -v filesrc location=x.avi ! decodebin ! ffmpegcolorspace ! \
> > video/x-raw-rgb,bpp=24 ! v4l2sink device=/dev/video0 tv-norm=PAL-B
> 
> thanks
> 
> > I also used a (possibly modified) program by Laurent (cc'ed) which either
> > I - with his agreement - can re-send to you, or maybe he'd send you the
> > original.
> 
> ok, is it media-ctl (git://git.ideasonboard.org/media-ctl.git)?

No, I'll send it to you off the list - Laurent agreed. But he also said, 
it was a preliminary version of his yavta proram, so, you might be able to 
use that one.

> > > Does
> > > the idea fb->v4l2 output
> > > http://www.spinics.net/lists/linux-fbdev/msg01102.html is alive?
> > 
> > More dead, than alive, I think.
> 
> Ok. Did you find another solution (software/library like DirectFB) for common
> and easier video output support in userspace?

No, sorry, I did not.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: SH7724, VOU, PAL mode

[Janusz Uzycki]

>> This is why "v4l2-ctl -s 5" used before my simple test program (modified
>> capture example with mmap method) finally has no effect for VOU.
>> When the test program opens video device it causes reset PAL mode in VOU 
>> and
>> does not in TV encoder.
>
> Right, this is actually a bug in the VOU driver. It didn't affect me,
> because I was opening the device only once before all the configuration
> and streaming. Could you create and submit a patch to save the standard in
> driver private data and restore it on open() after the reset? I guess,
> other configuration parameters are lost too, feel free to fix them as
> well.

Here you are. Something like that? I avoided encoder reconfiguration (it is 
not needed) - do not call sh_vou_s_std() and in result 
v4l2_device_call_until_err().

--- sh_vou.c.orig       2012-06-06 15:58:28.785086939 +0000
+++ sh_vou.c    2012-06-06 17:04:30.684586479 +0000
@@ -1183,6 +1183,13 @@ static int sh_vou_open(struct file *file
                        vou_dev->status = SH_VOU_IDLE;
                        return ret;
                }
+
+               /* restore std */
+               if (vou_dev->std & V4L2_STD_525_60)
+                       sh_vou_reg_ab_set(vou_dev, VOUCR,
+ 
sh_vou_ntsc_mode(vou_dev->pdata->bus_fmt) << 29, 7 << 29);
+               else
+                       sh_vou_reg_ab_set(vou_dev, VOUCR, 5 << 29, 7 << 29);
        }

        videobuf_queue_dma_contig_init(&vou_file->vbq, &sh_vou_video_qops,

I tested the std restoring and picture is synced/stable in PAL mode now. 
However I  have still problem after 480 line because next lines are always 
green.
Fixing other configuration parameters seems little more complicated 
(sh_vou_s_fmt_vid_out(), sh_vou_configure_geometry()).

>> > > I noticed that VOU is limited to NTSC resolution: "Maximum 
>> > > destination
>> > > image
>> > > size: 720 x 240 per field".
>> >
>> > You mean in the datasheet?
>>
>> Yes, exactly.
>>
>> > I don't have it currently at hand, but I seem
>> > to remember, that there was a bug and the VOU does actually support a 
>> > full
>> > PAL resolution too. I'm not 100% certain, though.
>>
>> OK, I will test it. Do you remember how you discovered that?
>
> Asked the manufacturer company :)

OK:) I found the sentence in sh_vou.c: "Cropping scheme: max useful image is 
720x480, and the total video area is 858x525 (NTSC) or 864x625 (PAL)." Next 
is some magic:)

> No, I'll send it to you off the list - Laurent agreed. But he also said,
> it was a preliminary version of his yavta proram, so, you might be able to
> use that one.

OK, the code you sent works much better than my simple video output program 
but the same problem after 480 line. I have to investigate it.
I use yavta for frame capturing tests.

Unfortunately I will be outside the company next 2 weeks. I will have remote 
access only to my hardware so more tests are not possible then.

best regards
Janusz

Re: SH7724, VOU, PAL mode

[Guennadi Liakhovetski]

Hi Janusz

On Wed, 6 Jun 2012, Janusz Uzycki wrote:

> > > This is why "v4l2-ctl -s 5" used before my simple test program (modified
> > > capture example with mmap method) finally has no effect for VOU.
> > > When the test program opens video device it causes reset PAL mode in VOU
> > > and
> > > does not in TV encoder.
> > 
> > Right, this is actually a bug in the VOU driver. It didn't affect me,
> > because I was opening the device only once before all the configuration
> > and streaming. Could you create and submit a patch to save the standard in
> > driver private data and restore it on open() after the reset? I guess,
> > other configuration parameters are lost too, feel free to fix them as
> > well.
> 
> Here you are. Something like that?

Yes, thanks, something like that. But please use a proper line-wrap 
formatting and submit it as a patch, according to the rules, specified in 
Documentation/SubmittingPatches, i.e., i.e., send it as a separate email 
with an appropriate subject, patch description, your Signed-off-by.

> I avoided encoder reconfiguration (it is
> not needed) - do not call sh_vou_s_std() and in result
> v4l2_device_call_until_err().
> 
> --- sh_vou.c.orig       2012-06-06 15:58:28.785086939 +0000
> +++ sh_vou.c    2012-06-06 17:04:30.684586479 +0000
> @@ -1183,6 +1183,13 @@ static int sh_vou_open(struct file *file
>                        vou_dev->status = SH_VOU_IDLE;
>                        return ret;
>                }
> +
> +               /* restore std */
> +               if (vou_dev->std & V4L2_STD_525_60)
> +                       sh_vou_reg_ab_set(vou_dev, VOUCR,
> + sh_vou_ntsc_mode(vou_dev->pdata->bus_fmt) << 29, 7 << 29);
> +               else
> +                       sh_vou_reg_ab_set(vou_dev, VOUCR, 5 << 29, 7 << 29);
>        }
> 
>        videobuf_queue_dma_contig_init(&vou_file->vbq, &sh_vou_video_qops,

Looks like you copied this code from sh_vou_s_std(). This does fix your 
PAL problem, at least to some extent, right? But we think, that we will 
eventually have to restore more configuration, than only the video 
standard on open(), right? Thinking about that, maybe it's easier to 
actually configure the hardware not as currently done immediately, but 
inside the .vidioc_streamon() handler. Could you maybe try the patch, 
attached below (to be applied without your proposed fix)? It's only 
compile tested, so, no guarantees.

> I tested the std restoring and picture is synced/stable in PAL mode now.
> However I  have still problem after 480 line because next lines are always
> green.
> Fixing other configuration parameters seems little more complicated
> (sh_vou_s_fmt_vid_out(), sh_vou_configure_geometry()).
> 
> > > > > I noticed that VOU is limited to NTSC resolution: "Maximum > >
> > > destination
> > > > > image
> > > > > size: 720 x 240 per field".
> > > >
> > > > You mean in the datasheet?
> > > 
> > > Yes, exactly.
> > > 
> > > > I don't have it currently at hand, but I seem
> > > > to remember, that there was a bug and the VOU does actually support a >
> > > full
> > > > PAL resolution too. I'm not 100% certain, though.
> > > 
> > > OK, I will test it. Do you remember how you discovered that?
> > 
> > Asked the manufacturer company :)
> 
> OK:) I found the sentence in sh_vou.c: "Cropping scheme: max useful image is
> 720x480, and the total video area is 858x525 (NTSC) or 864x625 (PAL)." Next is
> some magic:)

BTW, I've found the commit, that addresses that PAL documentation bug: 
765fe17c4f018c019f1976455084f528474fc7f8

> > No, I'll send it to you off the list - Laurent agreed. But he also said,
> > it was a preliminary version of his yavta proram, so, you might be able to
> > use that one.
> 
> OK, the code you sent works much better than my simple video output program
> but the same problem after 480 line. I have to investigate it.
> I use yavta for frame capturing tests.
> 
> Unfortunately I will be outside the company next 2 weeks. I will have remote
> access only to my hardware so more tests are not possible then.

Ok, let's wait then. Have a good journey!

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Subject: V4L: sh_vou: move hardware configuration to .vidioc_streamon()

The V4L2 spec mandates, that drivers preserve their configuration across 
close() / open() cycles. Currently the sh_vou driver violates this 
requirement by resetting the hardware upon each open() thus losing VOU's 
configuration. This patch moves hardware configuration from respective 
ioctl()s to the .vidioc_streamon() handler to guarantee, that the 
streaming is always performed with a configured hardware.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
diff --git a/drivers/media/video/sh_vou.c b/drivers/media/video/sh_vou.c
index 6a72987..50e39f7 100644
--- a/drivers/media/video/sh_vou.c
+++ b/drivers/media/video/sh_vou.c
@@ -72,6 +72,8 @@ struct sh_vou_device {
 	struct list_head queue;
 	v4l2_std_id std;
 	int pix_idx;
+	int w_idx;
+	int h_idx;
 	struct videobuf_buffer *active;
 	enum sh_vou_status status;
 	struct mutex fop_lock;
@@ -436,15 +438,16 @@ static const unsigned char vou_scale_v_num[] = {1, 2, 4};
 static const unsigned char vou_scale_v_den[] = {1, 1, 1};
 static const unsigned char vou_scale_v_fld[] = {0, 1};
 
-static void sh_vou_configure_geometry(struct sh_vou_device *vou_dev,
-				      int pix_idx, int w_idx, int h_idx)
+static void sh_vou_configure_geometry(struct sh_vou_device *vou_dev)
 {
-	struct sh_vou_fmt *fmt = vou_fmt + pix_idx;
 	unsigned int black_left, black_top, width_max, height_max,
 		frame_in_height, frame_out_height, frame_out_top;
 	struct v4l2_rect *rect = &vou_dev->rect;
 	struct v4l2_pix_format *pix = &vou_dev->pix;
 	u32 vouvcr = 0, dsr_h, dsr_v;
+	int w_idx = vou_dev->w_idx;
+	int h_idx = vou_dev->h_idx;
+	struct sh_vou_fmt *fmt = vou_fmt + vou_dev->pix_idx;
 
 	if (vou_dev->std & V4L2_STD_525_60) {
 		width_max = 858;
@@ -754,8 +757,8 @@ static int sh_vou_s_fmt_vid_out(struct file *file, void *priv,
 
 	vou_dev->pix = *pix;
 
-	sh_vou_configure_geometry(vou_dev, pix_idx,
-				  geo.scale_idx_h, geo.scale_idx_v);
+	vou_dev->w_idx = geo.scale_idx_h;
+	vou_dev->h_idx = geo.scale_idx_v;
 
 	return 0;
 }
@@ -825,6 +828,21 @@ static int sh_vou_dqbuf(struct file *file, void *priv, struct v4l2_buffer *b)
 	return videobuf_dqbuf(&vou_file->vbq, b, file->f_flags & O_NONBLOCK);
 }
 
+static u32 sh_vou_ntsc_mode(enum sh_vou_bus_fmt bus_fmt)
+{
+	switch (bus_fmt) {
+	default:
+		pr_warning("%s(): Invalid bus-format code %d, using default 8-bit\n",
+			   __func__, bus_fmt);
+	case SH_VOU_BUS_8BIT:
+		return 1;
+	case SH_VOU_BUS_16BIT:
+		return 0;
+	case SH_VOU_BUS_BT656:
+		return 3;
+	}
+}
+
 static int sh_vou_streamon(struct file *file, void *priv,
 			   enum v4l2_buf_type buftype)
 {
@@ -835,6 +853,14 @@ static int sh_vou_streamon(struct file *file, void *priv,
 
 	dev_dbg(vou_file->vbq.dev, "%s()\n", __func__);
 
+	if (vou_dev->std & V4L2_STD_525_60)
+		sh_vou_reg_ab_set(vou_dev, VOUCR,
+			sh_vou_ntsc_mode(vou_dev->pdata->bus_fmt) << 29, 7 << 29);
+	else
+		sh_vou_reg_ab_set(vou_dev, VOUCR, 5 << 29, 7 << 29);
+
+	sh_vou_configure_geometry(vou_dev);
+
 	ret = v4l2_device_call_until_err(&vou_dev->v4l2_dev, 0,
 					 video, s_stream, 1);
 	if (ret < 0 && ret != -ENOIOCTLCMD)
@@ -863,21 +889,6 @@ static int sh_vou_streamoff(struct file *file, void *priv,
 	return 0;
 }
 
-static u32 sh_vou_ntsc_mode(enum sh_vou_bus_fmt bus_fmt)
-{
-	switch (bus_fmt) {
-	default:
-		pr_warning("%s(): Invalid bus-format code %d, using default 8-bit\n",
-			   __func__, bus_fmt);
-	case SH_VOU_BUS_8BIT:
-		return 1;
-	case SH_VOU_BUS_16BIT:
-		return 0;
-	case SH_VOU_BUS_BT656:
-		return 3;
-	}
-}
-
 static int sh_vou_s_std(struct file *file, void *priv, v4l2_std_id *std_id)
 {
 	struct video_device *vdev = video_devdata(file);
@@ -895,12 +906,6 @@ static int sh_vou_s_std(struct file *file, void *priv, v4l2_std_id *std_id)
 	if (ret < 0 && ret != -ENOIOCTLCMD)
 		return ret;
 
-	if (*std_id & V4L2_STD_525_60)
-		sh_vou_reg_ab_set(vou_dev, VOUCR,
-			sh_vou_ntsc_mode(vou_dev->pdata->bus_fmt) << 29, 7 << 29);
-	else
-		sh_vou_reg_ab_set(vou_dev, VOUCR, 5 << 29, 7 << 29);
-
 	vou_dev->std = *std_id;
 
 	return 0;
@@ -1010,8 +1015,8 @@ static int sh_vou_s_crop(struct file *file, void *fh, struct v4l2_crop *a)
 	pix->width = geo.in_width;
 	pix->height = geo.in_height;
 
-	sh_vou_configure_geometry(vou_dev, vou_dev->pix_idx,
-				  geo.scale_idx_h, geo.scale_idx_v);
+	vou_dev->w_idx = geo.scale_idx_h;
+	vou_dev->h_idx = geo.scale_idx_v;
 
 	return 0;
 }

Re: SH7724, VOU, PAL mode

[Laurent Pinchart]

Hi Guennadi,

On Tuesday 05 June 2012 17:47:50 Guennadi Liakhovetski wrote:
> On Mon, 4 Jun 2012, Janusz Uzycki wrote:

[snip]

> > Do you have any test program for video v4l2 output?
> You can use gstreamer, e.g.:
> 
> gst-launch -v filesrc location=x.avi ! decodebin ! ffmpegcolorspace ! \
> video/x-raw-rgb,bpp=24 ! v4l2sink device=/dev/video0 tv-norm=PAL-B
> 
> I also used a (possibly modified) program by Laurent (cc'ed) which either
> I - with his agreement - can re-send to you, or maybe he'd send you the
> original.

Are you talking about yavta ? If so that's available at 
http://git.ideasonboard.org/, available under the GPL (you're obviously free 
to redistribute your modifications :-)).

-- 
Regards,

Laurent Pinchart